EU AI Act Article 12 Record-Keeping: How Do You Actually Satisfy the Logging Duty?

You satisfy the EU AI Act Article 12 logging duty by giving a high-risk AI system the built-in ability to record events automatically across its whole lifetime, then holding those logs in a form an auditor can prove was never altered. Article 12 is a design obligation, not a paperwork exercise: the system itself must generate the logs, and for biometric systems the record must capture the period of each use, the reference database queried, the input that produced a match, and the humans who checked the result. The duty is met only if each entry is tamper-evident and stays verifiable for the full retention period, which is why the signing scheme matters as much as the logging.

The high-risk obligations in Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that deferral as a build window, not a reprieve. Logging bolted on after deployment rarely convinces an auditor, so teams that treat 2026 and 2027 as design time are the ones that pass.

What exactly does Article 12 require?

Article 12 requires that a high-risk AI system technically allows the automatic recording of events, called logs, throughout its lifetime. The logging capability must record events relevant to three things: identifying situations where the system may present a risk or undergo a substantial modification, supporting post-market monitoring, and supporting the operational monitoring a deployer carries out. For remote biometric identification systems under Annex III, Article 12 sets a hard minimum. The log must capture the period of each use, the reference database checked against, the input data that led to a match, and the identity of the people who verified the result.

How do you map each requirement to a concrete control?

Each clause maps to a specific, checkable mechanism, not a policy statement:

• Automatic lifetime recording maps to an append-only audit ledger that the runtime writes to on every inference, with no manual entry path.
• Recording events that signal risk maps to cross-model consensus logging: when independent sovereign models disagree on an output, the divergence is written as a discrete event an assessor can review.
• Post-market monitoring maps to structured, queryable event schemas so a provider can reconstruct behaviour without re-running the system.
• Period of each use maps to sealed start and end timestamps bound to a hardware clock, not a mutable application field.
• The reference database and the matching input map to content-addressed entries that name the exact data version used.
• Identification of the human verifier maps to hardware-attested identity, so the person recorded against a decision is cryptographically bound to the log, not typed into a name field.

What can an auditor actually check?

An auditor should not be asked to trust that logs are complete. They should be able to run a verification test: take any historical log entry, recompute its signature against the published public key, and confirm the chain from that entry back to the system genesis is unbroken. If a single entry has been edited, deleted, or reordered, the chain breaks and the tampering is visible. This is stronger than a retention policy, because a retention policy proves that files exist, not that they are unchanged.

“A log satisfies Article 12 only for as long as its signature can still prove the entry is unchanged, so record-keeping is really a durability problem wearing a compliance label.”

Which rule makes quantum-durable signing necessary?

Article 12 says nothing about post-quantum cryptography, and that is precisely the gap. The rule is durability across the evidence lifetime. High-risk logs may need to survive many years of retention and litigation, yet the classical signatures most systems use today can be forged once a cryptographically relevant quantum computer exists. An adversary can harvest signed logs now and forge or repudiate them later, which quietly destroys their evidential value. We sign the audit ledger with post-quantum schemes standardised as FIPS 204 (ML-DSA) for signatures, so a log signed in 2027 still proves integrity in the 2030s. A retained log whose signature has become forgeable no longer functions as evidence.

Why does where the log is stored decide whether it counts?

A log held on infrastructure you do not control is only as trustworthy as that third party. Where a system runs on a public cloud AI service, the operator cannot fully attest that logs were not accessed or altered, and foreign jurisdiction reaches the data. Under the US CLOUD Act, a US provider can be compelled to disclose data it holds wherever the servers sit, which is hard to reconcile with a sovereign audit trail. Mickai runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so logs are generated, sealed, and verified inside the operator boundary and never leave it. The same design answers overlapping duties under DORA, NIS2, and GDPR, because the evidence stays where the operator can produce it on demand.

When does the duty apply, and what is the real deadline?

The record-keeping duty binds providers and deployers of high-risk AI systems. The operative date to plan against is 2 December 2027 for Annex III high-risk systems and 2 August 2028 for high-risk systems embedded in regulated products under Annex I, following the Digital Omnibus deferral. Do not treat 2 August 2026 as a live high-risk deadline, because it is not. Deployers must keep the logs under their control for a period appropriate to the purpose and at least six months, unless Union or national law requires longer, which financial and health sectors often do. Aligning your logging design with ISO/IEC 42001 gives the management-system evidence that sits beside the technical logs.

Frequently asked questions

Is Article 12 about keeping logs or being able to produce them?

Both, and the order matters. Article 12 is the design duty that the system must be able to record events automatically over its lifetime. The separate duty to retain those logs falls on deployers, who must keep the logs under their control. A system that cannot generate compliant logs fails Article 12 before retention is ever tested.

What is the deadline for Article 12 record-keeping?

Plan for 2 December 2027 for high-risk systems listed in Annex III, and 2 August 2028 for high-risk systems embedded in products regulated under Annex I. These dates follow the Digital Omnibus deferral of the obligations once set for 2 August 2026. The Article 50 transparency duties were largely unchanged by that deferral.

How long must AI logs be kept under the EU AI Act?

Deployers must keep the logs generated by a high-risk system, to the extent they are under their control, for a period appropriate to the intended purpose and at least six months. Sectoral law can require far longer, so financial services and healthcare should assume multi-year retention. The signing scheme must stay valid for whichever period applies.

Does storing AI logs in the cloud satisfy Article 12?

Cloud storage can hold logs, but it does not by itself satisfy the intent. If the operator cannot attest the logs were unaltered, and if foreign law can reach the data, the evidential value is weaker than it looks. Records generated and sealed inside operator-controlled infrastructure remove that dependency and keep the audit trail sovereign.

What does post-quantum signing have to do with AI Act logs?

The Act requires logs to remain useful across their retention life, which can span years. Classical signatures may become forgeable once quantum computers mature, and adversaries can store signed logs today to attack later. Signing the ledger with post-quantum schemes such as FIPS 204 keeps each entry provably intact for the full evidence lifetime.