The EU AI Act's Record-Keeping Clock Just Moved. The Requirement Didn't.

If your compliance calendar had "2 August 2026" pencilled in as the day the EU AI Act's record-keeping rules bite, it is time to rub it out. As part of the Digital Omnibus package agreed in mid-2026, the high-risk obligations of the AI Act — Article 12 record-keeping among them — have been pushed back. For stand-alone high-risk systems listed in Annex III, the new date is 2 December 2027; for AI embedded in already-regulated products under Annex I, 2 August 2028. What stays on 2 August 2026 is a narrower set of transparency duties under Article 50 — telling people when they are dealing with AI, and marking AI-generated content.

That is genuinely useful news, and it is also the moment to be careful. A deadline moving is not the same as a requirement changing. Article 12 asks for exactly what it asked for before; the clock simply has more runway on it. The mistake worth avoiding is reading "later" as "not now" — because record-keeping is the one obligation you cannot produce retroactively.

(A note before going further: this is an engineering and product perspective, not legal advice. The Omnibus amendments only bind once published in the EU's Official Journal, and how the Act applies to any specific system is a question for your own counsel.)

The Digital Omnibus moved the high-risk deadline to December 2027. Article 12's demand — automatic, lifetime, traceable logs — did not move at all.

What actually changed, and what didn't

It helps to be precise, because "the AI Act got delayed" is doing a lot of imprecise work in the current discourse. The Act itself is not repealed or paused. Its risk-based structure, its governance bodies, and its core obligations remain intact. What the Omnibus does is defer the application date of the high-risk requirements — a targeted postponement, replacing the original 2 August 2026 date for Annex III systems with 2 December 2027, and pushing Annex I product-embedded systems to 2 August 2028.

The transparency obligations in Article 50 are the exception: they proceed broadly on the original schedule from 2 August 2026, with a short grace period for the machine-readable watermarking duty on systems already on the market. So if your system's obligations are transparency-shaped — disclosure, labelling — 2 August 2026 is still a live date. If they are high-risk-shaped — record-keeping, risk management, human oversight, technical documentation — you have until late 2027 or 2028, depending on how the system reaches the market.

None of this is a reason to relax. It is a reason to plan with the real dates instead of the panicked ones.

What Article 12 actually asks for

Strip away the commentary and Article 12 is short and specific. High-risk AI systems must technically allow for the automatic recording of events — the Act's phrase is "logs" — "over the lifetime of the system." Those logs have to be good enough to trace how the system was functioning, specifically so an operator can identify situations where the system might present a risk or has been substantially modified, support post-market monitoring, and monitor the system's operation in the way the Act's deployer obligations require. For certain systems there is a minimum list of what each log must contain. And deployers are expected to keep those automatically generated logs for at least six months.

Three words in there carry the weight: automatic, lifetime, and traceable. Automatic rules out "we can pull it together manually if someone asks." Lifetime rules out "we started logging when the auditor emailed." Traceable rules out logs that record that something happened without capturing enough to reconstruct what. Article 12 is not a document you assemble at audit time; it is a capability the system has to have been exercising all along.

Record-keeping is the obligation you can't backfill

This is why the extension is build-time rather than skip-time. Most compliance obligations can be satisfied in a sprint near the deadline — you can write a risk-management policy, draft technical documentation, or stand up a human-oversight procedure in the weeks before a date. You cannot retroactively produce a lifetime of logs you were never capturing. If, in late 2027, you need to show what a high-risk system did in the months prior, the only way to have that record is to have been keeping it. Record-keeping is uniquely unforgiving of procrastination, and it is precisely the obligation the extension covers.

So the honest read of 2 December 2027 is not "eighteen more months of quiet." It is "eighteen months to instrument, deploy, and validate a logging capability that then has to run continuously to be worth anything." For a lifetime-logging obligation, that is not a generous runway. It is roughly the right amount of time, if you start now.

For AI agents, the records live on the wire

Here is where the general obligation meets a specific, under-appreciated problem. Article 12 is fundamentally about answering "what did this system actually do?" For a traditional model, that question is mostly answered at the model boundary — inputs and outputs. For an AI agent, it is not. An agent's behaviour is its actions: the tools it calls, the parameters it sends, and — critically — the responses those tools return and that the agent then acts on. The events most relevant to "did this system present a risk" or "was it substantially modified" happen in that agent-to-tool traffic.

Consider what "traceability" means for a concrete incident. An agent retrieves a document through one tool, the document carries a hidden instruction, and the agent then calls a second tool to send data outward. To reconstruct that afterwards — to show a regulator what happened and when the system began presenting a risk — you need the tool responses the agent received and the tool calls it made, correlated in order. A model-level log shows a plausible-looking conversation; it does not show the poisoned response that turned the sequence. The evidentiary trail runs along the wire.

A model log shows a plausible conversation; the wire log shows the poisoned response that turned the sequence — and tamper-evidence is what makes it auditable.

And that is exactly the layer most logging stacks do not capture. Teams log prompts and completions; they log identity and access; they may log platform-level operations. The bidirectional traffic between an agent and the tools it reaches — increasingly over open protocols like MCP — usually goes unrecorded, or is scattered across systems that were never designed to be read together. Which means the records Article 12 most cares about, for the systems the Act most scrutinises, are frequently the ones nobody is keeping. An agent that quietly received a manipulated tool response and acted on it is precisely the "situation that may result in the system presenting a risk" the Article names — and if the wire was not being recorded, there is no log of the thing that mattered.

"Logged" is not yet "auditable"

There is one more distinction worth drawing before the deadline, not after it. A log is only evidence if a reviewer can trust it was not altered after the fact. A plain log file that anyone with access could have edited answers an engineering question — what happened — but not the evidentiary one an auditor or regulator will ask. Turning logs into evidence means recording them in a form whose integrity can be demonstrated: tamper-evident, verifiable, hard to quietly rewrite.

This is the layer CheckedAgent is built to support. CheckedAgent inspects the traffic between an AI agent and the tools it calls, in both directions, and writes a tamper-evident record of what crossed the wire — the tool calls made, the responses returned, and how each was judged. It is designed to give exactly the kind of continuous, traceable, integrity-protected record of an agent's runtime behaviour that Article 12-style record-keeping calls for. To be clear about what that is and is not: it supports the record-keeping requirement; it does not, on its own, make an organisation "EU AI Act compliant," which depends on the whole set of obligations and your own legal assessment. What it does is make sure that when the record-keeping question is asked, the part that lives on the agent-to-tool wire has an answer.

Use the runway; don't wait for it

The lawyers advising on the Omnibus have converged on a consistent line, and it is the right one: the deferral is a deferral, not a dismantling. The architecture of the Act is intact, the high-risk obligations are coming, and the sensible response to more time is to start, not to stall. For record-keeping specifically, that advice has teeth, because this is the obligation where the work has to be running long before the date to be worth anything on it.

The clock moved to December 2027. Article 12 did not move at all. The organisations that treat the extension as time to build a real, continuous, auditable record of what their agents do — down to the tool traffic on the wire — will meet the date comfortably. The ones that read "later" as "never mind" will arrive in 2027 with a requirement they cannot satisfy retroactively, and no log of the eighteen months they had to prepare.

This article is for general information and is not legal advice. CheckedAgent is an Agent Detection & Response (ADR) platform for MCP and agent-to-tool traffic: an inline proxy that inspects the messages between AI agents and their tools in both directions and records them in a tamper-evident audit trail. It supports record-keeping and monitoring obligations; it complements, and does not replace, legal counsel and platform-level governance.