GovCompass
Knowledge base

Building an audit trail for EU AI Act compliance

By Michel Venniker· · Aligned with the consolidated EU AI Act, including the 2026 Omnibus amendments.

An audit trail for EU AI Act compliance is the structured, retained record, combining the system logs (Art. 12) with the deployer's own oversight and monitoring documentation, that lets you demonstrate to a supervisor that a high-risk AI system was used lawfully.

Updated: June 2026

Introduction: the audit trail as compliance evidence

The EU AI Act creates a documentation-heavy compliance framework. But documentation alone is not enough, the documentation must form a coherent, consistent audit trail that tells the story of how your organisation identified, classified, assessed, and managed AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → risks over time. When a supervisory authority investigates a complaint or conducts a routine audit, this is what they will want to see.

This guide explains what a complete EU AI Act audit trail looks like, how to build one from scratch, and how to maintain it efficiently.

The seven layers of an EU AI Act audit trail

Layer 1: AI inventory (foundation)

The audit trail begins with your AI inventoryAI inventoryA register of all AI systems an organization builds, buys or embeds, with owners and risk tiers — the prerequisite for governing any of them.Open full entry →. Every AI system in use must be documented: name, vendor, version, category, intended purpose, affected persons, and operational status. The inventory must be dated and version-controlled, so auditors can see what systems were in use at any given time.

Layer 2: classification records

For every AI system: document the classification analysis. Which Art. 6 track applies? Which Annex categories were considered? What is the conclusion and the rationale? Classification records must be traceable, showing who made the classification decision, when, and on what basis.

Layer 3: supplier documentation

File all supplier compliance documentation: declarations of conformity, instructions for use, EU database registration numbers, technical documentation summaries, and supplier correspondence. This layer demonstrates that your supplier due diligence was conducted systematically.

Layer 4: risk assessments (DPIA/FRIA)

For high-risk AI systems: file the DPIADPIAData Protection Impact Assessment — required before likely-high-risk processing (systematic profiling with significant effects, large-scale special categories, public monitoring); AI development triggers it constantly.Open full entry → and, where applicable, the FRIAFRIAFundamental Rights Impact Assessment — required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry →. Include review dates, reviewer identities, and the sign-off record. DPIAs and FRIAs must be updated when the AI system or its context changes, file each version.

Layer 5: human oversight records

The oversight log (see the Oversight Log guide) is a core audit trail element. It demonstrates that meaningful human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry → occurred for high-risk AI decisions. Oversight logs must be retained per Art. 26.6 requirements.

Layer 6: AI system logs

The automatically generated logs from the AI system itself (Art. 12 and Art. 26.6). These are the technical heartbeat of the audit trail, showing what the system did, when, and on what inputs. Ensure these are retained in secure, tamper-evident storage.

Layer 7: incident records

All AI-related incidents, near-misses, and serious incidents must be logged. Include: incident description, date discovered, classification analysis (is it a "serious incidentserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure — triggering regulatory reporting duties for high-risk systems.Open full entry →"?), notification to providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry →, notification to AP (if applicable), root cause analysis, and remediation actions.

Building the audit trail from scratch

If your organisation is starting from zero:

  1. Start with the AI inventory, this takes a day of effort for most organisations
  2. Build classification records for each system, prioritise high-risk systems
  3. File existing supplier documentation and identify gaps to be filled
  4. Conduct DPIAs for high-risk AI systems (starting with highest-risk)
  5. Implement oversight logging, even retrospectively for recently deployed systems where practical
  6. Set up log storage and retention procedures
  7. Create an incident log and establish the incident management procedure

Audit trail management best practices

  • Version control all documents, every update should be a new version, not an overwrite
  • Use dates consistently, ISO 8601 format (YYYY-MM-DD) across all documents
  • Assign document ownership, each element of the audit trail has a named owner responsible for keeping it current
  • Conduct annual reviews, at least once per year, review the completeness and currency of the audit trail
  • Simulate a supervisory audit, once per year, role-play a supervisory authority audit request and verify you can produce all required documentation within 5 business days

Compliance checklist

  1. Is there a current, version-controlled AI inventory?
  2. Are classification records complete and traceable for all AI systems?
  3. Is supplier documentation filed and current?
  4. Are DPIAs/FRIAs filed for all high-risk AI systems?
  5. Is an oversight log operational for all high-risk AI systems?
  6. Is AI system log storage in place with appropriate retention periods?
  7. Is there an incident log with a clear management procedure?
  8. Has a simulated audit exercise been conducted in the past 12 months?
Legal referencesArt. 12Art. 26

More on Accountability

Art. 10 EU AI Act: data and data governance for high-risk AI

Reference

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 12 EU AI Act: record-keeping and logging for high-risk AI

Reference

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 19 EU AI Act: keeping the automatically generated logs

Reference

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Art. 26.1 EU AI Act: following provider instructions as a deployer

Reference

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.