An AI audit trail requirement is not a log format. It is a reconstruction requirement. The question a regulator, court, or governance review asks is whether a specific decision can be reconstructed and shown to have been appropriate, and whether the system was approved to make it. Everything you capture should be working backwards from that.
This is why "what should we log?" is the wrong opening question. It produces a list of fields that are easy to collect, optimised for engineers, and silent on whether a decision was governed. The right opening question is what a complete audit of a decision would need to see. Answer that, and the fields follow. The full treatment of why this distinction matters is set out in the inference audit trail, and the difference from ordinary logging in why logs aren't evidence. This piece is the specification.
What a Complete Record Has to Contain
A record built for reconstruction has to carry the governing context that operational logs leave out. For most production systems that means the following.
The model and training-data version in force at the time of inference. Behaviour changes between versions, so a record that does not pin the version down cannot support any judgement about the decision: you would be assessing an output without knowing which system produced it.
The input context, including any prior context that shaped the output. For conversational and agentic systems the immediate prompt is rarely the whole input. The trail has to capture enough of the surrounding context to show what the output was actually responding to.
The policy the model was approved to implement. An output can only be judged against the rule it was meant to follow, so the trail has to record the governing policy in force at the time. Without it, a reviewer can confirm that an output occurred but not whether it should have.
The output, with enough surrounding context to judge whether it fell within the expected distribution. A bare output string supports no assessment. The record has to make it possible to ask whether this was a reasonable output for this input under this policy.
The downstream action the decision triggered. The consequence is often where the risk actually lands. A record that stops at the model's output and omits what happened next cannot show whether a wrong output became a wrong action.
The defining question is what a complete audit of the decision would require. If you cannot describe that, you are not yet ready to decide what to capture.
Mapping to the Standards You'll Be Audited Against
The frameworks converge on reconstruction without prescribing how. The EU AI Act requires high-risk systems to keep automatic records of events across their lifetime so that their functioning can be traced. ISO/IEC 42001 and the NIST AI Risk Management Framework expect traceability and documented evidence that the intended controls were actually applied, not merely defined.
None of them gives you a schema. They state the outcome, that a specific decision can be reconstructed and shown to have been governed, and leave the data architecture to you. An organisation that reads these as a logging obligation tends to produce comprehensive logs that still cannot answer the reconstruction question. An organisation that reads them as a reconstruction obligation captures the governing context from the start, and finds that the records a regulator asks for are generated as a by-product of running the system.
The Design Test
Before deciding what to capture for any system, state what a reviewer would need to reconstruct one of its decisions and judge whether it was appropriate. If that statement is clear, the capture requirements are clear, and any field that does not serve the reconstruction can be left to operational logging. If the statement is vague, no amount of logging volume will fix it, because the gap is in the design, not the storage.
Agentic systems sharpen the test further, because the trail has to reconstruct each step an agent took rather than only its final output. That is its own specification, covered in audit trails for AI agents.
Frequently Asked Questions
What should an AI audit trail capture?
An AI audit trail should capture what a regulator or governance review would need to reconstruct and assess a decision: the model and training-data version in force at the time, the input context including any prior context, the policy the model was approved to implement, the output with enough surrounding context to judge whether it was within the expected distribution, and the downstream action the decision triggered. The defining question is what a complete audit of the decision would require, not what is convenient to log.
What do AI audit trail requirements look like under the EU AI Act and ISO 42001?
The EU AI Act requires high-risk AI systems to keep automatic records of events over their lifetime so that their functioning can be traced. ISO/IEC 42001 and the NIST AI Risk Management Framework expect traceability and documented evidence that controls were applied. None of them prescribe a log format. They require that a specific decision can be reconstructed and shown to have been governed, which is a reconstruction requirement, not a logging one.
How long should AI audit trail records be retained?
Retention should be set by the longest applicable obligation, which is usually regulatory or contractual rather than operational. High-risk systems under the EU AI Act carry multi-year record-keeping expectations, and litigation or sector rules can extend that further. The practical test is whether the record will still exist, and still be intelligible, when a decision is questioned years after it was made.