EU AI Act Article 12: what logging means for AI agents

01What does Article 12 of the EU AI Act actually say?

Article 12, titled record-keeping, has three paragraphs. Paragraph 1 is the core duty: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." It is a design requirement on the system. The system has to be able to log automatically, for as long as it exists.

Paragraph 2 says what the logging is for. To ensure traceability appropriate to the system's intended purpose, logging capabilities "shall enable the recording of events relevant for" three things, quoted below. Paragraph 3 adds minimum fields, but only for remote biometric identification systems listed in point 1(a) of Annex III: the period of each use, the reference database checked, the input data that led to a match, and who verified the results.

Note what the article leaves out. Outside that biometric case it names no fields, no format, no storage medium and no integrity mechanism. It sets purposes, and the provider decides which events serve them. A note on sources: EUR-Lex did not allow our automated fetch, so the wording quoted here was read from the consolidated text reproduced by the AI Act Explorer and should be checked against the Official Journal before you rely on it.

• (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";
• (c) "monitoring the operation of high-risk AI systems referred to in Article 26(5)".

02Does Article 12 apply to my AI agent?

Only if the agent is part of a high-risk AI system. Article 6 sets two routes. The first covers AI systems that are, or are safety components of, products under the EU product safety laws listed in Annex I and that need a third-party conformity assessment under those laws. The second covers the use cases listed in Annex III. The European Commission's summary names areas such as biometrics, education, employment and migration for Annex III, and products such as lifts or toys for Annex I.

Classification follows the intended purpose, not the technology. A coding agent that helps engineers write internal software is not, by that fact alone, an Annex III use case. An agent that screens job applicants or ranks students' exams could be, because the purpose falls in a listed area. The same model and the same sandbox can be in scope in one deployment and out of scope in another.

This is a legal question, and this post is not legal advice. If an agent touches a listed area, get a classification decision in writing from someone qualified, before you design the logging around an assumption either way.

03When do the EU AI Act high-risk deadlines apply now?

As adopted in 2024, Article 113 made most of the Act apply from 2 August 2026, including the high-risk rules for Annex III systems. That changed in 2026. The Commission's AI Act page records that the AI Omnibus amendment was proposed on 19 November 2025, politically agreed on 7 May 2026 and entered into force on 27 July 2026.

Under the amended Article 113, Chapter III Sections 1 to 3, which include Article 12, apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems under Article 6(1) and Annex I. The Commission's page says the Act otherwise became applicable on 2 August 2026, with some exceptions.

A later date is a planning window, not a reason to wait. Logging that has to cover "the lifetime of the system" is far easier to design in than to retrofit, and Article 19 retention, below, starts counting from the first log you are required to keep.

04How long must AI Act logs be kept?

Two articles set the retention floor, one for each role. Article 19(1) makes providers keep the Article 12 logs "to the extent such logs are under their control", for a period appropriate to the intended purpose "of at least six months", unless other Union or national law provides otherwise, in particular Union law on the protection of personal data. Article 26(6) sets the same floor for deployers for the logs under their control.

Six months is a minimum, not a target. Sector rules can require more, and both articles add that financial institutions keep the logs as part of the documentation their financial services law already requires. The data protection carve-out pulls the other way: agent logs often hold personal data, so retention has to be justified under the GDPR as well.

• Provider (Article 19): keeps the logs under its control, at least six months unless other law says otherwise.
• Deployer (Article 26(6)): keeps the logs under its control, with the same floor.
• Both: who controls the logs decides who keeps them, so contracts between provider and deployer should say where the logs live.

05What should an AI agent's log record to serve Article 12?

Map each of the three purposes to events an agent actually produces. For identifying risk situations, record what the agent was refused: blocked tool calls, denied network destinations and policy decisions, each with the rule that decided it. For post-market monitoring, record which model and which version of the system acted, so trends can be tied to a release. For monitoring operation by the deployer, record when a human approved, rejected or stopped an action, and who that human was.

Attribution is the part agents make hard. A log that cannot tell a person's action from an agent's action acting for that person cannot support oversight. Neither can a log that records an agent identity the agent merely claimed. Integrity matters for the same reason: the Act does not prescribe tamper evidence, but a log anyone can quietly edit is weak evidence of anything.

Standards are on the way. prEN 18229-1, "AI trustworthiness framework - Part 1: Logging", is a draft European standard from the joint CEN and CENELEC committee on AI (JTC 21, working group 4). DIN lists it as a draft from July 2026. Drafts change, so treat it as a direction of travel and not a checklist.

06What a log cannot do for EU AI Act obligations

Logging is one requirement among several for high-risk systems. Chapter III also covers risk management, data governance, technical documentation, transparency to deployers, human oversight, accuracy and robustness, and conformity assessment. A good log supports several of those, but it satisfies none of them on its own, and no product can make a system meet the Act by being installed.

What a log can do is answer questions after the fact: what the agent did, under which rule, who approved it, and whether the record has been altered since. That is the evidence an investigation, a market surveillance request or your own post-market monitoring will ask for.