Agent Behaviour
Audit Trail
A readable record of what the AI did, in which mode, on what basis, and who approved it.
Overview
Every other governance pattern depends on answering “what happened?” Audit Trail records each AI action with its mode, flags, evidence, approver and any override reason, in a form system administrators, developers and auditors can read. It must distinguish agent events from human events, so accountability exists in agent designs.
This is distinct from the Monitoring Dashboard, which gives users a system-wide, task-level view for review. An audit trail is a read-only record for auditing and tracing agent events. Under the EU AI Act (Art. 26(6)), deployers of high-risk systems must keep the logs under their control for at least six months, unless other applicable law requires a longer period.
When to use
Use when
- Any AI system that acts, or whose outputs people approve.
- Agent actions have real-world consequences that may need to be investigated, reversed or defended.
- Regulation requires documentation of human oversight decisions.
- Never omit it for high-risk systems. Elsewhere, scale the detail to the stakes.
Not needed when
- A single person is responsible for all actions in a low-stakes flow.
Questions to ask
Ask these at kickoff, when design work starts. Tick them off as your team answers.
Example
An order flows through review. The audit trail records every event with a traceable reference, a full date and time zone, the configuration in force, the actor (agent, person or system) and the evidence behind each step.
| Event | Actor | Time (BST) | Evidence & context |
|---|---|---|---|
| Order received | Agent · Intake | 09:14:02 | Inbound email, EU-Orders channel msg 7f3a2 ↗ |
| Extraction complete | Agent · Extraction 3.2 | 09:14:05 | Confidence 0.61 vs threshold 0.75 (config v12) Extracted fields ↗ |
| Routed to review | Agent · Extraction 3.2 | 09:14:05 | Reason: below threshold · Queue: Order review |
| Review opened | Person · R. Mensah, Reviewer | 09:22:11 | Opened extracted fields and source PDF |
| Value corrected | Person · R. Mensah, Reviewer | 09:23:45 | Unit price £42.50 → £38.00 · Reason: header vs line item Invoice p. 2, line 3 ↗ |
| Correction submitted | Person · R. Mensah, Reviewer | 09:23:52 | Sent for second approval (separation of duties) |
| Correction approved | Person · K. Asante, Approver | 09:31:07 | Approved the correction made at 09:23:45 after viewing the source PDF |
| Order submitted | System | 09:31:08 | Final value £38.00, based on the approval at 09:31:07 |
Each row says whether an agent, a person or the system acted, and links to the evidence it was based on. The header carries what an auditor asks first: which order, which date and time zone, which configuration and agent version, and how long the record is kept.
Anti-patterns to pay attention to
- Logs don't record the mode or who approved it, and configuration state (threshold, mode, permissions) isn't recorded alongside action events.
- Overrides are recorded without reasons.
- Agent events and human events look identical in the log.
- The log is a debugging tool, not a compliance record.
References
Current guidelines · EU AI Act, ISO/IEC 420013 references
For orientation only, not legal advice. Record-keeping is explicit for high-risk systems. EU AI Act links open a readable version of the official text published on EUR-Lex; ISO/IEC 42001 is a paid standard.
- EU AI Act Art. 12 High-risk systems must technically allow automatic logging of events over their lifetime, to support risk identification and monitoring.
- EU AI Act Art. 26(6) Deployers keep the logs under their control for at least six months, unless other law says otherwise.
- ISO/IEC 42001 A.6.2.8 Decide which events are logged to support audit and incident investigation.