Is your AI system high-risk under the EU AI Act? A step-by-step guide

High-risk is the tier of the EU AI Act that carries the heaviest compliance load: a quality management system, technical documentation, risk and data governance, human oversight, post-market monitoring, conformity assessment, and registration in the EU AI database. Getting your classification right matters because the wrong answer either over-engineers a system that did not need it or, more painfully, leaves you out of compliance on a system that did.

This article walks through the actual decision, in the order you should make it. It does not skip the awkward bits, like the Article 6(3) exemption and the question of when a deployer turns into a provider. Use it once per AI system, document the result, and re-run whenever the intended purpose, training data or deployment context changes.

If you have not already done so, read the risk classifications overview first. This guide assumes you know what the four tiers are and you have already confirmed your system is not in the prohibited tier.

Step 1: get the intended purpose written down

Before any classification, you need a single, precise sentence describing what the system is for. Not what it could do, what it is intended to do. The Act consistently anchors obligations to "intended purpose," which Article 3 defines as the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider.

A useful test: if a customer asked you "what does this do," and you wrote down the answer in one sentence, that is your intended purpose. "Predicts the likelihood that a job applicant will succeed in a software-engineering role, based on their CV and a short technical questionnaire" is an intended purpose. "AI assistant for HR" is not.

Get this right before you move on. Half of the classification disputes that surface later trace back to a vague intended purpose. The narrower and more honest the description, the easier the rest of the analysis.

Step 2: check Annex I (the product-safety route)

Annex I lists existing Union harmonisation laws that already require CE-marked products to undergo conformity assessment. Your AI system is high-risk under Article 6(1) if it is a safety component of a product covered by one of these laws, or if it is itself a product covered by one. The list includes:

• Machinery (Regulation (EU) 2023/1230)
• Toys (Directive 2009/48/EC)
• Recreational craft and personal watercraft
• Lifts and safety components for lifts
• Equipment for use in potentially explosive atmospheres (ATEX)
• Radio equipment
• Pressure equipment
• Cableway installations
• Personal protective equipment
• Appliances burning gaseous fuels
• Medical devices (Regulation (EU) 2017/745) and in-vitro diagnostic medical devices (Regulation (EU) 2017/746)
• Civil aviation security
• Motor vehicles and trailers (Regulation (EU) 2018/858)
• Marine equipment
• Interoperability of the rail system
• Civil aviation (Regulation (EU) 2018/1139)
• Two- or three-wheel vehicles and quadricycles
• Agricultural and forestry vehicles

If your system sits inside, or is, a product regulated under any of these, stop here: it is high-risk. The remaining steps in this guide are about Annex III, which only kicks in if you are not high-risk via Annex I.

The Annex I route brings an additional wrinkle: the AI Act conformity-assessment obligations are integrated into the sectoral law's existing notified-body assessment. You do not run two parallel assessments; you run one combined one. The Commission has published guidance for several sectors on how this works.

Step 3: check Annex III (the use-case route)

If you are not high-risk via Annex I, the next question is whether the intended purpose falls in one of the eight Annex III areas. These are the use cases where the EU has decided the risk to fundamental rights or safety is high enough to warrant heavy regulation regardless of the underlying technology.

The eight areas:

1. Biometrics, where not already prohibited. Includes remote biometric identification systems, biometric categorisation systems for sensitive or protected attributes, and emotion recognition systems. Some sub-uses are outright prohibited under Article 5; others are high-risk.

2. Critical infrastructure. Safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating or electricity.

3. Education and vocational training. Determining access or admission, assigning people to institutions, evaluating learning outcomes (including those that steer the learning path), assessing the appropriate level of education a person will receive, and monitoring or detecting prohibited behaviour during tests.

4. Employment, workers management and access to self-employment. Recruitment and selection (placing targeted job adverts, analysing and filtering applications, evaluating candidates), making decisions affecting terms of work-related relationships, promotion and termination, allocating tasks based on individual behaviour or personal traits, and monitoring and evaluating performance and behaviour.

5. Access to and enjoyment of essential private and public services. Evaluating eligibility for public benefits and services (including healthcare); credit scoring and creditworthiness assessment (except detecting financial fraud); risk assessment and pricing for life and health insurance; emergency-call routing and prioritisation.

6. Law enforcement. Assessing the risk of becoming a victim of a criminal offence; polygraphs and similar tools; evaluating reliability of evidence; assessing the risk of offending or re-offending (except where prohibited under Article 5); profiling for detection, investigation or prosecution.

7. Migration, asylum and border control management. Polygraphs and similar tools; assessing risks posed by an entrant; verifying the authenticity of travel documents and detecting fraud; examining applications for asylum, visa and residence permits and related complaints about eligibility.

8. Administration of justice and democratic processes. Assisting a judicial authority in researching and interpreting facts and the law, and applying the law to facts (Article 6(2)). Influencing the outcome of an election or referendum or the voting behaviour of natural persons (this does not include systems whose output is not directly exposed to natural persons, like back-office tools used to organise campaigns).

If your intended purpose falls under one of these eight, you are not yet finished. Go to Step 4.

If it does not fall under any of these, stop: your system is not high-risk via Annex III. It will be either limited-risk (if it interacts with people, generates synthetic content, or performs emotion or biometric categorisation in a non-prohibited way) or minimal risk.

Step 4: apply the Article 6(3) exemption

This is the step most people miss, and it can save you a lot of work. Article 6(3) carves an exemption out of Annex III. An Annex III system is not high-risk if its intended purpose is narrow and limited to one or more of the following:

• (a) Performs a narrow procedural task — for example, a system that transforms unstructured data into structured data, classifies incoming documents into categories, or detects duplicates among a large set of applications.
• (b) Improves the result of a previously completed human activity — for example, a system that improves the language, style, or readability of a document already drafted by a human, or polishes the academic style of a piece of writing.
• (c) Detects decision-making patterns or deviations from prior patterns and is not meant to replace or influence the previously completed human assessment without proper human review — for example, a teacher uses an AI tool that detects an inconsistent grading pattern across exams compared to the teacher's historical patterns, and flags it for review by the teacher.
• (d) Performs a preparatory task for an assessment relevant to the Annex III use case — for example, a smart filing system that pre-sorts incoming applications by date or category.

The exemption has a hard floor: it does not apply when the system performs profiling of natural persons. If your system profiles individuals (creating any kind of personal scoring, evaluation or characterisation based on personal data), the exemption is unavailable and the system is high-risk by virtue of being in Annex III.

If you intend to rely on the exemption, the Act requires you to document your assessment before placing the system on the market and to register both the system and the exemption rationale in the EU AI database. You do not get to claim "exempt" silently.

Practical examples of the exemption working:

• A CV-parsing tool that extracts structured fields (name, education, work history) from uploaded CVs into a structured database, with no scoring or ranking, can rely on (a). Add scoring and the exemption is gone.
• A grammar-checking tool that polishes the text of an employee performance review previously written by a manager can rely on (b). Add suggested ratings and the exemption is gone.
• A spam-filter for incoming candidate emails can rely on (a) or (d). Add candidate ranking and the exemption is gone.

Practical examples of the exemption failing:

• A "skill-fit" score from a candidate's CV — profiling, exemption inapplicable, high-risk.
• A model that suggests promotion candidates from performance data — profiling, exemption inapplicable, high-risk.
• A polygraph used by a border officer — Annex III area 7, no narrow procedural task, high-risk.

Step 5: separate the provider question from the deployer question

The risk tier you have just calculated attaches to the AI system itself. Whether you are bound by the high-risk provider obligations depends on whether you are the provider of that system.

Article 3 defines a provider as the entity that develops an AI system, or that has an AI system developed, and places it on the market or puts it into service under its own name or trade mark, whether for payment or free of charge. The deployer is the entity that uses an AI system under its own authority (except where the use is in the course of a personal non-professional activity).

Importantly, a deployer can become a provider. Article 25 lists three triggers under which a deployer, importer, distributor or other third party is considered a provider of a new high-risk AI system:

• It puts its name or trade mark on a high-risk AI system already placed on the market or put into service (white-labelling).
• It makes a substantial modification to a high-risk AI system already on the market in a way that it remains high-risk.
• It modifies the intended purpose of an AI system, including a general-purpose AI system, that has not been classified as high-risk and has already been placed on the market, in such a way that the AI system becomes high-risk.

The third trigger is the one that catches people. If you take a general-purpose model and deploy it for a recruitment-screening use case, you have just made yourself a provider of a high-risk recruitment screening system. You are responsible for the full provider obligations on that system, even though you did not train the underlying model.

Step 6: document and re-run

Whatever you concluded, write down the assessment. For each AI system you should be able to produce, on request from a national competent authority:

• The intended purpose, in one sentence.
• The Annex I check result.
• The Annex III check result and which area, if any.
• The Article 6(3) exemption assessment, if applicable, with the specific sub-paragraph relied on and the reason it applies (or, equally importantly, the reason it does not).
• The role analysis (provider, deployer, importer, distributor).
• The date of the assessment and the next review date.

Re-run the whole thing on every material change. New training data that shifts the intended purpose? Re-run. New deployment context that brings the system into a different Annex III area? Re-run. Going from a minimal-risk content tool to a high-risk screening tool can happen on a single product-roadmap decision; the classification will not update itself.

A structured tool that applies the Annex III filter, the Article 6(3) exemption logic, and the provider/deployer triggers in the right order saves a lot of time on this. That is exactly what the aiactly classifier is built for, and it produces the documented assessment as a downloadable artifact, which is the form you will want it in when an authority asks. But the underlying reasoning is what this article walked through, and you can do it with a spreadsheet if you prefer.

If the conclusion is high-risk, your next read is the providers obligations guide (coming next in this series). If the conclusion is not high-risk, you may still face transparency obligations under Article 50 — see the risk classifications article for the limited-risk tier.