EU AI Act risk tiers, explained for engineers

The EU AI Act's risk classification is a hierarchy, not a spectrum. Systems are not graded on a continuous scale — they are placed into one of four defined categories, each with a distinct set of obligations. The tiers are:

• Unacceptable risk — prohibited systems that cannot be placed on the market or put into service in the EU.
• High risk — systems subject to pre-market conformity obligations under Chapter III of the Act.
• Limited risk — systems with specific transparency obligations but no pre-market gate.
• Minimal risk — systems with no specific obligations under the Act.

A system can only fall into one primary tier, though a high-risk system may also trigger limited-risk transparency obligations if it interacts with users in ways that require disclosure.

Article 5 lists the AI practices that are flatly prohibited in the EU. These are not subject to risk management or mitigation — they cannot be deployed at all. The prohibited categories are:

• Social scoring by public authorities — AI systems that evaluate or classify natural persons based on social behaviour or personal characteristics, producing social scores used to treat them detrimentally.
• Subliminal manipulation— systems that deploy techniques operating below the threshold of a person's consciousness to materially distort behaviour in ways that cause harm.
• Exploitation of vulnerabilities — systems that exploit vulnerabilities of specific groups (age, disability) to distort behaviour harmfully.
• Biometric categorisation inferring sensitive attributes — systems that infer political opinions, religious beliefs, sexual orientation, or race from biometric data.
• Real-time remote biometric identification in public spaces — with narrow law-enforcement exceptions subject to judicial or administrative authorisation.
• Emotion recognition in workplaces and educational institutions — with medical and safety exceptions.
• Untargeted scraping of facial images — building or expanding facial recognition databases by scraping from the internet or CCTV footage.
• Predictive policing of individuals — profiling individuals based solely on characteristics for the purpose of assessing criminal risk.

The high-risk category is defined by two routes: systems listed in Annex III of the Act, and systems that are safety components of products covered by Union harmonisation legislation listed in Annex I.

Annex III currently lists eight categories of high-risk AI systems:

1. Biometric identification and categorisation of natural persons
2. Critical infrastructure — AI used in managing or operating critical digital, transport, water, gas, heating, and electricity infrastructure
3. Education and vocational training — systems that determine access to, or assess outcomes in, educational institutions
4. Employment and workers management — recruitment, performance evaluation, promotion, task allocation, monitoring
5. Essential private and public services — credit scoring, insurance risk assessment, social benefit eligibility
6. Law enforcement — tools used to assess individual risk in criminal proceedings, detect or investigate offences
7. Migration, asylum, and border control — risk assessment, document authentication, examination of applications
8. Administration of justice and democratic processes — assisting courts, influencing electoral outcomes

Annex III is a defined list, not a subjective risk score. If your system falls within one of these eight categories and materially influences individual outcomes, it is high-risk — the question is not whether the risk is actually high.

The Annex I route is relevant for manufacturers of physical products. If an AI system is a safety component of a product that already requires third-party conformity assessment (medical devices, machinery, vehicles, aviation), the AI system is automatically high-risk.

High-risk systems face the most extensive set of obligations: documented risk management under Article 9, technical documentation under Annex IV, data governance under Article 10, transparency requirements under Article 13, human oversight measures under Article 14, and accuracy and robustness requirements under Article 15. These obligations apply before market placement, not after deployment.

Limited-risk systems are not subject to the pre-market obligations that apply to high-risk systems, but they do carry specific transparency requirements under Article 50 of the Act. Three categories are covered:

• AI systems interacting with humans — chatbots, virtual assistants, and any other conversational AI must inform users that they are interacting with an AI system, unless the context makes this obvious.
• Emotion recognition systems — must inform the people they are operating on that they are subject to emotion recognition, where the system is not prohibited.
• AI-generated synthetic content — deepfakes, synthetic voice, and AI-generated imagery in public communications must be labelled as AI-generated (with narrow exceptions for artistic and similar purposes with appropriate disclosure).

These transparency obligations are layered on top of any tier classification. A customer service chatbot that is also used to make credit decisions would be high-risk under Annex III and limited-risk under Article 50 — both sets of obligations apply simultaneously.

Most AI systems deployed today fall into the minimal-risk tier. This includes spam filters, AI-assisted video game characters, most recommendation engines (outside high-risk contexts), and the majority of internal enterprise productivity tools.

Minimal-risk classification does not mean risk-free. It means the EU AI Act does not impose specific obligations. Other frameworks — GDPR, sector-specific regulation, and internal governance requirements — may still apply. The Act encourages voluntary codes of conduct for minimal-risk systems, and the European AI Office is developing guidance on what good voluntary practice looks like.

Classification is not a one-time judgment. It requires examining what the system actually does in the deployment context — not what it is marketed as, and not what the vendor says it is. The same underlying model can be minimal-risk in one context and high-risk in another.

A general-purpose language model used to draft internal communications is minimal-risk. The same model used to screen job applications is high-risk under Annex III category 4 (employment and workers management). The technology is identical; the deployment context changes the classification.

The classification exercise for each assessed system should produce a documented rationale: which Annex III categories were considered, why the system does or does not fall within them, and who made that determination. This rationale becomes part of the technical documentation for high-risk systems and the evidence base for non-high-risk systems if the classification is later challenged.

When a system's classification changes — because its purpose expands, because it is integrated into a new context, or because Annex III is updated — the obligations change with it. The practical implications differ by direction:

Minimal to limited risk: The main addition is the transparency obligation. Users must be informed they are interacting with AI. This typically requires a UI change, updated terms of service, and a review of any communications that present AI output without disclosure.

Limited to high risk: The shift is substantial. Pre-market obligations must be satisfied before the system can be used in the new high-risk context. This means completing the Article 9 risk management process, preparing Annex IV technical documentation, reviewing training and validation data against Article 10 requirements, and establishing human oversight mechanisms. For a system already in production, this documentation must be prepared retrospectively before the high-risk use begins.

Deployer becomes provider:If a deployer makes a substantial modification to a high-risk system — changing the training data, retraining on proprietary data, integrating the system into a new pipeline that changes its intended purpose — they become a provider for that modification and take on full provider obligations. The threshold for “substantial modification” is not defined precisely in the Act; the assessment must be made case by case.

Tier is not a static property. It is tied to the system's intended purpose in a specific deployment context. Any material change to that context — new use case, new user population, new integration — requires re-classification.

The practical implication for governance teams is that classification must be part of the change management process for AI systems, not a one-time procurement exercise. Each assessed system in the inventory should carry its current classification with a record of when it was last reviewed and what triggered the review.