Under Article 12 of the EU AI Act, a high-risk AI system must be built to record events automatically across its lifetime, so risks can be traced and its operation monitored. For an AI agent, that log has to show what it read, what it tried to do, what was decided and who approved it.
What does Article 12 require, in plain words?
Article 12 is a design duty. A high-risk system must technically allow the automatic recording of events, usually called logs, for as long as it is in use. The logging must be good enough to support three things:
- identifying situations where the system may present a risk or has been substantially modified;
- the provider's monitoring of the system after it is placed on the market;
- the deployer's monitoring of how the system operates in its own use.
The Act sets more specific minimum contents for one category, remote biometric identification, such as the period of each use and the people who verified results. For everything else, it states the purpose and leaves the content to the provider. That is the gap agents fall into: a log designed for a scoring model records an input and an output, and an agent does far more than that between the two.
Who carries the duty?
The provider builds the logging capability. The deployer keeps the logs. Article 26 requires deployers of high-risk systems to keep the automatically generated logs under their control for a period appropriate to the system's purpose, with a minimum set in the Act unless other EU or national law, particularly data protection law, provides otherwise. Financial institutions can keep them as part of the records they already maintain under financial services law.
So a firm running a high-risk agent has two jobs: make sure the agent can produce a usable record, and retain and protect that record once produced. If you build the agent yourself, both jobs are yours.
What should an agent's log contain?
An agent plans, retrieves, calls tools, drafts and acts, sometimes across dozens of steps for one task. A log that only keeps the final message cannot reconstruct why money moved or why a customer was refused. We argue the point at length in Article 12 logging is not enough for agents; the short version is that the record must be built around actions, not conversations.
For each action an agent attempts, the record should hold:
- Identity. Which agent, which version of its brief, which certificate it held at the time.
- Instruction. The task or request that started the run, and who or what issued it.
- Sources. Each fact the agent relied on, with where it came from and its version.
- Proposed action. The tool or capability called, with its parameters, such as the payee and amount.
- Verdict. Whether the action was allowed, held for a person, refused or withheld, and which bound decided.
- Human step. If held, the named person who approved or rejected it, when, and what they saw.
- Outcome. What the downstream system reported back.
Our checklist of what an AI agent's record must capture expands each field. The test of the design is simple: pick any action from last month and rebuild the decision without asking anyone.
How do you meet Article 12 for an agent?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Automatic recording of events | Logging at the control layer that sits between the agent and every tool, so no action bypasses it | Complete action records, with no gaps between tool calls |
| Traceability of risk situations | Every verdict names the deciding bound; refused and held actions are logged as fully as allowed ones | Searchable record of refusals and holds by agent and reason |
| Detect substantial modification | Brief, source and model versions stamped on each record | Version history that ties behaviour changes to configuration changes |
| Support deployer monitoring | Records queryable by agent, capability, customer and outcome | Monitoring reports built from the record, not from samples |
| Integrity | Append-only storage; no edit or delete by operators | Tamper-evidence checks and access logs on the store |
| Retention | Retention schedule per record type, aligned with data protection law | Schedule, deletion jobs and their run history |
Integrity deserves emphasis. A log that an administrator can edit is a diary, not evidence. Append-only storage with tamper-evidence turns it into something a supervisor can rely on.
How do logging and data protection fit together?
Agent logs contain personal data: names, account details, message content. Keeping every word for years collides with the GDPR principle that personal data should be kept no longer than needed. The usual answer is to separate the event record from the content, keeping the action, verdict and source references for longer and the raw content for less. We work through the trade-off in EU AI Act record-keeping vs GDPR storage limitation.
What will a supervisor or auditor ask?
- Pick a case: show every action the agent took and why each was permitted.
- Show the actions that were refused or held last quarter, and who dealt with the held ones.
- Can anyone change or delete a record? Prove they cannot.
- How long do you keep logs, and on what basis?
- Which version of the agent was running on a given date?
- How do your monitoring reports use the logs?
What does Article 12 not cover?
It does not require logs for agents that are not high-risk, though most regulated firms will want the same record for any agent that touches customers or money. It does not say how long the provider must keep logs it does not control. It does not cover documentation of how the system was built, which sits in the technical documentation duties. And it does not make a chat transcript sufficient: the duty is about events relevant to risk, and for an agent those events are actions. Our guide to AI agent regulation, mapped to controls places logging alongside the other duties.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is a model provider's API log enough to meet Article 12?
No. It records prompts and completions, not the agent's tool calls, the bounds checked or the person who approved an action. The record that matters is produced where actions are decided, which is your control layer.
Do we have to log refused actions?
The Act does not list them, but a log that omits refusals cannot show that controls worked or identify situations that present risk. Treat a refusal as an event as important as an allowed action.
Can logs be stored outside the EU?
The Act does not set a location. Storage outside the EU is a data protection question, governed by GDPR's rules on international transfers, and may also be shaped by your financial regulator's record-keeping expectations.