An AI audit trail is a per-decision record of what an AI system did and who was accountable for it. Six fields: the input the system acted on, the model and version that produced the output, the output itself, the human who reviewed it, when, and whether that human agreed or overrode the model. Everything else is elaboration. If you can produce those six fields for a decision made eight months ago, you have an audit trail. If you can only produce a server log showing the service was up, you do not.
The distinction matters because the two get conflated in procurement. Engineering teams hear "audit trail" and point at observability — request volumes, latency, error rates, model invocation counts. All of that is real and none of it answers the question an auditor is asking, which is not did the system run but what did it decide, and who signed it.
§ I · What an auditor actually asks for
The request, when it arrives, is narrow and specific. It is usually some version of: here is a decision that affected a named person on a named date, show me how it was made.
Each sub-question inside it maps to a field.
- Was this system in scope? Answered by the registry, not the log. If the system is not on a list with a named owner, the audit stops here and becomes a much longer conversation.
- Which model produced this output? Not "the vendor's model" or "the credit model" — the version identifier. Vendors update models. Our own published account of a thirty-day registry build turned up an HR screening tool whose vendor had re-weighted the underlying model six months earlier without notifying anyone. The team had been treating the outputs as stable inputs to hiring decisions throughout.
- What did the system see? The input, or a reference to it sufficient to reconstruct it. Storing a pointer to a record that has since been overwritten is a common and expensive mistake.
- Who reviewed it? A person, named. The EU AI Act is explicit that deployers of high-risk systems must assign human oversight to natural persons with the necessary competence, training and authority — Article 26(2). "The operations team" is not a natural person.
- Did the human agree? In our experience this is the field most likely to be missing, and the one that does the most work. A trail full of approvals with no overrides tells an auditor either that the model is perfect or that the review is theatre, and they will assume the second.
§ II · What to log per decision
The minimum viable schema is short enough to fit in a table column set. Six fields, plus two that are cheap to add and worth having.
- Decision identifier — stable, and resolvable back to the affected person or transaction.
- Timestamp — of the decision, and separately of the human review if they differ.
- System and model version — the identifier the vendor or your own registry uses, and the date that version came into service.
- Input reference — enough to reconstruct what the system acted on, retained for as long as the log itself.
- Output — the raw output, including the score or ranking, not just the resulting action.
- Reviewer and disposition — the named person, and one of: accepted, overridden, escalated, not reviewed.
The two worth adding: the reason given for an override, in free text, because that field becomes your bias-monitoring dataset for free; and the policy version in force at the time, because a decision made under last quarter's rules has to be judged against last quarter's rules.
The EU AI Act's own floor is instructive on how concrete this gets. For biometric identification systems under Annex III point 1(a), Article 12(3) specifies the logging minimum directly: the start and end date and time of each use, the reference database the input was checked against, the input data for which the search produced a match, and the identification of the natural persons involved in verifying the result. That is a field list, written into a regulation. The structure generalises.
§ III · Retention, and what the law actually says
Article 12(1) of the EU AI Act requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(2) says what those logs have to be good enough to do: identify situations in which the system presents a risk or has been substantially modified, support post-market monitoring under Article 72, and let deployers monitor operation under Article 26(5). Capability, purpose, then retention.
Retention appears twice, symmetrically. Article 19(1) obliges providers to keep the Article 12(1) logs to the extent they are under their control, for a period appropriate to the intended purpose and "of at least six months." Article 26(6) places the identical six-month floor on deployers, for the logs under their control. Providers and deployers that are financial institutions subject to Union financial services law maintain the logs instead as part of the documentation that law already requires — which for most regulated firms means the retention period is set by their existing books-and-records regime, not by the AI Act.
The dates are the part worth writing down. Articles 12, 19 and 26 come into force on 2 December 2027 for high-risk systems under Annex III, and 2 August 2028 for high-risk AI covered by the product legislation in Annex I. Those are later than the 2024-vintage compliance plans assumed, and the gap reads easily as permission to defer. It is the wrong thing to defer, because a log is the one compliance artefact that cannot be produced retroactively. A policy can be written in a week. A year of decision history cannot.
In the United States there is no equivalent single instrument, and the state picture moved sharply this year. Colorado — which had enacted the first comprehensive state AI law — repealed it. Governor Polis signed SB 26-189 on 14 May 2026, replacing SB 24-205 before it ever took effect, and the new framework applies from 1 January 2027. The replacement drops the duty of care, the mandatory algorithmic impact assessment and the deployer risk-management programme. What it puts in their place is closer to the subject of this piece: disclosure obligations, a three-year record-keeping requirement, and a sixty-day pre-enforcement cure period administered by the Attorney General that sunsets on 1 January 2030. Secondary tracking of the statute describes the retained records as those reasonably necessary to demonstrate compliance, including covered-ADMT version identifiers, changelogs, and documentation of material mitigation changes.
Read the two regimes together and the operational conclusion is the same in both: version identifiers and a per-decision review record, kept for years rather than weeks. Colorado also requires deployers to explain an adverse outcome within thirty days and to offer meaningful human review where technically feasible — neither of which is answerable without a trail that records who reviewed what.
§ IV · Build or buy, honestly
Count decisions first. The build-versus-buy question resolves almost entirely on volume and on who is physically capable of writing the record.
If a system makes tens or low hundreds of consequential decisions a month, and a named person already looks at them, the trail is a set of columns added to whatever that person already touches — the ticket, the case file, the spreadsheet. It is defensible because it is complete, and it is complete because filling it in is part of a job someone is already doing. We have argued elsewhere on this site that the registry's value is the discipline rather than the database, and the same holds here: the form does not determine the outcome.
Buy when one of two things is true. Either the decision volume makes human-written records impossible, so the log has to be emitted by the system itself — which is what Article 12(1)'s "technically allow" language is pointing at. Or the logs sit across enough systems that reconciling them by hand would take longer than the thirty-day window Colorado allows for an adverse-outcome explanation.
The honest caveat on buying: the most expensive failure we have seen was not an absent platform but a purchased one that was never updated after implementation. A governance tool records what someone puts into it. If no one owns the input, a six-figure platform produces a worse audit trail than a maintained spreadsheet, and costs more to explain.
Two things are worth doing before either decision. Put the six fields in writing and see which ones your systems can already produce — that exercise usually takes an afternoon and reprices the whole project. Then check the retention on the input data, because a log that references records your warehouse purges at ninety days has a six-month retention obligation it cannot meet.
If you want that walked through against your own estate, that is what our AI governance advisory practice does.