What does EU AI Act Article 12 require you to log?
Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically enable the automatic recording of events (logs) across the system's lifetime. The capability has to be built in, not something an operator can switch on later.
Art. 12(2) names three things those logs must cover: (1) situations where the system may present a risk or need a substantial modification, (2) data supporting post-market monitoring, and (3) 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 provides otherwise. Data-protection law is the one to watch, and 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 obligation, and where harmonised standards or common specifications exist, conforming to them (the route under Arts. 40 and 41) earns a presumption of conformity, but only where a standard actually covers the requirement. As of mid 2026 no harmonised AI Act standards have been formally cited, so treat that route as coming rather than here. Second, for the Annex III high-risk systems this article targets, the substantive obligations for Annex III systems, Art. 12 among them, become applicable on August 2, 2026. One catch: high-risk AI that rides inside a product covered by Annex I law, medical devices being the obvious case, gets until August 2, 2027. One note before we go further: this is an 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, and critical infrastructure among them. Some healthcare AI is high-risk too, though a good deal of medical AI reaches that status through medical device legislation and Annex I rather than through Annex III. If your AI agent is making or materially shaping decisions in one of those domains, assume you're in scope until a lawyer tells you otherwise.
The obligation splits in two. The provider, whoever builds or brands the system, has to build the logging capability in. The deployer, whoever runs it in the EU, has to actually keep the logs and, under Art. 26(6), retain them for 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. If you deploy agents built on someone else's model or framework, you inherit the retention duty whether or not the vendor made it easy.
One thing teams routinely underestimate. An agent that calls tools, queries databases, and takes actions on a user's behalf is exactly the kind of system where "what did it do, when, and why" is the entire audit. The logging burden scales with autonomy, so the more freedom you give an agent, the more you have to account for. If those agents reach tools over MCP, our MCP server security threat model covers securing and logging every tool call.
The stakes are not small. Article 99 puts non-compliance with the high-risk obligations 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 modification events. Any situation where the system might present a risk within the meaning of Article 79(1) of the Act, or where it hits a state that would count as a substantial modification. This means capturing 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, and your logs are the raw material. If you cannot reconstruct behavior after the fact, you cannot monitor it either.
- Operational 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, that 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, and 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 have to capture four extra things:
- The period of each use. Start date and time, end date and time. Not just that it ran, but 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 natural persons involved in verifying the match, per Article 14(5).
If 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 and engineering supplies the what. For an AI agent, the practical minimum per event comes to six fields:
- Timestamp. When it happened, ideally from a trusted clock rather than 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 decision 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 difficulty is not writing them down but 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 appropriate to the system’s purpose, and in any case at least six months, unless other Union or national law provides 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 rather than the target you aim for.
"Under their control" is doing real work in that sentence. Logs sitting in a vendor's system that the vendor can rotate, expire, or edit are arguably not under your control at all. If 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 a database table an administrator can UPDATE, an S3 bucket someone with the right role can overwrite, or a SIEM that ingests whatever the app sends and trusts it completely.
Every one of those shares a defect. A privileged insider can silently change history. Once that is 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?" If your answer is "our access controls are good," you have already lost, because 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 obligation 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 reconcile with using logs as evidence for risk detection and post-market monitoring.
What tamper-evident logging actually looks like
"Tamper-proof" is a marketing word, since nothing truly is. The honest goal is tamper-evident: you cannot stop a determined insider from trying to alter a record, but you can guarantee the attempt is detectable and provable.
The standard mechanism is a hash chain. Each entry carries the cryptographic hash of the entry before it, so every record commits to the entire history that preceded it. 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, so verification 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 specificity is what turns a log from a liability into evidence.
The GDPR objection shows up immediately: if the chain is immutable, how do you honor an erasure request? You separate the two problems. Personal data is encrypted per subject, and erasure becomes a crypto-shred, meaning you destroy that subject's key so their data is unrecoverable while the hash chain stays fully verifiable. Article 17 is satisfied and Article 12 stays intact, so you do not have to pick one.
You do not have to take my word for it. You can 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, so 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, so here are three short explainers that set the scene, from the high-risk requirements to a plain-English overview.
A short checklist before August 2, 2026
If you are deploying AI agents in the EU, work backward from the date the high-risk obligations apply:
- Confirm scope. Is your system high-risk under the Act? Get that answer in writing.
- Log the six fields on every 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, and confirm the logs are genuinely under your control.
- Make the logs tamper-evident, not merely access-controlled. Assume the insider threat, because 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, and you can get a quote if you would rather not build the chain yourself. Either way, make the call before August rather than 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 obligation 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 obligations like GDPR still might. When in doubt, get the high-risk determination 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 a longer period. 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." It does treat logs as evidence for risk detection and post-market monitoring, and a folder of ad-hoc text files is unlikely to satisfy the record-keeping obligation. A log an administrator can silently edit has no evidentiary weight. In practice that points to tamper-evident logging: something like a hash chain with signed checkpoints that makes any alteration 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 and delete the key on an erasure request, a technique called crypto-shred. The subject's data becomes unrecoverable, which satisfies GDPR Article 17, while the underlying hash chain stays intact and verifiable, 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 obligations including Article 12 apply from 2 August 2026. For high-risk AI that is a safety component of a product covered by Annex I legislation, such as medical devices, the date is 2 August 2027. The Act’s governance and penalty provisions 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 automatically generate that are under the provider's control, appropriate to the system's purpose and 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). If you build or brand the system, this obligation 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 capability in under Article 12 and keeps the logs it automatically generates that stay under its 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). If you deploy an agent built on someone else’s stack, the deployer duty is yours.