The AI Act delay doesn't delay your evidence problem

The Digital Omnibus entered into force on 27 July 2026, and with it the deadline most teams had been planning around moved. Obligations for high-risk systems designated under Article 6(2) and Annex III now apply from 2 December 2027 rather than 2 August 2026; AI embedded in regulated products under Annex I moves to 2 August 2028.

The obvious response is relief, and it isn't unreasonable — reporting through 2026 consistently found that the large majority of organisations in scope hadn't meaningfully started. An extension for work nobody had begun is genuinely useful.

The less obvious response, and the one worth acting on, is that the extension bought calendar time rather than engineering time, and those are only the same thing if the work is paperwork. For one specific obligation, it isn't.

Article 12 is an architecture requirement

Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. Articles 19 and 26 set a six-month minimum retention. For deployers using a third-party system, the obligation doesn't disappear into the vendor relationship: you need to verify the system can produce the required logs, that they're accessible to you, and that they're retained in a form suitable for analysis and regulatory review.

"Technically allow" is doing real work in that sentence. It's a property of how the system is built, not a policy you can write in the final quarter before a deadline. And the difference between "we have logs" and "we can answer what this system decided, when, on what basis" is most of the effort.

Why this one doesn't compress

Most compliance work genuinely does compress. Documentation can be written quickly. Risk assessments can be produced by people who know the system. Policies can be adopted in a meeting. Those tasks scale with effort, which is why deadlines move them.

A per-decision evidence trail doesn't behave that way, for three reasons.

It has to be there while the decisions happen. You cannot retroactively produce records of what an agent decided last March. If instrumentation wasn't running, that period is simply undocumented, and no amount of subsequent effort recovers it. Every month without it is a month of history you don't get back.

It touches every code path. Adding a decision log to a running agent system means finding every point where the system acts, which in a mature codebase is a diffuse and unglamorous change spread across adapters, tool wrappers, and error paths. It's the kind of work that takes a quarter and produces no visible feature.

What you log has to be decided before you log it. A log line saying an action occurred is not evidence of anything useful. Evidence needs the inputs, the decision, the rule version that produced it, and the identity acting — and working out that schema after you've collected six months of the wrong shape means collecting six more.

What a governance layer contributes, precisely

Being specific here matters, because this is the point in the argument where the category usually starts overclaiming.

A policy decision point sits between the agent and its actions and evaluates each one. That position happens to be where the evidence lives: every governed event can be recorded with the arguments, the session and identity context, the policy version that decided it, the decision itself, and — for anything escalated — the human who approved it and when. Because the policy is version-controlled Rego, a decision made in March is reproducible in October against the rules as they existed at the time.

That produces the raw material for record-keeping obligations, and it produces it as a side effect of enforcement rather than as a separate logging project. Those are the two properties worth having.

What it does not do is make anyone compliant. The AI Act imposes risk management, data governance, technical documentation, transparency, human oversight, accuracy and robustness requirements, and conformity assessment — an organisational programme, most of which is not a software problem at all. A decision log supports specific controls within that programme. It is one input to an obligation that remains entirely yours.

The defensible claim is "produces evidence that supports record-keeping controls." The indefensible one is "makes you AI Act compliant." Vendors making the second claim are describing something that cannot exist.

What to do with the extension

If sixteen extra months are going to be worth something, the useful way to spend the first of them is on the part that can't be compressed later.

Instrument now, decide the schema now, and start accumulating history — so that when the documentation work does begin, it's describing a system that already produces evidence rather than proposing one that might. If you're a deployer, the question worth asking your vendors this quarter is whether they can produce per-decision records at all, because finding out in 2027 that the answer is no leaves you with no good options.

The deadline moved. The lead time didn't.

None of this is legal advice. Whether a system is high-risk, and what any organisation must do about it, is a question for counsel. The engineering point stands regardless of how that question resolves: evidence you didn't collect is evidence you don't have.

Frequently asked questions