The risk-based approach and why it won

Regulate the use case, not the technology

Early attempts to regulate AI tried to describe the technology itself: what counts as artificial intelligence, which architectures are dangerous, what compute threshold requires authorisation. Every such attempt broke on the same rock. Technology changes faster than rules are adopted, so by the time the rule took effect the system it described was already obsolete.

What the risk-based approach does instead

It moves the question from what kind of model this is to what happens to a person if the system gets it wrong. The same model can be harmless in one setting and tightly constrained in another. An image classifier inside a photo editor and the same classifier controlling access to a building are legally different things.

Unacceptable risk. Use cases prohibited as such, regardless of how good the system is or whether anyone consented.
High risk. Material effect on rights, access to goods and services, or safety. Permitted, but with the full package: documentation, data quality, human oversight, logging, impact assessment.
Limited risk. The core duty is transparency: the person must understand they are dealing with a system or looking at generated material.
Minimal risk. General law plus voluntary practice.

Category names and boundaries differ between jurisdictions and get revised. What stays stable is the underlying logic: the heavier the consequences for a person, the denser the duties.

Insight. A risk category is not a property of the system. It is a property of the system plus the use case plus the people affected. Change the use case and you must reclassify, even if the model is untouched.

Classifying your own use case

Five questions for a first-pass classification
1. Who is affected by what the system produces
2. What the person loses if it is wrong (money, access, reputation, health)
3. Whether the person can learn about the decision and challenge it
4. Whether a non-AI alternative exists
5. Whether the use case appears in your jurisdiction's lists, checked at source

Common mistake. Classifying by how impressive the model looks. A plain scoring formula that denies people a service is regulated far more heavily than an elegant chatbot that writes marketing copy.

Pro tip. Write the classification down and date it, even when the answer is minimal risk. A reasoned we looked at this and concluded X protects you far better than no trace of thinking at all.

Cheat sheet

The use case is regulated, not the model architecture.
The risk level sets the volume of duties.
A change of use case demands a fresh classification.
Check category boundaries against a current primary source.

1. Why did regulation move away from describing the technology itself?

2. What does a risk level attach to?

3. What is typically required for limited-risk use cases?

Task — checked by AI

Take one real AI use case from your own work. Describe it in one sentence, answer the five first-pass classification questions, and propose a risk level. Separately, name the source in your jurisdiction that you will check to confirm or overturn that assessment.

← Back

🔒 Answer the question correctly to move on to the next lesson.