EU AI Act Article 12, and what it actually requires you to log

Start here: it probably does not apply to you

Article 12 is an obligation on high-risk AI systems. That is a defined category in the Act, not a description of how important your system feels, and most business automation sits outside it.

This matters because a lot of writing about Article 12 is produced by people selling logging tools, and the incentive is to describe the requirement as though it lands on everyone. It does not. If you are running an agent that files tickets or drafts replies, you are very likely out of scope, and the correct next step is to confirm that once rather than to buy anything.

The parts of the Act that do reach general-purpose systems are a different set of obligations from this one. Conflating them is the single most common error in coverage of this topic.

This page is a plain-language summary of what the text says. It is not legal advice, we are not lawyers, and whether your system is high-risk is a determination to make with someone qualified. Where this page and the regulation disagree, the regulation is right.

What the text actually requires

High-risk AI systems must technically allow for the automatic recording of events over the lifetime of the system. Two words in that sentence carry most of the weight.

Technically means the capability is built into the system. A process where somebody exports records by hand, or a policy saying staff will write things down, does not satisfy it. The system produces the records itself, without operator intervention.

Lifetime means the obligation is not scoped to a debugging window. This is where a lot of existing observability tooling quietly fails to fit, not because it logs the wrong things but because its retention is set to weeks and the obligation is measured in the working life of the system.

The logs must enable identifying situations where the system may present a risk or has been substantially modified, support post-market monitoring, and support the operational monitoring that falls to whoever deploys it. Those three purposes are what determine whether a given log is adequate. A record that cannot serve them is not compliant just because it exists.

Nobody can tell you the technical standard yet

There is no finalised harmonised standard for Article 12 logging. Two drafts are the ones to watch: prEN 18229-1, covering AI logging and human oversight, and ISO/IEC DIS 24970 on AI system logging. Both are drafts.

So a vendor claiming their product meets the Article 12 standard is describing a document that has not been published. The honest position, for us and everyone else, is that the obligation is in force and the detailed conformity route is still being written.

The practical consequence is that decisions made now should be defensible on the text rather than on a certificate. Records that are automatic, retained for the system’s life, and adequate to the three stated purposes are defensible. A logo is not.

Where tamper-evidence comes into it

The text does not use the word tamper-proof, and neither should anyone describing it. What it requires is logging appropriate to the intended purpose of the system, which is widely read as implying records that would not silently change.

That reading is reasonable. A log that anyone can edit afterwards cannot support post-market monitoring in any meaningful sense, because the thing being monitored could be rewritten. But it is an interpretation of a general clause rather than an explicit requirement, and it is worth being precise about which of those you are relying on.

If you want the mechanics of that distinction, the difference between append-only, tamper-evident and tamper-proof is a separate question with real consequences, and it is covered properly elsewhere in these guides.

What to do if you are in scope

Confirm the classification first, with someone qualified, because everything downstream depends on it and the answer is often no.

Then check retention before features. This is the requirement most existing setups fail, and it is usually a billing setting rather than an engineering problem, which makes it the cheapest gap to close.

Then check that recording is automatic end to end. Any point where a human assembles or transcribes a record is a point where the technically-allow test is arguably not met.

Then check that the records serve the three purposes rather than merely existing. Risk identification, post-market monitoring, and operational monitoring by the deployer are the tests, and a trace built purely for debugging often does not answer any of them.

Claritty is not a compliance product and holds no certifications. It records actions automatically, keeps the provider’s identifier where the provider returns one we recognise, and seals its ledger — but our chain head has never left our own infrastructure, so that sealing proves internal consistency rather than independent custody. If you are in scope for Article 12, that distinction is exactly the kind of thing you should be asking every vendor, including us.