Is your AI feature high-risk under the EU AI Act?

Before you can comply with the EU AI Act, you have to answer a more basic question: does it even apply to you, and if so, how much? The Act treats a spam filter and a CV-screening model very differently. One carries almost no obligations. The other pulls in a full conformity assessment, technical documentation, logging, human oversight, and post-market monitoring. Getting the classification wrong in either direction is expensive. Over-classify and you burn months building compliance machinery you didn't need. Under-classify and you ship something that an auditor later decides was high-risk all along.

This guide walks through how the Act actually sorts AI systems, so you can place each feature in your product with confidence. It pairs with our two earlier pieces on what the Act means for QA and how to test non-deterministic AI. Those assume you already know you're in scope. This one helps you decide.

A note before we start: this is engineering guidance, not legal advice. The classification rules have genuine edge cases, and where real money or real rights are on the line you should get a lawyer who specializes in the Act to confirm. What follows will get you to the right question fast and tell you when you've hit one of those edges.

First, are you even a "provider" or a "deployer"?

The Act assigns obligations by role, and most of the heavy ones land on the provider: the entity that develops an AI system (or has one developed) and puts it on the market under its own name. If you build an AI feature into your product and sell that product, you're a provider. If you only use someone else's AI system in your operations, you're a deployer, and your obligations are lighter, though not zero.

Two things catch teams off guard here. First, geography doesn't save you. Article 2 extends the Act to providers and deployers outside the EU whenever the output of the system is used in the Union. A US company selling SaaS to European customers is in scope. Second, you can accidentally become a provider. Under Article 25, if you put your name on a high-risk system, or you substantially modify one, or you use a general-purpose model in a way that turns it into a high-risk use case, the provider obligations transfer to you. Fine-tuning a foundation model and shipping it inside a hiring tool is a classic way to inherit the full obligation set without realizing it.

So step one is honest: for each AI feature, write down whether you built it, rebranded it, modified it, or merely use it. That answer decides which obligations attach once you know the risk tier.

The four risk tiers, from most to least regulated

The Act sorts AI systems into four buckets. Work through them top to bottom. The first one a feature lands in is the one that governs it.

1. Unacceptable risk: banned outright (Article 5)

A short list of practices are prohibited entirely, and these prohibitions have already applied since February 2, 2025. They're not a compliance burden, they're a hard stop. The list in Article 5 includes:

• Subliminal or purposefully manipulative techniques that distort behavior and cause harm.
• Exploiting vulnerabilities tied to age, disability, or a specific social or economic situation.
• Social scoring of individuals based on behavior or personal traits.
• Untargeted scraping of facial images from the internet or CCTV to build facial-recognition databases.
• Emotion recognition in the workplace and in education (with narrow medical and safety exceptions).
• Biometric categorization that infers sensitive attributes like race, political views, or sexual orientation.
• Most real-time remote biometric identification in public spaces for law enforcement, and predictive policing based solely on profiling.

Most product teams won't touch these. But it's worth a five-minute check, because a couple of them, emotion recognition in a workplace tool and manipulative design patterns, can sneak into otherwise mundane products. If a feature lands here, no amount of testing or documentation makes it compliant. It can't ship into the EU.

2. High risk: allowed, but heavily regulated (Article 6)

This is the tier that matters for most serious AI products, and the one this guide spends the most time on. High-risk systems are legal to sell, but they carry the full weight of the Act: a risk management system, data governance, technical documentation, logging, human oversight, accuracy and robustness requirements, and a conformity assessment before you go to market. We'll break down how to tell if you're here in the next section, because this is where most of the real uncertainty lives.

3. Limited risk: transparency obligations only (Article 50)

Some systems are fine to ship as long as you're honest that they're AI. Article 50 covers these transparency duties:

• Chatbots and conversational agents must tell users they're interacting with an AI, unless it's obvious from context.
• AI-generated or manipulated image, audio, and video (deepfakes and synthetic media) must be labeled as artificial, in a machine-readable way.
• Emotion recognition and biometric categorization systems must inform the people exposed to them.

If your AI feature is a customer-support chatbot or generates marketing imagery, this is most likely your tier. The obligations are real but light: clear disclosure, proper content labeling, and records showing you do it. No conformity assessment, no technical file.

4. Minimal risk: no mandatory obligations

Everything else. Spam filters, AI in video games, inventory forecasting, most recommendation engines, the AI that suggests a tag for your support ticket. The Act encourages voluntary codes of conduct here but imposes nothing mandatory. The European Commission has said publicly that the vast majority of AI systems in use today fall into this category. That's worth holding onto, because the dread around the Act often comes from assuming everything is high-risk. Most things aren't.

The decision that actually matters: are you high-risk?

Almost all the real classification work is answering this one question. There are two independent routes into the high-risk tier, and a feature is high-risk if it matches either.

Route one: you're a regulated product, or a safety component of one

Article 6(1) catches AI that is itself a product, or a safety component of a product, already covered by a list of existing EU product-safety laws in Annex I. That list includes machinery, medical devices, in-vitro diagnostics, toys, lifts, radio equipment, cars, aircraft, and more. If your AI is the brain inside a medical device or the system that keeps an industrial machine from crushing someone, and that product already requires third-party conformity assessment, your AI is high-risk by extension.

Most pure-software SaaS teams won't hit this route. If you build physical products or regulated medical software, you almost certainly will, and you probably already have a regulatory affairs function that knows it.

Route two: your use case is on the Annex III list

This is the route most software teams need to check carefully. Annex III names eight areas where AI is presumed high-risk because of the impact on people's rights and safety:

• Biometrics: remote biometric identification, biometric categorization, and emotion recognition (the ones not already banned).
• Critical infrastructure: safety components for utilities, traffic, water, gas, electricity, digital infrastructure.
• Education and vocational training: deciding admissions, evaluating learning outcomes, or proctoring exams.
• Employment and worker management: CV screening, candidate ranking, promotion and termination decisions, task allocation, performance monitoring.
• Access to essential services: credit scoring, creditworthiness, health and life insurance risk assessment and pricing, eligibility for public benefits, and emergency-services dispatch prioritization.
• Law enforcement: risk assessments, evidence evaluation, profiling during investigations.
• Migration, asylum, and border control: visa and asylum application assessment, risk profiling.
• Administration of justice and democratic processes: assisting judicial decisions, influencing elections or voting behavior.

Employment and essential-services are the two that catch ordinary B2B SaaS companies most often. If your HR product ranks job applicants, your fintech scores credit, or your insurtech prices risk, you're looking straight at Annex III. That doesn't automatically make you high-risk, though, because of the exemption below. But it does mean you have to do the analysis and write it down.

The exemption that lets you out (and the trap inside it)

Article 6(3) is the most important sentence in this whole exercise. Even if your use case is on the Annex III list, the system is not high-risk if it doesn't pose a significant risk of harm to health, safety, or fundamental rights. The Act gives four qualifying conditions, any one of which can apply:

• The system performs a narrow procedural task.
• It improves the result of a human activity that's already been completed.
• It detects decision-making patterns or deviations from prior patterns, without replacing or influencing the human assessment.
• It performs a preparatory task for an assessment.

Here's a concrete example. An AI that reads incoming CVs and extracts the candidate's years of experience into a structured field is doing a narrow preparatory task. An AI that ranks those same candidates and tells the recruiter who to interview is influencing the assessment. The first might qualify for the exemption. The second almost certainly doesn't.

Now the trap. The exemption has a hard carve-out: if the system performs profiling of natural persons, it is always high-risk, full stop, no exemption. So the moment your "preparatory" tool starts building a profile of a person to inform a decision about them, you're back in the high-risk tier. And critically, Article 6(4) requires that if you claim the exemption, you must document your assessment before putting the system on the market, and register it. You don't get to claim the exemption silently. You have to show your work.

Don't forget the GPAI layer

The risk tiers classify AI systems. There's a separate, parallel set of rules for general-purpose AI models, the foundation models that get built into many systems. If you train or fine-tune a foundation model and make it available, Chapter V of the Act gives you obligations of your own: technical documentation, a summary of training data, and copyright compliance. Models above a compute threshold (the Act uses 10^25 floating-point operations as the marker for "systemic risk") carry heavier duties around evaluation and incident reporting. These obligations have applied since August 2, 2025.

For most teams this is somebody else's problem: you consume an API from a model provider who carries the GPAI obligations. But if you're fine-tuning open-weight models and shipping them, check whether you've crossed from deployer into provider territory here too.

The timeline you're classifying against

Classification is urgent because the obligations phase in on fixed dates. The Act entered into force on August 1, 2024, and the duties switch on in stages:

• February 2, 2025: prohibited practices and AI literacy obligations.
• August 2, 2025: general-purpose AI model obligations and governance rules.
• August 2, 2026: the big one. Most high-risk obligations (the Annex III systems) become fully applicable.
• August 2, 2027: high-risk obligations for AI embedded in regulated products under Annex I.

If you're reading this in 2026, the August 2 deadline for Annex III systems is the one to plan around. That's the date your CV-screener or credit-scoring model needs its conformity assessment, technical file, and logging in place.

A practical way to run the classification

Don't treat this as a one-time legal memo. Treat it as an inventory you maintain. Here's the sequence that works.

Start by listing every feature in your product that uses AI or ML. Be generous about what counts. The recommendation widget, the auto-tagging, the summarization, the fraud check, all of it. Teams consistently undercount their AI surface because half of it got added quietly inside other features.

For each one, run it down the four tiers in order. Is it prohibited? Is it a regulated product or a safety component? Is the use case in Annex III? If yes to Annex III, does the 6(3) exemption genuinely apply, and have you confirmed it isn't doing profiling? If none of that catches it, does it at least trigger an Article 50 transparency duty? Whatever's left is minimal risk.

Then record the verdict and the reasoning for each feature, with a date and an owner. This record is not busywork. For anything you classify as exempt under 6(3), the Act requires the documented assessment anyway. For anything high-risk, the classification is the first artifact in your technical file. And when a feature changes, which AI features do constantly, you re-run the analysis and the history shows how the classification evolved.

This is exactly the kind of requirement-to-evidence chain structured test management is built for. In Part 1 of our series we made the case that QA's traceability tooling is where compliance evidence should live. Classification records belong in that same chain: linked to the feature, versioned, and retrievable when an auditor asks why you decided a given model was or wasn't high-risk. We built qtrl so that the link from a requirement to its tests to their results carries an immutable history, which means the classification decision and the testing that backs it up sit in one auditable place instead of scattered across a wiki and a legal folder.

Classify early, because the answer shapes everything else

The risk tier you land in determines whether you need a conformity assessment, a technical file, logging, human oversight, and post-market monitoring, or just a clear "this is an AI" label. Get the classification right first and the rest of your compliance work becomes a known quantity. Skip it, and you're either building too much or shipping exposed.

Once you know which features are high-risk, the next questions are how to test them and who in the organization owns the work. We cover the testing in our guide to testing non-deterministic AI, and the ownership question in who owns EU AI Act compliance.

If you're building AI features for the European market and want the classification, the tests, and the audit trail to live in one place, try qtrl free and see how the traceability holds up.