The EU delayed the hard AI Act obligations to 2027. It did not delay the easy one.

The EU AI Act proved something about deadlines this summer: when one moves, the easy half of a rule survives untouched and the hard half is the part vendors quietly stop building for. On June 29, 2026, the Council gave final approval to the Digital Omnibus, which pushed the high-risk obligations for hiring and life and health insurance pricing systems out to December 2, 2027. It left the transparency duty exactly where it was: August 2, 2026. Most vendor decks lead with the first sentence and never reach the second.

What the Digital Omnibus changed

Parliament passed the Digital Omnibus on June 16, 2026. The Council followed on June 29. Between them, the two dates a buyer needs are already mapped in detail: the high-risk obligations for stand-alone Annex III systems, the ones with the heaviest machinery, now apply from December 2, 2027 instead of August 2, 2026, a sixteen-month reprieve. A later date, August 2, 2028, applies only to Annex I systems: AI that is a safety component of, or is itself, a product already governed by sectoral EU product-safety rules, such as machinery or medical devices. That date does not reach hiring or insurance-pricing software just because it happens to run inside a larger HR or policy administration platform. Those stay Annex III systems on the December 2027 date regardless of what they are integrated into. The transparency duty under Article 50, telling a person they are interacting with AI, was not touched. It still took effect on August 2, 2026.

What did not change is the classification underneath the clock. Annex III still names systems used to recruit or screen candidates, evaluate applicants, decide terms of employment, allocate tasks based on personal traits, or monitor worker performance. It still names risk assessment and pricing for life and health insurance. Property and casualty pricing stays outside the list. The category did not move. Only the deadline for the heaviest obligations did, and only for sixteen months.

For a Fortune 500 insurance carrier writing life and health coverage, or for any hiring system that screens and ranks candidates, that deferred deadline does not touch the decision that matters most: what a system recommends about a specific applicant. An underwriting agent that scores a case, drafts a recommendation, and waits for a human to approve, edit, or decline it before the number reaches the applicant is already built for the oversight Article 14 will require once its clock runs out. An underwriting agent that scores a case and moves straight to a quote now has sixteen months to retrofit that oversight onto a workflow that was never built to pause for it, or to keep shipping the fast path and treat the extra time as permission.

This is also the first specification to arrive as one text instead of a patchwork. The US approach runs city by city and state by state, with NYC's automated hiring-tool ordinance, Illinois's video interview statute, and Colorado's replacement ADMT rule each drawing the human-oversight line slightly differently, on their own timelines. A buyer selling across both markets has a European floor that will name the mechanism directly once its runway ends, and a US patchwork that mostly gestures at it today. The architecture question does not change with the jurisdiction or the calendar. Only the paperwork does.

Why the runway is not a reason to wait

A policy document will not satisfy Article 14 in December 2027 any more than it would have this year. A sign-off checkbox in a workflow tool will not satisfy Article 12 either. Both describe intent; neither produces the record an inspector will ask for. The gap between the two is the same gap this site has argued from a different direction for months: governance that lives in a document is a promise, and governance that lives in architecture is a fact, on whatever date someone finally checks.

A human approves, edits, or declines every proposed action before it executes. That is the oversight capability Article 14 will require: someone who can monitor the system, understand what it is doing, and intervene or stop it before an action executes. High-stakes decisions, the kind Annex III names, carry a second, independently authorized signer on top of that gate, a stronger control than the statutory floor, so the oversight is not one person's judgment call under deadline pressure. Every action that does execute, approved or declined, carries a signed Decision Trace: what happened, where, why, and what input the human gave. That is the logging half of what Article 12 will require, generated as a side effect of how the system runs rather than assembled after the fact when an examiner eventually asks.

A model that changes does not get to skip the oversight it earned on the version before it. A new model runs in parallel against the incumbent it would replace before it touches a live decision, so promotion itself is a recorded, human-reviewed event rather than a deploy that happens between audits. The concrete test a buyer can run on any vendor claiming this today, sixteen months early: ask for the trace on one action nobody flagged as sensitive in advance, from last quarter, not last week. If the answer is a screenshot assembled for the question, the logging is cosmetic. If the answer is a query against a record that already existed, it is structural, and December 2027 changes nothing about it.

None of this is new architecture invented for the Act. It is the same argument this site has made about system prompts: a control an enterprise cannot delete was never text in the first place. The omnibus moved the date a filing deadline would have forced the question.

Where the deferral stops and architecture has to start

Sixteen months is a long runway, and it is also exactly enough time for cosmetic to look identical to structural in a demo. Any vendor can add a log table and a sign-off button the week before a review and call the boxes checked. What no deadline, close or far, can inspect for is whether the logging and the oversight are structural, meaning every action produces a trace by default, or cosmetic, meaning a trace exists for the actions someone remembered to record. An examiner reading an audit binder will not be able to tell those two systems apart from the outside. A buyer evaluating a vendor can, today, by asking one question: show me the trace for an action nobody flagged in advance. If the vendor has to go build it, it is cosmetic.

Cosmetic looks identical to structural in a scheduled review, because retrofitting a record after the fact is cheaper than building the system so the record appears on its own. Both look the same in a binder handed to an examiner the week before that review. They stop looking the same the moment someone asks for a trace on an action nobody planned to check, which is exactly the question a real audit is supposed to include, and exactly the question a buyer does not have to wait until 2027 to ask.

Property and casualty underwriting stays outside Annex III even after the omnibus, and the automated decision-making rules some US states are drafting cover different ground entirely. A buyer who waits for a specific rule to name their specific workflow before demanding an inspectable trace is optimizing for the audit that already happened, not the one still coming, on whatever calendar it eventually lands on. The mechanism should not depend on which authority gets there first, or how many times the date moves before it does.

Logging and oversight also do not, by themselves, make a decision correct. A perfectly logged system can still make a bad call and simply log it well. That is a separate problem from the one Article 12 and Article 14 solve, and conflating the two is how "we passed our AI audit" gets mistaken for "our AI system is good." Once enforced, the Act will guarantee inspectability. It will not guarantee judgment.

The proof surface

The architecture answer here is not aspirational, and it does not wait on a filing date. The system is single-tenant and VPC-resident, with no data egress, so the logs an auditor would eventually request never leave the customer's own environment to be produced. The Decision Trace format follows the same methodology published for enterprise hiring decisions: what the system saw, what it recommended, what a human did with the recommendation, and when. An auditor will not have to take a vendor's word for any of it. The trace is the evidence.

Architecture answers what Article 12 and Article 14 will specify once their clock runs out. It does not, by itself, satisfy every obligation elsewhere in the Act, and it is not a substitute for a buyer's own counsel reviewing their specific deployment and timeline against the full text.

What the runway signals

A pushed deadline is not neutral information. It tells a buyer nothing about whether a vendor was building the right thing, only how much longer it can go unbuilt. Sixteen months is long enough to spend two different ways: finishing the architecture Article 12 and Article 14 already describe, or shipping the same fast, unauditable path a little longer because nobody is checking yet. The Digital Omnibus changed a date. It did not change which of those two a buyer is evaluating.

Sources

• The EU AI Act, original text (application dates for high-risk systems later amended by the Digital Omnibus)
• The Digital Omnibus and AI hiring: what changed, what did not
• Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.