What does EU AI Act Article 12 require you to log?
Article 12 of Regulation (EU) 2024/1689 sets one rule. High-risk AI systems must technically enable the automatic recording of events (logs) across the system's lifetime. The feature has to be built in. Not something an operator switches on later.
Art. 12(2) names three things those logs must cover. One, situations where the system may present a risk or need a big change. Two, data that supports post-market monitoring. Three, data that lets deployers monitor how the system actually runs. Art. 26(6) then hands deployers a separate duty. You keep the automatically generated logs under your control for at least 6 months. Unless other Union or national law says otherwise. Data-protection law is the one to watch. It can pull retention shorter just as easily as it extends it.
Two things shape how this plays out in practice. First, a folder of .txt files is unlikely to satisfy the record-keeping duty. Where harmonised standards or common specs exist, following them (the route under Arts. 40 and 41) earns a presumption of conformity. But only where a standard actually covers the rule. As of mid 2026, no harmonised AI Act standards have been formally cited. Treat that route as coming, not here yet.
Second, for the Annex III high-risk systems this article targets. The substantive duties for Annex III systems, Art. 12 among them, kick in on August 2, 2026. One catch. High-risk AI riding inside a product covered by Annex I law gets more time. Medical devices are the obvious case. The date is August 2, 2027. One note before we go further. This is engineering and compliance mapping, not legal advice. Read the Regulation, then call your counsel.
Who does Article 12 actually apply to?
Article 12 lands on high-risk AI systems. The Act draws much of that category from Annex III. Credit scoring. Hiring. Biometric ID. Critical infrastructure, among them. Some healthcare AI is high-risk too. A good deal of medical AI reaches that status through medical device law. Annex I, not Annex III. Say your AI agent makes or shapes calls in one of those domains. Assume you're in scope until a lawyer tells you otherwise.
The duty splits in two. The provider, whoever builds or brands the system, has to build the logging feature in. The deployer, whoever runs it in the EU, has to actually keep the logs. Under Art. 26(6), that means at least six months. The provider carries its own duty too. Under Art. 19, it keeps the logs it automatically generates that stay under its control. Say you deploy agents built on someone else's model or framework. You inherit the retention duty. Whether the vendor made it easy or not.
One thing teams routinely underestimate. An agent calls tools. It queries databases. It takes actions on a user's behalf. That's exactly the kind of system where "what did it do, when, and why" is the whole audit. The logging burden scales with autonomy. The more freedom you give an agent, the more you have to account for. Say those agents reach tools over MCP. Our MCP server security threat model covers securing and logging each tool call.
The stakes are not small. Article 99 puts non-compliance with the high-risk duties at up to 15 million euro. Or 3% of worldwide annual turnover, whichever is higher.
The three things Art. 12(2) says your logs must cover
Translate 12(2) into plain engineering terms:
- Risk and change events. Any situation where the system might present a risk under Article 79(1) of the Act. Or where it hits a state that counts as a substantial change. Capture the anomalies, the overrides, and the edge cases. Not only the runs that went well.
- Post-market monitoring data. The Act expects you to watch systems in production over time. Your logs are the raw material. If you cannot rebuild behavior after the fact, you cannot monitor it either.
- Day-to-day monitoring by deployers. The deployer needs enough signal to see how the thing behaves day to day. That means the boring, high-volume events too. Not a curated highlight reel.
All three purposes rest on the same assumption: the log is a faithful account of what happened. The moment anyone can rewrite it, all three quietly collapse.
What extra logging does Article 12(3) require for biometric systems?
Article 12(2) is the general rule. Article 12(3) is the part people skip. It lands on one group in particular: remote biometric identification systems, the Annex III point 1(a) crowd. Run one of those and your logs must capture four extra things:
- The period of each use. Start date and time, end date and time. Not just that it ran. Exactly when.
- The reference database. Which database the input data was checked against.
- The matching input data. The specific input that produced a match.
- Who checked the result. The people involved in verifying the match, per Article 14(5).
Say you build or deploy face recognition, or anything close to it. Your real logging spec is 12(2) plus 12(3). Those four fields are mandatory. Not nice to have.
What does a single log event have to contain?
The Regulation sets the why. Engineering supplies the what. For an AI agent, the practical minimum for EU AI Act Article 12 logging per event comes to six fields:
- Timestamp. When it happened. Ideally from a trusted clock, not the box the agent runs on.
- Agent identity. Which agent, which version, which instance. "An AI did it" is not an answer a regulator accepts.
- Action or tool called. The actual operation: the API hit, the query run, the call emitted.
- Input. What the agent received or was prompted with.
- Output. What it produced or returned.
- Context. Session, user or subject, tenant, correlation ID. Enough to place the event in a chain of events.
That is six fields. None of them exotic. The hard part is not writing them down. It's proving, months later, that nobody changed them.
How long do you keep the logs? Art. 26(6) says 6 months
Art. 26(6) sets the floor. Deployers keep the automatically generated logs under their control for a period fitting the system's purpose. In any case, at least six months. Unless other Union or national law says otherwise. The big exception is data-protection law, which can pull the period shorter, not only longer. Financial services, medical devices, and employment records routinely say longer. So treat six months as the minimum you're allowed to admit to. Not the target you aim for.
"Under their control" is doing real work in that sentence. Say logs sit in a vendor's system, one the vendor can rotate, expire, or edit. Those logs are arguably not under your control at all. Say you can't produce them, complete and intact, on the day an auditor asks. Retention on paper won't save you.
Why mutable logs fail
Most "audit logs" I have reviewed are one of three things. A database table an admin can UPDATE. An S3 bucket someone with the right role can overwrite. Or a SIEM that ingests whatever the app sends, and trusts it fully.
Each one shares a defect. A privileged insider can silently change history. Once that's possible, the log carries no evidentiary weight. Whether anyone actually altered it is beside the point. What sinks you is that nobody can prove they did not.
This is not theoretical. A mutable log fails the first time a regulator, an auditor, or opposing counsel actually tests it. They ask one simple question: "How do you know this record is the same as the one written on March 3rd?" Say your answer is "our access controls are good." That's already a loss. Access controls hold right up until the person with access is the problem. Post-market monitoring built on editable logs is monitoring you cannot defend.
The record-keeping duty is why ad-hoc text files and editable tables tend to fall apart under scrutiny. The Act never spells out immutability. But a log you can quietly rewrite is hard to square with that. Not when logs serve as proof for risk detection and post-market monitoring.
What EU AI Act Article 12 logging actually looks like in practice
"Tamper-proof" is a marketing word. Nothing truly is. The honest goal is tamper-evident. You cannot stop a determined insider from trying to alter a record. But you can make sure the try gets caught, and proven.
The standard mechanism is a hash chain. Each entry carries the hash of the entry before it. So each record commits to the entire history that came before. Change one field in one old entry and every hash downstream breaks. At DataShield we run a SHA-256 hash chain with Ed25519-signed checkpoints. Verification then does more than flag that something is wrong. It classifies the failure as tampering, insertion, deletion, or truncation. And it names where in the chain it happened. That detail is what turns a log from a liability into proof.
The GDPR objection shows up at once. Say the chain is immutable. How do you honor an erasure request? You split the two problems apart. Personal data gets encrypted per subject. Erasure becomes a crypto-shred. You destroy that subject's key. Their data becomes unrecoverable, while the hash chain stays fully checkable. Article 17 is satisfied. Article 12 stays intact. You do not have to pick one.
You do not have to take my word for it. Verify a sample chain yourself at /verify and watch it flag a tampered entry in real time.
Verification is classification, not a plain yes or no. One call returns VALID, or names the exact failure. A tampered log stops being your word against theirs.
Watch: the EU AI Act in context
No single clip nails Article 12 on its own. Here are three short explainers that set the scene, from the high-risk rules to a plain-English overview.
A short checklist before August 2, 2026
Say you deploy AI agents in the EU. Work backward from the date the high-risk duties apply. Confirm your EU AI Act Article 12 logging is ready:
- Confirm scope. Is your system high-risk under the Act? Get that answer in writing.
- Log the six fields on each agent action: timestamp, agent identity, action or tool, input, output, context.
- Cover all three of Art. 12(2)'s purposes. Anomalies and overrides included. Not only the successful runs.
- Set retention to at least 6 months per Art. 26(6). Longer where sector law applies. Confirm the logs are genuinely under your control.
- Make the logs tamper-evident, not merely access-controlled. Assume the insider threat. Auditors do.
- Test your own chain the way opposing counsel would. Before they do it for you.
Want to see how this maps onto a regulated deployment? Our healthcare walkthrough and the security model go deeper. You can get a quote if you'd rather not build the chain yourself. Either way, make the call before August. Not after the first request lands.
Frequently asked questions
Does EU AI Act Article 12 apply to all AI systems?
No. Article 12's automatic logging duty applies to high-risk AI systems, as defined by Regulation (EU) 2024/1689. If your system isn't high-risk, Art. 12 doesn't bind you. Though other parts of the Act, and separate rules like GDPR, still might. When in doubt, get the high-risk call confirmed in writing.
How long must AI Act logs be retained?
At least 6 months. Art. 26(6) requires deployers to keep the automatically generated logs under their control for a minimum of six months. Unless Union or national law, in finance, medical devices, or employment, for example, requires longer. Treat six months as the floor, not the goal.
Do I need immutable logs to comply with Article 12?
The Act doesn't use the word "immutable." But it does treat logs as proof for risk detection and post-market monitoring. A folder of ad-hoc text files is unlikely to satisfy the record-keeping duty. A log an admin can silently edit has no evidentiary weight. In practice that points to tamper-evident logging. Something like a hash chain with signed checkpoints. One that makes any change detectable and provable.
How do immutable logs work with GDPR's right to erasure?
Separate the data from the ledger. Encrypt personal data per subject. Delete the key on an erasure request, a technique called crypto-shred. The subject's data becomes unrecoverable, which satisfies GDPR Article 17. The underlying hash chain stays intact and checkable, which satisfies AI Act Article 12. You can honor both without breaking either.
When does EU AI Act Article 12 start to apply?
For Annex III high-risk systems, the duties including Article 12 apply from 2 August 2026. For high-risk AI that is a safety part of a product covered by Annex I law, such as medical devices, the date is 2 August 2027. The Act's governance and penalty rules have applied since 2 August 2025.
What does Article 19 of the EU AI Act require of providers?
Article 19 requires providers of high-risk AI systems to keep the logs their systems generate on their own. Logs that stay under the provider's control. Fitting the system's purpose. At least six months, unless other law says otherwise. It is the provider-side counterpart to the deployer's retention duty in Article 26(6). Say you build or brand the system. This duty is yours, even when someone else deploys it.
Who keeps the logs, the provider or the deployer?
Both, for different logs. The provider builds the logging feature in under Article 12. It keeps the logs it automatically generates, under its own control, under Article 19. The deployer keeps the logs generated in its own use, under its control, for at least six months, under Article 26(6). Say you deploy an agent built on someone else's stack. The deployer duty is yours.