AI Act High-Risk Classification: A Flowchart in Words

Most teams get stuck on the same question: is this AI system high-risk under the EU AI Act, or not? The answer is a sequence of checks, not a single label, and the order matters. This post lays the sequence out as a numbered procedure you can run on any system, with illustrative examples at the end. Last verified 2026-10-06.

Everything below follows the Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI, which entered into force on 27 July 2026. For the checklist version of the obligations that follow a high-risk finding, see the high-risk checklist.

Dates you need first

The Commission timeline reflects the Omnibus. Our timeline page tracks the rest. One more status point: the Commission's guidelines on the Article 6 classification rules are still draft consultation documents, published on 19 May 2026, according to Bird & Bird. Treat their reading as indicative, not final.

The procedure

Step 0: Is it an AI system, and is it in scope?

Start with the definition of an AI system in the Act, then confirm the Act reaches you at all, which turns on your role and where the system is offered or used. Plain software that follows fixed rules without inference is a different conversation. Record who you are for this system: provider, deployer or both. Step 6 returns to this.

Step 1: Is a practice prohibited under Article 5?

Check this first, because no risk classification rescues a prohibited practice. Article 5 covers, among others:

• Subliminal, manipulative or deceptive techniques causing significant harm, and exploiting vulnerabilities such as age, disability or social or economic situation.
• Social scoring, and predicting offending solely from profiling or personality.
• Untargeted scraping of facial images from the internet or CCTV to build facial-recognition databases.
• Inferring emotions in workplaces and education (with medical and safety exceptions).
• Biometric categorization that infers race, political opinions, trade-union membership, beliefs, or sex life or orientation.
• Real-time remote biometric identification in public spaces for law enforcement, with three narrow exceptions.

From 2 December 2026 the list also covers AI that generates non-consensual intimate imagery or child sexual abuse material. If a practice is prohibited, stop: do not build it.

Step 2: Is it a product, or a safety component of a product, under Annex I?

This is the Article 6(1) route. It applies where the AI system is, or is a safety component of, a product covered by the Union harmonization legislation listed in Annex I. It is mainly a concern for makers of regulated products, and the obligations on that route apply from 2 August 2028.

The Omnibus narrowed what counts as a "safety component" in Article 6(1a) to (1c), and moved the Machinery Regulation from Annex I Section A to Section B. If your system sits near a regulated product, read the amended text and the product's own conformity assessment route rather than relying on a summary.

Step 3: Does it fall in an Annex III area?

This is the route most software teams meet. Annex III lists eight areas:

1. Biometrics.
2. Critical infrastructure, including safety components in digital infrastructure, road traffic and utilities.
3. Education and vocational training.
4. Employment, workers management and access to self-employment.
5. Access to essential private and public services and benefits, including public benefits eligibility, creditworthiness and credit scoring (but not fraud detection), life and health insurance risk and pricing, and emergency call classification and dispatch.
6. Law enforcement.
7. Migration, asylum and border control.
8. Administration of justice and democratic processes.

Match on the use case, not the technology: the same model is high-risk when you deploy it to rank job candidates. If nothing in Annex III matches, and Steps 1 and 2 were clear, the system is not high-risk. Skip to Step 6.

Step 4: Does the Article 6(3) derogation apply?

An Annex III system is not high-risk if it does not pose a significant risk of harm and meets at least one of four conditions:

• It performs a narrow procedural task.
• It improves the result of a previously completed human activity.
• It detects decision patterns or deviations without replacing human assessment.
• It performs a preparatory task.

There is a hard override: a system that profiles natural persons is always high-risk, whatever the four conditions say. Draft Commission guidance reads the conditions narrowly, according to Bird & Bird, so do not treat the derogation as a loophole. If unsure, assume it does not apply.

Step 5: Document the conclusion and register it

If you rely on the derogation, the provider must document the assessment under Article 6(4) and register the system under Article 49(2). The Commission proposed dropping that registration duty, but according to commentary the negotiators rejected the change, so it stays. A dated written assessment is your best evidence if a regulator asks; the evidence pack post covers what to keep.

If the system is high-risk, the provider obligations in Articles 9 to 17 follow: risk management, data governance, technical documentation, logging, instructions for use, human oversight, accuracy and robustness, and a quality management system.

Step 6: What is your role?

Classification attaches to the system; duties attach to roles.

• Provider: develops the system or has it developed and places it on the market under its own name.
• Deployer: uses it under its own authority. For high-risk systems, Article 26 requires use per instructions, human oversight by competent and trained people, monitoring, keeping automatically generated logs under your control for at least six months, informing workers before workplace use, and informing people subject to Annex III decisions.
• You became the provider. Under Article 25, a deployer, distributor or importer becomes the provider if it puts its name on a high-risk system, makes a substantial modification, or changes the intended purpose so that a system becomes high-risk. This catches teams that point a general-purpose model at a listed use case and ship it as their own product.

Certain deployers must also complete a fundamental rights impact assessment before first use under Article 27: public bodies, private entities providing public services, and deployers of credit scoring and life and health insurance systems. It complements, rather than replaces, a GDPR data protection impact assessment; see DPIA for AI.

Step 7: Transparency applies whatever the tier

Article 50 applies from 2 August 2026 regardless of risk class. Systems that interact with people must make clear that they are AI unless it is obvious. Providers of generative systems must mark synthetic audio, image, video and text outputs in a machine-readable way. Deployers must inform people exposed to emotion recognition or biometric categorization, and disclose deepfakes. The Commission published a voluntary code of practice on marking and labelling AI-generated content on 10 June 2026.

Step 8: Add the GPAI layer if you build on or ship a model

GPAI is a separate track from high-risk classification. Providers of GPAI models carry Chapter V obligations, applying since 2 August 2025: technical documentation, information for downstream providers, a copyright policy and a public summary of training content. Models presumed to have systemic risk, at training compute above 10^25 FLOP, carry more. If you only build an application on someone else's model, you are usually a downstream provider; the model provider's documentation feeds your own. See the GPAI obligations page.

Worked examples (illustrative only)

These are simplified illustrations, not classifications of any real product. Facts change outcomes.

Two notes. The chatbot changes class if you wire it into a listed decision, such as benefit eligibility. And if a fraud score also drives who gets credit, you are back to the credit-scoring item.

Small companies get some relief on documentation and quality management; see the AI Act for startups.

How Swfte supports this

Swfte is a Sovereign Intelligence Platform built for Europe. It is designed to let you keep the inputs this procedure needs in one place: the Trust Profile records an AI system's owner, risk level, approved models, data classification, data residency, allowed and restricted actions, human approval rule and audit settings, which is the evidence base for a classification record and for deployer oversight. Swfte provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements; the exact posture depends on use case, jurisdiction, deployment and configuration. Swfte does not classify your systems for you, and it does not replace legal analysis. Start at the EU hub, then see governance, sovereignty, the Trust Profile and the trust page.

This is not legal advice. Confirm your classification with qualified counsel.