Audit trails in practice

An audit trail is the part of governance you will be judged on when something goes wrong. Everything else, the ownership, the scoped access, the approval gates, is invisible until a customer complains, a regulator asks a question, or your own board wants to know what the AI actually did last quarter. At that moment you either produce a record or you produce a story. This lesson is about building the record so you never have to tell the story.

The mistake most teams make is treating logging as something they will add later, once the system is working. By the time “later” arrives, the decisions you needed to capture have already happened and cannot be recovered. Audit trails are a build-time decision, not a retrofit. Here is how to get it right the first time.

What to log on every AI action

An audit entry answers a simple question months after the fact: what did the system do, on what basis, and who stood behind it. To answer that, each entry needs to capture the same set of fields every time. Missing one field usually turns out to be the field you needed.

Log these on every meaningful action:

• Inputs the model saw. The prompt or instruction, and a reference to the specific records or documents it was given. For sensitive material, store a hash or a record ID rather than the raw text, so the log itself does not become a new copy of the data you are trying to protect.
• Outputs the model produced. The result it returned, or a hash of it. If the output was edited before use, capture both the original draft and the final version. The gap between those two is often the most useful thing in the whole log.
• Model and version. Which model ran, at what version, with what configuration. A model that behaved correctly in March and incorrectly in June may have been quietly updated between them, and you cannot investigate that without the version stamp.
• Approver. For any gated action, the identity of the person who reviewed it, whether they approved or rejected, whether they overrode the model, and their rationale if they gave one. “The AI did it” is not an answer an auditor accepts. “Priya reviewed this draft and approved it at 2:14 on the ninth” is.
• Timestamp. When it happened, in a single consistent time zone, ideally synchronized to a trusted source. Logs with unreliable timestamps have weak standing, because the whole point of a record is to prove the order in which things occurred.
• Which gates fired. Every policy check that evaluated the action, including the ones that passed silently and the ones that blocked it. A blocked action is evidence that your controls worked. You want that on the record just as much as the approvals.

If you capture these six every time, you can reconstruct almost any decision. If you capture “a request was made and a response was returned,” which is what a standard server log gives you, you cannot.

How to make the record reconstructable later

Capturing fields is necessary but not sufficient. The test of an audit trail is not whether it exists, it is whether someone who was not in the room can rebuild what happened from it alone, six months later, without asking anyone. A few practices make that possible.

Write the log entry before the output is used, not after. If the system logs only on success, then any action that failed partway through, exactly the kind you most need to investigate, leaves no trace. Write the record at the moment the action is taken, so it exists even if the downstream step falls over.

Keep the log in one place, not scattered across systems. If reconstructing a single decision means pulling from the model provider’s logs, your application logs, and someone’s inbox, you do not have an audit trail. You have raw material for one, which is a different and much more expensive thing. Route every entry into a single authoritative store.

Make entries tamper-evident. A log that can be silently edited proves nothing, because a skeptical auditor has no way to know it was not adjusted after the incident. The two standard approaches are a hash chain, where each entry includes a fingerprint of the previous one so any alteration breaks the sequence and becomes visible, and write-once storage, where entries physically cannot be overwritten within their retention window. Neither is expensive when designed in from the start. Both are painful to add after a gap has already been found.

Record enough context to interpret the entry without insider knowledge. An entry that says “record 4471 processed” is useless to an auditor who does not know what record 4471 was or why it mattered. Capture the data classification, the workflow it belonged to, and the reason the action was taken, so the entry stands on its own.

Why reconstruction after the fact does not work

Some teams plan to assemble evidence only if they are ever asked. This fails reliably, and it is worth understanding why so you do not talk yourself into it.

The context decays. The person who reviewed a decision has since reviewed hundreds more, and their memory of any single one is not a record. The infrastructure logs, meanwhile, captured that a call was made but not the exact prompt, the model version, or which gates fired, which are precisely the details a real investigation turns on. And auditors increasingly discount records assembled after the fact, because a document created in response to a question does not carry the same weight as one created at the time of the event. The value of a timestamp is that it was written before anyone knew it would matter.

The practical consequence is simple. The cheapest time to capture an audit record is the moment the action happens. Every other time is more expensive and less trustworthy.

How long to keep it

Retention is a policy decision, and it should be made per workflow rather than as a single blanket rule, because different data carries different obligations.

• Match the strictest rule that applies to the data. If a workflow touches health records, records-retention obligations for that data can run to several years, and your AI logs about that data inherit the same horizon. Financial and legal material carry their own multi-year expectations. Do not set retention shorter than the underlying record it describes.
• Set a floor even for low-stakes workflows. A year is a reasonable baseline for anything you might need to explain to a customer or an auditor, and it costs very little to keep structured logs that long.
• Make deletion deliberate, not accidental. Logs should expire because a policy said so, on a schedule you can point to, not because a disk filled up. Enforceable retention includes enforceable deletion.

Write the retention period down alongside the workflow, so the answer to “how long do we keep this” is a documented decision rather than an argument you have during an audit.

How it maps to proving what the AI did

The reason all of this matters comes down to one distinction. A policy document that says “our AI is governed” establishes intent. An audit trail establishes fact. When an auditor asks what happened, intent is not evidence. The log is.

A complete trail lets you answer the questions that actually get asked. Which records did the system touch, and were any of them ones it should not have. Who approved the output that reached the customer. What did the model assert, and on what basis. Did any control ever block a risky action, and can you show it. Every one of those is answerable in minutes if you logged the six fields, and answerable only with a painful reconstruction, or not at all, if you did not.

The goal is to be able to hand over the record without flinching. Not a curated summary, the actual log, because you designed it from the start to be something you could show. That confidence is the entire point of building the trail.

Where this fits

This lesson is the practical companion to the risk tiers and approval gates you set earlier in the course. Tiers decide which actions need a human; the audit trail is what proves the human was there. Next you will look at finding the ungoverned AI already running in the business, where the same logging discipline gets applied to tools you did not deploy on purpose. If you want to see what continuous, build-time logging looks like without assembling it by hand, the Command Center build writes a structured entry for every governed action as the system runs, so the record exists before you ever need it. The free tools on the site are a reasonable place to sketch your own logging fields before you commit them to a system.