EU AI Act Risk Categories: The 4 Levels Explained

The EU AI Act does not treat every AI system the same way. It uses a risk-based design, so the obligations on a spam filter look nothing like the obligations on a CV-screening tool or a credit-scoring model.

That single decision, which risk category your system falls into, drives almost everything else: the controls you owe, the documentation you keep, and the size of the fine if you get it wrong.

The EU AI Act sorts every AI system into four risk categories: unacceptable risk (banned outright), high risk (heavily regulated), limited risk (transparency duties), and minimal risk (no extra rules). The category decides which obligations apply. Most everyday business tools land in limited or minimal risk, but the level has to be checked for each deployment.

The four levels are often drawn as a pyramid, with the smallest group of banned systems at the top and the large majority of harmless systems at the base. The table below summarizes what each tier means.

Risk level	What it means	Examples	Core obligation
Unacceptable	Banned under Article 5	Social scoring, untargeted facial scraping, workplace emotion recognition	Cannot be placed on the market
High	Heavily regulated (Annex III and Annex I)	CV screening, credit scoring, medical triage, biometric ID	Risk management, data governance, human oversight, FRIA
Limited	Transparency duties (Article 50)	Chatbots, deepfakes, emotion recognition	Disclose AI interaction and synthetic content
Minimal	No extra obligations	Spam filters, AI in games, inventory forecasting	Article 4 literacy only

Unacceptable-risk systems are banned outright. Article 5 lists eight categories of AI practice that cannot be placed on the EU market or put into service at all, because the risk to fundamental rights is judged too high to manage with controls.

The banned categories include subliminal or manipulative techniques that distort behavior, exploitation of vulnerabilities tied to age or disability, social scoring by public authorities, and untargeted scraping of facial images to build recognition databases. They also cover emotion recognition in workplaces and schools, biometric categorization by sensitive attributes, and most real-time remote biometric identification in public spaces by law enforcement.

This tier carries the highest penalty in the regulation, up to €35 million or 7% of global annual turnover. Recognizing a prohibited use before a product ships is a procurement and product-team skill, which is exactly what the prohibited AI practices exercise trains.

High-risk systems are allowed, but only under the strictest controls in the Act. A system is high-risk if it appears in Annex III or if it is a safety component of a product already regulated under EU law in Annex I.

Annex III lists eight domains: biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration and border control, and the administration of justice. A resume-screening tool, a credit-scoring model, and a medical triage system are textbook high-risk examples because they make or support decisions that affect people’s livelihoods, safety, or rights.

Most organizations are deployers of several high-risk systems without realizing it. The high-risk AI deployer obligations exercise walks through the seven compliance areas that decide whether a high-risk launch is ready or should be blocked.

High-risk systems carry the deepest obligation set in the regulation. Providers must build risk management, data governance, logging, transparency, and post-market monitoring into the system, and deployers must operate it under defined controls.

Human oversight is central. Article 14 requires high-risk systems to be designed so a person can understand, monitor, and override them, and the meaningful human oversight exercise rehearses overriding an AI recommendation when the evidence does not match. Data governance matters just as much, because a biased or leaky training set produces a non-compliant system, a risk the AI data governance exercise makes concrete.

Two further duties apply to specific deployers. Public bodies and certain high-risk operators must run a Fundamental Rights Impact Assessment before first use, covered in the FRIA exercise. And because discrimination is a frequent failure mode, the AI bias and discrimination exercise shows how proxy variables hide inside a resume-screening model.

Limited-risk systems are subject to transparency duties rather than the full high-risk regime. The concern here is that people should know when they are dealing with AI or AI-generated content.

Article 50 covers this tier. Systems that interact with people, such as chatbots, must disclose that a person is talking to a machine unless it is obvious. Providers of systems that generate synthetic audio, image, or video must mark the output as artificial, and deployers who create deepfakes must disclose that the content is generated or manipulated.

Getting these disclosures right is mostly an operational task rather than a legal one. The AI transparency and disclosure exercise trains teams to label chatbots and synthetic media correctly under Article 50.

Minimal-risk systems make up the large majority of AI in use today, and they carry no obligations beyond the baseline. Spam filters, AI in video games, inventory forecasting, and recommendation features generally sit here.

The only duty that still applies is the Article 4 AI literacy requirement, which reaches every provider and deployer regardless of tier. Staff who use even minimal-risk tools should understand what the system can and cannot do.

The catch is that classification is not permanent. A minimal-risk tool repurposed for a high-stakes decision can move up a tier, which is why the level has to be reviewed whenever a system’s use changes.

Classification starts with the intended purpose of the system, not its underlying technology. The same model can be minimal-risk in one deployment and high-risk in another, so the question is always what the system is used to decide.

Work top down through the tiers, and the first match decides the classification:

1. Is the use banned under Article 5? If yes, it is unacceptable-risk and cannot proceed.
2. Does it appear in Annex III, or sit inside an Annex I regulated product? If yes, it is high-risk.
3. Does it trigger Article 50 transparency duties, such as a chatbot or deepfake? If yes, it is limited-risk.
4. Anything left over is minimal-risk.

The AI risk classification exercise puts real deployments through exactly this sorting process, which is the single most useful skill for anyone building an AI inventory. For the deadlines that attach to each tier, see our EU AI Act timeline guide.

Both have a role, and confusing the two is a common compliance gap. A provider develops the AI system or has it developed and places it on the market, while a deployer uses the system under its own authority in a professional setting.

A compliant product from a provider does not make your deployment compliant. The provider classifies and documents the system it sells, but the deployer is responsible for how it is actually used, including human oversight, monitoring, and any fundamental-rights assessment. The provider versus deployer exercise makes this split concrete with a realistic scenario.

Most enterprises are deployers of many systems and providers of a few. Mapping which role you play for each system is part of building a defensible AI inventory, a task we cover in the EU AI Act timeline guide.

The AI Act and GDPR apply at the same time, and a high-risk AI system that processes personal data has to satisfy both. The risk category under the AI Act does not replace your data protection obligations; it sits on top of them.

A high-risk system that profiles people will often trigger a GDPR Data Protection Impact Assessment alongside the AI Act’s Fundamental Rights Impact Assessment. Lawful basis, data minimization, and data subject rights all still apply. The AI and data protection exercise runs a healthcare AI through both regimes at once so teams see where the duties overlap and where they differ.

This overlap is why a single, mapped training program is more efficient than separate tracks. A solid GDPR employee training program already covers data handling that high-risk AI depends on, and uncontrolled tools surfaced by shadow AI often breach both regimes at once.

RansomLeak turns the risk-based framework into role-based scenarios rather than slide decks. The dedicated EU AI Act course covers all four tiers, the classification process, and the obligations that attach to each level, and every module exports as SCORM for the LMS an auditor will inspect.

The privacy and compliance catalogue carries the full EU AI Act course next to GDPR scenarios, and the AI security catalogue covers the prompt injection, deepfake, and LLM risks that overlap with the OWASP LLM Top 10. For the regulation end to end, our EU AI Act training guide maps each obligation to a specific exercise.

If you want to see how scenario-based training maps to the four risk tiers, book a walkthrough with our team.

The EU AI Act defines four risk levels: unacceptable risk (prohibited systems banned under Article 5), high risk (heavily regulated systems in Annex III and Annex I), limited risk (systems with Article 50 transparency duties such as chatbots and deepfakes), and minimal risk (everything else, with no obligations beyond Article 4 AI literacy). The level decides which obligations apply.

Common high-risk examples include AI used to screen job applicants, score creditworthiness, support medical triage, or run biometric identification. These appear in Annex III because they make or support decisions that affect people’s livelihoods, safety, or fundamental rights. AI used as a safety component in a regulated product such as a medical device is also high-risk.

Article 5 bans eight categories, including manipulative or exploitative systems, social scoring by public authorities, untargeted scraping of facial images, emotion recognition in workplaces and schools, biometric categorization by sensitive attributes, and most real-time remote biometric identification in public spaces by law enforcement. These cannot be placed on the EU market and carry the highest penalty tier.

The provider classifies and documents the system it places on the market, but the deployer remains responsible for how the system is used. A compliant product does not guarantee a compliant deployment. Both should classify by intended purpose, working top down from prohibited to high-risk to limited-risk to minimal-risk.

Yes. Classification depends on the intended purpose, so a system can move tiers when its use changes. A minimal-risk tool repurposed for a high-stakes decision can become high-risk, which is why the classification should be reviewed whenever a system’s deployment changes.

Treating a high-risk system as limited or minimal risk means skipping the controls the Act requires, which is non-compliance. Penalties for breaching most obligations reach up to €15 million or 3% of global annual turnover, and breaching the Article 5 ban reaches €35 million or 7%. Accurate classification is the control that prevents both.

The EU AI Act is built around four risk levels, and the level you assign to a system decides everything that follows. Unacceptable-risk systems are banned, high-risk systems carry the heaviest controls, limited-risk systems owe transparency, and minimal-risk systems owe only AI literacy.

Classification is a skill, not a one-time form. Sort by intended purpose, work top down, map your provider and deployer roles, and review the level whenever a system’s use changes.

If your organization operates AI in Europe and wants scenario-based training on each risk tier, explore the privacy and compliance catalogue or talk to our team.

• Regulation (EU) 2024/1689 (AI Act) - Official Journal
• European Commission: AI Act regulatory framework
• European Parliament: EU AI Act and risk levels
• EU AI Office