The EU AI Act already requires a record of what your high-risk AI does

The EU AI Act is settled law. The Digital Omnibus that amended it was formally adopted by the European Parliament and the Council in June 2026; the text is final. For anyone operating a high-risk AI system, one requirement in that law deserves more attention than it gets, because it is the one you cannot satisfy on short notice: the obligation to keep a durable record of what the system does.

What the law asks for

Article 12 states the rule in one sentence:

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.
EU AI Act, Article 12(1)

Retention is the other half. Article 19 requires providers to keep those logs, and Article 26(6) places the same duty on deployers, in both cases for a period appropriate to the purpose and of at least six months. Read together, the articles describe an evidence obligation, not a monitoring feature: the system has to produce a record automatically, and someone has to retain that record long enough to answer for what happened. Both articles sit in the high-risk regime, which applies from 2 December 2027 for standalone Annex III systems, and 2 August 2028 for high-risk AI embedded in products regulated under Annex I.

Accuracy is the requirement, tamper-evidence is how a record meets it

The recital behind Article 12 says what the logs are for:

Having comprehensible information on how high-risk AI systems have been developed and how they perform throughout their lifetime is essential to enable traceability of those systems, verify compliance with the requirements under this Regulation, as well as monitoring of their operations and post market monitoring.
EU AI Act, Recital 71

Traceability is the job, and traceability rests on accuracy. The Act holds high-risk systems to “an appropriate level of accuracy, robustness and cybersecurity” that they have to sustain throughout their lifecycle, and it requires them to be resilient against unauthorised attempts to alter their use, outputs, or performance (Article 15). Apply that standard to the record itself. An account of what a system did that can be altered or truncated after the fact is not a reliable one, and a log that can change cannot dependably surface the risk situations Article 12 requires the logs to surface. Tamper-evident is another way of saying accurate, once the thing being kept accurate is a record of what happened rather than a model’s output.

Ordinary application logs are mutable by design, which is why the Article 12 record-keeping obligation turns on more than the existence of a log. NIST reaches the same place from the other direction: in its AI Risk Management Framework, measurement gives management “a traceable basis” for decisions only when the underlying record is one you can rely on.

So the record the law is asking for is automatic, retained, and reliable: signed when the event happens, hash-chained so any later change is detectable, and checkable without trusting the party that stored it. Tamper-evidence is not a gold-plated extra on top of the obligation. It is what makes the record reliable, an account you can show reflects what the system did, unchanged since it was written.

Why this is a now problem

An audit trail is the one control you cannot stand up at the deadline, because it cannot be created after the fact. On the day an incident is investigated or a market surveillance authority asks what a high-risk system did, you can only produce records that already exist, written when the events happened. The capability has to be live and its retention window already filling before it is ever relied on, because a contemporaneous record is the one thing you cannot produce after the fact. For a system already in production, standing that up is not a 2027 task.

That is the practical reading of the record-keeping duty. It is satisfied not by having logging ready on the application date, but by having run it, under real traffic, for long enough that the record is there when someone asks.

What building it now looks like

The step is to put a tamper-evident record under the high-risk systems you already operate, so the evidence accumulates as a byproduct of running them rather than as a project you start when an auditor calls.

AGLedger is one way to do that: a self-hosted, signed, hash-chained account of what an automated system intended and did, retained under your own keys and checkable offline. It provides the evidence pattern; your compliance program owns the policy, the risk methodology, and the decisions. The EU AI Act capability crosswalk maps the load-bearing articles to that pattern, Article 12 in depth covers the record-keeping obligation article by article, event logging under Article 12 covers what automatic recording looks like in practice, and log retention under the AI Act covers the six-month floor and what a retained record has to look like to be worth keeping.

Frequently asked

The high-risk rules apply in 2027. Why start record-keeping now?

Because an audit trail cannot be created after the fact. On the day anyone relies on the records, you can only produce what already exists, written when the events happened. For a system already in production, the logging and its retention window have to be running well before the 2 December 2027 application date, not started on it.

Is the EU AI Act timeline still changing, or is it settled?

Settled. The Digital Omnibus that amended the AI Act was formally adopted by the European Parliament on 16 June 2026 and the Council on 29 June 2026; the text is final. The high-risk obligations, Article 12 record-keeping included, apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for high-risk AI embedded in products regulated under Annex I.

Is an accurate log the same as a tamper-evident one?

For a record of what a system did, yes. The Act requires high-risk systems to meet an appropriate level of accuracy and to resist unauthorised alteration (Article 15), and it requires logs that keep the system traceable (Article 12). A record that can be changed after the fact is not an accurate account of what happened. A tamper-evident record, one where any later change is detectable, is how a log stays accurate over its lifetime.