Decision support
What auditors and enterprise customers actually ask about your AI agent
No framework has an “AI” chapter. They ask the same questions about a new system — and non-determinism makes two of the usual answers insufficient.
The question
What do we need to be able to show an auditor, or an enterprise customer, about our agent?
The short answer
That you can reconstruct any individual decision, and that a human is accountable for the ones that matter. No control framework has an AI section — SOC 2 asks about change management, access control and monitoring exactly as it does for any system. Two standard answers stop working, though. Logging the output is not enough, because the same input can produce a different output tomorrow: you need the input, the prompt version, the model version and the tool calls, or the decision is not reproducible. And “a human reviewed it” is not enough if the human only saw the agent’s recommendation — that is rubber-stamping, and in regulated contexts it does not count as meaningful oversight. If you deploy into employment, credit or other high-risk uses in the EU, note that the Annex III obligations have applied since 2 August 2026.
Written for
- Leaders filling in an enterprise security or procurement questionnaire
- Teams preparing for a SOC 2 audit with an AI feature in scope
- Anyone deploying agents in recruitment, credit, or other regulated decisions
Why the answer is that
The reason AI compliance feels confusing is that people go looking for an AI standard. There largely is not one to satisfy — SOC 2, ISO 27001 and your customer’s questionnaire all ask the same things they always did. What changes is that some of your usual evidence no longer demonstrates what it used to.
Change management is the clearest example. Your evidence is normally a pull request and a deploy log. But an agent’s behaviour is determined as much by its prompt and its model version as by its code, and in a lot of teams the prompt is a string in a config file that anyone can edit without review, and the model version is whatever the provider is currently serving behind an alias. Under that arrangement you cannot state what the system was doing on a given date, which is a change-management finding rather than an AI one. Version the prompt as an artefact, pin the model explicitly, and the finding disappears.
The second is reproducibility. For a deterministic system, the input and the code tell you the output. For an agent they do not — temperature, provider-side model updates and retrieval drift all mean the same question can be answered differently next week. So the audit trail has to capture everything that shaped the answer at the time: the resolved prompt, the prompt version, the pinned model version, what was retrieved, every tool call with its arguments, and the final output. If you can produce that for a decision from six months ago, you can answer almost any question an auditor or a litigant asks.
The third is human oversight, and it is the one most often claimed and least often true. A reviewer who sees only the agent’s recommendation and an approve button will approve nearly all of them — that is well documented, and it is why regulators distinguish meaningful oversight from a formality. Oversight that holds up means the reviewer sees the evidence the agent used, can see when the agent was uncertain, and has a realistic workload. Ten seconds per case is not review.
What to log per decision
The test: could you reconstruct this specific decision in twelve months, after the model has changed twice and the prompt four times?
| Field | Why it is needed | What breaks without it |
|---|---|---|
| Resolved prompt (as sent) | The template plus what was interpolated into it | You know the template, not what the model saw |
| Prompt version identifier | Ties the decision to a reviewed artefact | Cannot state what the system was doing on a date |
| Pinned model version | Behaviour changes when the provider updates an alias | “It used to pass” with no way to demonstrate why |
| Retrieved context and its source IDs | Shows the evidence base for the answer | Cannot show whether a claim was grounded or invented |
| Every tool call with arguments | This is what actually changed state | You have the reasoning but not the actions |
| Final output | The decision itself | Nothing to review |
| Caller identity and entitlements | Proves the data access was authorised | Cannot rule out cross-user data exposure |
| Human approval, with what was shown | Distinguishes oversight from rubber-stamping | “A human reviewed it” cannot be substantiated |
| Timestamp and latency | Correlates with incidents and shows review time | Cannot detect that review took four seconds a case |
This is one structured log line per decision, not a new system. Most teams already emit the last three and none of the first five — which is exactly backwards for answering questions later.
Framework requirement to concrete artefact
What to actually build, per obligation. Nothing here is AI-specific tooling — it is ordinary engineering applied to a non-deterministic component.
| Obligation | Where it comes from | Artefact that satisfies it |
|---|---|---|
| Changes are reviewed and traceable | SOC 2 change management, ISO 27001 | Prompts versioned in git, model versions pinned, both in the deploy record |
| Access is least-privilege | SOC 2 logical access | Agent runs with caller’s permissions; retrieval filtered pre-search |
| The system is monitored | SOC 2 monitoring | Tracing on tool calls, alerting on failure modes and spend |
| Decisions can be explained | GDPR Art. 22, EU AI Act, customer questionnaires | Per-decision log with retrieved evidence and tool calls |
| Meaningful human oversight | EU AI Act Annex III high-risk uses | Reviewer sees evidence and uncertainty; review time is measured |
| Bias is assessed for employment decisions | EU AI Act, NYC Local Law 144 | Outcome distributions by protected class, re-run per model change |
| Records are retained | Sector rules, AI Act logging duties | Decision logs retained per policy, with the redaction rules written down |
If your agent makes or materially influences employment, credit, education or essential-service decisions about people in the EU, the Annex III high-risk obligations have applied since 2 August 2026, with penalties up to €15M or 3% of global turnover. Confirm your classification with counsel rather than with a blog post — including this one.
Get the answer for your own system in four minutes
The free scorecard produces a score out of 100, a breakdown across reliability, cost and observability, and your gaps ranked by production risk with a fix and effort estimate for each. It prints to a PDF you can take into a planning meeting — which is usually more persuasive than an argument.
Run the scorecardIf you are the engineer who found this page: Written to be forwarded. If you are the engineer who found this, send the relevant one up — it is framed for the person who has to approve the work.
If you decide to do the work
The engagements this decision leads to, each with the full method and effort estimates — whether your team runs it or I do.
Questions
What should we log for AI agent audit trails?
Enough to reconstruct a specific decision after the model and prompt have both changed: the resolved prompt as sent, the prompt version, the pinned model version, what was retrieved and from where, every tool call with its arguments, the final output, the caller’s identity, and — if a person approved it — what they were shown.
Most teams log the output and the timestamp and nothing that shaped the answer, which means the decision cannot be explained later.
Is there a SOC 2 requirement specifically for AI?
No. SOC 2 asks about change management, logical access, and monitoring exactly as it does for any other system.
What changes is whether your usual evidence still demonstrates the control. A pull request and a deploy log prove change management for code, but not for an agent whose behaviour depends on an unversioned prompt string and a floating model alias. Version the prompt and pin the model, and the standard evidence works again.
Why is logging the model output not enough?
Because the same input can produce a different output later, so the output alone does not explain the decision.
Temperature, provider-side model updates and retrieval drift all change behaviour without any change on your side. Without the pinned model version, prompt version and retrieved context, you cannot demonstrate why the system answered as it did — which is precisely what an auditor, a regulator, or a customer’s lawyer will ask for.
Does a human clicking approve count as human oversight?
Not if the human only sees the recommendation. Reviewers presented with a suggestion and an approve button approve nearly all of them, and regulators distinguish meaningful oversight from a formality.
Oversight that holds up means the reviewer sees the evidence the agent used, can tell when the agent was uncertain, and has enough time per case for the review to be real. If your logs show four seconds per decision, that is evidence against you rather than for you.
Want a second opinion on the decision?
Describe your situation and I will tell you what I would do — including when that is "nothing" or "handle it internally". No charge for that, and it is genuinely how a lot of these conversations end.
Other decisions
- What an agent audit should cover
- Questions to ask before launch
- Build or buy: observability
- Metrics worth reporting upward
- Do you need outside help?
- Can an agent touch our internal data?
- Is an agent different from a chatbot?
- Do we need our own model?
- Where to put a human in the loop
- Agent cost versus hiring
- Working with the systems you already have