EU AI Act Article 12 logging: the high-risk deadline moved to 2027

If you built your compliance plan around 2 August 2026, that date has moved. Council and Parliament negotiators reached a provisional agreement on the Digital Omnibus on AI on 7 May 2026; Parliament adopted it on 16 June and the Council gave final approval on 29 June 2026. The headline: the rules for high-risk AI systems are pushed back by more than a year.

It’s tempting to read that as breathing room and move on. We’d push back on that - not to invent urgency, but because of what got delayed and why. The delay is real and welcome. For most teams, the right response is still to keep going. Here’s what changed, what Article 12 still demands, and why the training-data layer is the one part of this you want to start early.

What the Omnibus actually changed

The Omnibus delays high-risk obligations on two tracks.

Stand-alone high-risk systems - the Annex III list covering recruitment, credit scoring, education, biometrics, law enforcement, and essential services - now apply from 2 December 2027, about sixteen months later than the original 2 August 2026 date. High-risk AI built into regulated products (medical devices, machinery, vehicles) moves to 2 August 2028.

These are fixed dates, not conditional ones. The Commission’s original proposal tied the delay to a trigger mechanism; the co-legislators dropped that in favor of hard dates, specifically so teams could plan against them. Treat 2 December 2027 and 2 August 2028 as the dates that apply, and have counsel confirm which track your product sits on.

And here’s the part that matters most: only the deadline moved. The risk tiers, the assessments, the obligations themselves - all intact. When 2 December 2027 arrives, Article 12 will read exactly as it does today.

What Article 12 still requires

Article 12 catches teams off guard because it isn’t about how your model behaves. It’s about whether you can prove what it did.

It requires high-risk AI systems to “technically allow for the automatic recording of events (logs) over the lifetime of the system.” Two words carry the weight:

• Automatic - the system creates the records itself. A document you write afterwards, describing what you think happened, doesn’t count.
• Lifetime - from the day you deploy the system to the day you retire it. Not from the day your compliance program finally switched on.

The logs exist for three jobs: spotting when a system might pose a risk or has been changed significantly, supporting monitoring after launch, and helping deployers keep watch day to day. Related rules say you keep these logs for at least six months, and longer if the system needs it.

Does this apply to you? For most organizations running AI in real, decision-affecting situations that fall into a high-risk category, yes. And getting it wrong is expensive: penalties for high-risk non-compliance reach €15 million or 3% of global annual turnover, whichever is higher.

A quick note on who’s responsible. Article 12 lands mainly on the provider - the company that builds the system. Deployers have their own separate duties. But plenty of enterprises both build and deploy, and making significant changes to a system can pull provider duties onto you. So “we just deploy it” is rarely a clean way out.

The gap most teams miss: a log proves what happened in production, not where your data came from

This is the under-discussed part, and the reason a delay isn’t a reason to wait.

When a regulator, auditor, or customer’s procurement team digs into a high-risk model, the questions go back to the training data. That’s a data provenance question - and provenance has one inconvenient feature: you either captured it while you were labeling, or you didn’t.

That made sense when buyers asked about speed and cost per label. But the question has shifted: not “who labels fastest,” but “who can prove the label holds up.” The teams that treat these extra eighteen months as preparation, not a reprieve, will have a defensible evidence base when the date lands.

What a defensible annotation stack has to show

Trace Article 12’s logic back to the data, and a short checklist falls out. A pipeline that can stand up to scrutiny needs to show how its logs connect to where the data came from:

• A tamper-evident log of every labeling action - a record of who did what and when, written as it happened and impossible to quietly edit later.
• A clear chain of custody for the dataset - the full path from raw data to finished label, exportable in a form auditors recognize.
• Separation of duties - labeler, reviewer, and auditor as distinct, enforced roles.
• A real quality score - a measured number, plus a record of how disagreements got resolved.
• Retention you can rely on - logs kept long enough for the legal minimum and your model’s full life.

Where LabelFort fits

This is the problem LabelFort was built for, not bolted onto afterwards. Every label, every reviewer action, every configuration change goes into a record that can’t be quietly altered, and the full chain of custody for any project exports in formats auditors already accept.

To be precise: LabelFort governs the training-data layer. It works alongside, not instead of, the runtime logging your live system needs for its own Article 12 duties.

The honest bottom line

The deadline moved. The work didn’t. Article 12 doesn’t ask whether you mean to keep records; it asks whether your systems produce them automatically, across their whole life - and whether that same discipline reaches back to the data underneath. For training data, putting it off is the expensive choice, because you can’t backfill provenance. See evidence-grade annotation for what to capture at labeling time.

FAQs

If you want to know whether your annotation evidence would hold up under that scrutiny, that’s a conversation worth having now - while there’s still time to fix whatever it surfaces.