EU AI Act risk classification

An AI system is high-risk under EU AI Act Article 6 when it is, or is a safety component of, an Annex I product that needs a third-party conformity assessment (Article 6(1)), or when it is used in an Annex III area (Article 6(2)). Otherwise it is banned (Article 5), carries transparency duties (Article 50), or is minimal risk.

The requirement in plain English

The Act sorts systems by what they are used for, not by how they are built. Classification is the provider’s job, done before the system reaches the market, and it is checked by the market surveillance authority later. There are four outcomes, tested in this order.

Prohibited (EU AI Act Article 5). A use on the banned list cannot be placed on the market or used at all. The prohibited practices page lists them.

High-risk through a product (EU AI Act Article 6(1)). Two conditions must both hold. The system is a safety component of a product covered by an EU law in Annex I, such as the medical device, machinery or toy rules, or is that product itself. And the product needs a third-party conformity assessment under that law. Regulation (EU) 2026/1744 tightened what a safety component is. It now means a component that fulfils a safety function, that is, one meant to prevent or reduce risks to health and safety (EU AI Act Article 3(14)). New paragraphs 1a to 1c of EU AI Act Article 6 add that a feature used only for user assistance, performance, efficiency, automation, convenience or quality control is not a safety component, unless its failure would endanger health or safety, and that a third-party assessment needed only for radio or electromagnetic reasons does not count.

High-risk through a listed use (EU AI Act Article 6(2)). Annex III lists eight areas: biometrics; safety components of critical infrastructure; education and vocational training; employment and the management of workers; access to essential private and public services, including credit scoring and the pricing of life and health insurance; law enforcement; migration, asylum and border control; and the administration of justice and democratic processes. Each area names specific uses; being in the area is not enough. The Commission can add uses by delegated act (EU AI Act Article 7).

The way out of Annex III (EU AI Act Article 6(3)). A listed system is not high-risk if it poses no significant risk of harm, because it only performs a narrow procedural task, improves the result of work a person has already done, detects patterns in decisions without replacing human review, or does a preparatory task. A system that profiles people is always high-risk. A provider relying on this must document the assessment before placing the system on the market (EU AI Act Article 6(4)) and register the system in the EU database (EU AI Act Article 49(2)).

Transparency and minimal risk. A system that talks to people, generates content, recognises emotions or categorises people biometrically carries the Article 50 duties. Everything else is minimal risk, with no duties beyond AI literacy.

Article 6(5) required Commission guidelines with practical examples by 2 February 2026. A draft was published for consultation on 19 May 2026; check the Commission’s AI Act pages for the final version before you rely on an example.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 25-person HR software company keeps an AI system register with one classification per system, each signed by the product lead and reviewed by the compliance lead.

Its CV-screening feature ranks applicants, an Annex III employment use. The team considered the Article 6(3) way out and rejected it, because the feature profiles candidates. The memo says so in two sentences and names the Annex III point. The system goes into the plan for the high-risk obligations, due by 2 December 2027.

Its interview-scheduling assistant also sits in the employment area but only proposes calendar slots, a narrow procedural task. The company documents that assessment, registers the system in the EU database as the Act requires, and records what would change the answer: the day it starts filtering candidates by availability patterns, it is reclassified.

Its customer support chatbot carries the Article 50 disclosure. A meeting-notes summariser used internally is minimal risk.

Every classification has a review trigger: a new intended purpose, a new customer segment, or a feature that starts influencing decisions about people. The register shows the date of the last review against each system.

Evidence an auditor expects

An intended purpose statement per system: the market surveillance authority starts here, because classification follows the use the provider intended.
A dated classification with its reasoning: which tier, which Annex I law or Annex III point, and who decided.
The Article 6(4) assessment (required where you rely on Article 6(3)): why the listed use poses no significant risk, written before the system was placed on the market.
EU database registration of derogated systems (required): the registration reference for each system classified out of Annex III.
For the product route, the product’s conformity route: for a device, its class and the notified body that assesses it.
Review triggers and history: evidence the classification was revisited when the use changed.

Common mistakes

Classifying the model instead of the use

Teams label a model “low risk” and reuse the label in every product. The tier follows the intended purpose: the same language model is minimal risk in a notes tool and high-risk in a credit decision. Classify each system in each use.

Using the way out for a profiling system

The Article 6(3) conditions never apply to a system that profiles people. A ranking or scoring tool that evaluates individuals stays high-risk however narrow it looks.

Classifying out without the paperwork

Relying on Article 6(3) is a documented decision with a registration, not a quiet conclusion. An authority can ask for the assessment at any time.

Calling every device feature a safety component

Since 27 July 2026, AI that only helps a clinician find their way around a screen or schedules work is not a safety component of a device, unless its failure would endanger health. Map each AI feature to its function before deciding.

Forgetting that a deployer can become the provider

Turning a general-purpose assistant to an Annex III purpose makes you its provider for that use (EU AI Act Article 25). Classify what your configuration does, not what the vendor sold.

How Sted helps

Sted’s knowledge base includes an AI Use Case Definition and Classification Record (REC-AIUC), one per AI system under the AI System Lifecycle Procedure (PRC-AISL), which sets out the use case, its users, inputs, outputs and human oversight model and, in its Risk Classification and Regulatory Assessment section, the classification reached, and is approved before data collection or model development begins.
Records are part of the Full Management System plan.
Sted treats the EU AI Act as applying when at least one of your AI systems is in EU scope and carries obligations: it is prohibited, high-risk through the product route (it embeds a medical device under EU MDR classed above Class I) or through an Annex III use you recorded, or it is a generative system under the Article 50 transparency duties; a general-purpose model you trained and that is in EU scope counts only when it carries systemic risk; in-scope systems that are all minimal-risk give applies in part; and a stored high-risk assessment overrides the derived tier.
Which standards apply to you, and a device’s class, are worked out by Sted’s rules from your recorded answers; the AI model does not decide them.

Sted derives a tier from your recorded answers. The legal classification, and any Article 6(3) assessment, is the provider’s decision to make and document.

EU AI Act: the hub, with the roles and who enforces the Act.
Obligations for high-risk systems: what follows once a system is high-risk.
EU MDR: the device class that decides the Article 6(1) route for AI in medical devices.
ISO 42001 AI risk and impact assessment: the management process that holds each classification and its review.
Classification and applicability: how Sted records your AI systems and works out what applies.

Frequently asked questions

Is a customer service chatbot high-risk under the EU AI Act?

Usually not. A chatbot that answers product questions is not in Annex III and is not a safety component, so it carries the Article 50 duty to tell people they are talking to AI and nothing heavier. It becomes high-risk if it is used for an Annex III purpose, such as deciding who gets credit or screening job applicants.

Is AI inside a medical device automatically high-risk?

No. It is high-risk when it is the device, or a safety component of it, and the device needs a notified body, which for software usually means Class IIa or above. Since 27 July 2026 a feature that only assists the user, speeds things up or adds convenience is not a safety component unless its failure would endanger health or safety.