GovCompass

Building an audit trail for EU AI Act compliance

By GovCompass.ai· Last updated August 2026· 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 ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry → 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 organization 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 → risksriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → 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. It is 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 personsaffected personsThe individuals or groups who are subject to or impacted by an AI system's outputs or decisions, and whose rights the governance regime aims to protect.Open full entry →, 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 documentationtechnical documentationRecords a provider must compile and keep for a high-risk AI system to demonstrate conformity, covering its design, data, testing, risk management and monitoring.Open full entry → 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 systemshigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry →: 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. It is meaningful only when the human has authority, information and time to act. One of the seven pillars of responsible AI, and under the EU AI Act a requirement for high-risk AI systems: Article 14 requires that those systems are designed so natural persons can effectively oversee them. Oversight that exists on paper but amounts to confirming in practice does not meet that bar. See override rate, automation bias, high-risk AI system, fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, responsible AI. In the IAPP AIGP body of knowledge, this principle appears as human-centricity, with human oversight as one of its elements.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 incidentsserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure. It triggers regulatory reporting duties for high-risk systems.Open full entry → must be logged. Include: incident description, date discovered, classification analysis (is it a "serious incident"?), 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. It carries 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 organization is starting from zero:

  1. Start with the AI inventory, this takes a day of effort for most organizations
  2. Build classification records for each system, prioritize 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 controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → 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
Continue withAccountability
Share Share on LinkedIn

More on Accountability

Agentic AI and governance: why autonomy sharpens the control question

Analysis

Agentic AI does not need a new kind of governance. Autonomy widens the gap between what a system does and who is accountable for it, which makes the existing governance chain, control tracing to risk and forward to evidence, more important, not less. The actions are real and sometimes irreversible, so the stakes on each control rise.

Agentic AI risk assessment: from architecture decisions to control objectives

Analysis

Assessing the risk of an AI agent does not need a separate method. The steps stay the same: recognize the risk, assess how likely and how severe it is for your system, and control it. What changes is the input. An agent runs the process through recorded architecture decisions, about the model, the instruction, retrieved knowledge, tools, orchestration, memory, and autonomy, and each of those decisions, alone or in combination, creates the possibility of harm. The output of the assessment is a set of risk scenarios with a control objective for each.

AI certification: what exists and what it proves

Analysis

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

AI governance and enterprise risk management: where they meet

Analysis

AI governance is not a parallel structure that sits beside enterprise risk management. It belongs inside it. The seven pillars of responsible AI are the control structure the organization uses to govern each AI system; enterprise risk management is the machine that carries the residual risk those controls leave behind into the board's risk appetite, the risk register, and the assurance plan. The practical question is not whether to build AI governance or ERM, but how to slot the first into the second so that one accountable structure, not two competing ones, owns AI risk.