What changed — and what did not
On 19 November 2025 the European Commission published the Digital Omnibus on AI, a proposal that would defer the headline applicability date for high-risk systems listed in Annex III from 2 August 2026 to 2 December 2027. Product-embedded high-risk systems under Annex I would slip further, to 2 August 2028. The proposal also introduced a so-called fast-track: if the Commission concludes that the harmonised standards and compliance tooling are actually ready, Annex III obligations can apply six months after that decision, and Annex I obligations twelve months after.
Then the politics happened. The second trilogue between Parliament, Council and Commission on 28 April 2026 ended without political agreement. The sticking point was not the high-risk dates themselves — the three institutions had broadly converged on the December 2027 backstop — but the conformity-assessment architecture for Annex I products and how it interacts with existing sectoral safety law. A follow-up round is expected in mid-May under the Cypriot Presidency. Until a revised Omnibus is agreed and published in the Official Journal, Regulation 2024/1689 remains in force as drafted, and 2 August 2026 is still the date a court would point at.
Crucially, three things were never on the table for revision. The prohibited-practices regime under Article 5 has been live since 2 February 2025 and is not being unwound. The general-purpose AI obligations have applied since 2 August 2025 (covered in our GPAI deadline checklist). And the penalty ladder under Article 99 — up to thirty-five million euros or seven percent of worldwide turnover for prohibited use, fifteen million euros or three percent for high-risk non-compliance — is untouched.
The timeline, with penalties
The cleanest way to read the file is as a layered cake: prohibited practices first, GPAI second, high-risk last. The Omnibus is only loosening the icing on the top layer.
| Phase | Original date | Proposed (Omnibus) | Maximum fine |
|---|---|---|---|
| Entry into force (whole Act) | 1 Aug 2024 | Unchanged | — |
| Prohibited practices (Article 5) | 2 Feb 2025 | Unchanged — already live | €35M or 7% turnover |
| General-purpose AI obligations | 2 Aug 2025 | Unchanged — already live | €15M or 3% turnover |
| High-risk Annex III applicability | 2 Aug 2026 | 2 Dec 2027 | €15M or 3% turnover |
| High-risk Annex I (product-embedded) | 2 Aug 2027 | 2 Aug 2028 | €15M or 3% turnover |
| Misleading information to authorities | From entry-into-force | Unchanged | €7.5M or 1% turnover |
For SMEs, Article 99(6) flips the penalty calculation: it is the lower of the two figures rather than the higher. That mostly matters to bootstrapped scale-ups; once you cross roughly a billion euros of turnover, you are paying the percentage in either direction.
The slip is a proposal, not a fact. As of early May 2026 the August 2026 high-risk date legally stands. Any compliance plan that quietly pushes deliverables into late 2027 on the assumption that the Omnibus passes is making a political bet, not an engineering one. If the trilogue keeps stalling — it has stalled twice — the original date can come back into play.
What Annex III actually catches
Annex III is the part of the Act most builders are exposed to. It lists eight families of high-risk use cases: biometric identification and categorisation; safety components for critical infrastructure (water, gas, electricity, road traffic); education and vocational training, including admissions and exam scoring; employment, worker management and access to self-employment, including CV-screening; access to and enjoyment of essential private and public services, including credit scoring and benefits eligibility; law enforcement; migration, asylum and border control; and administration of justice and democratic processes.
If the system you ship lands in any of those buckets, you are obliged — whether the deadline is August 2026 or December 2027 — to maintain a documented risk-management system, ensure data governance over training and validation sets, produce technical documentation and instructions for use, enable human oversight, hit accuracy and robustness thresholds, register the system in the EU database before placing it on the market, and run post-market monitoring. Deployers in the public sector and certain regulated industries additionally owe a fundamental-rights impact assessment, or FRIA. None of that goes away in the Omnibus draft. Only the date you must be ready by moves.
The view from London — UK exporters
Brexit did not exempt UK firms from the Act. The Regulation reaches any provider placing a high-risk system on the EU market, any deployer established in the EU, and any provider or deployer outside the EU whose system's output is used inside it. A British fintech in Shoreditch running credit-decision models for a Dublin-based lender, or an Edinburgh medtech selling triage software to French hospitals, or an NHS-Digital partner offering analytics to a Belgian counterpart — all in scope. Domestic UK rules, including the recent SI 2026/425 on automated decisions, sit alongside the EU regime; they do not replace it.
The practical question for UK boards is whether the slip lets them defer hiring a notified-body assessor, postpone the database registration project, or trim the risk-management documentation budget for FY26. The answer, mostly, is no. The Act's risk-management obligations are continuous: by the time you place a system on the EU market, your evidence trail has to start before the model went into training, not after. A sixteen-month deadline slip does not give you sixteen extra months of training data — it gives you the same training data with sixteen extra months of records hygiene to demonstrate.
Treat the Omnibus the way good engineering teams treat feature flags: design to the later date, ship to the earlier one. Your data-lineage logging, your fundamental-rights impact assessment template, your post-market monitoring pipeline — build them on August 2026 milestones. If the December 2027 backstop materialises, you have a more polished release; if it does not, you are not scrambling.
The view from Bengaluru, Pune and Hyderabad — Indian GCCs
Indian Global Capability Centres are arguably the population the slip will tempt most. A typical EU-facing GCC build looks like this: parent bank or insurer in Frankfurt or Paris commissions a credit-scoring or claims-triage workflow; the build sits in Bengaluru or Pune; data flows are governed by the parent's contracts; the model serves end-users inside the EU. That puts the GCC squarely inside Annex III through the deployer's accountability chain. The Indian Digital Personal Data Protection Act gives a useful baseline on consent and data minimisation, but it does not satisfy the AI Act's risk-management, technical-documentation or post-market monitoring obligations. Treating DPDP as a sufficient internal standard while the EU dust settles is the most expensive shortcut available.
The harder problem is that GCC delivery cycles tend to be sprint-shaped, not regulation-shaped. A team aware that the deadline might slip can quietly deprioritise the unglamorous deliverables — the data-lineage register, the FRIA scoping document, the model-card refresh cadence — in favour of feature work. By the time the slip is, or is not, codified, the documentation backlog is too deep to clear in a quarter. The cheapest counter is to fold the documentation deliverables into the same sprint as the model work that produces them.
Concrete actions, regardless of the slip
- Data lineage — every training-data source must trace back to a contract, a licence, or a documented public-domain provenance. The Act expects this for any high-risk system; it does not care which year you started keeping the records.
- Post-market monitoring — define the metrics that would trigger a model rollback or recalibration, and the dashboard that surfaces them. The slip does not move the day you need this live.
- FRIA scoping — for public-sector or regulated-industry deployers, draft the fundamental-rights impact assessment template now. The first one always takes a quarter; the second takes a fortnight.
- Transparency obligations — Article 50's user-facing notices for chatbots, deepfake-style synthetic media and emotion recognition apply on the existing schedule. Do not bundle them into the high-risk workstream — they are a separate gating item.
- EU database registration — the technical mechanics of registering a high-risk system ahead of placement on the market take longer than teams expect. Pilot a registration walk-through on a non-production system this quarter.
Why the political tea-leaves matter
Two member-state positions are worth tracking. France has historically been sympathetic to relief for European AI champions and is broadly comfortable with the December 2027 backstop. Germany's posture is harder to summarise — both Berlin and Paris missed the original deadline for designating their national competent authorities, alongside seventeen other member states, which is part of why the Commission needed an Omnibus in the first place. The clean reading is not "France yes, Germany no" — it is that member-state divergence on enforcement architecture is itself the reason the deadline is moving, and the same divergence is what keeps stalling the trilogue.
For builders, the implication is operational rather than ideological. Even when the Omnibus eventually passes — and in our reading it will, possibly under the Cypriot Presidency in mid-May or the next Council rotation — the lag between adoption and effective enforcement will be uneven across the bloc. A high-risk system placed on the market in a country whose competent authority is fully staffed will face different scrutiny from one in a country still appointing officials. The compliance baseline you build for the strictest reading of the Act is the one that travels.
Want to discuss this with other verified Builders?
Every article on AI Tech Connect is written or edited by Verified Builders. Browse profiles, shortlist who you want to hire or collaborate with.
Browse Builders →So what should you actually do this quarter?
Three things. First, read your own product portfolio against the Annex III categories and decide — at the leadership level, with the decision documented — which systems you intend to keep, which you intend to redesign out of scope, and which you intend to withdraw from the EU market. The second category is where most of the cost-saving lives, and it is also the category that needs the most lead time.
Second, scope the documentation programme as if the August 2026 deadline holds. The Omnibus has stalled twice. A team that is ready in August 2026 is also ready in December 2027 with a cleaner record; a team that paces itself for December 2027 and gets caught by the original deadline is in trouble. Design for the later date in your architecture, but ship to the earlier one in your release plan.
Third, do not let the slip dilute the prohibited-practices and GPAI obligations that are already in force. Those two layers of the cake are baked. If your product anywhere touches social-scoring-style behavioural assessment by public authorities, untargeted facial-image scraping, emotion recognition in workplaces or schools, or real-time biometric identification in public spaces with the narrow law-enforcement carve-outs, you have a thirty-five-million-euro exposure today, not in 2027.
Builders who treat the Omnibus as breathing room are reading the file as a bureaucrat would. Builders who treat it as a feature flag — same architecture, same evidence trail, slightly different release date — are reading it as engineers do. The second reading is cheaper, faster, and survives the political weather.
For the canonical text of the Regulation, see the consolidated version on EUR-Lex (Reg 2024/1689), the Commission's regulatory framework page, and the community tracker at artificialintelligenceact.eu. Cross-reference our deeper dive on the August 2026 high-risk deadline and the India DPDP deepfake rules for the cross-jurisdiction picture.