Builds on AR-000151 (Logging & Record-Keeping, Article 12), which covers the EU AI Act Article 12 logging obligation in full. This article covers the broader practice of AI audit trail design, applicable across all AI systems regardless of classification. See also AR-000460 (Prompt Injection) for how audit trails support security incident investigation.
What an AI audit trail is
Article 12 requirements for high-risk AI
What to log: the complete field set
| Field | Description | Requirement level |
|---|---|---|
| session_id | Unique identifier for each use session. Links all events within a single interaction. | Mandatory (Article 12(2)(a)) |
| timestamp_start / timestamp_end | Start and end time of each use. ISO 8601 format with timezone. For high-risk AI systems under Article 12(2)(a). | Mandatory (Article 12(2)(a)) |
| model_id / model_version | The exact model and version that processed the request. Critical for investigation when model updates change behaviour. | Mandatory (Article 12(1) traceability) |
| input_data | The input to the model. For personal data: hash or reference only (GDPR minimisation). For biometric systems: per Article 12(2)(c). | Mandatory for biometric; recommended for all |
| output_data | The model output, recommendation, or decision produced. For systems that produce scores or classifications: the score/class and confidence level. | Mandatory (Article 12(1) traceability) |
| decision_taken | The action taken based on the output (approved/rejected/referred). Captures the human decision where human oversight is required under Article 14. | Recommended for high-risk systems with human oversight |
| human_reviewer_id | Identifier of the natural person who reviewed/verified results. For biometric systems: mandatory under Article 12(2)(d). For all high-risk systems with human oversight: best practice. | Mandatory for biometric (Article 12(2)(d)) |
| tool_calls (agentic) | For agentic systems: every tool called, inputs passed, outputs returned. The tool call log is the primary record of what the agent did in the world. | Mandatory for agentic systems (governance best practice) |
| retrieved_content_refs (agentic) | References to content retrieved from external sources and used as model context. Required for prompt injection investigation. | Recommended for RAG and agentic systems |
| anomaly_flags | Automated flags from anomaly detection: out-of-scope actions, confidence below threshold, deviation from baseline behaviour. | Recommended for all deployed systems |
| reference_database_id | For systems that check inputs against a reference database (biometric, watchlist): the database version and reference used. Article 12(2)(b). | Mandatory for biometric / reference-checking systems |
Retention periods
EU AI Act (Article 12)
Provider-determined
Appropriate to the intended purpose
The Act specifies no single retention period. Providers must determine what is appropriate for their system type and document the determination in Annex IV technical documentation. The preamble references the period appropriate to post-market monitoring and incident investigation needs.
GDPR (personal data in logs)
Minimum necessary
Data minimisation principle (Article 5(1)(e) GDPR)
Personal data in audit logs must be retained only as long as necessary for the specified purpose. Where possible, logs should reference personal data by hash or pseudonymous identifier rather than raw personal data, to allow retention of the audit record without storing personal data indefinitely.
Incident investigation
3–7 years
Limitation periods for legal proceedings
Logs needed to support legal proceedings or regulatory investigations should be retained for the applicable limitation period in the relevant jurisdiction. In many EU member states, civil limitation periods run 3–5 years; some regulatory investigation periods run longer. Legal advice is required for the specific use case.
Audit trail integrity
Audit trails for agentic systems
The four uses of an AI audit trail
1. Internal governance review
2. Regulatory inspection
3. Post-incident investigation
4. Legal and adversarial proceedings
What organizations must do
- For every high-risk AI system: implement the Article 12 mandatory fields (session period, model version, input data for biometric systems, reviewer identification for biometric systems). Document the retention determination in Annex IV technical documentation.
- Design log architecture to separate the audit record (pseudonymous, retainable) from the personal data fields (subject to GDPR minimisation). Do not design a log where retaining the audit record requires retaining personal data indefinitely.
- Implement append-only storage with access controls. No individual user should be able to modify or delete log entries. Implement hash-chaining or equivalent tamper-evidence on the log.
- Log access to the audit trail itself: who queried the log, when, what they retrieved. This is the chain-of-custody record for the audit trail.
- For agentic systems: extend the audit trail to every tool call and every external action. The audit trail must follow the agent’s action surface, not just the model’s I/O boundary.
- Test inspection readiness annually: run a mock log-export exercise, verify that the exported records are complete and readable, and produce a chain-of-custody document for the export. Do not first test this when an inspection is imminent.
- Schedule regular internal governance reviews of audit trail data: look for drift, boundary violations, and unexpected output patterns. Document findings and corrective actions.
Common mistakes
Logging only model inputs and outputs for agentic systems is the most common mistake. For an agent that calls tools and takes actions in the world, the model I/O log is a fraction of the audit record needed. Without tool call logs and external action logs, the audit trail cannot support post-incident investigation of what the agent did in the world.
Storing personal data indefinitely in logs because "we might need it" is a second mistake. GDPR data minimisation applies to personal data in audit logs. Design the log architecture so that the audit record (pseudonymous) can be retained while the personal data is deleted or further pseudonymised when no longer needed.
Treating audit trail integrity as a technical default is a third mistake. Append-only storage, access controls, and tamper-evidence must be explicitly designed and verified. A log stored in a mutable database table with no access controls provides no evidentiary assurance.
First testing log export capability when a regulatory inspection arrives is a fourth mistake. Audit trail export is a capability that must be built, tested, and maintained. Organisations that have never exported their logs for inspection have no assurance that the export will be complete, readable, or usable when needed.
Open questions
- What the EU AI Office considers adequate for Article 12(1) traceability for non-biometric high-risk AI systems — no technical guidance has been published specifying the minimum log fields for employment, essential services, or other Annex III category systems beyond the Article 12(2) minimum.
- How long Article 12 logs must be retained for specific system types — the Act specifies no retention period; provider determination is required. The AI Office may publish guidance.
- Whether the Digital Omnibus amended Article 12’s logging requirements — the article is not confirmed as amended; check the current consolidated text.
- How audit trail requirements interact with GDPR erasure rights (Article 17) — if a data subject requests erasure of their personal data and their data appears in an AI audit trail required for regulatory compliance, the interaction between the erasure right and the audit retention obligation is not clearly resolved in either regulation.
Frequently asked
FAQ
FAQ
FAQ