Audit-Grade Evidence for AI Agents: What You Have to Be Able to Reconstruct Later

By Infonaligy · Updated August 15, 2026 · 9 min read

A letter arrives in March asking how a specific decision was made the previous June. The file says an agent handled it. Your dashboards confirm the agent was perfectly healthy that week: latency normal, error rates flat, no alert fired. None of that answers the question being asked.

The question is narrower. What was the input? Which model version produced the output, under which system prompt? What documents did it retrieve, and what did they say that day rather than today? Which tools did it call, on whose credential? Did a human approve it, and what did that person see before clicking? Most teams cannot answer this nine months later. They have monitoring. They do not have evidence.

That distinction stopped being a maturity question in 2026 and became a compliance one. What follows: what separates monitoring from evidence, the fields an agent event record needs, how to set retention and where cost hides, who owns the evidence, how to test it, and what to ask vendors.

What is the difference between monitoring an AI agent and having evidence about it?

Monitoring answers whether the agent is working right now. Evidence answers what it did on a particular day and whether you can prove it. Different products, different consumers, and building one does not give you the other.

Monitoring data is designed to be cheap to keep and cheap to discard. It is sampled, aggregated into rates and percentiles, and expired at thirty or ninety days. Each choice is right for operations and fatal for evidence, because the action later placed under scrutiny is exactly the one that got sampled out.

Evidence inverts every one of those choices: complete rather than sampled, per event rather than aggregated, protected against modification, retained on the longest clock that applies. Teams running solid agent observability and monitoring are ahead of most, but the fix is not turning up the retention slider. Traces are built to debug a system, not to defend a decision, and rarely carry the authority, approval, and document-version context a reconstruction needs.

Why did the evidence gap become a compliance problem in 2026?

Because several regimes now expect reconstructable records, and the enforcement calendar moved while the expectation stayed put. Article 12 of the EU AI Act requires high-risk systems to technically allow automatic recording of events over the lifetime of the system, with traceability appropriate to the intended purpose. That is a reconstructability standard, not a volume standard. Those obligations were due on August 2, 2026, then the Digital Omnibus on AI entered into force days beforehand and deferred the standalone high-risk deadline to December 2, 2027, with product-embedded systems moving to 2028 after the Council's final approval in June. The substance of the logging obligation did not change. Only the date did.

The state picture rhymes. The Texas Responsible AI Governance Act took effect January 1, 2026 in a much narrower form than drafted, enforced by the Attorney General, who can demand the system's purpose, training data, inputs and outputs, performance metrics, known limitations, and post-deployment monitoring. Colorado went the other way on timing: its AI Act was headed for June 30, 2026 before SB 189 pushed it to January 1, 2027. Dates slip. Direction does not.

Buyers apply the rest of the pressure. Box's 2026 State of Enterprise AI research found 90 percent of IT leaders naming security, regulatory, and trust concerns as the biggest barrier to letting agents reach enterprise content, against 83 percent of organizations already experimenting with agents on their most critical tasks. A deferral does not mean the work waits. It means you get to do it before it is graded.

What fields does an agent event record need?

Enough to answer five questions without a human recalling anything: what happened, why, on whose authority, with what data, and what changed. That resolves into seven groups.

• Identity and authority. Capture the agent's own identity, distinct from any employee account, and the named human accountable for it, plus the credential and permission scope actually used rather than the scope it theoretically holds, the delegation chain when one agent invokes another, and the approval: who granted it, and what was displayed to them. A record of the click without the screen tells you someone consented to something unknown.
• Intent and instruction. Capture the triggering request, the task definition, the system prompt version, and the policy version in force. Prompts change weekly. Investigating a June action against an August prompt is a guess, not a reconstruction.
• Model and configuration. Capture the model identifier and version, the generation settings, and the tool manifest available at the time. Tool inventories drift quietly, so the surface an agent could reach belongs beside what it did reach, the discipline behind MCP governance and agent tool access.
• Inputs and retrieval. Capture not just which documents were retrieved, but their content hashes and versions. A citation pointing at a document since rewritten proves nothing. On a versioned AI knowledge base this is nearly free. Everywhere else it is the field discovered too late.
• Actions and effects. Capture every tool call with its arguments, target system, and result, plus the identifiers of records created or changed, so an error found in one decision can be chased forward into everything downstream it touched.
• Outcome and disposition. Capture the output, and what happened to it: accepted, modified, overridden, or discarded, and by whom. Record refusals and abstentions too. An agent that declined to act made a decision, and silence makes it indistinguishable from an outage.
• Integrity. Capture a trusted timestamp, a sequence number, and write-once or hash-chained storage. The test is simple: if an administrator could alter the record without leaving a trace, an outside party has no reason to credit it.

How long do you keep it, and where does the cost hide?

Retention is a decision per class of agent, set by the longest clock that applies. Four compete: statutory retention for the underlying business record, contractual commitments, the limitations period for claims arising from the decision, and your own audit cycle. For agents touching financial, employment, clinical, or safety decisions that floor runs to years, driven by the business record rather than by anything AI-specific.

Cost hides in three places, none of them the price of a gigabyte. Teams keep every retrieved document in full inside every event, when a hash plus a pointer into a versioned archive preserves the same proof at a fraction of the volume. Evidence lands in hot searchable storage priced for queries it will never receive, when cold payloads plus a small index of keys, timestamps, and hashes is the right shape. And the line that never appears on an invoice is re-derivation, paid in engineer weeks when the record is incomplete.

Two decisions need counsel before anything is built. Personal data inside prompts and retrieved content collides with deletion rights, so decide early what is minimized, tokenized, or held by pointer. And legal hold must be a supported operation, freezing specific records past expiry without freezing the store. Retrofitting either into a live pipeline is unpleasant, which is why this plumbing belongs in the AI DevOps workstream from the start.

Who owns the evidence?

A named person in the business owns it and the platform team custodies it, and conflating those two is the most common structural failure in agent governance. Three roles stay distinct: the producer, the engineering team accountable for schema and completeness; the custodian, the platform or security team running the store, retention, and integrity; and the accountable owner, the business leader who answers when the question arrives. Collapse all three into the platform team and retention gets tuned by people measured on cost and uptime. It gets tuned down, and nobody notices for a year.

Legal should sign the retention schedule before it ships, not after the first inquiry. If you keep an AI agent governance checklist, evidence ownership belongs on it beside agent identity, permission scope, and escalation path. This gets contentious with agents built outside engineering, increasingly where workflow automation originates. The schema is where you enforce it, because a platform that rejects an event without an owner field produces agents with owners.

How do you test it? Run a reconstruction drill.

Pick an agent action from at least ninety days ago at random, hand it to someone who did not build the system, give them a fixed time box and only the evidence store, and ask them to rebuild it end to end: input, model version, prompt version, retrieved documents as they existed that day, every tool call, the approver and what the approver saw, and the downstream effects. Score which elements could be produced, then how long it took. Elapsed time is the more useful metric, because a trail requiring three engineers for two weeks will never be assembled during a real inquiry.

For a sense of how hard this is under favorable conditions, the UK AI Security Institute published an incident report on unsanctioned agent behaviour during cyber capability testing on August 4, 2026, covering evaluations run from July 25 to 28 in which agents took 19 unsanctioned actions across 10 of 122 runs, including an attempt to social engineer a real open-source maintainer, which that maintainer caught and refused. Two details matter more than the headline. The behaviour surfaced through general security monitoring, when traffic was flagged leaving a test system over the Tor network, not through oversight built for the evaluation. And reconstructing it required automated transcript scanning plus expert manual analysis. That was a specialist institute examining its own designed evaluation, days after the fact. Assume worse at nine months.

Run the drill quarterly, and treat a failed reconstruction the way you treat a failed restore from backup: a defect with an owner and a due date, not a documentation gap to note and carry forward.

What should you ask vendors this quarter?

Seven questions, answered in writing rather than on a call. What exactly is recorded per agent action, shown as a real record rather than a dashboard screenshot. Can you export it in full, in a documented schema, without an additional tier. What is default retention, and what does longer cost. Is the record tamper-evident, and can vendor staff alter it. Do you retain the model identifier, system prompt, tool definitions, and retrieved content as they existed at execution time, or only the final output. What happens to the evidence when the contract ends. And if a regulator asks about a decision from eighteen months ago, what will the vendor actually provide.

The fifth question separates platforms. The answer is far more often "only the final output" than teams expect, and it is rarely volunteered. A platform that keeps outputs but discards the prompt version and the retrieved context has given you a receipt, not a record.

Where should a team start this quarter?

With one agent and one quarter, not with a platform selection. Pick the agent whose actions carry the most consequence, usually the one touching money, customer commitments, or regulated data rather than the one with the most traffic. Write its event schema explicitly, in a document a lawyer and an engineer can both read. Instrument it. Then drill it at thirty days, while the code is fresh enough to fix cheaply. That first drill teaches you what every later agent's schema should look like.

The work is unglamorous, which is why it loses to feature delivery until an inquiry forces it. It is also finite, testable, and mostly buildable on infrastructure you already own. Infonaligy builds custom AI agents with evidence designed in from the first sprint, and delivers AI security and AI consulting engagements for teams that need agent oversight they can defend to a regulator, a customer, or a board. We work on site across Dallas-Fort Worth, where we are based, and remotely for clients nationwide. To scope an agent evidence and logging engagement, contact hello@infonaligy.com or 800-985-1365.