The core idea: regulate the use, not the algorithm

The European Union's AI Act is the most comprehensive attempt yet to put guardrails around artificial intelligence, and its central design choice is worth understanding before any of the detail. The law does not try to regulate 'AI' as a monolithic thing. Instead it sorts uses of AI into tiers of risk and attaches heavier obligations as the stakes rise. A spam filter and a system that screens job applicants both run on machine learning, but the law treats them very differently because the consequences of getting them wrong are very different.

That framing matters. It means the same underlying model can sit in a lightly-regulated product in one context and a heavily-regulated one in another. Compliance is a question about deployment, not just about the code.

The four bands

Broadly, the Act recognises four levels of risk.

Unacceptable risk — banned. A narrow set of practices are prohibited because they're judged incompatible with fundamental rights. These include things like social-scoring systems run by public authorities, certain forms of manipulative behavioural targeting that exploit vulnerabilities, and some uses of biometric categorisation. The list is deliberately short; the point is to draw bright lines around the worst cases.

High risk — heavily regulated. This is where most of the law's weight sits. Systems used in areas like employment, education, essential public services, critical infrastructure, law enforcement and medical devices fall here. They aren't banned, but providers must meet a substantial set of obligations before and after going to market.

Limited risk — transparency duties. Systems that interact with people or generate content carry lighter, mostly disclosure-based obligations. The guiding principle is that people should know when they're dealing with a machine or looking at synthetic media.

Minimal risk — largely unregulated. The vast majority of AI applications — recommendation tweaks, game AI, productivity features — fall into this catch-all and face few specific obligations.

What 'high risk' actually requires

If your use case lands in the high-risk band, the obligations are real operational commitments, not box-ticking. Expect to need:

• A risk-management system that runs across the lifecycle, not a one-off sign-off.
• Data governance covering the quality and representativeness of training and testing data.
• Technical documentation detailed enough that a regulator could understand how the system works.
• Logging so that operation can be traced and audited after the fact.
• Human oversight designed in, so a person can intervene or override.
• Accuracy, robustness and cybersecurity appropriate to the purpose.

The through-line is accountability: someone must be able to show their working.

General-purpose models get a separate layer

Large general-purpose models — the foundation models that power many downstream products — receive their own set of obligations layered on top of the tier system. These centre on transparency: documenting capabilities and limitations, providing information to downstream developers who build on the model, and respecting copyright in training. The most capable models, those judged to carry systemic risk, face additional expectations around evaluation and incident reporting.

This two-track approach reflects a practical reality: the company that builds a base model and the company that deploys it in a hiring tool are often different, and the law tries to put obligations where the relevant knowledge and control actually sit.

Why this is a template, not just a European story

Even organisations with no European footprint should pay attention, for two reasons. First, like data-protection law before it, the Act has extraterritorial reach: it can apply to providers outside the EU whose systems are used inside it. Second, and more strategically, it's becoming a reference architecture. Other jurisdictions are watching how the risk-tier model works in practice, and global companies often find it simpler to build to the strictest standard once.

How to orient yourself

If you're trying to work out where you stand, start with three questions. What does the system actually decide or influence? That tells you the likely tier. Are we the provider or the deployer? That tells you which obligations land on you. Can we show our working? That tells you how much documentation and oversight you'll need to build. Get those three straight and the rest of the law becomes far easier to read.