Proving an AI Agent's Work to an Auditor
KEY TAKEAWAYS
- An auditor does not ask whether the agent is accurate. They ask how one specific number was produced, who was accountable, and how they can know the log was not edited afterwards.
- Those three questions map onto three parts of one record: the evidence actually used, the decision plus any human review, and a hash chain that makes tampering visible.
- Evidence has to be written before the answer exists. A citation attached after the fact proves the agent could find a source, not that it used one.
- Retention is set by law, not by your storage bill. EU AI Act Article 19 puts a floor of at least six months on high-risk system logs, and US broker-dealer records under Rule 17a-4 run to six years.
- Append, never edit. A correction is a second record, and an audit trail that can be updated in place is not an audit trail.
NOT LEGAL ADVICE
Not legal advice. This is an engineering write-up from an AI and smart-contract engineer, current as of 3 August 2026. Whether a given rule applies to your system is a question for a qualified lawyer. Every legal requirement below is linked to its source so you can check it yourself.
The question that ends most AI pilots
The demo goes well. The pilot goes well. Then someone from audit picks one line out of a report the agent produced, points at it, and asks how that number got there.
That is the moment most AI projects in regulated companies quietly stop. Not because the system was wrong, but because nobody can reconstruct one specific decision six weeks after it was made.
Observability does not save you here. Observability is built for the team that owns the system. An audit record is built for someone who does not trust you, and the difference shows up in every design choice. So instead of describing what I instrument, here is the record itself.
The record, field by field
One record per agent action. Not per session, not per user question. Per action, because an action is the unit an auditor points at.
It is append-only. A correction never edits a row, it writes another one. And every field below exists because a specific question was asked of me and the answer was not in the logs.
The legal spine for this is short. The EU AI Act requires high-risk systems to technically allow the automatic recording of events over the lifetime of the system, which is Article 12, record-keeping. It says the logging has to exist. It does not hand you a schema, so this is mine.
Sortable unique id. Ordering is part of the evidence, so use something time-ordered rather than a random uuid.
ISO-8601 UTC. When the action happened, never when the row was written. The gap between those two matters to an auditor.
Who took this action. Human corrections live in the same table as agent actions, which is what makes the sequence readable.
Which deployed agent, versioned. Not a display name, because the name outlives the behaviour.
The business object this belongs to: the statement line, the invoice, the report. This is what the auditor points at.
The exact model string sent to the provider. Models are retired and replaced, and the answer belongs to the one that produced it.
Content hash of the prompt, not a human label. Labels drift, hashes do not.
SHA-256 of the exact input. Proves what was asked without storing a second copy of sensitive data.
Per source actually used: docId, sha256, page, byteRange. Written at retrieval time, before any answer exists.
Every gate that ran, with its result: numeric tie-out, entailment, policy. Failures are recorded, not just passes.
The routing outcome as a first-class value. Abstaining is a result, not an error.
Reviewer, timestamp, verdict, and free-text reason. Null is a valid and meaningful answer.
Which rule sets the clock on this row. Storing it makes deletion a policy decision instead of a cron job.
Each record hashes the one before it. Alter any row and every hash after it stops matching.
Two of these fields carry more weight than the rest, and both are about ordering rather than content.
evidence is written when the documents are retrieved, before the model produces anything. Attach citations after the answer and you have proved the system can find a plausible source, which is not the claim under test. And chain makes the log tamper-evident: an auditor can recompute it in front of you, which is a much stronger position than asking them to trust your access controls.
{
"recordId": "01K4R7QW3M8ZC2VJ9F0X6TBNPD",
"occurredAt": "2026-08-03T06:14:22.118Z",
"actor": "agent",
"agentId": "recon-agent@4.2.0",
"taskRef": "stmt:2026-07/line-0412",
"modelId": "claude-haiku-4-5-20251001",
"promptVersion": "sha256:9f1c…a07e",
"inputDigest": "sha256:3b8d…41c2",
"evidence": [
{ "docId": "inv-2026-07-0188", "sha256": "sha256:c41a…7b90", "page": 1, "byteRange": [2048, 2560] },
{ "docId": "bank-stmt-2026-07", "sha256": "sha256:0d72…e3f1", "page": 4, "byteRange": [8192, 8448] }
],
"checks": [
{ "name": "numeric_tie_out", "passed": false, "detail": "delta 0.02 EUR" },
{ "name": "entailment", "passed": true, "detail": "supported by inv-2026-07-0188" }
],
"decision": "escalate",
"humanReview": null,
"retentionClass": "sec-17a4-a-6y",
"chain": {
"prevHash": "sha256:77ab…10de",
"recordHash": "sha256:e908…5c33"
}
}One real-shaped record: an escalation. The tie-out failed by two cents, so no answer was produced and a person was asked. Note that the failure is stored with the same status as a success.
One reconciliation, traced end to end
Here is that record being produced, start to finish, for a single bank-statement line. This is the reconciliation workflow, so the numbers stay qualitative and the interesting part is where the writes happen.
Watch the order. The evidence is written before the decision, and the human correction becomes a second record rather than an edit to the first.
The workflow itself, and why this agent was allowed to refuse in the first place, is the bank reconciliation build.
Three auditor questions, three fields
In practice the interrogation is short. Auditors are not trying to understand your architecture, they are trying to falsify one claim. Three questions do most of the work, and each one lands on a specific field.
The third question is the one engineers underestimate, and it has a precise regulatory answer in the US. Under SEC Rule 17a-4(f), an electronic recordkeeping system must either preserve records in a non-rewriteable, non-erasable format, or maintain a complete time-stamped audit trail of modifications and deletions. A hash chain is one part of the second option, not the whole of it: it makes tampering evident, but on its own it does not retain what a deleted row said, record who changed it, or let you recreate the original. You still need the retained prior values, the actor identity, and the retention window around it. Ask your counsel which option you are actually claiming.
The retrieval side of question one, verifying a citation instead of merely attaching one, has its own deep dive.
How long you have to keep it
The last field, retentionClass, is the one engineers leave until an emergency. Deletion is the only irreversible operation in this system, so it should be a policy decision stored on the row, not a cron job someone wrote in a hurry.
Which clock applies is a legal question, and the answer depends on what the record supports rather than on what produced it. The shape looks like this.
Both retention rules above are worth reading in the original rather than in a vendor summary: EU AI Act Article 19 for the six-month floor on high-risk system logs, and the SEC rule linked in the previous section for the six-year and three-year tiers.
What the record costs, and what it buys
The objection I hear is that this is heavy. It is not, and the cost is not where people expect.
Mechanically it is one insert per action and a hash. The real cost is discipline: you cannot retrofit it. Evidence written after the answer is not evidence, and a log you can update in place is not an audit trail, so the ordering has to be right from the first commit.
The observability version
The audit version
How a system climbs from a demo to something defensible in front of a regulator is the whole subject of the FDE Evidence Ladder, and the Article-by-Article engineering translation of the AI Act is episode five.
For the wider approach this record belongs to, AI in regulated finance is the hub: evidence-grounded retrieval, containment, machine-enforced compliance, and evals that gate a release.
FAQ
Reconstruction, not reassurance. They pick one output, usually the one that looks odd, and ask you to rebuild how it was produced: what evidence was used, what checks ran, what the system decided, who signed off, and proof that the record of all that has not been altered since. If you can do that for any single action on demand, you are in good shape. If you can only show aggregate accuracy, you are not.
No, and the two get confused constantly. Observability is built for the team that owns the system: it is sampled, it expires, and it can usually be edited or backfilled. An audit record is built for someone who does not trust you: complete for the actions in scope, retained for a period the law sets, and tamper-evident. You can build one on top of the other, but a tracing dashboard is not one by default.
It depends on which rule catches you, and it is a lawyer's question rather than an engineer's. As a shape: EU AI Act Article 19 requires providers of high-risk systems to keep automatically generated logs for a period appropriate to the purpose and at least six months, unless other Union or national law says otherwise. US broker-dealer records under SEC Rule 17a-4 run to six years for some categories and three for others, the first two years in an easily accessible place. Build for the longest rule that could apply to you.
You can, and it will not survive scrutiny. A citation attached after the answer proves the system can find a plausible supporting document, which is a different claim from the one an auditor is testing. The evidence has to be captured at the moment it is retrieved, with a hash of the document and the exact span used, before any answer exists. That ordering is the whole difference between a citation and evidence.
Append-only writes plus a hash chain: each record contains the hash of the record before it, so altering any row breaks every hash after it and the break is trivial to demonstrate. Be careful how you describe that to a regulator, though. Under SEC Rule 17a-4 an electronic recordkeeping system must either preserve records in a non-rewriteable format or maintain a complete time-stamped audit trail of modifications and deletions. The chain gives you tamper evidence, which is one ingredient of the second option. It does not by itself keep what a deleted row said, record who made the change, or let you recreate the original record, and those are part of the requirement too.
Enjoyed this post?
Get more like it in your inbox every Tuesday.