EU AI Act compliance audit log: what regulators expect and how to document it

Updated June, 2026

TL;DR

The EU AI Act shifts AI governance from advisory policies to enforceable mandates. High-risk AI systems must maintain continuous, automatically generated logs under Article 12 for a minimum of six months, alongside Annex IV technical documentation (defined by Article 11) retained for ten years under Article 18. Article 5 prohibitions have been enforceable since February 2, 2025, and full high-risk obligations are now targeted for 2 December 2027 for stand-alone systems (and 2 August 2028 for embedded systems) following provisional political agreement on the Digital Omnibus on AI. Financial penalties reach up to EUR 35 million or 7% of global annual turnover for Article 5 violations, and up to EUR 15 million or 3% for high-risk documentation gaps. If your audit log is generated outside your own infrastructure, you face a structural compliance gap: Article 12 requires automatic log generation and Article 19 requires logs be kept to the extent they are under your control, together making generation and control within your own operational perimeter an effective requirement.

This article covers AI Systems running entirely on self-hosted models, where governance logic and audit logs remain inside the customer's infrastructure.

Many compliance teams still track AI risk in manually updated spreadsheets and point-in-time documentation reviews. That approach cannot meet the EU AI Act's requirements for continuous, automated logging. Regulators are already conducting inspections under Article 5 prohibitions that took effect in early 2025, and non-compliance carries fines up to EUR 35 million or 7% of global turnover.

Manual processes leave you exposed: you cannot retroactively generate the six-month continuous log record Article 19 requires, and a policy document is not proof of enforcement.

Security teams, end customers, and regulators all now ask the same question: how is this AI under control? The defense against those fines is a continuous, system-level audit log: structured evidence of what your AI systems did, when, and under what governance policies, stored where your audit team and regulators can reach it.

EU AI Act: audit log requirements

Meeting EU AI Act obligations starts with understanding exactly what a compliant audit log contains and how it must be maintained. The sections below define the required components, documentation approach, and retention rules for high-risk AI systems.

Defining the EU AI Act audit log

An EU AI Act-compliant audit log for high-risk AI systems is a structured, machine-generated record covering data version, model version, key parameters, decision logic, input, output, timestamp, operator ID, and any risk flags triggered at the time of each interaction. Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the full lifetime of the system, from deployment to decommission. Article 12's reference to automatic recording means logs are created without operator intervention at the moment events occur. Manual recording does not meet this standard.

Documenting for EU AI Act audits

The structural shift the Act demands is from point-in-time reviews to continuous, structured compliance evidence. A written policy that says "AI outputs will be reviewed for accuracy" is not a control. A system-level log that records every output alongside a governance policy check, timestamped and stored inside your own infrastructure, is. The EU AI Act implementation timeline confirms Article 12 logs must cover the entire operational lifetime of the system, not just the period bracketing an audit.

EU AI Act audit log retention and access

Retention requirements under the Act split across two articles with distinct timelines:

• Automatically generated logs (Article 19): Minimum six months, unless applicable Union or national law requires longer.
• Technical documentation (Article 18): Ten years from the date the high-risk AI system is placed on the market.

Note that Article 18 governs the retention period only. The content requirements for the technical file, covering the nine mandatory sections, are defined by Article 11 and Annex IV.

National competent authorities may request access at any time during those windows, so both must be retrievable on short notice, not archived in a system requiring weeks of IT effort to access.

EU AI Act risk categories and their audit requirements

The Act defines four risk tiers with distinct documentation obligations. The table below maps the core requirements by category.

Identifying prohibited AI systems

Article 5 prohibits AI systems that:

• Use subliminal techniques to manipulate behavior
• Apply social scoring based on personal traits
• Make criminal risk predictions based solely on profiling
• Scrape facial images to build recognition databases
• Infer emotions in workplaces or educational institutions without legal basis
• Perform real-time remote biometric identification in publicly accessible spaces for law enforcement (outside narrow exceptions)

These prohibitions have been enforceable since February 2, 2025. Compliance teams should document the assessment confirming no deployed system falls into these categories. If any system does, the gap is an active legal exposure, not a documentation shortfall.

High-risk AI audit requirements

High-risk AI systems fall into categories defined by Annex III, covering critical infrastructure, employment decisions, essential services, education, law enforcement, migration, and administration of justice. The audit burden is the heaviest in the Act. Providers must draw up technical documentation before placing the system on the market and keep it current throughout the system's lifetime. Deployers inherit downstream obligations, including ensuring human oversight is actually implemented and logs are retained and accessible.

Limited-risk AI audit log evidence

Operators must inform users when they are interacting with an AI system, and systems generating synthetic content must mark outputs as artificially generated. Documentation centers on proving disclosures were made and instructions for use were provided.

Internal controls for low-risk AI

Minimal-risk systems carry no mandated documentation requirements, but baseline internal governance remains advisable. An AI system's risk classification can change if its intended use expands, and regulators will scrutinize whether your organization has a documented process for classifying all AI systems in use.

Documenting high-risk AI for EU Act audits

The documentation burden for high-risk systems flows primarily from Article 11 and Annex IV, which define nine mandatory sections for the technical file.

Documenting Article 11 for compliance

Your Annex IV technical file must address the following documentation requirements (summarized from the official Annex IV structure for readability):

1. General description: System purpose, provider identity, version, and hardware dependencies.
2. Design and development: Algorithms, design choices, expected output quality, and trade-offs.
3. Data governance: Training and validation dataset sources, labeling procedures, and quality measures.
4. Risk management: Lifecycle risk assessment, bias testing, and fairness metrics by protected group.
5. Human oversight: Intervention options, stop mechanisms, and competency profiles for supervising personnel.
6. Monitoring and control: Performance capabilities, failure modes, and oversight measures.
7. Performance metrics: Appropriateness of selected metrics for the specific system.
8. Lifecycle changes: A running record of all changes to data, models, and governance configurations.
9. Post-market monitoring plan: How you will detect and respond to risks after deployment.

Annex IV is a living document. Every model update and governance configuration change must be recorded in section eight.

Traceable training data for EU compliance

Article 10 requires high-quality training datasets with documented data provenance. You must record where training data originated, what preprocessing steps were applied, which data was excluded and why, and what bias testing was performed. The CycloneDX ML-BOM specification provides a machine-readable format that supports Article 10 data lineage requirements. To satisfy the Act, extend the standard component metadata with fields covering:

• Intended purpose and risk classification (Annex IV §1)
• Bias testing methodology and results by protected group (Article 10(2)(f))
• Human oversight configuration and intervention options (Article 14)
• The governance policy applied at the time of each training data version (Article 9)

EU AI Act risk documentation

Article 9 mandates a risk management system covering the full AI lifecycle. You must document identified risks by category, the mitigation measures applied to each, evidence those measures were tested before deployment, and your monitoring plan for detecting risks post-deployment. Risk documentation is a continuously updated record, not a one-time pre-launch assessment.

Human intervention audit records

Article 14 defines human oversight requirements and the documentation that proves those requirements are met. Recommended practice is to record the initiating person, timestamp, reason for the halt, and restart authorization chain. Training for oversight personnel must cover the system's known limitations, how to interpret its outputs, and override procedures, with documentation refreshed when the AI system changes significantly.

Required evidence for each AI risk level

The documentation a regulator will request varies depending on how an AI system is classified. The sections below outline the specific evidence requirements across registration, post-market monitoring, transparency disclosures, and vendor accountability.

High-risk AI: registration audit log

Before a high-risk AI system goes to market, providers must complete a conformity assessment and register the system in the EU database (see the EU AI Act implementation timeline for the registration sequence). The EU Declaration of Conformity references the Annex IV technical file and the applicable standards against which conformity was assessed, making it the first document a regulator will request. Prediction Guard's AI System registration captures models, Model Context Protocol (MCP) servers, and datasets into governed AI Systems and exports a structured inventory as an AIBOM in CycloneDX format as a byproduct of that registration. For background on how that registration and export process works, see Why we built AIBOM export with CycloneDX into Prediction Guard.

High-risk AI: required monitoring documentation

Post-market monitoring under Article 72 requires a proactive system to collect, document, and analyze data on the AI system's performance in real deployment conditions. Your monitoring documentation must show that the process for detecting risks and reporting serious incidents is active, not just designed. A six-month log record populated with structured interaction data is the evidence base your post-market monitoring relies on.

Limited-risk AI transparency audit

Article 13 requires instructions for use to include information on capabilities and limitations, accuracy levels, known risks, and logging mechanisms. For limited-risk systems under Article 50, the transparency record centers on disclosure logs showing users were informed they were interacting with AI, and that synthetic content was marked as artificially generated at output.

Managing AI risk with vendor documentation

The deployer remains accountable for log retention and accessibility even when the AI system was built by an external provider. Article 19 specifies that providers shall keep automatically generated logs to the extent such logs are under their control. That phrase carries significant compliance weight. If a third-party vendor generates and stores your AI governance logs in their own infrastructure, without you holding an independent, continuously replicated copy subject to your own retention policies, those logs are not under your control in the sense Article 19 requires. This is the structural gap that external gateways create.

Preparing EU AI Act audit logs for regulators

Generating logs is necessary but not sufficient. The structure, integrity, and storage of those logs determine whether they hold up under regulatory scrutiny. The sections below cover the required fields, timestamp standards, immutability controls, and framework alignment regulators expect.

Required log fields for AI Act audits

For high-risk systems, Article 12 requires logging of events relevant to identifying risk situations, supporting post-market monitoring, and monitoring system operation. A compliant log record should capture at minimum:

• Timestamp
• Operator or user identifier
• AI input
• AI output
• Model version
• Governance policy applied
• Policy flags triggered

For biometric identification systems specifically, required fields also include the reference database checked, input data that produced a match, and the identity of the verifying persons.

Verifiable timestamps and audit logs

Chronological integrity is non-negotiable. Article 12 requires that high-risk AI systems technically allow for the automatic recording of events throughout their operational lifetime, meaning the capability for automatic log generation must be built into the system architecture, not delegated to developer discretion at runtime. Application code that writes timestamps after the fact, or developer-controlled logging libraries that can be omitted, do not meet this requirement. System-level enforcement, where the control plane intercepts every API call and writes the log entry before returning a response, produces verifiable timestamps without depending on developer discipline. For the compliance team, this means a timestamp record that holds up under an Article 12 inspection.

EU AI Act log immutability

Logs that can be deleted or modified after generation are mutable records with limited evidentiary value. Article 12 does not mandate specific tamper-prevention mechanisms, but logs that can be deleted or modified after generation carry reduced evidentiary value. Implementing data integrity measures is strongly advisable to preserve their usefulness in a regulatory inspection. Store logs in a SIEM (Security Information and Event Management) system with write-once retention policies, or forward them to an append-only log target.

The control plane generates the structured log record. Your SIEM stores and retains it. Conflating these two responsibilities creates a gap in either log integrity or retention policy. Keeping these responsibilities separate ensures the log record your auditor inspects is both structurally complete and subject to your own retention controls. The self-hosting and scaling models discussion covers the architectural reasoning behind keeping log generation inside your own infrastructure. It addresses specifically why delegating log control to vendor-hosted systems creates the Article 19 compliance gap described above.

Documenting EU AI Act compliance via NIST

NIST AI RMF provides a practical implementation methodology for meeting EU AI Act requirements. NIST AI RMF functions align directly with EU AI Act obligations: the Govern function supports Article 9 risk management, the Map function supports risk classification analysis, the Measure function supports conformity assessments, and the Manage function supports ongoing monitoring under Article 72. For a broader crosswalk between NIST AI RMF, ISO/IEC 42001, and the EU AI Act, see the EC Council cross-framework comparison. The AI Security & Safety Directory NIST AI RMF guide notes that organizations may align with NIST AI RMF to support EU AI Act compliance. Prediction Guard enforces NIST AI RMF policies at the system level across every model interaction, generating structured audit logs inside your own infrastructure, as outlined in the LLM threat modeling discussion.

Fortifying your AI governance program

A defensible compliance program requires more than a logging policy: it requires continuous enforcement, control deviation detection, and automated evidence collection. The sections below address each operational pillar of an audit-ready AI governance program.

Continuous AI Act compliance monitoring

The Council of the EU reached provisional political agreement on 7 May 2026 to move the high-risk compliance deadline to 2 December 2027 for stand-alone high-risk AI systems, and to 2 August 2028 for AI systems embedded in regulated products, under the Digital Omnibus on AI. The Digital Omnibus on AI is a European Commission legislative package published on 19 November 2025. Formal adoption is expected before the original 2 August 2026 deadline. Organizations that start their logging programs at the enforcement deadline will arrive with no audit log to show. Article 19 requires six months of logs accessible at any time. If you begin continuous logging today, you reach six months of retained, inspectable records well before the deadline. If you wait, you arrive at enforcement with a gap that cannot be retroactively filled.

Identifying control deviations post-review

Control drift is one of the most common EU AI Act preparation failures. A governance configuration accurate at your last review may not reflect the model version or policy rules currently in production. Manual audit cycles, typically quarterly or annual, cannot detect a configuration change an engineer made in week three. System-level enforcement prevents this: the control plane intercepts every API call, applies policy rules automatically, and generates a detection event at the moment any deviation occurs, not weeks later during a scheduled review. The EP03 session on agentic AI threats covers the specific risk patterns that ungoverned agent interactions create between cycles.

Automated evidence collection workflows

Manual evidence assembly produces inconsistent artifact quality and consumes compliance team capacity that is already stretched. Prediction Guard generates audit logs inside your own infrastructure, forwarding them natively into Splunk, Datadog, and generic SIEM/SOAR targets through direct integrations. The logs are available for inspection within your security team's existing workflows, not as a separate export process triggered when an auditor arrives.

AI System inventory for audit readiness

A regulator asking which models process regulated data in your organization expects a specific, documented answer. Organizations that have deployed AI capabilities faster than governance processes have captured them cannot produce that answer accurately or quickly. Prediction Guard's AI System registration captures models, MCP servers, and datasets into governed AI Systems. The AIBOM, exportable in CycloneDX format as a byproduct of that registration, provides the structured inventory that supports the Article 11 Annex IV requirements relating to model and dataset provenance (sections 1 and 3). Prediction Guard built CycloneDX AIBOM export directly into the control plane for this reason.

Robust AI logging for regulatory defensibility

Structural gaps in log generation, not just missing policies, are the most common reason high-risk AI deployments fail regulatory inspection. The sections below identify the specific failure patterns and the architectural controls that close them.

EU AI Act model traceability gaps

The most common traceability gap in high-risk AI deployments is the absence of a consistent model version record in operational logs. When an AI system is updated, operational logs may not consistently capture the version in use at the time of each interaction, leaving entries that cannot be reliably tied to a specific model version. This breaks the Article 12 reconstructability requirement. System-level log generation, where the control plane writes the model version at the time of each interaction, closes this gap structurally rather than relying on developer process discipline.

EU AI Act oversight compliance

Documented policies and actual system behavior are two different things. Regulators do not accept a written governance policy as proof that the policy was enforced. Article 12 logs are the evidence that enforcement happened in practice. Prediction Guard enforces NIST AI RMF and OWASP policies at the API level on every model call, generating a log entry for each interaction. This provides the system-level evidence that bridges the gap between policy text and operational reality. For a practical view of the control plane approach, see the controlling AI models from the inside discussion.

Documenting vendor AI risk for audits

External AI gateways and filters that retain logs do so in vendor-controlled infrastructure. Article 19 holds you accountable for logs to the extent they are under your control: when your compliance evidence lives in a third-party vendor's infrastructure, it is not under your control. If that vendor has a security incident, changes their retention policy, or is acquired, you lose access to evidence you are legally required to retain. Under Article 26, deployers bear direct obligations for how AI systems are used and how vendor arrangements affect log control and data handling, making supply chain documentation a first-order compliance concern, not an ancillary one.

Self-hosted deployment, whether on-premises, in a cloud VPC, or air-gapped, removes this structural vulnerability: when governance logic, policy enforcement, and log generation all run inside your own infrastructure, you control the evidence chain from end to end.

Managing external AI data risks

Prediction Guard closes this structural gap by deploying a sovereign AI control plane that ships with NIST AI RMF and OWASP policy enforcement built in and integrates with your existing SIEM for log retention, with no data transiting vendor infrastructure. The AI in national security discussion covers practical deployment considerations for regulated environments.

EU AI Act audit log: key insights

The sections below consolidate the core documentation requirements, retention obligations, and storage decisions that determine whether your compliance program is defensible at the point of inspection.

Immediate documents for EU AI Act audit

Under Article 21, providers of high-risk AI systems must supply competent authorities with all information and documentation necessary to demonstrate conformity, including access to automatically generated logs under Article 12. Three documents form the core of any high-risk AI inspection package:

1. EU Declaration of Conformity: Confirms the system was legally placed on the market following a completed conformity assessment.
2. Annex IV technical documentation: Covers all nine required sections, demonstrating that the system meets Article 11 requirements.
3. Article 12 automatically generated logs: Covers at least the last six months of operation, proving that governance controls are enforced in practice.

EU AI Act log retention rules

The Act sets two distinct retention requirements. Article 19 automatically generated logs must be retained for a minimum of six months from the time of generation. Article 18 technical documentation must be retained for ten years from the date the high-risk AI system is placed on the market. Both must be accessible to national competent authorities on short notice, not archived in offline systems.

Where to store EU AI Act audit logs

Your SIEM is the appropriate retention system: structured logs forwarded from the control plane into your SIEM sit inside your perimeter, are subject to your own retention policies, and are accessible to regulators without depending on a vendor's cooperation. For the full Article 19 control argument, see the Documenting vendor AI risk for audits section above.

Audit log gaps: compliance failure

A policy document that says your AI system is governed is not the same as a system-level audit log that proves it. The EU AI Act was written to close exactly that gap. Organizations that arrive at a regulatory inspection with document-based optimism and no continuously generated, system-level log record are exposed regardless of how thorough their written policies appear.

Book a deployment scoping call to assess whether self-hosted deployment fits your infrastructure and regulatory requirements.

FAQs

What specific data fields must a high-risk AI system log under Article 12?

Article 12 does not publish an exhaustive field list for all high-risk systems but requires that high-risk AI systems technically allow for automatic recording of events throughout their operational lifetime to support post-market monitoring and identification of risk situations. Every interaction log should capture at minimum: timestamp, operator ID, model version, AI input, AI output, governance policy applied, and any policy flags triggered. For biometric identification systems, mandatory fields also include start and end timestamps, the reference database checked, matching input data, and the identity of verifying personnel.

How long must EU AI Act audit logs be retained?

Automatically generated operational logs under Article 19 must be retained for a minimum of six months. Technical documentation under Article 18 must be retained for ten years from the date the system is placed on the market. Both must be accessible to national competent authorities on short notice.

When does full high-risk AI compliance apply under the EU AI Act?

Following provisional political agreement on 7 May 2026, the Council of the EU agreed to move the high-risk compliance deadline from 2 August 2026 to 2 December 2027 for stand-alone high-risk AI systems, and to 2 August 2028 for AI systems embedded in regulated products, under the Digital Omnibus on AI. Formal adoption is expected before 2 August 2026. Article 5 prohibitions have been enforceable since February 2, 2025. Organizations that begin continuous logging now reach six months of retained log evidence well before the December 2027 enforcement date.

What is the penalty for missing Article 11 technical documentation requirements?

Under Article 99, breaches of high-risk AI system requirements including technical documentation carry fines up to EUR 15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher.

Key terms glossary

AIBOM (AI Bill of Materials): A structured inventory of every AI component in a deployed system, including models, datasets, code, hardware dependencies, and governance configurations. Exported in CycloneDX format as a byproduct of AI System registration, it maps directly to Annex IV technical documentation requirements.

Article 12 logging: The EU AI Act requirement that high-risk AI systems automatically record events over their full operational lifetime, without operator intervention, enabling reconstruction of algorithmic decisions and supporting post-market monitoring. Minimum retention is six months under Article 19.

MCP server (Model Context Protocol server): A server implementing the Model Context Protocol, an open standard that enables AI models to connect to external data sources, tools, and services. MCP servers are captured as governed components in AI System registration because they extend model capabilities and introduce data flows that fall within the scope of Article 11 Annex IV technical documentation requirements.

Conformity assessment: The process by which a provider of a high-risk AI system evaluates that the system meets all applicable EU AI Act requirements before placing it on the market. The output is the EU Declaration of Conformity, a central document in any high-risk AI regulatory inspection.

Control drift: The divergence between documented governance policies and actual system behavior that occurs between formal audit cycles. System-level policy enforcement, where every AI interaction is governed at the API level automatically, prevents control drift by applying policy rules to every call regardless of configuration changes made outside formal review processes.