Risk classification and scoping: the large inventory

Episode 2: risk classification and scoping, the large inventory

Risk classification under the EU AI Act means assigning each AI system to one of four levels: minimal, limited, high, or unacceptable. Which use cases are high-risk is set out in Annex III of the AI Act; how classification works is governed by Article 6: a system with an Annex III purpose is high-risk unless one of the narrow exceptions of Article 6(3) applies, and that never applies to profiling. Scoping starts with language: first define what counts as an AI system in your organization, then inventory all algorithms (including embedded modules in SaaS) and classify them, before you start a FRIA for the high-risk systems.

During an internal audit at the municipality of Middelveld, policy advisor Noor van der Wijst stares at an Excel sheet with more than a hundred columns. Each field represents an algorithm that has quietly crept in over the past few years: from automatic parking enforcement to a model that predicts which students need extra care hours. Noor needs to answer one simple question: which of these systems are "high risk" according to the EU AI Act?

From four risk levels to one core question

The AI Act divides all applications into a pyramid of four layers. At the bottom are minimal and limited-risk systems; these require at most transparency notifications. At the very top are the "unacceptable" use cases, such as real-time facial recognition on the street: these are simply prohibited. But in the middle (the broad, gray strip of high-risk AI) is where the real game is played. Here, strict design, documentation, and supervision requirements apply. For Noor, the key question is therefore not whether a model is useful, but whether it falls within the high-risk scope of Article 6 and Annex III. ([1], [2])

Article 6: the legal filter

Article 6 works in two steps. (1) Does the intended purpose fall under a point of Annex III, think of benefit decisions, law enforcement or critical infrastructure? Then the system is in principle high-risk. (2) Only if the system performs one of the four narrow tasks of Article 6(3) and does not profile people can it fall outside; you record that assessment. ([2]) In practice, a municipality first compares its use cases against the Annex, and then tests the exception per system: who could be harmed if the model fails?

Noor discovers that the parking enforcement module doesn't go beyond an automatic recommendation; a parking officer ultimately decides for themselves. Limited risk, check. The model that selects students for extra care hours? That affects access to public services (Annex III §5) and can lead to stigmatization. High risk.

Scoping without language confusion

Inventorying seems simple (copy-paste all algorithms into a spreadsheet) but reality is erratic. IT calls something a "tool", HR talks about a "dashboard", and the supplier sells an "AI module". Scoping therefore starts with language: define what constitutes an AI system in your organization. The Dutch government uses a broad description in its Algorithm Register ("any automated decision or data analysis that affects citizens"). ([3]) Adopt that definition and you'll avoid endless semantic discussions.

Practical lesson: the "heatmap round"

Noor then organizes a so-called heatmap round: in two workshops, she places each algorithm on a large screen with two axes: impact on fundamental rights versus chance of errors. Lawyers, data specialists, and policy people shift post-its back and forth. Within a morning, a visual risk landscape emerges: red dots (potentially high-risk) cluster around social benefits, permit issuance, and fraud monitoring.

Pitfall 1: false security from suppliers

Suppliers like to put the "AI inside" label on every software package. Some claim their model falls outside the scope because "a human always confirms with a click". Such a checkbox approach doesn't hold up. The EU AI Act clearly states that human intervention only counts if the supervisor is actually able to correct and has time to intervene. A 'yes button' without context or a stop button doesn't qualify. ([4])

Pitfall 2: forgotten shadow algorithms

Not all risk models are in-house developments; many are hidden in external SaaS tools. Think of a cloud package that automatically sends payment reminders based on a credit score. Therefore, explicitly ask about AI functionalities in every procurement scan, even if the product is primarily HR software or CRM.

When is the classification complete?

Only when each system has a label (unacceptable, high, limited, or minimal) can you freeze the list and start a Fundamental Rights Impact Assessment (FRIA) for the high-risk category. That's exactly what Episode 3 is about. The AI Act requires deployers that are bodies governed by public law to carry out a FRIA before use, covering the risks, human oversight and measures, and to notify the result to the market surveillance authority (Article 27(1) and (3)). For a system already in use before 2 December 2027, Article 111(2) applies: by 2 August 2030 at the latest, or earlier after a significant change. ([5])

Finally: three questions for your organization

1. Do you even know which algorithms are live, including embedded modules?
2. Can you substantiate for each system why it does or does not fall under Annex III?
3. Is the high-risk shortlist already online in the Algorithm Register or an internal variant?

As long as the answer to one of these questions is no, your organization is in Noor's risk phase: the fact sheet is larger than the confidence. In the next episode, we'll therefore dive into the FRIA methodology: how to put risks on paper without drowning in legal jargon?

Stay tuned, because compliance begins with knowing what you have.

Want to know how your organization scores in terms of risk classification and scoping of AI systems? We offer a quick inventory scan that shows where you stand and what you still need to do. Feel free to contact us for more information.