EU AI Act Article 12: what it means for AI agent logs

Article 12 applies to high-risk systems, not to every agent

The article is short. Article 12 opens: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Everything after that depends on the words "high-risk".

A system is high-risk in two ways. Under Article 6(1) it is a safety component of a product, or itself a product, covered by the Union harmonisation legislation in Annex I. Under Article 6(2), "AI systems referred to Annex III shall be considered to be high-risk". Annex III lists areas. Two that agent builders hit quickly:

• Employment, point 4(a): "AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates".
• Essential services, point 5(b): "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud".

An agent that triages invoices, rotates credentials or answers support tickets is not in those lists on its face. An agent that screens job applications is. Article 6(3) adds a way out: an Annex III system "shall not be considered to be 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", for example where it performs "a narrow procedural task". Whether that applies to a given system is a legal judgement. This entry does not make it.

Article 12 lists three purposes and one set of minimum fields

Paragraph 2 says the logging capabilities "shall enable the recording of events relevant for":

• (a) identifying situations that may result in the 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).

Paragraph 3 names minimum fields for one category. For remote biometric identification systems (Annex III, point 1(a)), logs must provide at a minimum the period of each use with start and end date and time, the reference database the input was checked against, the input data that led to a match, and "the identification of the natural persons involved in the verification of the results". For every other high-risk system the Article names no fields. It states purposes and leaves the content to the provider.

Providers and deployers each keep the logs for at least six months

Article 12 describes what the system must be able to do. Two other articles say who keeps the output.

Article 19(1): "Providers of high-risk AI systems shall keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control." 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."

Article 26(6) repeats the same duty for deployers, again "to the extent such logs are under their control". Both articles treat financial institutions differently: they keep the logs as part of the documentation they already keep under financial services law.

The terms matter for an engineer who builds on someone else's model. The Act's definitions call a deployer a "natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity". A company that runs its own agent to screen job applications is plausibly a deployer, and a company that sells that agent as a product is plausibly a provider. Both can hold logs, and the phrase "to the extent such logs are under their control" decides who holds which. That phrase is why log location is a design question and not an afterthought.

The dates moved to 2 December 2027 and 2 August 2028

Article 113 gives 2 August 2026 as the general date from which the Act applies. Regulation (EU) 2026/1744 amended the dates for the high-risk chapters. Its publication record gives the title: "Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)". It was published in the Official Journal on 24 July 2026.

Article 113, point (c), now reads that Chapter III, Sections 1, 2 and 3, with the exception of Article 6(5), apply from:

Article 12 sits in Section 2 of Chapter III, and Articles 19 and 26 in Section 3, so all three fall under that point. On the Commission's page Articles 12, 19 and 26 carry no "AMENDED" marker, while points (c)(i) and (c)(ii) of Article 113 do.

One caveat on sources. The official EUR-Lex pages returned empty responses to a script on 8 October 2026, so the wording above was read on the Commission's AI Act Service Desk. That site states its text "is based on the EUR-Lex consolidated version of the AI Act as at 27 July 2026". Its page summaries say they are "not legal binding". The authentic text is the one in the Official Journal, and anyone relying on a quotation should check it there.

What an agent log would need to hold to serve those three purposes

The following is an engineering reading, not something the Act says. Article 12(2) asks for events relevant to risk, to post-market monitoring and to deployer monitoring. For an agent, the events that carry that information are the ones where it acts on the world or where its configuration changes.

Three properties make such a log usable as evidence. It is written by something other than the agent, because an agent that writes its own log can misreport. It is complete for refusals as well as successes, because "what it was stopped from doing" is the question a reviewer asks first. And its integrity can be checked by someone who does not trust the operator. The first two follow from the purposes in paragraph 2. The third is a design choice: Article 12 does not mention integrity, signatures or tamper-evidence anywhere in its three paragraphs.

Retention carries its own tension. Articles 19 and 26 point to "Union law on the protection of personal data" as able to override the six-month floor. A log that stores prompts and tool outputs can hold personal data, and a log built to be tamper-evident cannot honour an erasure request without failing its own checks. That conflict has to be settled in the design, by deciding what goes into the log, and not afterwards by deleting entries. How to settle it is a question for counsel.

Where Mandare fits, and where it does not

Mandare is open source and pre-1.0 (@mandarelabs/cli 0.1.0 on npm on 8 October 2026). Its concepts page describes doors that follow "log-before-act": "write the intent to the ledger, execute, write the result. No entry, no action. A refused action is also an entry". The ledger is "Append-only, hash-linked, door-signed", and mandare verify checks it. The agent does not write it.

That matches the first two properties above for calls that pass through a door. The CLI reference and the threat model are explicit about the third: without an out-of-band key, verification "proves internal consistency, not authorship", and truncation is caught by a witness running on infrastructure the operator does not control. In the single-host stack the witness shares the machine. The transcript below, copied from docs/demos/S6-witness-demo.txt in the repository with cuts marked, shows both halves of that:

[attacker] copy A: newest 2 entries DROPPED, chain re-signed
…
[verify]  truncated copy, self-anchored:      chain VALID — the lie is locally perfect
…
[verify]  truncated copy, --witness:      TRUNCATION DETECTED (exit 1)

Limits that apply to the Article 12 question:

• Mandare makes no claim that it satisfies Article 12 or any other article. Records are evidence, and compliance is the reader's job.
• A door sees what passes through it. The gateway proxies Anthropic POST /v1/messages and OpenAI or OpenRouter POST /v1/chat/completions. Events elsewhere in an agent's process are not in the ledger.
• There is no external security audit yet, and there is no hosted service. Retention and erasure are not addressed by a documented setting in v0.1.0.
• The journal entry on why the ledger keeps proofs and not data explains what crosses to the witness: salted head fingerprints, not content.

For a wider look at other tools that cap, identify or audit agents, see the comparison of 20 governance tools. The CLI reference lists the verify and certify flags.