Is My AI System High-Risk Under the EU AI Act?

Your AI system is high-risk under the EU AI Act if it falls into one of two buckets: it is listed as an Annex III use case (such as employment, creditworthiness, biometrics, critical infrastructure, education, or law enforcement), or it is a safety component of a product already covered by EU product-safety law under Article 6. Most business software is not high-risk — many tools land in the limited-risk transparency tier or the minimal-risk tier with no extra obligations. This guide is general information, not legal advice; for any borderline case, get a formal classification opinion.

The four risk tiers in plain terms

The EU AI Act sorts every AI system into one of four tiers based on the harm it could cause, not the technology it uses. The tier decides your obligations — so getting the classification right is the first thing to settle, before you spend a euro on compliance work you may not need.

• Unacceptable risk (banned). A short list of practices that are simply prohibited in the EU: social scoring by public authorities, manipulative or exploitative systems that distort behaviour, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and schools, and most real-time remote biometric identification in public spaces. If your system does one of these, the question is not how to comply — it is to stop or redesign.
• High risk (heavily regulated, but allowed). Systems that can materially affect health, safety, or fundamental rights. These are permitted but carry the heaviest obligations: risk management, data governance, technical documentation, human oversight, logging, and a conformity assessment before you go to market. This is the tier this guide helps you test for.
• Limited risk (transparency only). Systems that interact with people or generate content, where the main duty is to tell people they are dealing with AI. Chatbots, AI-generated content, and deepfakes sit here under Article 50.
• Minimal risk (no extra obligations). Everything else — the large majority of AI in business use. Spam filters, recommendation engines, inventory forecasting, an internal meeting-summariser. You can build and run these freely; the Act adds nothing beyond good practice.

The practical point: high-risk is a narrow, defined category, not a vibe. You do not become high-risk because your system is powerful or because it uses a large language model. You become high-risk because you match a specific legal test — and there are exactly two routes into it.

Route A — the Annex III use-case list

The first route is the most common. Annex III lists specific high-risk use cases by purpose. If your system is *intended to be used* for one of these, it is high-risk — regardless of how sophisticated or simple the underlying model is. Read the list against what your system actually decides or influences:

• Biometrics — remote biometric identification, biometric categorisation by sensitive attributes, and emotion recognition (outside the contexts that are outright banned).
• Critical infrastructure — AI used as a safety component in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating, and electricity. This is where a lot of energy-sector AI lands.
• Education and vocational training — systems that decide admission, evaluate learning outcomes, assign people to programmes, or monitor and detect prohibited behaviour during exams.
• Employment, worker management, and access to self-employment — recruitment and selection (including CV screening and candidate ranking), and decisions on promotion, termination, task allocation, or monitoring and evaluating performance.
• Access to essential private and public services — eligibility for public benefits, creditworthiness and credit scoring (with a narrow carve-out for detecting financial fraud), and risk assessment and pricing in life and health insurance.
• Law enforcement — risk assessments of individuals, polygraph-style tools, evidence reliability evaluation, and profiling in the course of investigations.
• Migration, asylum, and border control — risk assessments, application examination, and detection systems at borders.
• Administration of justice and democratic processes — systems assisting judicial authorities in researching and interpreting facts and the law, and certain tools that could influence elections.

There is one important escape hatch. Annex III includes a filter: if your system performs a *narrow procedural task*, improves the result of a previously completed human activity, detects decision-making patterns without replacing human judgement, or only does preparatory work for an assessment, it may not be high-risk even though it touches a listed area. But if the system profiles individuals, the exception does not apply — you are high-risk. Do not lean on this filter casually; document your reasoning, because you have to be able to defend it.

If Annex III does not match your use case, move to Route B.

Route B — the Article 6 'safety component of a regulated product' route

The second route catches AI embedded in physical or regulated products. Under Article 6(1), your AI system is high-risk if both of these are true: it is intended to be used as a safety component of a product (or is itself such a product) covered by the EU harmonisation legislation listed in Annex I, *and* that product must undergo a third-party conformity assessment before it can be placed on the market.

Annex I covers a long list of familiar product-safety regimes: machinery, medical devices and in-vitro diagnostics, toys, lifts, radio equipment, civil aviation, marine equipment, vehicles, and more. The logic is simple — if a product already needs independent safety certification, and AI now performs a safety function inside it, that AI inherits high-risk status.

Concrete examples make it click. An AI vision system that decides when an industrial press is safe to actuate is a safety component of machinery. AI that interprets diagnostic images inside a medical device is a safety component of a regulated medical device. AI that controls braking behaviour in a vehicle is a safety component of a vehicle. In each case the product was already regulated; the AI does not escape that.

Most office and back-office software never touches Route B. It matters mainly for manufacturers, medtech, automotive, robotics, and industrial-equipment builders — exactly the kind of work where a computer vision model is doing something physical and consequential. If you build for manufacturing, test this route carefully.

Limited risk and minimal risk — where most systems actually land

If you clear both routes without a match, you are not high-risk. You then check whether any transparency duties apply under Article 50 — the limited-risk tier.

Article 50 is about honesty, not safety. If your system interacts directly with people, you must make clear they are talking to an AI unless it is obvious. If it generates synthetic audio, image, video, or text, that output must be machine-readable and marked as AI-generated. Deepfakes and AI-generated text published to inform the public on matters of public interest must be disclosed as such. These are real obligations, but they are light — a clear notice and proper content labelling, not a conformity assessment. We cover them in depth in our guide to Article 50 transparency.

Everything that is neither high-risk nor caught by Article 50 is minimal risk, and the Act imposes no specific obligations at all. You should still follow good engineering and data-protection practice — GDPR has not gone anywhere — but the AI Act itself stays out of your way.

A useful rule of thumb: classification is a *waterfall*. Test prohibited first, then high-risk (Routes A and B), then Article 50 transparency, then minimal. Stop at the first tier you match. Run it per system and per intended use — the same model can be minimal in one product and high-risk in another, because the use case is what the Act regulates, not the algorithm.

Three worked examples

Abstract tiers are easier to apply against real systems. Here is how the waterfall plays out for three common builds.

• CV-screening and candidate-ranking tool → high-risk. It is intended to be used for recruitment and selection, which is an explicit Annex III employment use case. It profiles and ranks individuals, so the narrow-task exception does not save it. This system needs the full high-risk programme before deployment.
• Marketing chatbot on your website → limited risk. It is not in Annex III and is not a safety component, so it is not high-risk. But it interacts directly with people, so Article 50 applies: tell visitors they are chatting with an AI. That is the whole obligation.
• Internal meeting-summariser → minimal risk. It transcribes and summarises your own team's calls. No Annex III use case, no regulated product, no public-facing interaction or synthetic-media publication. It carries no AI Act obligations beyond your usual data-protection housekeeping.

Notice how the *purpose and context* decide the tier every time, not the cleverness of the model. The chatbot and the CV tool might even share an underlying language model — they land in different tiers because of what they are used to do.

What changes the moment you are high-risk

If your classification lands on high-risk, a defined set of obligations switches on. You do not have to design these from scratch — the Act spells them out, and a provider can build to them deliberately. The headline duties:

• Risk management system (Article 9) — a continuous, documented process to identify and mitigate risks to health, safety, and fundamental rights across the system's lifecycle.
• Data and data governance (Article 10) — training, validation, and test datasets that are relevant, representative, and examined for bias, with documented data provenance.
• Technical documentation (Article 11) — a complete file describing the system, its design, and its performance, ready for authorities before it goes to market and kept current.
• Record-keeping / logging (Article 12) — automatic logging of events over the system's lifetime so behaviour can be traced and incidents reconstructed.
• Human oversight (Article 14) — the system must be designed so a human can understand its output, intervene, and override it; oversight cannot be a token checkbox.
• Accuracy, robustness, and cybersecurity (Article 15), plus a conformity assessment and CE marking before placing the system on the market, registration in the EU database, and post-market monitoring.

That is the build-side detail, and it is substantial. We have written it up step by step in our EU AI Act compliance guide and reduced it to a working AI Act compliance checklist so your engineering and compliance teams have one reference. This post stays on the *classification* question — deciding whether you are in scope at all.

The phased timeline you are working against

The EU AI Act entered into force on 1 August 2024 and applies in phases, so different obligations bite on different dates. Knowing where you sit on this timeline tells you how much runway you actually have.

• 2 February 2025 — the bans on unacceptable-risk practices took effect, along with AI-literacy obligations for staff who deploy AI.
• 2 August 2025 — rules for general-purpose AI models and the governance structure (the AI Office and national authorities) began to apply.
• 2 August 2026 — the bulk of the high-risk obligations under Annex III, and the Article 50 transparency rules, become applicable. This is the date most organisations are planning toward.
• 2 August 2027 — the extended deadline for high-risk systems that fall under Route B (safety components of products already regulated under Annex I).

The takeaway is not to panic about a single cliff-edge but to know which date applies to *your* classification. A high-risk Annex III system needs to be ready well before August 2026; that is not a lot of time to build a risk-management system, clean your data governance, and pass a conformity assessment from a standing start.

What to do next — inventory, then classify

The practical first move is not legal analysis — it is an honest inventory. Most organisations underestimate how many AI systems they actually run, because procurement, marketing, HR, and individual teams all bought or built tools independently.

• Inventory every AI system you build, buy, or embed — including AI features inside SaaS you already pay for. Note the intended purpose and who is affected by each one.
• Classify each one through the waterfall — prohibited, then high-risk via Route A and Route B, then Article 50, then minimal. Write down the reasoning, especially where you rely on the Annex III narrow-task exception.
• Confirm your role — are you the *provider* (you develop or rebrand the system) or the *deployer* (you use it under your own authority)? Obligations differ, and a deployer who substantially modifies a system can become a provider.
• Triage by deadline — concentrate first on anything that classifies as high-risk under Annex III, given the August 2026 date.

For a structured run-through you can hand to a non-specialist, our AI Act compliance checklist turns this into a worksheet, and the broader EU AI Act compliance guide sets the Dutch and EU context. If you would rather not do the first pass alone, this readiness assessment is the core of a Crux Digits AI Audit & Strategy engagement — a fixed-scope, fixed-price (EUR 2,500) piece of work that inventories your systems, classifies them, and tells you plainly which ones are in scope and what each needs. You can read how we work on our AI consulting page or just get in touch for a short, no-obligation conversation.

One honest caveat to close on: this article is general information, not legal advice. The classification routes are well defined, but borderline cases — especially around the Annex III exception and the provider/deployer line — turn on specifics. For anything that could be high-risk, get a written classification opinion you can rely on.

Frequently asked questions