AI Agent Audit Trails Under EU AI Act Article 12: What to Log, and for How Long
Article 12 requires high-risk AI systems to log events automatically over their lifetime, so that their operation can be traced. Providers and deployers must keep those logs for at least six months (Articles 19 and 26). Since the Digital Omnibus, this applies from 2 December 2027 for Annex III systems. For an agent, that means one record per consequential action: who acted, on whose authority, what it did, what it relied on, what checked it, and what happened next.
On this page
Logging a chatbot is easy: a question goes in, an answer comes out, and you keep both. Logging an agent is not. One request becomes a chain of model calls, tool calls and decisions, some of which change things in the world. And the logs that exist are usually written by the agent framework itself, which is to say by the system you would be auditing.
The EU AI Act's record-keeping rules were written before agents were common. They still apply, and for high-risk systems they say more about what logs are for than most teams realise.
This is a practical reading, not legal advice.
What EU AI Act Article 12 requires
Article 12 has three parts.
- Automatic logging, for the system's whole lifetime. High-risk AI systems must technically allow events to be recorded automatically while they run.
- Logs that serve traceability. Logging must give a level of traceability appropriate to the system's intended purpose. In particular it must record events relevant to three things: spotting situations where the system may present a risk or has been substantially modified; post-market monitoring under Article 72; and the deployer's monitoring of the system's operation under Article 26(5).
- A minimum list for one category. For remote biometric identification systems, the logs must include at least the period of each use, the reference database checked, the input data that led to a match, and the people who verified the results.
What Article 12 does not give you is a schema. Outside that one category, it defines logging by what the logs must let you do. For an agent, that bar is high. To trace how the system "functioned", you need to reconstruct what it did and why, one action at a time.
When Article 12 applies: the Digital Omnibus moved the dates
The high-risk obligations were due to apply from 2 August 2026. They no longer do.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It moved the dates:
| High-risk systems | Was | Now |
|---|---|---|
| Annex III (stand-alone: credit, employment, education, essential services and others) | 2 August 2026 | 2 December 2027 |
| Annex I (AI in products covered by EU product-safety law) | 2 August 2027 | 2 August 2028 |
Deferred is not cancelled. And a logging design has a lead time a calendar date hides: a log only covers the period after you start collecting it. If your agent will be in scope in December 2027, the record you'll need starts with whatever you deploy before then.
How long to keep AI agent logs: Articles 19 and 26
Two articles set the retention floor.
- Providers — whoever develops the system and places it on the market — must keep the automatically generated logs that are under their control for a period appropriate to the intended purpose, and at least six months (Article 19).
- Deployers — whoever uses the system in their own operations — have the same duty for logs under their control, again for at least six months (Article 26(6)).
Three things follow:
- Six months is a floor, not a target. Both articles yield to other Union or national law, which can set a different period.
- Financial institutions can keep these logs as part of the documentation their financial services rules already require.
- Data protection pulls the other way. Agent logs are full of personal data. Plan pseudonymisation, access control and deletion alongside retention, not after it.
If you build an agent in-house and run it yourself, you may well be both provider and deployer.
Is your AI agent high-risk at all?
Many agents will not be. The question is not what the system is but what it decides. Annex III lists the high-risk areas:
- biometrics
- critical infrastructure
- education and vocational training
- employment and worker management
- access to essential private and public services, including creditworthiness and risk assessment and pricing for life and health insurance
- law enforcement
- migration and border control
- the administration of justice and democratic processes
An agent that screens job candidates, scores credit, or prices health cover is a strong candidate. An agent that drafts internal summaries probably is not. Check yours against the annex, with counsel, before you design the logs.
What to log for an AI agent: 8 things per action
The Act tells you what the logs must make possible. This is a field list that makes it possible for an agent. Write one record per consequential action, not per conversation.
| # | Field | What it holds | Why it matters |
|---|---|---|---|
| 1 | When | Start and end time of the action, and of the session it belongs to | Ordering, and the "period of each use" Article 12 asks for in its strictest case |
| 2 | Which agent | Agent identity, model version, prompt and configuration version | Detecting substantial modification; knowing which version did what |
| 3 | On whose authority | The user, service account or delegated credential it acted under | Accountability, which agents running on shared service accounts lose |
| 4 | What it relied on | The request, plus references to the documents and tool results it used | Reconstructing why, not just what |
| 5 | What it did | The tool called, the arguments, the target system | The action itself, as executed |
| 6 | What checked it | Which control evaluated the action, its verdict, its version — or "unchecked" | Showing the control worked, and where it didn't |
| 7 | What happened | Executed, blocked, held or escalated, and the result | Outcome, for risk monitoring and incident review |
| 8 | Who intervened | Any person who reviewed, approved or overrode the action, and when | Human oversight under Article 14, recorded rather than asserted |
Field 6 is the one most often wrong, because a check that failed silently tends to be recorded as a check that passed. Record unchecked as unchecked. An audit trail that turns failures into approvals is worse than none.
Why an agent's own logs are not enough
Most agent stacks log through the framework that runs the agent. That is useful for debugging, and weak as evidence, for three reasons.
- It is self-reporting. The system under audit writes its own account. Process safety settled long ago that a system should not certify its own safety, and the same goes for its own record — the same separation principle behind independent stop paths.
- It fails together with the agent. The moment an agent misbehaves, crashes or loops is the moment its own logging is least reliable.
- It can be edited. Evidence needs tamper-evidence: append-only storage outside the agent's reach, ideally with each record chained to the last.
None of those three is spelled out in Article 12. All of them decide whether your logs will persuade an examiner, which is the point of keeping them. For the wider list of what to demand from a vendor, see what a governance platform must prove before compliance signs off.
Where Syntrox fits
Syntrox records, for each trace it evaluates, the judge's score and confidence and the exact judge version that produced them, next to the trace itself, outside the agent. That covers field 6 of the table above for the checks we run. It does not make anyone compliant. No certificate exists under the AI Act, and no vendor can sell you one. What a system like ours produces is evidence, and Article 12 is, in the end, a requirement for evidence.