EU AI Act Article 12 for AI agents: what to log, with working code
Since August 2026, the EU AI Act’s high-risk obligations are enforceable, and Article 12 is the one that lands on engineering: the system must automatically record events over its lifetime, the record has to hold up to after-the-fact verification, and it must be kept for at least six months. This guide covers what that means for AI agents specifically, why ordinary logs fail the reading, and a working, self-hosted implementation. It is written by a builder, not a lawyer, and it is not legal advice.
What does Article 12 actually require?
Read plainly, Article 12 requires high-risk AI systems to technically allow the automatic recording of events (logs) over the system’s lifetime, and those logs must make three things possible: identifying situations where the system may present a risk, supporting post-market monitoring, and monitoring the system’s operation. The companion duties in Articles 19 and 26 make providers and deployers keep those logs for at least six months, longer where other law applies.
Two words in that reading carry most of the weight for agents: events, and verification. An agent’s consequential event is not “an HTTP request happened”. It is “the agent decided to do something, on the basis of what it believed”. And a record you cannot verify after the fact, because the system could have rewritten it, is a diary, not evidence.
Why do ordinary logs fail for agents?
- They record actions, not reasons. The regulator question, and the client security review question, is why the agent acted. If the memory that produced the intent overwrote its own history when facts changed, the reason is unrecoverable.
- They lose the conflict. When two sources disagreed and the system silently picked a winner, the log shows the winner acting and nothing else. The risky situation Article 12 wants identifiable is exactly that disagreement, and it is gone.
- They are editable. A mutable store fails the verification reading. The record needs to be append-only, and ideally provably so.
- They collide with GDPR instead of coexisting. Article 12 wants retention; GDPR wants erasure on request. A record that cannot execute a real deletion without destroying its own verifiability fails one law to satisfy the other.
The four properties a compliant agent record needs
Strip the legal text to engineering requirements and you get four properties. Each maps to a concrete mechanism below.
- Reconstructable belief: what did the agent believe at the moment it acted, with provenance per belief.
- Preserved conflict: when sources disagreed, both sides on record, with which one was believed.
- Named authority: who approved a risky action, recorded with the decision, refusals included.
- Tamper evidence: proof the record was not quietly rewritten afterwards.
A working implementation
The following runs on your own infrastructure with pip install omem-infrastructure. OMEM is an open-source (MIT) memory and accountability layer for agents; each block below is the mechanism for one property.
Tamper evidence is structural rather than an API call: the record is an append-only operations log, and the engine that interprets it is frozen. It must replay the log to a byte-identical state, and that replay is verified continuously (a CI test also tampers with one operation and requires the check to fail, so the proof is proven able to fail). An upgrade cannot rewrite recorded history.
And the GDPR coexistence: erasure is a real, first-class operation, not a soft delete. One request rewrites the person’s data out of the record, replay-verified before anything is touched; what remains is a hash, counts, and a date. So the record satisfies retention and lawful deletion at the same time.
Frequently asked questions
Does the EU AI Act require logging for AI agents?
For high-risk AI systems, yes. Article 12 requires the system to technically allow automatic recording of events over its lifetime, and the logs must make it possible to identify risky situations, support post-market monitoring, and monitor operation. Providers and deployers must keep the logs, at least six months under Articles 19 and 26, longer if other law such as GDPR applies.
Are ordinary application logs enough for Article 12?
Usually not for agents. A log line records that an action happened, but an agent's consequential event is why it believed the action was right. If the memory behind the agent overwrites facts on conflict, the state that explains a past decision is gone, and the record cannot support the after-the-fact verification the article expects.
How long must AI agent logs be kept under the EU AI Act?
At least six months, per Article 19 for providers and Article 26 for deployers, and longer where other applicable law requires it. GDPR can also require deletion of personal data, so the record needs to support both retention and lawful erasure at once.
What should an AI agent audit log contain?
Four things, at minimum: what the agent believed at the moment it acted and where each belief came from; what conflicted and which side was believed; who authorised any risky action, by name; and enough integrity protection that the record can be shown not to have been quietly rewritten afterwards.
The honest caveats
Whether your agent is a high-risk system under the Act is a legal classification that depends on what it does; ask a lawyer, not a README. And no tool makes a system compliant by itself: Article 12 sits inside a wider set of obligations (risk management, human oversight, documentation). What a builder controls is whether the technical record can support those obligations at all. That is the part this page, and OMEM, is about.