The EU AI Act, in plain terms

The EU AI Act is a long document that has generated a great deal of anxiety and very little clarity. Most of what is written about it is either a compliance sales pitch or a summary so high-level it tells you nothing you can act on. The truth is more manageable. For almost any organisation, the practical question comes down to two things: which risk tier your use of AI falls into, and what that specific tier requires. Everything else is detail.

Here is the version I wish someone had handed me the first time I had to work under it.

It is a pyramid, not a wall

The Act sorts AI by risk into four bands, and your obligations depend entirely on which one you land in (high-level summary).

At the top, a small number of uses are simply prohibited. Below that sits a defined set of high-risk uses, which carry real, heavy obligations. Below that, some systems have transparency duties, meaning you mostly just have to tell people. And at the bottom, the large majority of AI, the spam filters, the recommendation engines, the everyday tools, is minimal risk and carries essentially no new legal burden at all.

The single most useful thing you can do is find your tier honestly, because most of the panic comes from organisations assuming they are in a heavier band than they actually are, and most of the real risk comes from the few who assume they are in a lighter one.

The banned list

A handful of practices are outright prohibited under Article 5, and these rules have applied since 2 February 2025 (Article 5). The list includes things like manipulative techniques that distort behaviour to a person’s harm, exploiting the vulnerabilities of the elderly or disabled, social scoring of individuals, scraping the internet to build facial-recognition databases, and inferring emotions in the workplace or in schools.

For most organisations this band is easy: you are not doing any of it, and you can move on. But it is worth an honest read, because a few of the bans, emotion inference at work, for example, catch tools that vendors cheerfully market without mentioning the legal line they sit on.

High-risk: where the real work is

This is the band that matters, and the one worth slowing down on.

A use is high-risk if it falls into one of eight domains listed in Annex III: biometrics, critical infrastructure, education, employment, access to essential services (including credit and insurance), law enforcement, migration and border control, and the administration of justice (Article 6). If your AI helps decide who gets hired, who gets a loan, who gets triaged, or who gets a benefit, you are probably here.

High-risk systems carry the heavy obligations: a risk management system, data governance, technical documentation, logging, accuracy and robustness and cybersecurity, a conformity assessment before the system goes on the market, and, running through all of it, meaningful human oversight. Article 14 requires that a person can actually oversee the system in use, and Article 26 requires the organisation deploying it to assign that oversight to a named person with the competence, training, authority, and resources to do it.

Read that last part again, because it is the whole point of the other essays on this site. The law is not asking for a better model. It is asking you to name the accountable human on the floor, which is exactly the management gap written into statute, and to keep watching the system in production rather than certifying it once, which is exactly the demo-to-ship delta made a legal duty. The Act, read plainly, is mostly a legal description of what teams who ship AI well already do.

These standalone high-risk obligations apply from 2 December 2027. That date matters, because a lot of coverage still reports the old 2 August 2026 date, which is actually when general application and the transparency rules began, not when the high-risk duties bite. You have time, but the work these rules describe takes about that long to do properly.

What a high-risk file actually contains

“Heavy obligations” stays abstract until you see the list, so here is what a high-risk system has to be able to produce. None of it is exotic.

• A risk management system: a living record of what could go wrong and what you did about it, not a document you write once and file.
• Data governance: evidence that the data you trained and tested on was relevant, representative, and checked for bias.
• Technical documentation: what the system is, how it was built, and how it performs, detailed enough that a regulator could follow it.
• Automatic logs: the system records its own activity, so events can be traced after the fact.
• Instructions for use: clear guidance for whoever runs it on how to keep it inside its limits.
• Human oversight: not a sentence in a policy, but a named person with the authority and training to step in (Articles 14 and 26).
• A conformity assessment and CE marking before it goes on the market, and post-market monitoring once it is live.

Read that as an operator rather than a lawyer and it is mostly a description of a system that someone actually understands and can stand behind. The paperwork is a by-product of having done the work. Which is exactly why teams that try to produce the file without doing the work find it the hardest paperwork they have ever written: you cannot document an accountable owner who does not exist.

Transparency: mostly, just tell people

A middle band of systems does not carry the high-risk burden but does have to be honest about itself, under Article 50, in force since 2 August 2026 (Article 50).

The rules here are close to common sense. If a person is talking to an AI, tell them. If content is an AI-generated deepfake, label it. If you publish AI-generated text on a matter of public interest, disclose it. Synthetic media has to be machine-marked as artificial. None of this is heavy engineering. It is mostly a matter of not pretending a machine is a human, which is a reasonable thing for a law to ask.

If you use ChatGPT, or a model like it

Most organisations do not build models, they use someone else’s: a general-purpose model like GPT or Gemini. The Act has a separate track for these, and most of it is genuinely not your problem.

The heavy duties fall on the model provider, not on you. Since 2 August 2025, providers of general-purpose AI have had to keep technical documentation, pass capability and limitation information down to the companies building on their model, put in place a copyright-compliance policy, and publish a summary of what the model was trained on (Article 53). The largest, most capable models carry extra obligations around evaluation, testing, and incident reporting (Article 55). That is OpenAI’s and Google’s homework, not yours.

The catch is the part people miss. Using a general-purpose model does not launder your own use out of the high-risk band. If you build a hiring tool or a triage system on top of a general model, you are still the deployer of a high-risk system, with every duty in the sections above. The model belonging to someone else does not make the decision it drives any less yours.

The timeline, so you panic about the right date

The Act does not switch on all at once. It phases in, and confusing the phases is the most common mistake I see.

• 2 February 2025: the prohibited practices, and AI-literacy duties.
• 2 August 2025: rules for general-purpose AI models, plus governance and the penalty regime.
• 2 August 2026: general application, including the Article 50 transparency duties.
• 2 December 2027: the core obligations for standalone high-risk systems (Annex III).
• 2 August 2028: high-risk obligations for AI embedded in already-regulated products (Annex I).

If you take one thing from this essay, take the difference between August 2026 and December 2027. The scary, expensive, high-risk obligations are the later date. Plenty of organisations are either panicking early or, worse, assuming the whole thing is already in force and quietly ignoring it.

Who it actually applies to

Two roles matter. A provider builds an AI system or puts it on the market. A deployer uses one under its own authority. Most organisations are deployers, and the Act gives deployers of high-risk systems real duties of their own, chiefly the human-oversight and monitoring obligations above.

It also reaches beyond the EU. Under Article 2, the Act applies not only to providers and deployers in the Union, but to those outside it whenever the system’s output is used in the EU (Article 2). A US vendor selling into Europe, or a system whose results land in front of an EU user, is in scope. “We are not a European company” is not the exemption people hope it is.

The penalties everyone quotes, in context

You have seen the number: up to 35 million euros or 7 percent of global turnover. It is real, but it is worth knowing what it is actually for. Under Article 99, that top fine applies to the prohibited practices, the banned list (Article 99). Breaching the other obligations, including the high-risk duties, carries up to 15 million euros or 3 percent of turnover, whichever is higher. Supplying incorrect information to regulators is up to 7.5 million euros or 1 percent. Small companies get the lower of the amount or the percentage, not the higher.

The point is not that the fines are gentle. It is that the number in the headline is attached to doing something banned, not to a paperwork slip on a low-risk tool. Match your fear to your tier.

The honest read

Here is what I actually think about the Act, having had to work under it rather than write think-pieces about it.

Most of it is not new work, it is written-down good practice. If you were already going to name an accountable owner, document what your system does, watch it in production, and be honest with the people it affects, the Act is largely asking you to keep doing that and keep the records. The genuine new burden falls on high-risk uses, and it is real, but it is the same burden that separates AI that ships from AI that gets abandoned, now with a legal deadline attached.

The trap is treating the Act as a box to tick. A compliance file that says you have human oversight, produced by a team that does not actually have it, is worse than useless, because it is trendslop with a legal letterhead: a confident claim built so that nobody checks whether it is true. The Act rewards the organisations that do the thing, and it will, eventually, expose the ones that only wrote it down.

What I have seen

I build and ship AI in the domains this regulation is aimed at, and my honest experience is that the Act is less of a shock to teams that were already serious and more of a reckoning for teams that were not. The organisations that struggle with it are usually the ones being asked, for the first time, to write down who is accountable and how they know the system works, and to discover they never had a clear answer. The regulation did not create that gap. It just turned on the lights.

What to do about it

Start with one honest hour: work out which tier each of your AI uses actually falls into. Most will be minimal or transparency-only, and you can stop worrying about those. For anything that looks high-risk, do not start with the paperwork, start with the substance the paperwork is supposed to describe: who owns it, how you would know it was failing, and what you would show a regulator if they asked. Get that right and the compliance file mostly writes itself. Get it wrong and no file will save you.

The Act is not the thing to be afraid of. Shipping AI you cannot actually stand behind, in a domain where being wrong is expensive, is the thing to be afraid of. The regulation is just the part that finally makes someone ask.

---

Sources

• Regulation (EU) 2024/1689 (the EU AI Act).
• High-level summary of the AI Act, artificialintelligenceact.eu.
• EU AI Act, Article 5 (prohibited practices), Article 6 and Annex III (high-risk), Article 50 (transparency), Article 53 and Article 55 (general-purpose AI), Article 2 (scope), and Article 99 (penalties).
• EU AI Act implementation timeline (as updated 31 August 2026).