An audit question is asked about one transaction
The question that matters is rarely about a model. It is about a specific case: why was this credit note issued on this date, what did the system see when it made the decision, who confirmed it, and what did the business do next. Answering it should not require a week of reconstruction from colleagues who have since moved on.
In most organisations it does require that week. The evidence exists, but it is spread across a workflow log, a message thread, a model trace, a database change and somebody's memory, joined together only by a transaction reference never written to all of them. Nothing is missing individually; the trail simply has no joints.
Seven things have to be traceable, and most systems record three
A defensible trail for an AI-assisted process connects seven elements under one identifier. This is the full list, and it is deliberately not a list of logs.
| Element | What has to be captured | Why it is needed |
|---|---|---|
| Input | The request or event that started the work, as received | Without it the trail has no beginning |
| Source data | The records read, their version, and the time of reading | To explain what the system actually saw |
| Output | What was produced, and by which version of the system | To separate the answer from later edits to it |
| Approval | Who confirmed, when, on what evidence, under which rule | To show the point of human accountability |
| System action | Every change written, with its target and value | To reconstruct the effect, not just the intention |
| Exception | Where the routine path was abandoned, and why | Because the exceptions are where risk concentrates |
| Outcome | What the business did afterwards, including corrections | To link a decision to its consequence |
The two most commonly missed are the third and the sixth. Output records are usually kept but not versioned, so it is impossible to say whether the thing that was approved is the thing that was acted on. Exceptions are usually handled in a separate channel and never reconciled, which is precisely where a reviewer will look.
Source data without a version is not evidence
Most systems record which record was used, not which version of it. The difference decides whether the trail can support a conclusion. If the customer record has since been amended, a trail that names the record without naming the version can only show what the record says now, which is not what the system read at the time.
Capturing a version does not require a technical answer. It requires that the source of truth keeps history, that the identifier used in the trail is the one the source uses, and that the read is logged with a timestamp. Where a source keeps no history at all, the honest conclusion is that the process cannot currently be audited to that standard. Making records joinable across systems is covered in business ontology explained.
The record of an action is not the record of a decision
Approval and action are separate events and are frequently confused. A log saying a case was approved at one time and a record changed at another does not establish that the approval applied to that change, unless both carry the same identifier for the decision. Where they differ, a reviewer is left inferring, and inference is what an assurance exercise is designed to prevent.
This is also where the difference between a proposal and a decision becomes visible. An agent that proposes an amendment and a person who accepts it have produced one decision with two actors, and the trail should show both the recommendation and the acceptance, because on review the interesting question is often whether the human had enough information to accept it.
Exceptions are where the audit trail is thinnest
The routine path produces logs because the system was built to produce them. The exception path is handled by a person, usually at the end of a long day, usually with a note in a queue and a message to a colleague. This is where the money and the risk sit, and it is where a reviewer finds nothing. Fixing it means treating the exception as a first-class transaction with its own record and closure condition, rather than as an interruption of the normal flow.
Retention and access are governance decisions, not technical defaults
An audit trail has a cost: storage, and a wider surface for access. Both need decisions. How long records are kept should follow the period over which a question could still be asked, which is usually longer than the operational need and shorter than the maximum permitted. Who can read a trail should reflect the sensitivity of what it contains; a trail that exposes everything to everybody is a new risk created by the control itself. In regulated settings this becomes a question of where records can physically be held, discussed in enterprise AI in regulated and sensitive environments.
A sequence for building the trail
- Choose one process that already has a genuine question attached to it, and find out who asks questions about it today and what they have to work with.
- Pick the transaction identifier that all the relevant systems already share, and check that it is actually written to each of them.
- Define the seven elements above as required fields, and mark each one as captured, capturable, or not currently possible.
- Fix the not-possible ones first, because they are usually source systems that keep no history, and that work cannot be done by the workflow team.
- Choose where the record lives, how long it is kept and who can read it.
- Reconstruct one historical case end to end using only the trail, and treat every gap as a defect with an owner.
The reconstruction step is the one that tells you whether the work succeeded, because it does not depend on the opinion of the team that built it. The measures to carry forward are the number of elements captured automatically against the seven required, the time to reconstruct a single case, and the number of cases where the answer was not available.
Where a full trail is not worth its cost
Not every process needs this. For low-consequence, reversible, high-volume work, a trail capturing the output, the approval and the action is usually sufficient, and the source-versioning and exception disciplines can wait. What is not defensible is having no answer to a question somebody is entitled to ask, and finding that out during an enquiry rather than during design. Deciding where the line sits is a business judgement about consequence.