EU AI Act logging: what agents must record

If you operate a high-risk AI system in the EU, Article 12 requires it to automatically record events over its lifetime, in a form that lets someone reconstruct what happened afterwards. The obligations for high-risk systems have applied since 2 August 2026. For agent builders the practical consequence is specific. A log the agent produces about its own behaviour is unlikely to satisfy a rule whose purpose is independent reconstruction.

We are not lawyers, and this is not legal advice. Whether your system is high-risk at all is a question for a lawyer, and it should be answered first. What follows is what the text says and what it implies for how you build a trace.

What does Article 12 require?

The key sentence is short. Article 12 states that "high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system."

Three phrases in that sentence matter most. Technically allow makes logging a property of the system, not of your process. A policy saying staff will keep records does not satisfy it. Automatic excludes anything a person compiles afterwards. Over the lifetime rules out logging that only begins when an investigation does.

The article then says what the logging has to make possible: identifying situations where the system may present a risk or undergo substantial modification, supporting post-market monitoring, and letting deployers monitor operation. Those are reconstruction jobs. They describe a record somebody reads later to work out what occurred.

Why does self-reported telemetry sit badly with this?

Because the log and the thing being logged have the same author.

When an agent writes its own trace, the record of what it did is produced by the component whose behaviour is in question. It is usually accurate. But it is not independent, and independence is what the obligation exists to create. If an agent misunderstood its task, its self-report will faithfully record the misunderstanding as though it were the intent.

There is a second, more ordinary problem. An agent that crashes, hangs or is killed writes nothing about the moment that matters most. A record kept along the path the call took survives the failure of the agent that made the call.

This is why a gateway matters for compliance as well as for control. The component that issues the token and forwards the call can record that call, whatever happens to the agent afterwards.

What does "appropriate" logging look like in practice?

The regulation does not give you a schema, and anyone selling you one as mandated is overstating it. What the surrounding requirements imply is fairly consistent, though:

• Append-only. A record that can be edited after the fact is of little use to anyone trying to find out what happened. Chaining each entry to the one before it by hash means tampering can be detected, not only forbidden.
• Refusals as well as actions. A blocked call is the kind of event that indicates a system presenting a risk. If you log only what succeeded, you lose the most useful half of the record.
• Retention you can meet. The Act sets a minimum for keeping automatically generated logs: at least six months where the provider controls them. Other law may require longer.
• Redaction at capture, not afterwards. If you filter personal data out of a trace store later, it was stored there first. Article 12 applies alongside GDPR and does not replace it. A log that solves traceability by keeping everything has swapped one problem for another.
• Identity on the record. Record which agent acted, for whom, and under what authority. "The system did X" cannot be reconstructed. "This key, issued for this contract, called this tool" can.

Does human oversight change the design too?

Yes. It is usually the second requirement people notice.

Article 14 requires high-risk systems to be designed so that people can effectively oversee them, with measures proportionate to the risk and the level of autonomy. The word "effectively" matters a lot here. A dashboard that nobody is accountable for reading is not obviously effective oversight. Oversight that can stop the system is much easier to call effective.

In practice this points to two mechanisms. The first is a checkpoint before anything irreversible, so a person approves the action before it happens instead of reviewing it afterwards. The second is a halt that takes one action, not a deployment. If stopping the system needs a release first, you cannot stop it at the moment you need to.

What should you do if you are not sure you are in scope?

Ask a lawyer, and instrument anyway.

Scope is uncertain for a lot of agent deployments, and it would be wrong of us to tell you otherwise with confidence. But the costs are very uneven. A tamper-evident trace written by a gateway is cheap to build at the start and expensive to add later. If you add it later, you have no record covering the period before you started.

It is worth doing even when no regulator is involved. Every reason Article 12 gives for wanting reconstructable logs is a reason you already have: working out why an agent did something strange, showing a customer what happened, and finding out who authorised a change six months after the person who knew has left.

In Cognibl the gateway writes the trace, not the agent. Entries are append-only and hash-chained, so the chain re-verifies end to end. Refusals are recorded alongside calls. Redaction happens at capture according to the policy map, not as a later cleanup.