Disclosure: BlueBear builds an AI agent platform that produces audit evidence, so we have a commercial interest. This article is not legal or regulatory advice, describes no specific obligation as applying to you, and names no customer — your obligations depend on your jurisdiction, your licences and your regulator, and should be established with your compliance function.
The short answer: a review asks about one action, not about your AI
The framing that makes this tractable is that a regulated review is almost never a question about artificial intelligence. It is a question about one action, on one date, and whether you can produce five things for it:
- Who was responsible — the human accountable, and the agent that acted.
- What permitted it — the control that was evaluated, and its result.
- What the system did — the operation, the target, the timing.
- What it produced — the artefact or the change, identifiable.
- What the business result was — accepted, corrected, rejected, reversed.
Everything else in this article is downstream of those five. If you can produce them for any action a reviewer picks, you have a trail. If you can produce a beautiful architecture document but not those five for a named instance, you do not.
What is different about agents, compared with the model governance you already do
Financial institutions generally have mature model governance: an inventory, development standards, independent validation, ongoing monitoring. That machinery answers is this model fit for purpose, and is it still fit.
An agent adds a question that machinery was never built to answer: what did it do, to which system, under whose authority. The two are genuinely different, and the gap is not academic — a fully validated model taking an unauthorised action is a governance failure that a model inventory will never surface, because the model behaved exactly as validated. The failure is in the authority layer, which model governance does not cover.
| Model governance answers | Agent audit answers | |
|---|---|---|
| Unit of concern | The model | The action |
| Question | Is it fit for purpose, and still fit? | Was this specific act authorised, and what did it change? |
| Evidence | Validation reports, monitoring, an inventory | Per-run records: actor, control, execution, artefact, outcome |
| Produced | Periodically, by a validation function | Continuously, at the moment of the action |
| Fails when | Performance drifts | A validated model does something it should not have been permitted to do |
Practically, this means the agent trail is an addition to model governance rather than a replacement, and it usually needs a different owner — the control owner rather than the validation function.
The fields, and the three that cannot be produced afterwards
The general specification is in the seven-link requirements list. Three of the seven deserve particular emphasis in a regulated setting because they have no other source:
Identity, established from the credential. The actor and the boundary must come from the credential presented at admission, never from a field in the request. In a multi-entity institution this is also how you keep one legal entity's activity separable from another's, which is a question that arrives sooner than people expect.
The control decision, with its reason. "Permitted" is not evidence that a control operated; "permitted by control X, version 4, because the amount was below the threshold and the counterparty was on the approved list" is. In an examination the reason is what demonstrates the control was operating rather than merely present.
The business outcome. Whether the action was accepted, corrected or reversed. This one is worth planning for explicitly, because it does not exist in infrastructure and needs something in the business process to report it back.
Completeness is the requirement that most often fails
This is worth its own section because it is a technical default that produces a compliance failure silently.
Observability platforms sample. That is correct engineering — retaining every span from a high-volume system is unaffordable and unnecessary for debugging. It is also fatal for evidence, because a sampled trail cannot demonstrate that a control operated throughout the period; it demonstrates that it operated on the runs that were kept.
Nobody usually mentions this until testing, because to the engineering team it is not a defect. The question to ask, in exactly these words, is: "are these records sampled, and at what rate?" Ask it of your own platform as well as of a vendor's.
Approval records that establish something
Human approval is often the control that a regulated design leans on hardest, and it is the one most often recorded in a way that establishes very little.
"Jane approved at 14:32" is an assertion. What makes an approval record evidence is what the approver was shown — the summary, the amount, the counterparty, the flagged exceptions — captured at the moment of approval. Without it, a reviewer cannot distinguish a considered decision from a reflex click, and neither can you, six months later, when it matters. Human-in-the-loop approval patterns covers designing the approval itself; the audit requirement is simply that the context is part of the record.
Retention, and where the records live
Two practical consequences follow from obligations running for years while log platforms default to weeks.
First, audit records need a separate store from operational telemetry. Retaining debug logs for a multi-year period is usually unaffordable; retaining audit records for the log period is non-compliant. Splitting them is the only arrangement that satisfies both.
Second, the store outlives the team. That makes a typed, versioned schema a compliance property rather than an engineering preference — in year four the people who wrote the records are gone and the only thing that makes them legible is a declared contract.
An exercise that finds your gaps before a reviewer does
Pick three actions from the last quarter: one routine, one where an exception was raised, and one that failed. Hand each to someone in a second line function who was not involved, and ask them to produce the five items from the top of this article. Give them a working day each.
The failed one is the important one. Systems are consistently thinner on failures than on successes, and a review that starts with an incident starts with a failure. It is worth being concrete that this is an ordinary gap rather than a sign of negligence: in our own production database, session records carry a field for the error that ended a failed session and it is populated in none of the error rows. The schema is correct; nothing writes it. That is the shape of the problem you are looking for — not a missing design, a missing producer.
If you are a platform or engineering lead
The two changes with the best ratio of effort to regulatory value are a run identifier attached at admission and the control decision written with its reason. Both are days of work rather than projects, and both are permanently unavailable for every day they are deferred. The control plane architecture walkthrough covers where each is written.
If you resell this to regulated customers
Your customers inherit their obligations and will pass a version of them to you contractually. Two capabilities become product requirements rather than compliance ones: per-tenant export of a complete run, and the ability to state your retention as a number. Multi-tenant isolation for buyers covers the boundary guarantees; security posture evidence for buyers covers the artefacts to have ready.
Do this next
Run the three-action exercise, and put the failed action first. It converts a general worry into a specific field list, and a field list is something a second line function and an engineering team can both act on. Then read the existing guide to designing an AI agent audit trail for governance and compliance for the control mapping, or the seven-link requirements list to write the specification.
Questions people actually search for
- how do you produce compliance audit trails for ai agent activity in regulated industries
By recording authority at the moment each consequential action is permitted, in a typed store with retention set by obligation rather than by storage cost. A regulated review asks about one named action on one date and expects five things: who was responsible, what control permitted it, what the system did, what it produced, and what the business result was. Three of those - identity, the control decision, and the outcome - have no other source, so anything not recorded as the run happened cannot be produced afterwards at any price.
- ai soc audit trail
For a service organisation control examination, what an auditor tests is whether a control operated as described throughout the period, not whether it exists. For AI agent activity that means three things have to be demonstrable: that every consequential action passed through the control point, that the control decision was recorded with its reason, and that the record was complete rather than sampled. The completeness requirement is the one that most often fails, because telemetry platforms sample by default and nobody mentions it until testing.
- does model risk management cover ai agents
Partly, and the gap is important. Established model risk guidance covers development, validation, and ongoing monitoring of a model - is it fit for purpose, is it still fit. An agent adds a second question that model governance was never designed to answer: what did it do, to which system, under whose authority. A validated model taking an unauthorised action is a governance failure that a model inventory will not surface, because the model is behaving exactly as validated.
- what evidence do auditors want for ai decisions
Reconstruction of a specific instance rather than a description of the system. Expect to be given a date and an action and asked to produce the actor, the control that permitted it, what executed, what was produced, and the business outcome, with the record showing when each was written. Descriptions of the architecture are supporting material; the test is whether the specific instance can be assembled from retained records without an engineer interpreting anything.
- how long must ai audit records be retained in financial services
Longer than any log platform default, and the governing period is whichever of your obligations reaches furthest - sector recordkeeping rules, contractual commitments, and the window in which a dispute could arise. That is normally measured in years. The practical consequence is that audit records need a separate store from operational telemetry, with its own retention policy, because retaining debug logs for the same period is usually unaffordable and retaining audit records for the log period is non-compliant.