Reference · AI Act
How do I meet the logging duty in Article 12 of the AI Act?
Checked against the primary text on 2026-08-09. Where a date is derived rather than written down, the arithmetic is shown.
Article 12 of Regulation (EU) 2024/1689 requires a high-risk AI system to be technically capable of automatically recording events over its lifetime. It is an obligation on the provider of the system, about what the system must be able to do. The duty to actually keep those logs sits elsewhere: on the provider in Article 19 and on the deployer in Article 26(6), both with a floor of six months. The high-risk obligations apply from 2 August 2026.
What does Article 12 actually say?
That high-risk AI systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system”, and that the logging must cover events relevant to three purposes: identifying situations where the system presents a risk or undergoes a substantial modification, facilitating post-market monitoring, and monitoring the system's operation. Manual record-keeping does not satisfy it — the capability has to be in the system.
For one narrow category — remote biometric identification systems under Annex III — Article 12(3) adds a specific minimum: the period of each use, the reference database against which input data was checked, the input data that produced a match, and the identity of the people involved in verifying the results.
Who has to do what, and by when?
| Duty | On whom | Where |
|---|---|---|
| The system must be able to log automatically | Provider | Article 12 |
| Keep the generated logs, at least six months, where they are under your control | Provider | Article 19 |
| Keep the logs, at least six months, unless other Union or national law says otherwise | Deployer | Article 26(6) |
| Obligations start applying for high-risk systems | Both | 2 August 2026 |
High-risk systems that are safety components of products already covered by Union product legislation (Annex I) follow later, in 2027. The 2 August 2026 date is the one that applies to the Annex III categories most companies encounter.
Which common claims about Article 12 are not in its text?
Several, and they matter because the gap between them is exactly where a compliant log turns out to be useless in a dispute.
- It does not say “tamper-evident”, “immutable” or “append-only”. A plain rotating file satisfies the letter of the article. That is worth knowing before you buy anything, including from us.
- It prescribes no format, no schema and no retention technology. There is no mandated export shape to be compatible with.
- It does not require a third party to hold the logs. Custody stays with you.
- Six months is a floor, not the period. Article 26(6) sets it as a minimum and defers to sector law that requires longer — and to the period appropriate to the system's purpose, which is a judgement you have to make and record.
So the honest framing is this: Article 12 tells you to have logs. It does not tell you to have logs anyone else has reason to believe. The question that arrives with a regulator, an auditor or a counterparty's lawyer is not “did you log this” but “why should I accept your copy of it”, and nothing in the article answers that.
Is my system even high-risk?
Probably not, if you are asking because AI agents are hitting your checkout. Whether a system is high-risk is decided by Article 6 together with Annex III, and an e-commerce backend that decides whether to accept an order is not on that list. The AI Act may still reach you from the other side — as a deployer of something that is listed, or because your counterparty is a provider — but if the only thing that has changed at your company is the traffic, your real exposure is contractual and evidentiary rather than administrative.
We would rather say that than sell against a deadline that does not bind you. Buy a verifiable log because you will one day have to prove what an agent did on somebody else's behalf and what you decided in response — not because you assume the article applies.
What a Mandaton receipt records
For every decision: what was requested, whether the agent's signature verified and with which key, which policy version applied and which rule matched, the outcome, the reasons for it, and the time. That object is canonicalised (RFC 8785), hashed, and appended to an append-only Merkle log (RFC 6962) whose head is signed. Whether you need that on top of a log file depends entirely on whether you expect anyone to disagree with you later.