EU AI Act Risk Categories: How to Classify an AI System

by David Porter

Wednesday, 12 August 2026 at 13:53

thumbnail_eu-ai-act-risk-categories-how-

The EU AI Act is commonly summarized using four risk categories: unacceptable risk, high risk, transparency risk and minimal or no risk. That model is useful for explaining the law, but it can create a false impression that every AI product belongs in one mutually exclusive box.

Actual classification is multidimensional. A customer-service chatbot may be low-risk in its use case but subject to Article 50 because people interact with it directly. The chatbot may use a general-purpose AI model whose provider has separate Chapter V duties. An employment system may be high-risk and also process personal data under GDPR. A generative model can be legal in most uses while a specific deployment is prohibited.

The correct approach is a sequence of legal tests. Start with scope and the AI-system definition, screen prohibited practices, evaluate both high-risk routes, assess transparency, examine GPAI status and assign operator roles. Our complete EU AI Act guide explains the overall law; this page owns the classification method.

The four categories at a glance

Common label	Legal consequence	Typical examples	Important qualification
Unacceptable risk	Practice is prohibited	Harmful manipulation, social scoring, certain biometric and sexual-content uses	Each prohibition has elements, conditions and exceptions
High risk	System is allowed only with extensive requirements	Recruitment ranking, exam scoring, specified essential-service decisions, safety components	Must satisfy Article 6 and Annex I or Annex III; not every system in a broad sector qualifies
Transparency risk	Specific notice, marking or disclosure applies	Chatbots, synthetic content, deepfakes, emotion recognition	Article 50 is separate from high-risk classification
Minimal or no risk	No mandatory AI Act controls beyond generally applicable provisions	Many spam filters, games and ordinary productivity tools	Article 4, other EU law and voluntary codes may still matter

Step 0: define the unit you are classifying

Do not classify a vendor, brand or procurement contract as one object. Define the specific AI system, GPAI model and use case.

For each item, record:

system name and version;
provider and underlying model;
intended purpose;
users and affected people;
inputs, outputs and data categories;
decisions or processes influenced;
autonomy and human review;
deployment geography;
integration and modification;
and whether it is placed on the market under your name.

A platform may contain a low-risk drafting feature, an Article 50 chatbot and a high-risk hiring module. Treating the platform as one classification hides the obligations.

Step 1: is it within the AI Act’s scope?

Article 2 covers providers, deployers and other operators in the EU and reaches some actors outside it. The first questions are:

Is the organization placing an AI system or GPAI model on the EU market?
Is it deploying a system from an EU establishment?
Is a non-EU system producing output used in the EU?
Is the actor an importer, distributor, product manufacturer or authorized representative?
Does an exclusion apply?

Material exclusions include purely personal non-professional use, certain research and development before market placement, sole-purpose scientific R&D, and military, defense or national-security uses. Exclusion from the AI Act does not necessarily remove GDPR, consumer, product, employment or sectoral law.

Step 2: does the software meet the AI-system definition?

Article 3 defines an AI system through machine basis, varying autonomy, possible adaptiveness, objectives, inference and outputs influencing physical or virtual environments.

The Commission’s definition guidelines emphasize that ordinary software is not automatically AI merely because it automates a process. Useful questions include:

Does the system infer how to produce an output rather than execute only rules fully specified by humans?
Does it generate predictions, recommendations, decisions or content?
Does it operate with some independence after deployment?
Can the output influence a real or virtual environment?

Document borderline decisions. A classification file should show why the system is or is not within scope, not just the conclusion.

Step 3: does Article 5 prohibit the practice?

Screen prohibitions before asking whether the system is high-risk. A prohibited practice cannot be cured through conformity assessment.

The original Article 5 bans cover:

harmful subliminal, manipulative or deceptive techniques;
exploitation of vulnerabilities linked to age, disability or social or economic situation;
specified social scoring;
individual criminal-offence risk assessment based solely on profiling or personality traits;
untargeted scraping of facial images to create or expand recognition databases;
emotion inference in workplaces and education, except for medical or safety reasons;
biometric categorization inferring specified sensitive traits;
and most real-time remote biometric identification by law enforcement in public spaces, with narrow exceptions.

From December 2, 2026, additional prohibitions apply to defined non-consensual intimate material and child sexual abuse material. See prohibited AI practices for the elements and safeguards.

A prohibition assessment should include intended purpose, reasonably foreseeable misuse, safeguards, affected groups, deployment context and exceptions. “The vendor says it is compliant” is not enough when the deployer deliberately uses the system for a prohibited purpose.

Step 4: is the system high-risk under Annex I?

Article 6(1) creates the product route. Both conditions must be met:

the AI system is intended as a safety component of a product, or is itself a product, covered by Annex I legislation;
that product requires third-party conformity assessment before market placement or service.

The 2026 Omnibus clarified the safety-component test. AI used solely for non-safety user assistance, performance optimization, service efficiency, automation, convenience or quality control does not qualify as a safety component. If its failure or malfunction would endanger health and safety, it can qualify.

This route can cover AI in medical devices, machinery, vehicles, aviation, lifts, pressure equipment and other regulated product categories. Product teams should map the exact Annex I legislation and conformity route rather than use a broad label such as “healthcare AI.”

The main Chapter III requirements for Annex I systems apply from August 2, 2028.

Step 5: is the system listed in Annex III?

Article 6(2) identifies high-risk systems through listed use cases. Annex III is organized into eight areas.

1. Biometrics

This includes specified remote biometric identification, biometric categorization based on sensitive or protected attributes, and emotion recognition where permitted. Some practices are prohibited under Article 5, so the prohibition test comes first.

2. Critical infrastructure

AI intended as a safety component in managing or operating critical digital infrastructure, road traffic or the supply of water, gas, heating or electricity can be high-risk when failure risks life or health.

3. Education and vocational training

Examples include admissions, access, assignment, learning-outcome evaluation, education-level assessment and monitoring prohibited behavior during tests, subject to the precise Annex wording.

4. Employment and worker management

Recruitment and selection, targeted job advertising, application filtering, candidate evaluation, promotion, termination, task allocation and performance monitoring can fall within Annex III.

5. Essential private and public services

Listed uses include eligibility for public benefits, creditworthiness and credit scoring, life and health insurance risk and pricing, and emergency-call triage or dispatch, with defined exceptions.

6. Law enforcement

Specified systems used for assessing evidence, victim risk, polygraphs, profiling and criminal-investigation functions can be high-risk where permitted.

7. Migration, asylum and border control

Uses include polygraphs, risk assessments, application examination and identification in migration contexts.

8. Justice and democratic processes

AI assisting judicial authorities with legal interpretation and application, and systems intended to influence election or referendum outcomes, can be high-risk under the listed conditions.

The main Annex III requirements apply from December 2, 2027.

Step 6: can an Annex III system be treated as non-high-risk?

Article 6(3) creates a narrow route for an Annex III-listed system not to be high-risk when it does not pose a significant risk of harm to health, safety or fundamental rights, including because it does not materially influence decision-making outcomes.

The original conditions cover systems intended to:

perform a narrow procedural task;
improve the result of a completed human activity;
detect decision patterns or deviations without replacing or improperly influencing human assessment;
or perform a preparatory task for an Annex III assessment.

A system performing profiling of natural persons remains high-risk notwithstanding that route.

The provider must document the assessment before placing the system on the market or putting it into service and comply with the relevant registration requirement. This is not a casual self-declaration. The reasoning should address intended purpose, material influence, human review, consequences, affected groups and foreseeable use.

As of August 7, 2026, the Commission’s high-risk classification guidelines were still draft following a consultation that closed on July 23. Do not present draft examples as final law.

Step 7: does Article 50 apply?

Article 50 is a separate classification layer. It can apply whether a system is high-risk or not.

Evaluate four use patterns:

direct interaction with natural persons;
generation of synthetic or manipulated audio, image, video or text;
deployment of emotion recognition or biometric categorization;
deployment of deepfakes or certain public-interest text.

Provider and deployer obligations differ. A provider may need to build machine-readable marking into generated output. A deployer publishing a realistic deepfake may need a visible disclosure. An organization can have both roles.

See the EU AI Act transparency guide for exceptions and implementation.

Step 8: is there a GPAI model layer?

A general-purpose AI model is regulated at model level because it can perform a wide range of tasks and be integrated into many systems. The model’s provider has Chapter V obligations even when no individual downstream use is high-risk.

Ask:

Are we placing a GPAI model on the EU market?
Did we develop it, commission it or materially modify it?
Are we only integrating a third-party model into a system?
Does an open-source exemption cover particular Article 53 duties?
Does the model meet or approach systemic-risk criteria?
Have we received enough information for downstream compliance?

Do not call every generative application a GPAI model. A model and a system are distinct legal objects. Our GPAI guide explains fine-tuning and open-source treatment.

Step 9: assign operator roles

Classification controls are attached to actors. The same system can create different duties for:

the provider that develops and markets it;
the deployer using it in a process;
an importer bringing a non-EU system into the market;
a distributor making it available;
a product manufacturer integrating it;
and a downstream actor that becomes a provider after rebranding or substantial modification.

Role analysis should be repeated after changes. A customer that starts as a deployer can become a provider if it changes the intended purpose and turns the system into a high-risk use. See our AI Act roles guide.

A practical classification decision tree

1. Is the object an AI system or GPAI model within Article 2 scope? └─ No: document the reason and assess other laws. └─ Yes: continue. 2. Is the intended practice prohibited by Article 5? └─ Yes: do not place, put into service or use it except within a valid exception. └─ No: continue. 3. Does Article 6(1) and Annex I apply? └─ Yes: classify as product-related high-risk. └─ No: continue. 4. Is the intended use listed in Annex III? └─ Yes: test Article 6(3), profiling and documentation. └─ No: continue. 5. Does Article 50 apply to interaction, generation or deployment? └─ Yes: assign provider/deployer transparency controls. 6. Is a GPAI model being placed on the market or modified? └─ Yes: assign Chapter V obligations. 7. Apply Article 4, other EU law and voluntary controls where relevant.

Classification examples

Use case	Likely AI Act analysis	Why the answer is conditional
Internal email-drafting assistant	Usually not high-risk; Article 4 applies; Article 50 may not require external disclosure for internal drafting	Publication context, branding and use can change the result
Website customer-service chatbot	Article 50 direct-interaction notice; usually not high-risk on that fact alone	It could support access to an essential service or make consequential decisions
CV-ranking system	Potential Annex III employment high-risk system	A narrow procedural feature may need Article 6(3) analysis; intended purpose is decisive
AI medical diagnostic device	Potential Annex I high-risk route	Product legislation and third-party conformity assessment must be confirmed
Creditworthiness scoring for natural persons	Potential Annex III high-risk	Statutory exceptions and the exact decision process matter
Spam filter	Usually minimal risk	Article 4 and other security or data-protection duties may still apply
Deepfake in a clearly fictional film	Article 50 disclosure rules with artistic-context treatment	The disclosure must still be appropriate and not necessarily absent
Employee emotion detector	Likely prohibited in workplace except medical or safety use	The exception is narrow and must be genuine
General-purpose foundation model API	GPAI model obligations belong primarily to model provider; downstream system duties also possible	Fine-tuning, market placement and systemic risk can shift duties
Election-targeting AI	Potential Annex III democratic-process high-risk or prohibited manipulation	Actual purpose, technique and harm determine the route

These examples are orientations, not legal conclusions for a named product.

What to put in an AI classification register

A useful register contains more than a colored risk label.

Identification

unique system ID;
business and technical owner;
vendor, model and version;
first market or deployment date;
countries and legal entities.

Purpose and context

intended purpose;
actual use;
users and affected persons;
decisions influenced;
level of autonomy;
human oversight and override;
data categories.

Legal tests

AI-system definition reasoning;
Article 2 scope and exclusions;
Article 5 screening;
Annex I test;
Annex III use case;
Article 6(3) assessment;
Article 50 duties;
GPAI status;
operator roles;
other applicable laws.

Evidence and governance

source documents and contracts;
decision date and approver;
controls required;
implementation deadline;
review trigger;
open issues and legal advice.

Review triggers

Reclassify when:

intended purpose changes;
a model or major version changes;
the system is fine-tuned or substantially modified;
branding or market placement changes;
a human-review step is removed;
new data or affected groups are introduced;
the deployment expands into the EU;
an authority publishes relevant guidance;
a serious incident reveals different risk;
or a vendor changes documentation or terms.

Annual review alone is not enough for rapidly changing systems.

Common classification mistakes

Starting with the vendor’s risk label

Vendor documents help, but your intended use may differ. Deployers need their own context assessment.

Treating the four categories as mutually exclusive

Article 50, GPAI and high-risk obligations can overlap.

Classifying by sector only

“Healthcare,” “finance” or “HR” is too broad. The listed intended use and decision influence matter.

Assuming human review always avoids high-risk status

Human involvement can be relevant, but nominal review does not automatically remove material influence or profiling.

Using Article 6(3) without evidence

The provider must document why the Annex III system does not pose significant risk and meet the conditions.

Ignoring role changes

Rebranding, substantial modification and changed intended purpose can turn a deployer or distributor into a provider.

Frequently asked questions

How many risk categories are in the EU AI Act?

The Commission communicates four levels: unacceptable, high, transparency, and minimal or no risk. The legal framework also regulates GPAI models and operator roles separately.

Is “limited risk” an official legal term?

It is commonly used to describe Article 50 transparency-risk systems, but the binding duties come from the specific provisions rather than the label.

Are all AI systems used by banks high-risk?

No. Certain creditworthiness, insurance and essential-service uses are listed, but ordinary productivity, fraud-support or customer-service systems require separate analysis.

Is all workplace AI high-risk?

No. Annex III covers specified recruitment and worker-management uses. Emotion recognition in the workplace can be prohibited. A general writing assistant is different.

Can a high-risk AI system be used legally?

Yes, if the applicable requirements and operator obligations are met. High-risk is a regulated category, not a ban.

Does a human in the loop make a system low-risk?

Not automatically. The human’s authority, competence, information and real ability to disregard the output matter.

Can an Annex III provider decide its system is not high-risk?

Only through the Article 6(3) route, with the required conditions, documentation and registration. Profiling systems remain high-risk.

Is a foundation model automatically high-risk?

No. GPAI model obligations apply at model level. A downstream system can be high-risk based on its intended use.

Are open-source systems minimal-risk?

Open-source licensing is not a risk category. Specific exemptions may apply, but prohibited, high-risk, transparency and systemic-risk rules can remain relevant.

Who should approve classification?

A cross-functional process is strongest: business owner, technical owner, privacy, security, legal/compliance and, where relevant, HR, safety or product-regulatory experts.

Bottom line

The four-level risk diagram is an orientation, not the complete classification method. A defensible assessment defines the exact system and use, tests scope and Article 5, evaluates both high-risk routes, applies Article 50 and GPAI rules separately, assigns roles and records the evidence.

The output should be a living classification register with controls, deadlines and review triggers—not a one-time color assigned during procurement.

byDavid Porter

AI Act Europe Artificial Intelligence

EU AI Act Roles: Providers, Deployers and Other Operators

Microsoft to Unveil New Maia 300 Chip in September

Write a comment