How to classify a high-risk AI system under the EU AI Act

If your EU AI Act classification starts with “is this high risk?”, it will stall there. The question has no independent answer. High risk is a conclusion you reach by working through a specific sequence, and the order matters, because an earlier answer can make a later one irrelevant.

This is that sequence, in the order the Regulation imposes it, with the obligations each step triggers.

Step 0: establish what you are before you classify what it is

Decide your role for this specific system first. The Act imposes different duties on providers and deployers, and one organisation can be both. Different systems, and sometimes the same one.

• Deployer. You use an AI system supplied by someone else, under your own authority. Most SaaS and vendor tooling lands here.
• Provider. You develop the system, or have it developed, and place it on the market or put it into service under your own name or trademark.
• Provider and deployer. You built it and you use it yourself. Internal tools built in-house on top of a foundation model almost always fall here, and not having trained the model yourself does not move you out of it.

That last point is worth sitting with. Fine-tuning someone else’s model, or building an application around it that you put into service under your own name, generally makes you a provider of that system. “We just use OpenAI” is not a role determination.

Role does not change the risk tier. It changes which obligations attach once you have one.

Step 1: rule out prohibited practices

This comes first because it settles everything. If a system engages in a prohibited practice, nothing downstream matters. There is no mitigation, no conformity assessment, no documentation package that makes it permissible. It cannot be placed on the market or used at all.

Article 5 lists eight:

Practice	Article
Subliminal or manipulative techniques causing significant harm	5(1)(a)
Exploiting vulnerabilities of age, disability, or social/economic situation	5(1)(b)
Social scoring leading to detrimental treatment in unrelated contexts	5(1)(c)
Predictive policing based solely on profiling or personality traits	5(1)(d)
Untargeted scraping of facial images to build recognition databases	5(1)(e)
Emotion recognition in the workplace or education	5(1)(f)
Biometric categorisation inferring protected attributes	5(1)(g)
Real-time remote biometric identification for law enforcement in public spaces	5(1)(h)

These prohibitions have been in force since 2 February 2025. They are not a future deadline.

Two of them reach ordinary commercial software. Emotion recognition in the workplace under 5(1)(f) reaches sales-call sentiment analysis and candidate-interview tooling that scores affect. The medical and safety carve-outs are narrow and will not cover a productivity use case. Biometric categorisation under 5(1)(g) reaches systems that infer protected attributes from biometric data even when the inference is incidental to the stated purpose.

Hit one of these and the exercise is over. The answer is no.

Step 2: check Annex III

Assuming nothing is prohibited, the question becomes whether the system falls into one of the eight Annex III areas:

1. Biometrics. Remote biometric identification, biometric categorisation by sensitive attributes, emotion recognition.
2. Critical infrastructure. Safety components in digital infrastructure, road traffic, or water, gas, heating and electricity supply.
3. Education and vocational training. Admission, assessment of learning outcomes, evaluating education level, monitoring prohibited behaviour during tests.
4. Employment and workers management. Recruitment, screening, evaluating candidates, promotion and termination decisions, task allocation, monitoring workers.
5. Essential private and public services. Eligibility for public benefits, creditworthiness and credit scoring, life and health insurance risk pricing, emergency call triage.
6. Law enforcement. Victim risk assessment, polygraphs, evidence reliability, recidivism risk, profiling in investigations.
7. Migration, asylum and border control. Risk assessment, application examination, identification of persons.
8. Justice and democratic processes. Assisting judicial authorities with facts and law, or influencing election outcomes.

Areas 4 and 5 are the ones that reach ordinary private-sector work. A CV-screening tool is Annex III, 4. A credit decisioning model is Annex III, 5. An internal tool that allocates tasks or monitors worker productivity is also Annex III, 4, and that catches a lot of “AI for operations” projects whose owners have never thought of them as regulated.

Note what is not on the list. A customer-support chatbot, a marketing copy generator, a code assistant, a document summariser. None of these are Annex III on their own. They may still carry transparency obligations, covered in step 4, but they are not high risk.

Step 3: test the Article 6(3) derogations

Landing in an Annex III area creates a presumption of high risk rather than a conclusion. Article 6(3) provides an escape hatch. A system in an Annex III area is not high risk if it poses no significant risk of harm to health, safety or fundamental rights, and meets one of four conditions:

• Narrow procedural task. Transforming unstructured data into structured data, classifying documents, detecting duplicates.
• Improves the result of a previously completed human activity. Adds a layer on top of a human decision without replacing it, such as polishing language.
• Detects decision patterns or deviations without replacing human assessment. Flags inconsistencies for a human to review, and does not influence the assessment without proper human review.
• Preparatory task. Indexing, searching, text processing or translation feeding a later human-led assessment.

There is a hard carve-out. Profiling of natural persons always makes an Annex III system high risk, regardless of derogation. If the system profiles people, the escape hatch is closed.

The derogations are also narrower in practice than they read. “A human reviews the output” is not the same as “does not replace human assessment”. If the human rubber-stamps a ranked list the system produced, the system is doing the assessment. Regulators will look at the actual decision process rather than the org chart.

If you claim a derogation, document the reasoning at the time you claim it. You are asserting a conclusion about your own system, and the assertion is the thing that gets audited.

Step 4: layer on transparency obligations

Article 50 applies independently of tier. A minimal-risk system can still carry transparency duties, and it is an easy step to skip, because it does not feel like risk.

Five triggers:

• Interacts directly with people. Chatbots, voice assistants, any interface where a person may not realise they are talking to AI. Article 50(1).
• Generates synthetic audio, image, video or text. Output must be marked machine-readable as artificially generated. Article 50(2).
• Emotion recognition or biometric categorisation. Exposed persons must be informed. Article 50(3).
• Produces or manipulates deep fakes. Content resembling real persons, places or events must be disclosed. Article 50(4).
• Publishes AI-generated text on matters of public interest. Disclosure required unless human-reviewed with editorial responsibility. Article 50(4).

These came into force on 2 August 2026. The synthetic-content marking requirement in 50(2) is the one with real engineering consequences. Machine-readable marking is a build task rather than a policy statement, and it applies to a great deal of ordinary generative tooling.

Step 5: check whether a FRIA is required

If the system is high risk and you are a deployer, Article 27 may require a fundamental rights impact assessment before first use. Four triggers:

• You are a body governed by public law
• You are a private entity providing public services such as healthcare, education, housing or social services
• The system assesses creditworthiness or credit scores natural persons, under Annex III, 5(b)
• The system performs life or health insurance risk assessment and pricing, under Annex III, 5(c)

The FRIA is a deployer duty, distinct from the provider’s risk management system under Article 9. Both can exist for the same system with different owners, and that is exactly the situation that produces gaps.

What each outcome obliges

Tier	What attaches
Prohibited	Nothing. The system cannot be used. Art. 4 AI literacy still applies to your organisation.
High risk	Arts. 9–15 (risk management, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy and cybersecurity), plus provider obligations 16–17 or deployer obligations 26–27, conformity assessment under 43, registration under 49, and post-market monitoring under 72–73
Limited risk	Art. 50 transparency obligations only
Minimal risk	Art. 4 AI literacy. Voluntary codes of conduct.

Article 4 AI literacy applies across the board and gets forgotten constantly. It is an organisational duty rather than a per-system one, and it has been in force since February 2025.

Where the deadlines stand

As of September 2026, most of the Act is already live:

Milestone	Date	Status
Prohibited practices, AI literacy	2 Feb 2025	In force
General-purpose AI model obligations	2 Aug 2025	In force
Transparency obligations (Art. 50)	2 Aug 2026	In force
Annex III high-risk requirements	2 Aug 2026	In force
Annex I high-risk (regulated products)	2 Aug 2027	Upcoming

If you are still treating the EU AI Act as a 2027 problem, you are behind on four of five milestones. The remaining runway applies only to high-risk AI embedded in products already covered by EU product-safety legislation under Annex I.

Do this per system, and keep the reasoning

The first failure to watch for is classifying at the wrong granularity. Classify “our AI programme” or “the chatbot project” and end up with a tier that describes nothing precisely. Classification attaches to a system with a defined purpose. Change the purpose and you have changed the classification. The same underlying model used for document search and for candidate ranking is two systems with two tiers.

The second is treating the output as a one-time artefact. A classification is a claim about a system at a point in time, made on the basis of specific answers. When the system’s purpose expands, the claim needs re-testing, and you need to show what you concluded, when, and on what basis.

That is the part worth engineering. The questions above are answerable in an afternoon per system. Keeping the answers attached to the system, versioned, and linked to the evidence behind them is the work that survives contact with an auditor.

---

This article is a practitioner’s walkthrough, not legal advice. Classification conclusions should be reviewed by counsel, particularly where an Article 6(3) derogation is claimed.