The EU AI Act's headline deadline was 2 August 2026. Five days before it landed, the Digital Omnibus moved most of it. High-risk obligations for standalone systems now fall due in December 2027, and for AI inside regulated products in August 2028. Here is what the Act actually is, who it binds, what genuinely applies on 2 August, and what the deferral costs you if you read it as relief.
The EU AI Act's headline compliance date was 2 August 2026. Five days before it arrived, most of it moved.
The Digital Omnibus on AI was published in the Official Journal on 24 July 2026 and entered into force on 27 July. It is the first set of amendments to the Act since it was adopted in 2024, and it pushed the high-risk obligations that nearly every published summary attaches to 2 August into 2027 and 2028.
That matters more than a calendar correction. Teams plan against dates. A team that reads a stale summary this week either sprints at obligations that are not due, or reads "deferred" as "dropped" and stops. In a regime where the deliverable is evidence that has to survive an audit, both failures cost the same thing: time you cannot buy back at the end.
The AI Act is product safety law wearing the vocabulary of technology policy. It does not regulate models in the abstract. It sorts systems by what they are used for, then attaches duties to the risk tier rather than to the architecture.
Four tiers. Unacceptable risk is banned outright, in force since February 2025: social scoring, untargeted facial-image scraping, emotion inference in workplaces and schools, and several categories of biometric identification. High risk carries the heavy obligations, and that is the tier this article is mostly about. Limited risk owes transparency and nothing more. Minimal risk, which is most software, is essentially untouched.
Anyone who has shipped under ISO 26262 or IEC 62304 will find the high-risk requirements familiar to the point of boredom: risk management across the lifecycle, data governance, technical documentation, record keeping, human oversight, accuracy and robustness and cybersecurity targets, conformity assessment, post-market monitoring, incident reporting. The novelty is not the engineering. It is that the engineering now has a statutory audience.
Four roles carry obligations: providers who develop and place systems on the market, deployers who use them under their own authority, and importers and distributors who move them.
Deployer is the one companies underestimate. You can buy a system, deploy it in a hiring or credit decision, write no model code at all, and hold obligations of your own.
The reach is extraterritorial in the way GDPR taught everyone to expect. The Act applies to providers placing systems on the EU market wherever they are established, and to providers and deployers outside the EU when the system's output is used inside the EU. Penalties are calculated on total worldwide annual turnover, not EU revenue: up to 7% or 35 million euro for prohibited practices, 3% or 15 million for high-risk breaches, 1% or 7.5 million for misleading information supplied to authorities. SMEs and startups get the lower of the two figures rather than the higher. The 7% ceiling was set above the GDPR's 4% on purpose.
| Date | What falls due |
|---|---|
| 1 Aug 2024 | Act enters into force |
| 2 Feb 2025 | Prohibited practices banned; AI literacy obligations begin |
| 2 Aug 2025 | General-purpose AI model obligations |
| 2 Aug 2026 | Article 50 transparency; machine-readable marking of synthetic media |
| 2 Dec 2026 | Marking grace period ends for synthetic-media systems already on the market |
| 2 Dec 2027 | Annex III standalone high-risk systems (moved from 2 Aug 2026) |
| 2 Aug 2028 | Annex I AI embedded in regulated products (moved from 2 Aug 2027) |
| 2 Aug 2030 | High-risk systems operated by public authorities |
What genuinely lands on 2 August 2026 is Article 50. If your system talks to a person it has to say it is a machine, unless that is obvious. Synthetic audio, image, video and text need machine-readable marking. Emotion recognition and biometric categorisation have to tell the people exposed to them. Systems already on the market get until 2 December 2026 to add the marking.
That is the whole of it. Not the risk management file, not the technical documentation, not the conformity assessment.
The two deferrals are not the same deferral, and the split is the first thing to establish.
Annex III is standalone systems in listed uses: biometrics, critical infrastructure, education, employment and worker management, essential services, law enforcement, migration, justice. If you sell a CV-screening tool, this is you. Your date is 2 December 2027.
Annex I is AI that is a safety component of, or is itself, a product already covered by EU harmonisation legislation that requires third-party conformity assessment. Vehicles, machinery, medical devices, lifts, toys. If you put a perception stack in a car or a control model in an industrial machine, this is you. Your date is 2 August 2028.
The extra eight months on the Annex I side is not generosity. It exists because that AI work has to fold into a product certification that already exists, with a notified body that already has opinions, on a programme that was planned before anyone wrote an AI regulation. Anyone who has watched a homologation timeline knows that integrating a new evidence stream into an existing certification is slower than producing that evidence standalone.
The new dates are fixed. They are not conditional on harmonised standards being published, which means the usual excuse for waiting does not apply: you cannot argue you were blocked pending a standard that never arrived.
More to the point, the obligations did not shrink. Risk management, data governance, technical documentation, human oversight, post-market monitoring. Every one of them survives the amendment unchanged. What moved is when the auditor arrives.
I have spent fifteen years inside programmes governed by this kind of regime, writing the work products and sitting in the assessments. The failure mode is consistent and it is not ignorance of the deadline. Teams treat a moved date as permission to stop, then compress three years of evidence production into the final six months. The documents get produced. They are signed, traceable, complete, and they describe a development process that did not happen. That is the point at which compliance stops being a safety mechanism and becomes a paperwork exercise with legal exposure attached.
The work that makes the deadline survivable is the work that was always going to make the product better: knowing what your training data is and where it came from, being able to say why the system behaves as it does, having a human in the loop who can actually intervene, and monitoring the thing after it ships. None of that is faster in 2028 than it is now.
Establish which annex you fall under, and whether you are provider or deployer or both. Those two answers set your date and your obligations, and a surprising number of companies cannot state them today.
Then check Article 50 against what you have in production right now, because that one has been live since 2 August. If a system of yours talks to customers, it has to say what it is.
Everything else you have until December 2027 or August 2028 to get right, which sounds like a long time and is roughly one product programme.
Fadi Labib runs this field lab. 15 years in automotive, robotics, and embedded systems; ESMT Berlin EMBA. I give AI real engineering problems, then check its work. More about the lab →
Carmakers now call themselves "Software-Defined Vehicle" companies. Nobody calls a smartphone "software-defined". Phones were software-first from day one, so the label was never needed. The SDV prefix is automakers announcing they have to rebuild around software two decades after mobile did.
Every carmaker chasing software-defined vehicles qualifies the same foundational tools on its own: operating systems, toolchains, LLVM. The work is duplicated across the industry and none of it is a differentiator. The fix is to qualify those shared foundations together and compete on the product instead.
Nokia launched the first smartphone in 1996, 11 years before the iPhone, and had superior technology with a massive R&D budget, thousands of patents, and advanced features like GPS and 5MP cameras. Yet they failed. Why? Not because of technology, but because they couldn't transform from a hardware company to a software company. Developers abandoned them for platforms that took software seriously. Today's carmakers are repeating Nokia's mistake: spending billions on research but focusing on the wrong things, while Tesla and Chinese EVs play by software-first rules, just as Apple and Samsung did against Nokia.