The EU AI Act’s high-risk timeline is in flux. As of mid-2026 there’s active discussion — a proposed “Digital Omnibus” — about pushing the deadlines for high-risk systems: standalone Annex III systems reportedly toward late 2027, product-embedded ones toward 2028. But that’s a proposal, not settled law; nothing confirming a postponement has been published in the Official Journal yet. The Act itself (Regulation (EU) 2024/1689) is in force on its original phased schedule: prohibited practices and AI-literacy duties applied in February 2025, general-purpose AI obligations began in August 2025, and transparency rules arrive in August 2026. If any of this touches you, check the Official Journal and current guidance rather than trust any one summary — including this one.

The reason the deadlines are slipping is the interesting part, because it points straight at a gap you can do something about today.

Why the delay is happening

The deadlines are moving largely because the technical standards aren’t ready. The articles that matter for logging already say what to keep — Article 12 (automatic record-keeping over the system’s lifetime), Article 19 (retention of automatically generated logs), Article 26 (deployers keep those logs at least six months unless other law requires longer), Article 14 (human oversight that presupposes reviewable records). What they don’t yet say is how those records prove they weren’t altered after the fact. The harmonized standards that would pin that down are still being drafted in CEN-CENELEC’s committee JTC 21; until they’re published and referenced in the Official Journal, there’s no officially sanctioned spec for the integrity of a log.

So the law knows it wants trustworthy records. It just hasn’t agreed how you demonstrate trustworthiness. That’s the gap the timeline keeps tripping over.

Why the delay isn’t permission to wait

Here’s the thing a postponement doesn’t change: no future standard can reach backward and make a mutable log trustworthy. Once a system is running, every decision lands in whatever storage you chose. If that storage can be edited, later alteration is always possible — and, worse, can’t be disproven. You can hash-chain old exports after the fact, but you can’t retroactively establish that the record was intact at the moment it was created. That property has to be built in at write time or it’s gone.

I framed houses for years before this, and the rule there is the same: the framing has to be square before the sheathing goes on. You don’t get to fix it later without tearing things apart. Decision records are no different — get the integrity right at creation, or accept that you can’t prove anything about them once it matters.

What we built around it

Marturia produces a tamper-evident receipt for each agent decision:

Verification needs no account and no API call. The public verifier checks the tenant signature, the hash chain, and the witness signatures locally — and past receipts keep verifying even after a key is rotated, because each receipt references the key that signed it:

pip install marturia-verify
marturia-verify --receipt receipt.json --pubkey-hex <tenant-public-key>

This isn’t a compliance program. It addresses one narrow, non-negotiable property: once a decision record exists, its integrity can be demonstrated later without trusting your current storage — and that’s true regardless of which exact date the Act lands on or which fields the standards eventually require. A record that can’t be altered after signing without detection stays verifiable no matter what the harmonized standard adds on top.

This is not legal advice. Confirm your actual obligations against the Official Journal and current guidance for your use case.

The honest way to use a postponement is to spend the runway closing the integrity gap, not deferring it. When the standards do land, you’ll still have to show that the logs you kept match what the system actually did — and starting now, with records that already carry their own proof, is a far shorter trip than retrofitting it under a deadline.

Closed beta is open for engineering and compliance teams who want to test receipt generation and verification in their own pipelines:

Related Marturia resources - /guides/ai-act-iso-42001-crosswalk.html - /blog/what-the-ai-act-makes-you-keep.html - /blog/the-year-we-have-logs-stops-being-enough.html