How do you prove AI controls to an auditor?
Short answer. You prove an AI control to an auditor by reproducing one governed action (an AI action that went through approval) from records. Show the identity the AI worker used and the sources it could read. Show the exact action it proposed, the person who approved or rejected it, and the state of the source system afterwards. A policy describes what should happen. An auditor samples what did happen, so the control needs a record for every run.
The pattern is familiar from twenty years of security work. Privileged access went through it a decade ago. A team arrives with a policy document and a vendor’s assurance letter, and the auditor asks for the record behind one transaction.
What does an auditor accept as evidence of an AI control?
Auditors work from samples. They pick a period, select transactions from it, and ask for the record behind each one. For an AI workflow the transaction is a governed action: a draft sent, a ledger entry proposed, a customer record updated. The evidence has to be tied to that action and produced by the system at the time, with a timestamp and an identity the auditor can check against another source.
A screenshot of a settings page shows one configuration at one moment. It says nothing about the run the auditor selected. A vendor’s SOC 2 report covers the vendor’s own operations. It does not describe how your deployment was configured or who in your firm approved an action last Tuesday.
Which records should exist for every governed AI action?
I ask for the records in the table below. Each row pairs the control an auditor will test with the record that answers it.
| Control under test | What the auditor asks | The record that answers it |
|---|---|---|
| Identity | Which account did the AI worker act as, and who granted its scope? | Worker identity, permission scope and the grant record in the source system |
| Source boundary (what the AI could see) What could it read for this task? List of sources retrieved for the run, with one out-of-scope record shown as blocked |
||
| Model route | Did content leave the tenant, and to which endpoint? | Configured provider and endpoint for the run, with the policy version in force |
| Human approval | Who approved this action, and what exactly did they see? | The proposal as displayed, the approver’s identity, the decision and its timestamp |
| Rejection | What happens when approval is withheld? | A rejected proposal with a separate check of the source system showing no change |
| Execution | Did the approved action run as approved? | The operation that ran, its result and the source state afterwards |
| Retention | Can you retrieve this record in a year? | Retention rule, the owner of the log store and an export retrieved outside the original conversation |
I would start with the rejection row. A product demonstration usually shows an approval. Ask to see the source system after a reviewer says no.
How do you run the test before the auditor does?
Pick one workflow and use synthetic data in an isolated environment. Agree the expected behaviour with the workflow’s owner before you start.
- Run the permitted task and keep the proposal the AI worker produced.
- Have the authorised reviewer reject it. Inspect the source system yourself and record what changed.
- Run it again and approve it. Compare the executed operation with the proposal that was displayed.
- Make one required source unavailable. Check that the workflow reports an unknown instead of reusing an earlier answer.
- Hand the records to a colleague who was not in the session. Note what they cannot reconstruct and give each gap an owner.
Step five is the audit in miniature. If a colleague cannot rebuild the story from the records alone, an auditor will not manage it either.
What do the frameworks ask for?
The frameworks agree on the substance and differ on wording.
- EU AI Act. Article 12 requires high-risk systems to log events automatically over their lifetime. Article 14 requires effective human oversight. Article 26 requires deployers to keep the logs under their control for at least six months. The Digital Omnibus, in force since 27 July 2026, moved the high-risk application dates to 2 December 2027 and 2 August 2028 (dates reviewed against the regulation text on EUR-Lex, reviewed through 3 October 2026). See the regulation text on EUR-Lex.
- ISO/IEC 42001. The management-system standard expects documented controls with evidence that they operate. A certificate covers the management system. It does not replace the run-level records above (the action-by-action logs for each individual AI run).
- NIST AI RMF. The Govern and Measure functions ask for accountability structures and documented test results. See the NIST AI Risk Management Framework.
- OWASP. The excessive-agency guidance recommends limited permissions and human approval for high-impact actions, enforced in the connected system.
None of these tells you which log format to use. They all assume you can produce the record when asked. Your legal and compliance reviewers decide which obligations apply to your use.
Where do AI control audits usually fail?
Check four gaps before the audit. The approval exists but is not tied to the exact proposal, so a changed amount or recipient rides through on an earlier decision. The logs live with the vendor and the customer cannot export them. The AI worker runs under a shared service account, which leaves no way to show who held authority. The team tested approval and never tested rejection.
Each of these is fixable before the audit. They are hard to fix during one.
Questions buyers ask.
Is a vendor’s SOC 2 report enough to prove our AI controls?
No. A SOC 2 report describes the vendor’s own control environment. Your auditor will still ask how your deployment was configured, who approved actions in your firm and where your records are kept.
How long should AI action logs be kept?
Under Article 26 of the EU AI Act, deployers of high-risk systems keep logs for at least six months unless other law requires longer. Sector rules and contracts often set longer periods. Set the retention rule with your compliance reviewer and record who owns the log store.
Does human-in-the-loop satisfy an auditor on its own?
Only when the record shows it. The auditor needs the proposal as displayed, the approver’s identity and the decision bound to that proposal. A statement that a human reviews outputs is a policy claim.
Can we prove controls for an AI tool we do not host?
Partly. You can evidence your own identity, approval and source-system records. You depend on the vendor for model-route and log records, so confirm before you buy that those can be exported on request.
This is the method behind the twelve tests in the Agentic AI Procurement Handbook, and it is the review I bring to a Vantage Workspace evaluation. It is an evaluation method. It is not legal advice or a certification. Choose one workflow, run the rejection test this week and see which record is missing.
On the workspace site, the companion guide How to prove AI controls to an auditor lists the records to retain for one approval-controlled workflow. It maps them to NIST AI RMF and SOC 2 review questions.
Josh Olayemi · Founder, Handvantage · About the author
