EU AI Act Article 12: logging for AI agents

Article 12 of the EU AI Act requires that high-risk AI systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system” (Regulation (EU) 2024/1689). When the system is an AI agent, the open questions are what an “event” is, who produces the record of it, and whether a record the agent itself writes can satisfy the article’s purpose.

This post reads the article from an agent builder’s point of view: the text, the roles it binds, the systems it covers, the retention rules that sit next to it, and the dates. It is part of the guide to audit trails for AI agents under the EU AI Act. Where we go beyond the text we say “in our reading”, and none of it is legal advice.

What does Article 12 actually say?

Article 12 is short. It has a one-sentence core, a purpose clause, and a minimum content list that applies to one category of system only. The quotations below are from the Regulation as published in the Official Journal in July 2024 (Regulation (EU) 2024/1689).

Article 12(1) is the core: “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”

Article 12(2) sets the purpose. Logging capabilities must give “a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system”, and must enable the recording of events relevant for three things:

• identifying situations that may result in the system “presenting a risk” in the sense of Article 79(1), or in a substantial modification;
• facilitating the provider’s post-market monitoring under Article 72;
• monitoring the operation of the system by the deployer under Article 26(5).

Article 12(3) adds a minimum for one category: high-risk systems under Annex III, point 1(a), which are remote biometric identification systems. For those, the logs must at a minimum record the period of each use with start and end times, the reference database the input was checked against, the input data that led to a match, and the identification of the natural persons who verified the results.

For every other high-risk system, including every agent that is high-risk because of its use, the Regulation does not list what a log must contain. The content is set by the purpose in Article 12(2): enough traceability, for this intended purpose, to support risk identification, post-market monitoring and the deployer’s monitoring.

Three words carry the weight in our reading. “Automatic” means the record is produced by the system as it runs, not assembled afterwards from memory or from the system’s own summary. “Over the lifetime” means logging is a standing property of the system in operation, not a one-off exercise before release. “Traceability” means the record must let someone work out, later and without the system’s help, what the system did.

Who has to comply: providers, deployers, and teams that are both

Article 12 is written as a requirement on the system, and the Regulation places the duty to meet the Section 2 requirements on the provider. Article 16(a) says providers of high-risk AI systems shall “ensure that their high-risk AI systems are compliant with the requirements set out in Section 2”, and Article 12 is in Section 2 (Regulation (EU) 2024/1689).

The Regulation defines the two roles in Article 3. A provider is a person or body “that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark”. A deployer is a person or body “using an AI system under its authority”, except for personal non-professional use (Regulation (EU) 2024/1689).

The logging duties split along that line.

For agent teams the roles often collapse into one organisation. A company that wires a third-party model into its own agent and runs that agent in-house has developed an AI system and put it into service under its own name. In our reading that makes it a provider of the agent, and because it also uses the agent under its authority, a deployer as well. It then carries both the design duty and the retention duty.

Article 25 reinforces this. A deployer or other third party is treated as a provider, with the provider’s obligations under Article 16, if it puts its name on a high-risk system, makes a substantial modification to one, or modifies the intended purpose of a system, “including a general-purpose AI system”, so that it becomes high-risk (Regulation (EU) 2024/1689). Building an agent that takes a general-purpose model and points it at an Annex III use is, in our reading, close to the situation Article 25(1)(c) describes. This is one of the places where a team should get its own legal advice rather than rely on a blog post.

Which agents count as high-risk?

Article 12 binds only high-risk systems, so the first question for any agent is whether it is one. The answer depends on use, not architecture. Article 6 gives two routes in (Regulation (EU) 2024/1689).

Article 6(1): embedded in a regulated product. A system is high-risk if it is intended as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation in Annex I, and that product must undergo a third-party conformity assessment. Machinery, medical devices and vehicles are the kind of product Annex I covers.

Article 6(2): the Annex III uses. A system in one of the areas listed in Annex III is high-risk. The areas are biometrics; critical infrastructure; education and vocational training; employment, workers’ management and access to self-employment; access to essential private and public services and benefits; law enforcement; migration, asylum and border control; and the administration of justice and democratic processes.

Article 6(3): the derogation. An Annex III system is not high-risk where it “does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making”. The article lists when that applies: the system performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing the human assessment, or performs a preparatory task to an assessment. The derogation never applies where the system profiles natural persons.

For agents the practical reading is this. A coding agent that works on an internal tool for a software company is not in an Annex III area. An agent that screens job applications is in area 4. An agent that drafts a summary for a human caseworker who then decides a benefit claim is in area 5, and whether the derogation applies turns on whether “preparatory task” fits what it does and whether it profiles anyone. The same agent, built on the same model, can fall on either side depending on the deployment.

Article 12’s purpose clause makes classification matter twice. A system that is high-risk must log. And the logging must be “appropriate to the intended purpose”, so the intended purpose has to be written down before anyone can say whether the log is adequate.

What is an “event” when the system is an agent?

The Regulation does not define “event”, and for a classifier nobody needs it to: there is an input and an output. An agent has many more candidates. Each message to and from the model, each tool call, each command run, each file written, each external system touched, each retry, and each decision to stop are all events in the ordinary sense of the word.

In our reading, Article 12(2) answers the question indirectly. The log must give traceability “appropriate to the intended purpose”, and it must enable recording of events relevant to three named activities. So the test for whether something is an event worth recording is whether a later reviewer, trying to do one of those three things, would need it.

For an agent, the reviewer’s questions are concrete:

• What was it asked? The task as given, including any changes to the task during the run.
• What did it do? The actions it took on the systems it could reach, in order.
• What did it change? The effects of those actions: files, records, messages sent, settings altered.
• Why did it stop? Whether it finished, gave up, was interrupted, or hit a limit, and what it reported at that point.

The fourth question is specific to agents and it is where ordinary logging falls short. Agents report their own status, and the reports are often wrong. In one 2026 study of coding agents that reported their own status, 75.8% of failures were false successes: the agent said “done” and it was not (Advani, 2026). A log that records the agent’s statements records those claims as if they were events. The event that matters is what happened; the claim is at most a second event, to be compared against the first.

The Article 12(3) list for biometric systems is a useful model even though it does not apply to most agents. It asks for the period of use, the reference data, the inputs that produced a match, and the people who verified the result. Translated to an agent: when it ran, what it worked from, what it did, and who checked.

Can the agent’s own trace be the log?

Not on its own, in our reading. An agent’s trace is produced by the agent and its harness, and in most setups it is stored where the agent can reach it. Qin et al. tested agent harnesses and found that most of them let the agent delete or rewrite its own trace, and that agents did so when it served their goal (Qin et al., 2026). Their recommendation is logging outside the agent’s control.

That recommendation is also the plain reading of what Article 12 asks for. The purpose is traceability of the system’s functioning. A record the system can edit does not trace the system; it traces what the system chose to leave behind. Nothing in Article 12 says the word “independent”, but a log that fails when the system has a reason to alter it cannot reliably identify “situations that may result in the high-risk AI system presenting a risk”, because those are exactly the situations in which the system’s incentives and the record’s accuracy pull apart.

Two properties follow for a log intended to satisfy Article 12 when the system is an agent:

1. Produced outside the agent’s reach. Recorded by a component the agent cannot read, write or delete during the run, so that the record reflects what the agent did rather than what it reported.
2. Tamper-evident afterwards. Kept so that any later change is detectable, which is what lets a provider or deployer hand the record to a market surveillance authority or an auditor and have it relied on.

Neither property is set out in the article in so many words. Both are implied by its purpose, and both are what any auditor already expects from a system of record. The guide to verifying what an AI agent actually did covers the same ground from the evaluation side.

How long must the logs be kept?

Article 12 says the system must be able to log. The retention rules are in Articles 19 and 26, and they match each other.

Providers. Article 19(1): providers of high-risk AI systems shall keep the logs referred to in Article 12(1), “to the extent such logs are under their control”, and “the logs shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data” (Regulation (EU) 2024/1689).

Deployers. Article 26(6) uses the same formula: deployers shall keep the logs automatically generated by the system “to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months”, again subject to other Union or national law and in particular data protection law (Regulation (EU) 2024/1689).

Both articles add that providers and deployers that are financial institutions keep the logs as part of the documentation required under financial services law.

Three things about this are worth stating plainly.

The six months is a floor. The operative period is “appropriate to the intended purpose”, and for a system whose decisions can be challenged years later, six months is unlikely to be appropriate. Data protection law can cut the other way and require deletion sooner. The two have to be reconciled per deployment.

“Under their control” is the phrase to read twice. For an agent, if the agent can reach the log, the log is under the agent’s control as much as the deployer’s. In our reading a deployer that wants to say with confidence that it kept the logs needs the logs to be somewhere the agent could not have thinned them before the deployer ever saw them.

The quotations above are from the 2024 text. The AI Omnibus amended the Regulation in 2026, and the briefing we rely on for the new dates does not report any change to Articles 12, 19 or 26 (Addleshaw Goddard, 2026). Teams should still confirm the retention wording against the consolidated text before building a retention policy around it.

When does Article 12 apply?

The original timetable was in Article 113. The Regulation applied from 2 August 2026, with the exception that Article 6(1), the embedded-product route to high-risk, and its corresponding obligations applied from 2 August 2027 (Regulation (EU) 2024/1689).

The AI Omnibus, adopted by the European Parliament and Council in 2026 after the Commission proposed it in November 2025, moved the high-risk obligations. They now apply from 2 December 2027 for standalone high-risk AI systems and from 2 August 2028 for high-risk systems embedded in products (Addleshaw Goddard, 2026). The briefing uses the terms “standalone” and “embedded in products”; in our reading those correspond to the Annex III and Annex I routes respectively.

For an agent already in production, the practical implication is that the logging capability must exist and be producing records by those dates, and the retention clock starts then. Because Article 12 speaks of logging “over the lifetime of the system”, a system that went live in 2026 without an adequate record will have an unrecorded stretch of its history when the obligation applies. The record of what an agent did can only be made while it is doing it. The post on the AI Omnibus dates goes through what else moved.

Reading Article 12 as an engineering requirement

Lawyers read Article 12 for scope and liability. Engineers have to build something. The table below restates each element of the article as a requirement a team can check off, with our reading of what it demands when the system is an agent.

None of this prescribes a technology. It prescribes properties, and the properties are the same ones any audited system already has to meet.

What this means for teams deploying agents

Decide, per agent and per use, whether Article 6 puts it in scope, and write the intended purpose down, because the adequacy of the log is judged against it. Work out whether you are the provider, the deployer or both; for most teams building agents on third-party models and running them in-house, it is both, and that means both the design duty and the retention duty. Define what an event is for your agent before building anything, using the reviewer’s four questions as the test. Treat the record as a product requirement: produced automatically, outside the agent’s reach, tamper-evident, and kept for at least six months and as long as the intended purpose demands. And confirm the retention wording in the consolidated text with your own counsel before you rely on it.

Inoku is building an independent record of agent actions for teams that need to answer the reviewer’s questions; it is research-stage work, and the requirement above stands whether or not any product exists. For how Article 12 fits with the Omnibus dates, deployers’ duties and certification, see the full guide to audit trails for AI agents under the EU AI Act.