Article 12 of the EU AI Act requires high-risk AI systems to technically allow the automatic recording of events (logs) over the lifetime of the system. For an AI agent that calls tools, that means the system has to be able to record, as it runs, the events that let someone trace a risk or an unplanned change back to what the agent did, support the provider's post-market monitoring, and support the deployer's monitoring of operation. Articles 19 and 26(6) then require the provider and the deployer to keep those logs, to the extent each controls them, for at least six months.
This post reads Article 12 and the articles around it for teams that build or run agents. It is narrower than our AI agent audit trail guide, which covers what any audit trail should record, why application logs fail an audit and how tamper evidence works. Here the questions are what this one article asks of an agent, who carries which duty, and what has to be kept. It is not legal advice on your classification or your role.
What Article 12 says
Article 12, Record-keeping
1. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.
2. In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for:
(a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification;
(b) facilitating the post-market monitoring referred to in Article 72; and
(c) monitoring the operation of high-risk AI systems referred to in Article 26(5).
3. For high-risk AI systems referred to in point 1 (a), of Annex III, the logging capabilities shall provide, at a minimum:
(a) recording of the period of each use of the system (start date and time and end date and time of each use);
(b) the reference database against which input data has been checked by the system;
(c) the input data for which the search has led to a match;
(d) the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5).
Source: Regulation (EU) 2024/1689, Article 12, as published in the Official Journal of the European Union.
Four phrases that carry the obligation
- "Technically allow." Article 12 is a design requirement on the system, so it falls on the provider. A deployer cannot meet it afterwards by keeping notes. Whether the logs are then collected and kept is the business of Articles 19 and 26(6), and Article 13(3)(f) asks the instructions for use to describe, where relevant, the mechanisms that let deployers properly collect, store and interpret the logs.
- "Automatic recording of events." The system writes the events as it runs. A timeline rebuilt afterwards from chat transcripts, tickets and memory is not an automatic record.
- "Over the lifetime of the system." From first use to retirement, including after updates. Logging that starts after an incident, or stops during a migration or a model change, leaves a gap in exactly the period a reviewer will ask about.
- "Appropriate to the intended purpose." The level of traceability scales with what the system is for. Article 12 names the purposes the logs must serve, not a list of fields, so the provider decides which events serve them and documents why.
What "automatic recording of events" means for an AI agent
A chat model produces text; an agent acts. Most of what an agent does happens through tool calls: to an MCP server, an internal API, a database or another agent. That is the point where a model's output becomes a change in the world, so it is where the events relevant to Article 12 are generated. A log of prompts and completions on its own shows what the model said, not what the agent did.
Read against the three purposes in Article 12(2), the events an agent system should be able to record look like this.
| Article 12(2) purpose | What the logs have to support | Agent events that serve it |
|---|---|---|
| (a) A risk within the meaning of Article 79(1), or a substantial modification | Spotting situations in which the system may put health, safety or fundamental rights at risk, or has changed beyond what its conformity assessment covered | The tool calls the agent attempted and the control decision on them (allowed, denied or held); findings from checks on a call's arguments and results; a tool that appears on, or is renamed by, a connected server; a change of model, system prompt, tool set or policy version |
| (b) Post-market monitoring under Article 72 | The provider's systematic collection and analysis of performance data over the system's lifetime, including, where relevant, its interaction with other AI systems | Outcome, denial and error rates over time; calls between agents, with which agent delegated to which |
| (c) The deployer's monitoring of operation under Article 26(5) | The deployer watching operation on the basis of the instructions for use, and informing the provider and authorities and suspending use when a risk appears | Human approvals, rejections and overrides; an agent being stopped or revoked; alerts raised, and who acted on them |
Three properties of agents make this harder than for a single model behind an API:
- Fan-out. One user request can lead to dozens of tool calls and calls to other agents. Unless one identifier for the run travels with them, the log holds events but not the sequence that connects them.
- Delegation. When one agent asks another to act, the record has to say which agent acted on whose behalf. Article 72(2) names the analysis of interaction with other AI systems as part of post-market monitoring where relevant, and that analysis needs the delegation recorded.
- Capabilities that change without a release. An MCP server can add or rename tools while the agent's own code stays the same. A new tool changes what the system is able to do. Whether that amounts to a substantial modification is the provider's judgement, and the log is what lets the provider see that the change happened.
An Article 12 event record, field by field
Article 12 does not prescribe fields. A record that serves the three purposes above usually answers seven questions, the same seven the AI agent audit trail guide uses for audit evidence in general. Below, each field is mapped to the Article 12(2) purpose it serves.
| Field: the question it answers | Illustrative scenario: a support agent | What it does for Article 12(2) |
|---|---|---|
| Who: which agent acted, for which application or person? | Support agent | (b) and (c): ties trends and incidents to one system the deployer can monitor and, if needed, suspend |
| What: what did it try to do, with which parameters? | Export 40,000 customer records | (a): the situation that may present a risk |
| Target: which tool, system or data would it touch? | Customer database / bulk export tool | (a): what the action would have reached |
| Policy: which rule applied, at which version? | Restricted bulk export | (a): a new version marks a change in how the system behaves |
| Decision: allowed, denied or held, and by whom? | Denied | (c): shows the control operated; (b): denial rates over time |
| Result: what actually happened afterwards? | Nothing is exported | (a) and (c): whether a risk materialised |
| Proof: what lets someone check this later? | Audit record of the denial | Lets the record be relied on when it is kept under Articles 19 and 26(6), or given to an authority |
Illustrative scenario: the agent, volume and rule are examples, not customer data, and say nothing about whether such an agent is high-risk. In Praesidia a denial applies once a policy is set to enforce; the default, observe mode, records the decision and lets the call through.
Article 12(3): the only fixed minimum
Only one category of system gets minimum log contents written into the Act: the remote biometric identification systems in point 1(a) of Annex III. Their logs must record the period of each use, the reference database checked, the input data that led to a match and the natural persons who verified the results. Few agent deployments fall into that category, but the list is a useful model of what "traceable" means in practice: when the system ran, against what, on which input, and which people confirmed the outcome.
For any other high-risk system, the provider chooses the events and documents the choice. Under Article 40, a high-risk system that conforms to harmonised standards whose references are published in the Official Journal is presumed to conform to the requirements those standards cover, so check which standards, if any, are cited for logging when you design the capability.
Who does what: providers, deployers and the articles around Article 12
Article 12 is one article in a chain. The duties to keep the logs, hand them over and use them sit elsewhere.
| Article | Who | What it asks |
|---|---|---|
| 12 | Provider | Build in the capability to record events automatically over the system's lifetime, at a level of traceability appropriate to its intended purpose |
| 13(3)(f) | Provider | Describe in the instructions for use, where relevant, the mechanisms that let deployers properly collect, store and interpret the logs |
| 19 | Provider | Keep the automatically generated logs, to the extent they are under the provider's control, for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise |
| 21(2) | Provider | On a reasoned request, give the competent authority access to those logs, to the extent they are under the provider's control |
| 26(5) | Deployer | Monitor operation on the basis of the instructions for use; where there is reason to consider that the system presents a risk, inform the provider or distributor and the market surveillance authority without undue delay, and suspend its use |
| 26(6) | Deployer | Keep the logs the system generates automatically, to the extent they are under the deployer's control, for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise |
| 18 | Provider | For comparison: technical documentation and quality-management documentation are kept for 10 years after the system is placed on the market or put into service. That period applies to documentation, not to logs |
Financial institutions get a variant: under Articles 19(2) and 26(6), providers and deployers that are subject to internal-governance requirements under Union financial services law keep the logs as part of the documentation that law already requires.
When an agent team is the provider
Many teams assemble an agent from a third-party model, tools and prompts and use it in-house. Who is the provider of that agent system depends on who develops it and puts it into service under its own name. Article 25(1) also makes a deployer or another third party the provider of a high-risk system when it puts its name or trademark on one, makes a substantial modification to one, or changes the intended purpose of a system so that it becomes high-risk. A team that builds an agent for a high-risk use may therefore carry the provider's Article 12 duties as well as the deployer's. Settle the role, with counsel, before designing the logging.
What deployers keep under Article 26(6)
Three phrases in Article 26(6) decide what a deployer has to do with the logs.
"To the extent such logs are under their control." If the agent runs on a provider's platform, the deployer may control only what it can export. Agree in the contract which logs you can obtain, in what format and how quickly, and keep your copy in a system you control.
"A period appropriate to the intended purpose … of at least six months." Six months is a floor, not a target. Write down the period you chose and why, and keep the logs longer where the purpose, an investigation or a sector rule calls for it.
"Unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data." Agent logs often hold personal data: a customer's name in a tool's arguments, a record in its result. The GDPR's data-minimisation and storage-limitation principles in Article 5(1)(c) and (e) still apply to those logs, so record what the purposes need, redact what they do not, and set a deletion point. How that balance works for agents is on GDPR and AI agents.
A kept log is only useful if someone outside the team can rely on it. A record that can be checked for later changes, and a stated limit on what the record covers, are what make that possible; the techniques are explained in tamper-evident audit logs with cryptographic proofs.
Is your agent in scope?
Article 12 applies to high-risk AI systems. Whether an agent is one depends on its intended purpose, not on its technology: it is high-risk if it is used in an area listed in Annex III, such as employment, education, access to essential private and public services including creditworthiness, law enforcement, migration or the administration of justice, or if it is a safety component of a product covered by Annex I. Many internal agents, such as a coding assistant or an internal search agent, fall outside both lists, but the answer turns on what the agent is used for. The method is in classifying an AI agent under the EU AI Act's risk tiers.
The high-risk obligations apply in phases. The dated timeline, and what the Digital Omnibus changed, are on EU AI Act compliance for AI agents; this post does not repeat the dates.
An Article 12 checklist for agent teams
- Classify each agent by intended purpose, and record the reasoning.
- Decide your role for each high-risk system: provider, deployer or both (Article 25).
- Capture events where the agent acts, at the tool-call boundary, not only at the model.
- For each of the three Article 12(2) purposes, write down which events you record and why. Providers carry that description into the technical documentation and, under Article 13(3)(f), into the instructions for use.
- Record changes to what an agent can do: new or renamed tools, model and prompt changes, policy versions.
- Carry one identifier through a run, including calls delegated to other agents.
- Set and document the retention period: at least six months, longer where the purpose or other law requires it, and no longer than data-protection law allows.
- Make sure the logs you must keep are under your control: who exports them, in what format, and where your copy lives.
- State coverage: which agent paths produce events, and which do not.
- Rehearse handing one period's logs to an auditor or authority, and check that they can verify them without your help.
Where Praesidia fits
Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. A signed record shows it was not changed afterwards. It does not show that every action was captured. External anchoring is optional; without it, removal of the most recent records cannot be detected. Calls that do not pass through Praesidia are not recorded.
For Article 12, that makes Praesidia one source of events for the agent paths you route through it, not the whole of a high-risk system's logging. The events the system itself generates, and any path that bypasses Praesidia, still have to be covered and documented.
- A copy under your control. Organization owners and compliance officers can export a signed bundle for a chosen period, so the copy you keep under Article 26(6) sits in your own systems. Your auditor checks it on their own machine with a verifier we provide to you and your auditor; it never calls Praesidia. What it checks, and what it does not, is on verify your audit trail offline.
- Observe first, then enforce. New policies start in observe mode: the decision is recorded and the call goes through unchanged. Denials and holds apply once a policy is set to enforce. Approving a held call is in every plan; multi-step approval workflows are Enterprise.
- Classification first. An automatic run only suggests a risk tier; a person concludes the classification with an assessment that records the intended purpose and the rationale. EU AI Act risk classification, impact assessment and AI-literacy register are on the Advanced tier and Enterprise; EU AI Act technical documentation and post-market monitoring are Enterprise (pricing).
Controls are mapped to the EU AI Act, not certified against it: the evidence supports your assessment and does not grant a certification. The article-by-article mapping is on EU AI Act compliance for AI agents.
Common questions
What does Article 12 of the EU AI Act require?
Article 12 requires high-risk AI systems to technically allow the automatic recording of events (logs) over the lifetime of the system. The logs have to support three purposes: identifying situations that may result in a risk or a substantial modification, facilitating the provider's post-market monitoring under Article 72, and the deployer's monitoring of operation under Article 26(5).
Does Article 12 apply to every AI agent?
No. It applies to high-risk AI systems: those used in an area listed in Annex III or that are safety components of products covered by Annex I. Many agents fall outside both. Classification depends on the intended purpose, so an agent built on the same model can be high-risk in one use and not in another.
What should an Article 12 log contain for an AI agent?
Article 12 sets purposes, not fields, except for remote biometric identification systems in Article 12(3). For an agent, a useful record names the agent, the action and its parameters, the target, the policy and its version, the decision, the result and what lets someone check the record later. Changes to the agent's tools, model, prompts and policies belong in the log too, because they bear on whether the system has been substantially modified.
How long must Article 12 logs be kept?
Articles 19 and 26(6) require providers and deployers to keep the logs under their control for a period appropriate to the intended purpose of the system and of at least six months, unless other Union or national law, in particular data-protection law, provides otherwise. Six months is a minimum. Technical documentation has a separate 10-year period under Article 18.
Who is responsible for Article 12 logs, the provider or the deployer?
Both, for different things. The provider builds the logging capability (Article 12), describes it in the instructions for use (Article 13(3)(f)), keeps the logs under its control (Article 19) and gives authorities access on request (Article 21(2)). The deployer monitors operation (Article 26(5)) and keeps the logs under its own control (Article 26(6)). A deployer can become a provider under Article 25(1).
Does Article 12 require tamper-evident or signed logs?
Article 12 does not name a technique for protecting logs. Tamper evidence helps a provider or deployer show that a kept log was not changed after it was written, which matters when the log is handed to an auditor or an authority. It does not show that every relevant event was captured; that depends on coverage, which should be documented.
When does Article 12 apply?
Article 12 applies once the high-risk obligations apply to the system in question, and those apply in phases that depend on whether the system falls under Annex III or Annex I. The dated timeline is on EU AI Act compliance for AI agents.
Further reading
- AI agent audit trail: the complete guide: what any audit trail should record, why application logs fail an audit, and how tamper evidence and offline checks work.
- EU AI Act compliance for AI agents: the article-by-article control mapping and the dated timeline.
- Classifying an AI agent under the EU AI Act's risk tiers: whether Article 12 applies to your agent at all.
- The EU AI Act explained for engineering teams: the regulation as a whole, for engineers.
- How to audit AI agent activity: reconstructing one agent action from the record.
Primary source: Regulation (EU) 2024/1689, the EU AI Act, Articles 12, 13, 18, 19, 21, 25, 26, 40, 72 and 79, and Annex III.