AI audit evidence: what regulated organisations must log.
Short answer. Log the identity that acted, what it read, what it proposed, who approved or refused it, what ran and the state left behind. Timestamp every entry. Keep the record for at least six months under EU AI Act Article 26, longer where another rule sets a longer period. A “reviewed” checkbox next to a login is not a log. The record has to let someone who was not in the room rebuild the decision.
What does an auditor actually ask for?
An auditor does not ask for your AI policy. They pick a period, select a handful of actions from it, and ask for the record behind each one.
For an AI system that means a governed action: a payment drafted, a customer record changed, a claim assessed, a document classified. The auditor wants proof that action happened the way your controls say it should, produced by the system at the time, not a description written afterwards.
A SOC 2 auditor samples control operation across the review period. A PCI DSS assessor samples log entries around cardholder data access. A market surveillance authority under the EU AI Act asks a deployer to produce logs it is required to hold. Different vocabulary, same request: show the record, not the policy.
What must be in the log?
Nine things, and a log missing any one of them leaves a gap an auditor will find. Identity: which account acted, and who granted its permissions. Sources: what the system read to produce its output. The proposal: the exact content shown to a human, captured as it was displayed, not summarised later. The decision: who approved or refused it, bound to that exact proposal. Execution: what actually ran. Resulting state: what the target system looked like afterwards. Timestamps on every step. The policy or configuration version in force at the time, so a later reviewer knows which rules applied.
We set out the same chain, field by field, in how to prove AI controls to an auditor. The short version: a chat transcript shows what was said, and an application log shows what the software did. Neither one ties an identity to a decision to a consequence. Only a log built for that purpose does.
How long do we keep it?
Article 12 of the EU AI Act requires high-risk systems to support automatic logging over their working life. Article 26 puts the matching duty on the organisation using the system: keep those logs under your own control for at least six months, longer if other law requires it. See Article 12 and Article 26 on the AI Act Explorer.
Those duties are not yet in force for Annex III systems. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. It pushed back the application dates for high-risk systems: Annex III to 2 December 2027, Annex I to 2 August 2028. See the Digital Omnibus explorer page (reviewed through 27 September 2026). The six-month log floor was not rewritten. It has simply not started its clock for Annex III systems.
Other regimes give a shorter runway. A SOC 2 Type II review covers a fixed period, and your logs must survive intact across the whole of it or the sample fails. PCI DSS v4.0 expects audit log history to be retained and the recent part of it to be readily available; check the current requirement text for the periods that apply to you. ISO/IEC 42001, the international AI management system standard, does not fix a number. It requires the organisation to define its own retention and show the record still exists when asked. Set your own period against the longest obligation, not the shortest.
What makes a log evidence rather than a status flag?
A workflow tool will give you a “reviewed” flag and a login next to it. That is not the same as a record. A flag tells you someone opened a screen. It does not tell you what they saw when they opened it, what they changed before they clicked through, when that happened, or whether the action then actually went out.
Evidence captures all four. The proposal as displayed to the reviewer, word for word. The reviewer’s identity, tied to that specific proposal. The timestamp of the decision. And the outcome: did the action execute, and does the target system now show what the decision said it should.
Refusals belong in the log with the same weight as approvals. A demonstration tends to show something getting approved. What an auditor wants is a refused action, with a separate check of the source system proving nothing changed. A log that only fills in on a yes is not a log of the control. It is a log of the successes.
Tamper-evidence is the other half. Entries get appended, never overwritten, and a change to an old entry has to be detectable, whether through checksums or simple append-only storage with no update permission granted to any account. The account that carries out actions should not also hold permission to edit the record of them.
None of this counts as evidence if nobody can retrieve it inside a working day. A log that exists somewhere but takes a support ticket and a week to extract is not evidence when an auditor is sitting across the table. Test retrieval before you need it, not during the audit.
Who has to be able to read it?
Start inside your own organisation. The person who approved or refused an action should not be the only one who can see the record of it. A second reviewer or your compliance function needs independent read access. Under Article 26(5) of the EU AI Act, a deployer that suspects a high-risk system presents a risk must tell the provider and, for a serious incident, the market surveillance authority too. You cannot meet that duty if the log sits somewhere only the original operator can open.
Your external auditor or regulator needs the ability to receive an export, not a screen-share of a dashboard. And if the only copy of the log lives inside a vendor’s product with no export path, custody of your evidence sits with the vendor, whatever the contract says about ownership. We cover the same custody test for the wider platform in what is a sovereign AI platform. Ask who can read the logs, and whether you can get them out without the vendor’s support desk.
What should we do this quarter?
- Pick one AI-assisted workflow already running in production and check whether its “reviewed” step is a checkbox or an actual record of what the reviewer saw and changed.
- Confirm the log storage is append-only, and test it: try to edit or delete a completed entry using the access your own administrators already hold.
- Deliberately trigger a refusal in that workflow and confirm the log captures it with the same detail as an approval, including a check of the source system afterwards.
- Set a retention period against the longest obligation that could apply to that workflow, not the shortest, and write down who owns that decision.
- Time how long it takes to pull one action’s full record end to end. If it takes longer than an hour, fix the retrieval path before an auditor asks for it.
How do the four frameworks compare on logs?
| Framework | What it expects of your logs, in plain terms |
|---|---|
| EU AI Act | High-risk systems must be built to log automatically over their working life (Article 12). Once a system is classified high-risk, the organisation using it keeps those logs under its own control for at least six months (Article 26). |
| ISO/IEC 42001 | The AI management system standard separates a document, which says what you plan to do, from a record, which says what you actually did. Both have to exist, and the record is what an auditor tests. |
| SOC 2 | An auditor samples whether your logging and monitoring controls operated across the whole review period. A control described in a policy but missing from the sample fails. |
| PCI DSS v4.0 | Audit logs must be protected from alteration and limited to people with a job-related need to read them. Requirement 10 sets the retention period and how much recent history must be readily available. |
Questions buyers ask.
Does the Digital Omnibus mean we can wait before building AI logs?
Not for long, and not for every obligation. The Digital Omnibus moved the dates when systems become high-risk under the EU AI Act, not the underlying duty to log once they are. SOC 2 and PCI DSS reviews run on their own clocks now, regardless of that deferral.
Is a “human reviewed” checkbox enough for an auditor?
No. A checkbox shows someone opened a screen. An auditor wants the proposal as it was shown, the reviewer’s identity tied to that exact content, the decision timestamp, and confirmation the outcome matched the decision.
Do refusals need to be logged as carefully as approvals?
Yes. A refusal, with a separate check that the source system shows no change, is often the sample an auditor asks for first. A log built only around approvals proves nothing about the control that is supposed to stop the wrong action.
Can we rely on our AI vendor’s own logs?
Partly. A vendor can show you which model ran and what it executed. You still need your own record of who at your organisation approved or refused each action. Confirm before you buy that the vendor’s raw logs export on request, not just a summary view.
This is the evidence discipline behind the twelve tests in the Agentic AI Procurement Handbook. It is what I check first when a regulated organisation asks whether its AI logs would survive an audit. Handvantage builds Vantage Workspace, a self-hosted governed AI workspace, so weigh my view accordingly. This is an evaluation method, not legal advice. Your own counsel and compliance function should confirm which retention periods and access rules apply to your organisation.
Josh Olayemi · Founder, Handvantage · September 2026 · About the author
