Annex III high-risk categories, with real product examples

High-risk under the AI Act is not about how powerful a model is — it is about where the system is used. Annex III lists eight areas. Here is each one in plain terms, with the product features that actually land in it.

Updated July 24, 2026 · Informational guidance, not legal advice

How Annex III classification works

Article 6(2) makes an AI system high-risk when it falls into one of the use-case areas listed in Annex III. The test is intended purpose and deployment context — not model size, not whether it is generative, not how the vendor describes it. A modest logistic-regression scorer used for credit decisions is high-risk; a frontier model answering support tickets usually is not.

That makes classification the first real task of any AI Act program: you cannot know which obligations attach — the provider requirements of Articles 9–15, the deployer duties of Article 26, or neither — until each system has been walked through Annex III and the reasoning written down.

The eight areas, in product terms

  • 1. Biometrics: remote biometric identification, biometric categorisation by sensitive attributes, and emotion recognition. Note the overlap with Article 5 — some biometric practices (like untargeted facial-image scraping) are prohibited outright, not merely high-risk.
  • 2. Critical infrastructure: AI used as a safety component in the management of critical digital infrastructure, road traffic, or the supply of water, gas, heating, and electricity.
  • 3. Education and vocational training: systems deciding admission or assignment, evaluating learning outcomes, or monitoring prohibited behaviour during tests. An exam-proctoring feature is the canonical example.
  • 4. Employment and worker management: recruitment and targeted job advertising, screening or filtering applications, decisions on promotion or termination, task allocation based on behaviour or traits, and monitoring or evaluating workers. A resume screener sits here; so does a shift-scheduling optimizer that allocates work based on individual worker behaviour.
  • 5. Essential private and public services: eligibility for public assistance benefits, creditworthiness and credit scoring (with an exception for financial fraud detection), risk assessment and pricing in life and health insurance, and triage of emergency calls.
  • 6. Law enforcement: risk assessments, evidence-reliability evaluation, profiling in the course of investigations, and similar uses by or on behalf of law enforcement authorities.
  • 7. Migration, asylum, and border control: examination of applications, risk assessments, and verification tools in the migration context.
  • 8. Administration of justice and democratic processes: systems assisting judicial authorities in researching and interpreting facts and law, and systems intended to influence the outcome of elections or referendums.

Where most SaaS features actually land

A customer-support chatbot, a summarizer, or a copilot is usually in none of these areas — which means no high-risk obligations, but not no obligations: Article 50 transparency duties and the Article 4 literacy duty still apply. The most common genuine Annex III exposure for software companies is area 4 (anything touching hiring or worker management) and area 5(b) (anything touching credit).

The Article 6(3) derogation — and its trap

Article 6(3) says a system in an Annex III area is nevertheless not high-risk when it does not pose a significant risk of harm — specifically where it only performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns or deviations without replacing or influencing the prior human assessment without proper review, or performs a purely preparatory task.

Two things make this a trap rather than an exit. First, a system that performs profiling of natural persons is always high-risk — the derogation cannot rescue it. Second, the derogation is not self-executing: the provider must document its 6(3) assessment before the system is placed on the market and register the system. An undocumented "we decided it's just preparatory" is not a classification; it is a gap.

Write the reasoning down either way

Whether a system lands in Annex III, escapes via 6(3), or was never in an Annex III area at all, the defensible position is the same: a register entry with the classification and the reasoning, dated and owned. The classifications an authority or enterprise customer will challenge are the ones that exist only in someone's head.

What to do with a high-risk classification

  • Establish your role for the system — provider and deployer carry different obligation sets, and many teams hold both roles across their portfolio.
  • Map the obligations: Articles 9–15 and conformity assessment for providers; Article 26 oversight, monitoring, log retention, and worker notification for deployers; Article 27 FRIA for the deployer categories it captures.
  • Assign owners and start collecting evidence now. The Digital Omnibus deferred the Annex III regime to December 2, 2027, which is runway rather than reprieve — conformity assessment and evidence history are not things you can assemble retroactively.
  • Re-classify when things change: a new intended purpose, a new user population, or a vendor's feature expansion can move a system into (or out of) Annex III.

Classify a system against Annex III in minutes

The free Attevera classifier walks Articles 5 and 6 and every Annex III area for one system, and gives you the reasoning to keep — no signup.

Run the free classifier

Frequently asked questions

Is a general-purpose model like a large LLM automatically high-risk?

No. Annex III classification follows the use case, not the model. A general-purpose model becomes relevant to Annex III when a system built on it is intended for one of the listed areas. GPAI model providers carry separate obligations under Articles 51–56, which are a different regime.

Our hiring tool only recommends candidates — a human always decides. Is it still high-risk?

Very likely yes. Screening and filtering applications is expressly listed in area 4, and human review does not remove the classification — it is one of the obligations (human oversight) that attaches because of it. The Article 6(3) derogation is narrow and cannot apply to profiling of natural persons.

Who decides whether the Article 6(3) derogation applies?

The provider assesses and documents it before placing the system on the market, and registers the system. Deployers relying on a vendor's non-high-risk position should ask to see that documented assessment rather than assume it exists. This guide is informational, not legal advice — edge cases belong with counsel.

What if none of our systems are in Annex III?

Then the high-risk regime does not attach — but document that conclusion per system in your register, and check the obligations that apply regardless: Article 50 transparency for AI that interacts with people or generates content, and the Article 4 AI literacy duty for your staff.

Keep reading