The EU AI Act as a Decision Tree and a Timeline

If your product is reachable from Brussels, the eu ai act probably applies to you, and the tier you sit in decides everything that follows. That is the whole practical content of this page. Everything else is detail, and the detail is where teams waste quarters.

What follows is a dated timeline taken from the official sources, a decision path from what your system does to which tier it lands in, and a plain list of what each tier obliges you to produce. It is written to be re-checked, because the dates have already been changed once.

What are the four tiers?

The Commission's own framing on the AI Act regulatory framework page is a risk pyramid with four levels, and the levels are not a spectrum of severity so much as four different regulatory regimes.

Unacceptable risk. Banned outright. These are systems judged a clear threat to safety, livelihoods and rights, and no amount of documentation makes them lawful.

High risk. Permitted, heavily conditioned. This covers systems that can pose serious risks to health, safety or fundamental rights, in areas including education, employment, critical infrastructure, biometric identification, law enforcement and migration management.

Transparency risk. Permitted, with a duty to disclose. The concern is people not knowing they are dealing with a machine or with generated content, so chatbots and deepfakes sit here.

Minimal or no risk. The vast majority of systems in the EU. No specific rules. The Commission's own examples are video games and spam filters.

Which tier am I in?

Work it in this order and stop at the first match. Most products stop at step four.

1. Does the system do something on the prohibited list? The high level summary of the Act lists Article 5 practices including subliminal or deceptive techniques that distort behaviour, exploiting vulnerabilities of age or disability or socioeconomic status, biometric categorisation that infers sensitive attributes, social scoring, criminal risk assessment based solely on profiling or personality traits, untargeted scraping to build facial recognition databases, emotion inference in workplaces and schools, and real time remote biometric identification in public spaces for law enforcement, with narrow exceptions. If yes, stop. There is no compliance path.
2. Is it a safety component of a product already covered by EU law requiring third party conformity assessment? That is the Annex I route into high risk, and it usually means you already have a notified body relationship. The Annex III route is the one ordinary businesses fall into, most often through hiring, since filtering job applications is a listed high risk use.
3. Is the use case listed in Annex III? Biometrics, critical infrastructure, education, employment decisions, access to essential services, law enforcement, migration control and administration of justice. There is an escape hatch: systems performing narrow procedural tasks, or improving a prior human decision without replacing human judgement, are treated differently.
4. Does it interact with people or produce synthetic content? Then Article 50 transparency applies. Users must be aware they are interacting with AI, and generated content has to be identifiable as such.
5. None of the above? Minimal risk. Keep a record of how you reached that conclusion, because the record is the answer when somebody asks.

What are the actual dates?

Here is the timeline as it stands, taken from the Commission page and from the omnibus agreement that revised it.

The revision came through the digital omnibus. Gibson Dunn's account of the agreement records the Commission proposal tabled on 19 November 2025, political agreement reached on 6 May 2026 and Council confirmation on 13 May 2026, with formal adoption expected before 2 August 2026.

What did the omnibus not change?

The three things already in force. Article 5 prohibitions have applied since 2 February 2025. General purpose model obligations have applied since 2 August 2025. Article 50 transparency for AI generated content stayed on 2 August 2026 rather than moving with the high risk rules.

That distinction is the practical heart of the matter for anyone shipping a normal product. The deadline that slipped is the one for hiring tools, credit scoring and biometric systems. The deadline that did not slip is the one that says your chatbot has to be identifiable as a chatbot, and it is the same date on which Claude started marking the text it generates with an invisible watermark.

What else did the omnibus add?

Several things that get lost in the delay headline. A new prohibition covering nudifier tools and child sexual abuse material was added to Article 5, with a transitional period to 2 December 2026. Existing systems got a four month watermarking grace period to the same date. Bias detection provisions were widened to cover all AI systems and general purpose models. The regulatory sandbox deadline moved to 2 August 2027. The AI Office gained investigative and enforcement powers, and the AI literacy obligation was softened from a duty to guarantee to a duty to support.

What does each tier oblige you to produce?

Documents, mostly. This is the part that converts a regulation into a project plan, so the table below states outputs rather than principles.

Two notes on the last row. Open source general purpose models are relieved of most of it, retaining the copyright and training summary duties, unless the model is classified as carrying systemic risk. That classification attaches above a compute threshold of 10 to the power of 25 floating point operations, and it brings adversarial testing, systemic risk mitigation, serious incident reporting to the AI Office and cybersecurity requirements.

What does high risk actually cost to satisfy?

More than a document review, less than a clinical trial. The obligations in Articles 8 to 17 are a management system, and management systems have a shape that is familiar to anyone who has been through a quality certification in another industry.

The risk management system has to run across the lifecycle rather than being a document produced once before launch. Data governance requires that training, validation and testing sets be relevant and representative and, in the Act's language, error free to the extent possible, which in practice means you have to be able to describe where your data came from and what you did to it. Technical documentation has to be sufficient for an authority to assess conformity. Logging has to be automatic. Human oversight has to be designed in, meaning a person must be able to understand the output well enough to override it, not merely be present. And accuracy, robustness and cybersecurity must be appropriate to the intended purpose, with the level of each stated rather than assumed.

The item teams underestimate is the last one on the list: a quality management system. That is an organisational commitment rather than an artefact. It says how changes are approved, how incidents are handled, how the documentation stays current when the model is retrained. A team that ships weekly and has never written down its release process will find this the expensive part, not the data governance.

Does using someone else's model make you a provider?

It can, and this catches people. Building on a general purpose model does not automatically make you the provider of that model, but it can make you the provider of the high risk system you built with it. The obligations attach to the system placed on the market under your name for your intended purpose, which is why the same underlying model can sit behind a minimal risk product and a high risk one at the same time.

There is a second trap in the other direction. Substantially modifying a system, or putting your own name on someone else's, can move provider obligations onto you even where you wrote no model code. The practical protection is contractual and documentary: know what the upstream provider has committed to supply, since downstream integrators are explicitly entitled to information under the general purpose model rules.

What counts as a general purpose model with systemic risk?

The threshold is a compute figure rather than a capability judgement. A model trained with more than 10 to the power of 25 floating point operations falls into the systemic risk category, which brings adversarial testing, risk assessment and mitigation, serious incident reporting to the AI Office and cybersecurity obligations on top of the baseline documentation duties.

Two observations about that threshold. It is objective, which is why it was chosen, and it is a proxy for capability rather than a measure of it, which is why it will age. Almost no company reading this trains at that scale. The reason to know the number is that it determines what your upstream supplier is obliged to do, and therefore what you can reasonably ask them for.

What are the penalties, and where do the numbers come from?

From Article 99 of the Act itself, which is worth insisting on because the headline figures circulate widely without a citation and the summary pages do not carry them.

Article 99 sets three bands. Breaching the Article 5 prohibitions carries administrative fines up to 35 million euro or, for an undertaking, up to 7 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. Most other infringements, including the obligations on providers and the Article 50 transparency duties, carry up to 15 million euro or 3 percent, whichever is higher. Supplying incorrect, incomplete or misleading information carries up to 7.5 million euro or 1 percent, whichever is higher.

Then the clause almost nobody quotes. For SMEs, including start-ups, the fine is capped at whichever of the fixed amount or the percentage is lower. The whichever is higher rule that makes the numbers frightening for a large company is inverted for a small one. That is not a loophole, it is written into the penalties article, and it materially changes the risk calculation for a company with twelve employees.

Does this apply to a company outside the EU?

Yes, when the output reaches EU users. That is the mechanism that catches teams who assumed a European regulation was a European problem, and it is the same extraterritorial logic that made data protection everybody's problem a decade ago.

Practically, the question to ask is not where your servers are. It is whether a person in the Union interacts with your system or receives its output as part of your service. If the answer is yes, run the tier decision above and act on the result.

The contrast with the United States is instructive here, because the two jurisdictions are solving different problems. Europe wrote one horizontal law organised by risk. Washington has moved through targeted measures instead, which we traced in how US AI regulation narrowed to targeted bans on open weights and in the split in US policy over Chinese models. A product shipping into both markets is complying with two different theories of regulation, not two versions of the same one.

What should a small team do this quarter?

Four things, in order, and none of them requires outside counsel to start.

1. Classify, in writing. One page per system: what it does, which Annex III use cases it does not fall under and why, and the tier you concluded. Date it.
2. Fix the disclosure. If people can talk to your system or receive content it generated, the transparency duty is already live. This is usually a copy change and a marking convention, not an engineering project.
3. Start the log. High risk obligations require automatic recording of events. Even if you are not high risk, a log you already keep is the cheapest possible evidence when a classification is questioned. Incident handling is the part everyone improvises, which is the failure we described in why AI incident reporting has no playbook for rogue agents.
4. Write the policy down. Not for the regulator. For your own team, so that the answer to what are we allowed to build is a document rather than a conversation. Ours is public on the MaShop AI policy page, and the point of publishing it is that a policy nobody can read is not a policy.

What to re-check

Treat this section as the part that expires. The dates in this piece have already moved once, which is the single most important thing to know about them.

Watch for formal adoption and publication of the omnibus in the Official Journal, because until that happens the revised deadlines are an agreement rather than law. Watch the transitional periods ending 2 December 2026 for the new Article 5 prohibition and for the watermarking grace period. Watch guidance from the AI Office on what a sufficiently detailed training content summary means, since that phrase currently does more work than its length suggests. And watch whether the Annex III list itself is amended, because a change there moves products between tiers without any change to the product.

The honest summary is that the eu ai act is now a live compliance obligation for transparency and for general purpose models, a 2027 problem for high risk systems, and a permanent classification exercise for everyone else. The classification is the work. Do it once, write it down, and revisit it when the product changes rather than when the deadline arrives. Where that classification sits inside a wider programme is set out in a first ninety days of AI governance.