Annex III is the part of the EU AI Act that actually determines how much work you're in for. It lists the categories of AI systems presumed to be "high-risk," which triggers the Act's heaviest requirements: risk management, data governance, logging, human oversight, and conformity assessment. Most engineering teams have never read it. Here's what's in it, in plain language.
The categories, without the legal phrasing
Annex III groups high-risk systems into a set of use-case areas. You don't need to memorize the article numbers, you need to recognize whether your product sits in one of these buckets:
Biometric identification and categorization. Facial recognition, biometric verification, systems that infer characteristics like emotion or demographic category from biometric data.
Critical infrastructure. AI used to manage safety components of things like power grids, water supply, or traffic control.
Education and vocational training. Systems that decide access to education, evaluate students, or detect exam misconduct.
Employment and worker management. Resume screening, candidate ranking, performance monitoring, or systems that decide promotions or terminations.
Access to essential services. Credit scoring, insurance risk assessment (for life and health), eligibility for public benefits, and emergency dispatch prioritization.
Law enforcement. Risk assessment tools, evidence reliability evaluation, and profiling used in criminal investigations.
Migration, asylum, and border control. Systems used to assess visa applications, asylum claims, or security risk at borders.
Administration of justice and democratic processes. Tools that assist judicial decision-making, or systems used to influence elections and voter behavior.
If your product doesn't touch any of these areas, you're probably looking at limited-risk or minimal-risk obligations instead, mostly transparency requirements. If it does, keep reading.
A practical self-check, not a legal opinion
Here's a framework for a first-pass gut check, something you can run in five minutes without a lawyer in the room:
Does the system make or materially influence a decision about a specific person? Hiring, lending, admissions, benefits, and law enforcement outcomes are the pattern to watch for. A system that ranks or filters candidates counts, even if a human technically clicks "approve" at the end.
Is the decision consequential and hard to reverse? Denying someone a loan or flagging them for fraud review has real consequences. A system that suggests which blog post to show next generally doesn't.
Does the use case match one of the eight Annex III categories above, even loosely? Err toward "yes" if you're unsure. It's cheaper to review a borderline case than to miss one.
Would a regulator, or a journalist, describe what this system does using words like "screening," "scoring," "assessing eligibility," or "identifying"? That phrasing is a strong signal.
If you answer yes to the first two and the system fits a category, treat it as high-risk until someone with legal authority says otherwise.
This is a starting point, not a determination
None of the above is legal advice, and this checklist won't catch every edge case in a 100+ page regulation with ongoing guidance from the European Commission. What it will do is stop you from being blindsided. Any system that looks like it might fall under Annex III should go through an actual legal review before you ship it, not after a regulator asks about it. The goal here is to make sure engineering flags the right systems early, not to replace counsel.
Where automation fits
The hard part isn't knowing the eight categories, it's remembering to ask the question every time a new AI feature ships, and every time an existing one changes scope. That's exactly the gap OpenComplAI's classification checks are built to close: they run against your codebase in CI, flag systems that look like they match an Annex III category, and keep a running registry instead of relying on someone's memory of a decision made two sprints ago. For the wider engineering rundown of what the Act requires once a system is classified as high-risk, see our guide to EU AI Act readiness. And if you're already generating documentation for these systems, pairing that with automated model cards gives you both halves of the evidence an auditor will ask for: what the system is, and why you classified it the way you did.