Regulated by
risk, not tech.

The single most important thing to understand about the EU AI Act is that it is risk-based. It does not regulate "neural networks" or "large language models" as such; it regulates uses according to how much harm they could do to people's rights, safety, and livelihoods. The very same technology can be unregulated in one product and tightly controlled in another, purely because of what it's used for.

A sentiment classifier sorting support tickets is minimal-risk and carries no obligations; the same class of model deciding who gets a loan or a job interview is high-risk and triggers a serious compliance program. This is why the Act's first question is always about the application, not the architecture. Every AI system is sorted into one of four risk tiers — unacceptable, high, limited, or minimal — and that tier determines everything: whether you're banned, heavily regulated, lightly obligated, or free. Because the sorting is defined by concrete criteria about use, it behaves like a classification rule you can reason about deterministically, which is exactly how we'll model it. Getting the tier right is the whole ballgame.

The whole regime is a four-level pyramid, from banned at the top to unregulated at the base:

The tiers are checked most-severe-first: is it a prohibited practice? If not, is it in a high-risk domain? If not, does it interact with people or generate content (limited)? Otherwise it's minimal. The reassuring reality for most builders is that the base of the pyramid is enormous — the great majority of AI systems are minimal-risk with no mandatory obligations at all. The Act concentrates its weight on the narrow top: an outright ban on a short list of uses society has decided are unacceptable, and a heavy compliance burden on the specific high-stakes domains where AI decisions can seriously harm people. Everything in between gets a light transparency duty. So "does the AI Act apply to me?" almost always resolves to "which of these four buckets is my use case in?" — and for most, the answer is the bottom one.

The tier that matters most in practice is high-risk, because it's where real engineering obligations kick in and where it's easy to land without realizing. A system is high-risk when it's used in a domain the Act designates as consequential for people's fundamental rights or safety — the concrete list includes employment and hiring, access to credit and essential services, medical devices and healthcare, education, law enforcement, migration and border control, administration of justice, critical infrastructure, and certain biometric systems. If your AI makes or materially influences decisions in one of these areas, assume high-risk until proven otherwise.

High-risk status is not a label — it's a program. It obliges you to run a risk management system across the lifecycle, ensure data governance (representative, high-quality training data with bias controls), guarantee meaningful human oversight (a person who can understand, override, and stop the system), meet standards of accuracy and robustness, keep technical documentation and logs, pass a conformity assessment before going to market, and register in an EU database. That's a substantial build, and — this is the practical crux — it's dramatically cheaper to design in from the start than to retrofit onto a shipped system. The moment you suspect you might be high-risk is the moment to bring in legal and start building the oversight, logging, and documentation, not after launch.

Because the tiers are defined by concrete use-case criteria, classification is a deterministic rule — check the most severe conditions first and fall through to minimal:

Order matters: a prohibited use is banned even if it's also "high-risk"; a hiring tool is high-risk even if it also chats. Most systems fall through to minimal.

The tier then maps to a fixed set of obligations, from "prohibited" down to the empty set for minimal-risk:

Only high-risk requires a conformity assessment; limited-risk requires only transparency; minimal-risk requires nothing. The runnable version below classifies systems and returns each tier's obligations.

You don't need to be a lawyer to be responsible about the Act; you need a short, practical discipline:

The last row is the mindset that turns compliance from a chore into an asset. Almost everything the Act demands of high-risk systems — knowing your data, keeping a human able to intervene, logging decisions, documenting how the thing works and testing that it's accurate — is what a careful engineering team should do anyway, because it's how you avoid shipping a biased, opaque, or unaccountable system that blows up in production or in the press. The Act is a floor of responsible practice with legal teeth in the EU; meeting it well tends to make your system better and safer everywhere. And there's a hard commercial reality behind it: penalties for prohibited-use and serious violations run into the tens of millions of euros or a percentage of global turnover, and the EU market is large enough that most serious products can't simply ignore it. So the pragmatic play is to classify early, build compliance into high-risk systems from day one, and treat the whole exercise as the responsible-AI hygiene it largely is.

The first and most dangerous mistake is optimistic self-classification — deciding you're minimal-risk because high-risk sounds like a hassle, when your system actually influences hiring, credit, or health decisions. The tier is determined by the use, not by your preference, and getting it wrong on the downside means shipping a non-compliant high-risk system with real legal exposure. When a use plausibly touches a high-risk domain, get a proper legal read; don't reason your way to the convenient answer.

Two more. Retrofitting compliance: bolting human oversight, data governance, and documentation onto a system built without them is painful and sometimes requires re-architecting — the cost of the high-risk program is much lower if it's designed in, so the decision "are we high-risk?" needs to happen early, not at launch. And forgetting the general-purpose-model layer: if you provide (not just use) a foundation model, you have your own transparency obligations independent of any downstream application's tier, and the most capable models carry additional systemic-risk duties. The meta-lesson is that AI regulation is less mysterious than it looks once you see its shape: it's a risk classifier over use cases, and your job as an engineer is to classify honestly, build the required controls in early for the high-risk cases, and treat the transparency and oversight requirements as the good-practice floor they mostly are. Do that and "the AI Act" stops being a fog and becomes a checklist — which is exactly how a well-designed regulation should feel to the people who have to build under it.