EU AI Act Audit Trail Requirements 2026

Contents

What is an audit trail in AI systems
What information the AI Act requires to be logged
How long records must be kept
Who has access to the logs
How to implement the audit trail in practice
Option 1: Inference-integrated logging
Option 2: Audit middleware
Option 3: Application-layer logging
Privacy and logs: the conflict with GDPR
What happens if the audit trail is incomplete or absent
Design for the audit trail from the start
How Yeeply can help

One of the most concrete technical requirements the EU AI Act imposes on high-risk AI systems is automatic logging: the system must be capable of generating records that allow its behaviour to be reconstructed after it has made or assisted a decision.

This is not an abstract requirement. The AI Act specifies the type of information that must be logged, and August 2026 is when these obligations take effect for most systems. This guide explains what to record, how, and for how long.

What is an audit trail in AI systems

An audit trail is a chronological sequence of records documenting a system’s inputs, processing and outputs over time. In conventional systems it has existed for decades for security and compliance purposes. In high-risk AI systems, the AI Act makes it mandatory and specifies the minimum content of those records.

The regulatory objective is concrete: if an AI system assists a decision affecting a person — evaluating a job candidate, rejecting a loan or recommending a diagnosis — it must be possible to reconstruct exactly what inputs the system received and what outputs it generated, so the decision can be audited afterwards.

What information the AI Act requires to be logged

Identify the period of operation of the system
Record the inputs the system processed for each decision or assistance
Record the outputs for each decision
Identify the people responsible for overseeing the system in each operation
Detect and record risk situations or operational anomalies

Field	Description
timestamp	Exact date and time of each operation
input_hash or input_id	Reference to the input data (without necessarily storing raw data, for privacy)
output	The decision or recommendation generated
model_version	Version of the model that generated the output
confidence_score	Confidence score or probability if applicable
human_override	Whether a human intervened to modify or reject the output
operator_id	Identifier of the human operator or supervisor
context_flags	Any anomaly flags or risk situations detected

How long records must be kept

The AI Act requires records to be retained for a minimum of six months unless otherwise required by applicable EU or national law. In practice, for many systems in regulated sectors such as finance or healthcare, retention periods may be significantly longer — 2, 5 or even 10 years — due to overlap with other regulations.

Who has access to the logs

National supervisory authorities: full access rights for audits and investigations
The system deployer: must be able to access logs to manage the system and document usage
Affected persons: entitled to receive information about the decision that affected them, but not necessarily direct access to the full log

How to implement the audit trail in practice

Option 1: Inference-integrated logging

The cleanest architectural option is to instrument the AI system directly at the inference layer: each call to the model automatically generates a log entry before returning the output to the application. This guarantees the record is complete and cannot be accidentally omitted.

Option 2: Audit middleware

For systems where modifying the model code is not feasible — for example, using third-party models via API — a middleware layer can intercept model calls, record inputs and outputs, and send them to a log store before returning the response.

Option 3: Application-layer logging

If the system already has an application layer orchestrating model calls, logging can be implemented there. The risk with this option is that if the application layer changes or encounters errors, logging may be incomplete.

The biggest technical challenge of AI audit trails is their intersection with GDPR. Input data may contain personal data — and GDPR requires minimising it and not retaining it longer than necessary.

Pseudonymisation: inputs are stored with a reference ID, not raw personal data. The personal data stays in a separate system that is only cross-referenced during audits
Input hashing: store the hash of the input, not the input itself — this allows verifying whether a specific input was processed without exposing the data
Log separation: the AI Act audit log and the personal data log are separate systems with differentiated access

What happens if the audit trail is incomplete or absent

Missing adequate records in a high-risk system constitutes AI Act non-compliance, subject to fines of up to €15 million or 3% of global turnover. Beyond the fine, the inability to audit a decision can generate additional civil liability if that decision caused harm to a person.

Design for the audit trail from the start

The practical conclusion is that an audit trail is significantly cheaper to implement when designed from the outset than when retrofitted to a system already in production. Retrofitting logging to legacy systems can be complex and expensive, especially if the model was not originally instrumented for it.

How Yeeply can help

At Yeeply we work with certified companies specialising in AI architectures that already incorporate AI Act logging and traceability requirements into their design patterns. Whether you need to audit an existing system or design a new one with compliance built in, we can connect you with the right technical team.

For budget-constrained projects, we also work with specialist Spanish teams offering the same technical guarantees at 30–40% lower cost. Use the Request a quote button at yeeply.com/en or write to sales@yeeply.com.