Which use cases are listed in Annex III as high risk?

What Annex III Is Trying to Capture

Annex III is not a general label for “important AI”; it is the EU AI Act’s list of use case categories that become high risk when the system is used in sensitive decision-making or service contexts. The practical test is whether the deployment can materially affect someone’s rights, opportunities, access, or treatment, which is why teams should classify the use case before build or procurement work advances.

That framing matters because the same model can be low risk in one workflow and high risk in another. A screening, ranking, approval, or eligibility use case may move into scope even when the underlying model is ordinary, so the compliance question is about intended use and consequence, not just technical architecture.

For teams building an inventory, the useful first step is to map each proposed use case to the Annex III category it would fall under if deployed as designed. The EU AI Act Compliance Guide is the most direct internal reference for aligning that screening with broader obligations, including governance, documentation and oversight.

How Organisations Should Screen a Proposed Use Case

Use-case screening should start with the decision being made, the population affected, and the degree of discretion the system has. If the output influences access to employment, education, essential services, public-sector decisions, law enforcement, migration, biometric identification, or similarly consequential outcomes, the use case deserves closer review than a generic productivity deployment.

A useful operational pattern is to separate the business label from the actual control point. “Customer prioritisation,” “risk scoring,” “case triage,” or “identity verification” may each hide a high-risk Annex III use case depending on how the output is used and whether a person can realistically challenge or override it.

That is why an enterprise register should capture not only the model and owner, but also the intended decision, the affected group, the downstream action, and the human role in review or override. The AI Governance Guide is useful here because it treats use-case registers and approval gates as core governance artefacts rather than paperwork after the fact.

When the use case appears close to a boundary, a conservative review is usually better than a narrow one. If the deployment could influence eligibility, access, ranking, or status in a way that is hard to reverse, treat the screening outcome as a governance decision, not a labelling exercise.

What Changes When a Use Case Falls Within Scope

Once a use case lands in Annex III, the compliance burden changes in practical ways. Organisations should expect stronger documentation, clearer accountability, more rigorous risk treatment, and human oversight that is meaningful rather than ceremonial. The point is to make the system explainable enough for internal control and defensible enough for external scrutiny.

In practice, that means the team should be able to describe the purpose of the system, the intended domain of use, the key assumptions, the known limitations, and the controls that reduce the chance of harmful or discriminatory outcomes. ISO/IEC 42001:2023 AI Management System Standard is a useful external anchor for structuring those governance and accountability processes.

Scope also affects lifecycle discipline. A deployment that starts as advisory may drift into operational reliance, and that change alone can make the original classification stale. Teams should therefore reassess the use case when the user population, decision criticality, or level of automation changes.

Risk and Threat Considerations

Annex III matters because the main failure mode is not technical malfunction alone, but harmful use in consequential decision paths. If a system is misclassified as low risk, it may be deployed with insufficient oversight, weak documentation, or inadequate challenge paths, and those gaps can become amplified at scale.

Failure mechanism: A system crosses into a high-risk Annex III category when it influences access, ranking, selection, or treatment in a way that materially affects rights or services, yet the organisation continues to operate it under lighter controls.

Impact: That mismatch can lead to compliance failure, poor auditability, contestability problems, and higher exposure to unfair or unjustified outcomes for affected individuals.

Practitioner Guidance

What to prioritise: Build a short, repeatable screening checklist that identifies the decision, affected population, and downstream consequence before any pilot is approved. The checklist should force a yes or no answer on whether the use case could land in a high-risk Annex III category.

What to verify: Confirm that the human reviewer can actually intervene, not merely rubber-stamp the system’s output. If the person responsible cannot override or justify the decision, the oversight control is weaker than it looks on paper.

Practitioner takeaway: The most important discipline is to classify by real-world impact, not by the model’s elegance or the project’s internal name; Annex III is about consequential use, and consequential use deserves stronger governance from the start.

Related resources from NHI Mgmt Group

• Annex III High-Risk Use Cases
• When should organisations treat an NHI as a high-priority risk?
• How should financial institutions govern explainable AI in high-risk use cases?
• Why do high-risk AI systems create more governance work in identity-related use cases?