Is My AI System High-Risk Under the EU AI Act?
Two pathways, eight categories, one question that determines everything.
You’re sitting at your desk, staring at the notes from a meeting that ended twenty minutes ago.
It was supposed to be a routine check-in. The IT team had been building an internal tool — an AI system that would help the lending department assess credit applications faster. Pattern recognition on historical data. Risk scoring. The kind of thing every bank, every lender, every fintech is building right now because someone in the C-suite heard the phrase “AI-driven efficiency” at a conference and came back inspired.
The meeting was fine. Normal. The development lead walked through the architecture. The business team nodded along. Someone asked about the timeline. Someone else asked about integration with the existing workflow. The usual.
And then — somewhere between the system architecture slide and the projected ROI — it hits you.
This scores people.
Not products. Not processes. People. Natural persons applying for a loan, being evaluated by a system that learned its patterns from historical data. A system that would — if you’re reading Article 6 and Annex III correctly — fall squarely into the category of high-risk AI systems under the EU AI Act.
Or would it?
Because the more you think about it, the less certain you become. The system doesn’t make final decisions — it generates a score, and a human loan officer reviews every application. Does that matter? The system uses machine learning, but the model is relatively simple. Does that matter? The IT team called it a “decision-support tool” not an “AI system.” Does that matter?
You pull up the AI Act. Article 6. Annex III. Point 5 — access to essential private services. Sub-point (b) — AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score.
It fits. It clearly fits.
Except — Article 6(3). The exception. The escape hatch that says an Annex III system isn’t high-risk if it doesn’t pose a significant risk of harm, doesn’t materially influence the outcome of decision making. The system is decision-support, not decision-making. A human reviews every output. Maybe you qualify.
But then — the profiling kill-switch. If the system performs profiling of natural persons, the exception doesn’t apply. And a system that evaluates personal data to assess someone’s creditworthiness... that’s profiling. Almost by definition.
You close the laptop. Open it again.
This is the moment. Not the dramatic, cinematic kind — the quiet, Tuesday-afternoon kind. The moment when you — an in-house lawyer at a bank — realize that the AI system your company has been building for eight months might carry obligations nobody on the project team has even heard of. Obligations that include a risk management system, technical documentation, conformity assessment, human oversight requirements, and registration in an EU database — all before the system can be put into service.
And the deadline? Shifting. The standards? Not ready. The Commission guidelines that were supposed to clarify exactly this kind of question? Late.
High-risk AI classification under the EU AI Act. Less straightforward than you’d like. More consequential than most people realize. And — as of right now — missing some of the guidance you’d need to do it with full confidence.
But you still need to do it.
Three Questions to Ask First
Before you even start thinking about high-risk AI systems, you need to make sure to answer to the following three questions regarding your AI system:
First: Is your system an AI system under the EU AI Act?
Not everything that your IT team calls “AI” qualifies.
The legal definition in Article 3(1) has seven elements — the critical one is inference. If the system just executes predefined rules without learning, reasoning, or modeling, it’s probably not an AI system under the AI Act.
If your system isn’t an AI system under the EU AI Act, stop here. Nothing else applies.
Second: Is it within scope?
Even AI systems that fulfill the definition of an AI system under the EU AI Act can still fall outside the Act entirely, if they are:
Military and defense systems used exclusively for national security;
Systems still in R&D before being placed on the market or put into service;
Personal, non-professional use;
Open-source systems — but only if they’re not high-risk, not prohibited, and don’t trigger transparency obligations;
And non-EU systems whose output never reaches the EU.
The exclusions are narrower than they look. “Exclusively” is doing heavy lifting in the military carve-out. “Before market placement” evaporates the moment you run a real-world pilot. And the extraterritorial reach mirrors GDPR — if the output produced by your AI system is used in the Union, you’re in scope regardless of where your servers sit.
Third: Is it prohibited?
Eight categories of AI practices are banned outright under Article 5 — manipulative techniques, exploitation of vulnerabilities, social scoring, certain predictive policing, untargeted facial scraping, emotion recognition in workplaces and education, biometric categorization by sensitive characteristics, and real-time remote biometric identification by law enforcement.
If your system is doing any of these, high-risk classification is irrelevant because the system is banned. Fines are up to €35 million or 7% of global turnover. These have been in effect since February 2025.
If your system passed all three checks — it’s an AI system, it’s in scope, and it’s not prohibited — the next question is the one that determines your compliance obligations for the next several years.
Is it high-risk?
Two Doors Into the Same Room
Most Law Firms’ alerts treat “high-risk” as a single category. It’s not.
Article 6 creates two separate pathways — and which one applies to your system determines not just whether you’re high-risk, but how your conformity assessment works.
Pathway 1: Your AI is inside a regulated product
Article 6(1). If your AI system is a safety component of a product — or is itself a product — covered by the Union harmonization legislation listed in Annex I, and that product requires third-party conformity assessment before being placed on the market, the AI system is high-risk.
Both conditions. Simultaneously. The AI must be a safety component (or the product itself), and the product must require third-party assessment under its own sectoral legislation.
Annex I lists over 30 pieces of existing EU product safety law. The ones that matter most: the Machinery Regulation, the Medical Devices Regulation, the In Vitro Diagnostics Regulation, toy safety, radio equipment, civil aviation, motor vehicles. If you’re building AI into a physical product — a medical diagnostic device, an autonomous braking system, an industrial robot — this is your pathway.
An AI system that controls braking assistance in a vehicle? The vehicle falls under motor vehicle type-approval legislation. The AI is a safety component. Third-party assessment is required. High-risk under Pathway 1.
An AI-powered diagnostic tool in a Class IIa medical device? The Medical Devices Regulation requires third-party conformity assessment for Class IIa and above. High-risk under Pathway 1.
What makes this pathway different: the conformity assessment follows the existing sectoral procedure, with EU AI Act requirements layered in. You don’t run two separate assessments. You integrate obligations under the AI Act into the product safety process you’re already doing — or should be doing.
If your AI system isn’t embedded in a regulated product — which, for most companies reading this article, it won’t be — Pathway 1 doesn’t apply. Move to Pathway 2.
Pathway 2: Your AI operates in a sensitive domain
Article 6(2). AI systems referred to in Annex III are high-risk.
That’s the entire provision. If your system falls within one of the eight areas and specific use cases listed in Annex III — it’s high-risk. No product safety hook needed. No third-party assessment trigger required. The use case alone is enough.
This is where most companies will land. Annex III captures AI systems used in employment, credit scoring, education, law enforcement, migration, critical infrastructure, biometrics, and the administration of justice. Software systems making or influencing decisions about people — not embedded in physical products, but consequential all the same.
The full breakdown of what Annex III actually covers — and where the boundaries are less clear than you’d expect — is coming. But there’s an exception built into Article 6 that deserves attention first. Mostly because it’s narrower than it looks.
The escape hatch that probably doesn’t fit
Article 6(3). The derogation that says an Annex III system isn’t high-risk if it doesn’t pose a significant risk of harm — including by not materially influencing the outcome of decision making.
Four conditions. Any one is enough, but the overarching “no significant risk” requirement must also be met:
The system performs only a narrow procedural task — converting data formats, sorting documents by file type.
The system only improves the result of a previously completed human activity — rewriting text for tone after a human drafted it.
The system only detects decision-making patterns without replacing or influencing human judgment.
Or the system only performs a preparatory task for an assessment — organizing documents that a human decision-maker will review.
Read those carefully. “only”, “narrow”, “previously completed”, “without replacing or influencing”. Every word is a constraint.
And then the kill-switch.
If the system performs profiling of natural persons — automated processing of personal data to evaluate aspects of a person’s life, including work performance, economic situation, health, personal preferences, interests, reliability, behavior, location, or movements — the exception doesn’t apply. The system is high-risk. No conditions, no arguments, no workarounds.
That definition of profiling comes from the GDPR, Article 4(4). It’s broad. And it catches almost every system that companies want to argue out of high-risk classification. A credit scoring tool that evaluates personal financial data to assess reliability? Profiling. An HR analytics system that uses behavioral data to evaluate work performance? Profiling. A system that assesses insurance applicants based on personal characteristics? Profiling.
The company that invokes Article 6(3) derogation must document the assessment in writing before the system goes to market. Register it in the EU database. And be prepared to defend that assessment to market surveillance authorities who can request the documentation at any time. If the authority disagrees — and the burden of proof is on the provider — the company has placed an unregulated high-risk system on the market. Fines for that are up to €15 million or 3% of global turnover.
The practical reality: most companies that think they qualify for this exception probably don’t. The conditions are narrow. The profiling kill-switch is broad. And the downside of being wrong is not a slap on the wrist.
The Eight Areas — What Annex III Actually Covers
Annex III lists eight areas. Within each, there are specific use cases. Not every AI system touching these domains is high-risk — only the listed use cases. But several of those use cases are broader than they first appear.
1. Employment
AI systems used for recruitment, selection, and hiring — placing targeted job ads, screening applications, evaluating candidates. AI systems making decisions about terms of employment — promotion, termination, task allocation based on individual behavior or personal traits. AI systems monitoring and evaluating worker performance and behavior.
This is the broadest and most operationally relevant area for most readers. Any AI that touches hiring, firing, promotion, task allocation, or performance monitoring is likely in scope. And this includes AI features embedded in third-party HR platforms — not just systems you built in-house.
If your HR software vendor added an AI-powered “talent analytics” feature last quarter, and your managers are using it to inform promotion decisions, you may be a deployer of a high-risk AI system. The fact that you didn’t build it doesn’t make it someone else’s problem. Deployers have their own set of obligations under Article 26.
AI resume screening tools. AI-driven performance scoring. Automated task allocation in gig economy platforms. AI scheduling systems that factor in individual behavioral patterns. All potentially high-risk.
2. Essential services
There are four sub-categories worth knowing.
AI systems evaluating creditworthiness or establishing credit scores — high-risk. But with an explicit carve-out: systems used for detecting financial fraud are not high-risk under this provision. If your system does both — evaluates creditworthiness and detects fraud — you need to separate the functions and classify each independently. The fraud detection piece is out. The credit scoring piece is in.
AI systems for risk assessment and pricing for life and health insurance — high-risk. This is narrower than it sounds. It covers life and health insurance specifically. Property insurance, motor insurance, travel insurance — not listed. But before you exhale — if your AI system evaluates personal characteristics of natural persons to price any insurance product, check whether it falls under a different Annex III area or triggers the profiling analysis.
AI systems evaluating and classifying emergency calls, or dispatching and prioritizing emergency first responders — high-risk. This includes triage systems. The AI deciding whether to send an ambulance or a police car is making a high-risk classification.
AI systems determining eligibility for public benefits and services — high-risk. Welfare scoring algorithms. Benefits eligibility tools. The systems that were at the center of the France CAF scandal and the Netherlands childcare benefits disaster — both of which I covered in the prohibited practices article. Those cases involved systems that crossed into prohibited territory. But AI systems that evaluate benefits eligibility without crossing the prohibition line are still high-risk.
3. Education
AI systems determining access to or admission into educational institutions at all levels. AI systems evaluating learning outcomes — when those outcomes steer the learning process or affect the level of education received. AI systems determining what level of education a person can access. AI systems monitoring and detecting prohibited behavior during tests.
AI-powered proctoring software that monitors students during exams — high-risk. An AI system that determines university admissions — high-risk. An adaptive learning platform that adjusts content difficulty — probably not high-risk if it doesn’t affect the student’s grade, certification, or access to education. Probably high-risk if it does.
4. Critical infrastructure
AI systems used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating, or electricity.
“Safety component” is the limiting phrase. An AI that optimizes energy routing in a power grid, as a safety component, is high-risk. An AI that forecasts energy demand for planning purposes — without being a safety component in actual infrastructure operation — may not be. The distinction between operational optimization and safety function isn’t always obvious. If the system’s failure could endanger people or disrupt essential services, treat it as a safety component until you can demonstrate otherwise.
5. Biometrics
Remote biometric identification — face recognition in a crowd, fingerprint matching against a database of unknowns, voice identification against a database. Not one-to-one verification (scanning your face to unlock your phone — that’s out). Biometric categorization by sensitive attributes outside the prohibited contexts. Emotion recognition outside the workplace and education contexts that Article 5 (prohibited practices) already bans.
The prohibited practices article covers what’s banned. Point 1 of Annex III. catches what isn’t banned but is still high-risk.
6. - 8. Law enforcement, migration, and justice
Three areas that primarily affect public authorities and their vendors.
Law enforcement: AI systems assessing victim risk, functioning as polygraphs, evaluating evidence reliability, assessing re-offending risk (not solely based on profiling — that’s prohibited), and profiling during criminal investigations. These are high-risk only when used by or on behalf of law enforcement. The same technology used privately falls under different rules.
Migration and border control: AI polygraphs, risk assessment for visa and entry applicants, travel document verification, and examination of asylum and visa applications.
Justice and democracy: AI systems assisting judicial authorities in researching, interpreting, and applying law. And AI systems intended to influence election outcomes or voting behavior — but not campaign logistics tools.
For most corporate readers, these three areas are relevant primarily if you’re a vendor selling to government agencies. But if you are — every system in these categories carries high-risk obligations, and the conformity assessment for some (particularly biometric systems in law enforcement contexts) requires third-party review by a notified body, not just self-assessment.
The Real Problem — “Intended Purpose” Isn’t What You Think
The entire classification system hinges on intended purpose. And intended purpose under the EU AI Act isn’t just what you wrote in the product documentation.
Article 3(12) defines it as:
‘intended purpose’ means 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 in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.
And then Article 3(13) adds a companion concept:
‘reasonably foreseeable misuse’ means the use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems.
This means your marketing materials inform the classification. Your sales team’s pitch informs the classification. If a sales deck describes the system as a “talent analytics” tool — its intended purpose includes employment decisions, regardless of what the technical documentation calls it.
And if the system is designed for one purpose but foreseeably used for another — the foreseeable use can trigger high-risk classification. A general-purpose analytics platform marketed to HR departments? Even if you technically label it “business intelligence,” the foreseeable use is employment-related decision-making.
The multi-purpose trap
What happens when a single system has multiple use cases — some high-risk, some not? The AI Act doesn’t give you a clean answer.
The practical approach: if the system is capable of and marketed for a high-risk use case, it’s high-risk — even if it also does non-high-risk things. You can’t escape classification by bundling a high-risk feature into a larger product with mostly minimal-risk functions.
But you might be able to architect the system so the high-risk use case is clearly separated — a distinct module or service. That’s an architectural decision with legal consequences, and it needs to be made early. Not after the system is built. Not after the auditor asks.
The deployer who became a provider
Once you know a system is high-risk, the next question is: are you the provider or the deployer? The distinction determines which set of obligations you carry — and the line between the two is less stable than most companies assume.
Under Article 25, a deployer can become a provider by (a) rebranding a system, (b) making a substantial modification, or — the one that catches people — (c) changing the intended purpose. A company buys a general-purpose AI model and uses it for credit scoring. The model provider never intended that use. But the deployer just changed the intended purpose — and stepped into the provider’s shoes with all the heavier obligations that come with them.
Classification doesn’t end at “high-risk.”
It continues to “high-risk — and in what role?”
What Happens When Your AI System Is High-Risk
Classification as high-risk is where the compliance work starts — and the obligations are the reason the classification matters so much. The deep dive on each obligation is a future article. But you need the overview now.
A risk management system — not a one-time assessment but a continuous, iterative process spanning the system’s lifecycle.
Data governance requirements — your training data needs to meet quality criteria, and you need to demonstrate it.
Technical documentation — comprehensive, drawn up before market placement, covering everything from system design to performance metrics.
Automatic logging — an audit trail of what the system did and when.
Transparency obligations toward deployers (if you are the provider) — enough information that the humans using the system can actually interpret its output.
Human oversight — the system must be designed so humans can effectively monitor it, override it, and shut it down.
Accuracy, robustness, and cybersecurity requirements throughout the lifecycle.
Conformity assessment — before the system reaches the market. For most Annex III systems, that’s a self-assessment. For some — particularly biometric identification systems — it requires a third-party notified body.
Then CE marking.
Then EU database registration.
The penalty for non-compliance with high-risk requirements is up to €15 million or 3% of global turnover. Not as high as the prohibited practices ceiling — but not the kind of number that disappears in a quarterly business report.
The Timeline Problem
If you’re reading this and thinking “when do I need to have all of this done?” — the honest answer is: it depends on which version of the timeline you’re following.
The original deadline for high-risk obligations on Annex III systems was 2 August 2026. That’s the date in the AI Act as published.
Then reality intervened. The technical standards that companies need — the benchmarks that tell you what “compliant” actually looks like for risk management, data governance, documentation, and the rest — weren’t ready. CEN and CENELEC, the European standardization bodies tasked with developing them, missed their fall 2025 deadline. The Commission guidelines on high-risk AI systems, which were supposed to include practical examples of high-risk and non-high-risk systems, were due by 2 February 2026. The Commission missed that deadline too.
So in November 2025, the Commission proposed the Digital Omnibus on AI — a targeted amendment pushing the high-risk deadline to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product-embedded systems. The European Parliament’s IMCO and LIBE committees adopted their joint report in March 2026. Trilogue negotiations between Parliament, Council, and Commission are underway.
As of May 2026, we are still waiting for the final Commission guidelines on high-risk AI system classification. The guidelines that were supposed to include the very examples companies need to resolve edge cases like the one you were staring at after that meeting — the ones that would clarify whether a credit-scoring decision-support tool with human oversight is high-risk or not. Those guidelines don’t exist yet.
Which leaves companies in an uncomfortable position. The classification is already consequential — even before the full high-risk obligations kick in — because you need time to build the compliance infrastructure. Risk management systems, documentation, data governance processes — these aren’t things you implement in a quarter. If you wait for the guidelines and the guidelines arrive six months before the deadline, you’re already behind.
The prudent approach: classify now, based on the text of Article 6 and Annex III. Build the compliance structure. And be prepared to adjust when the guidelines finally arrive.
The Classification Exercise — What to Do
You’ve read the law. You understand the two pathways, the eight areas, the escape hatch, the profiling kill-switch, the intended purpose trap. Now you need to turn that into something your company can act on.
Start with an inventory. Every AI system your company builds, deploys, or procures. Not just the ones your IT team calls “AI” — the ones that meet the Article 3(1) definition. The vendor tools with AI features embedded. The model your data science team fine-tuned. The chatbot someone in marketing set up without telling anyone. You can’t classify what you haven’t mapped.
Run each system through the decision tree. Is it in scope? Is it prohibited? Does it fall under Annex I (product safety pathway) or Annex III (standalone pathway)? If Annex III — which area and which specific use case? Be precise. “It’s an HR tool” isn’t a classification. “It screens job applications using machine learning, which falls under Annex III, Point 4(a) — recruitment and selection” is.
Don’t skip the intended purpose analysis. Pull the marketing materials. The sales deck. The vendor’s product description. The internal documentation about how the system is actually used — not how it was originally purchased. If there’s a gap between the vendor’s intended purpose and your actual use, that gap is where Article 25 (and your role as a provider or deployer) lives. A system bought for analytics and used for credit decisions isn’t an analytics tool anymore.
Assess Article 6(3) exceptions honestly — and document it either way. If you think the escape hatch applies, write down why. Which of the four conditions is met? Does the system profile natural persons? (If it evaluates personal data to assess any aspect of a person’s life — it almost certainly does.) Does it materially influence decision-making? Be honest. “A human reviews the output” isn’t enough if the human rubber-stamps the AI’s recommendation 95% of the time. If Article 6(3) doesn’t apply — document that too. The assessment matters regardless of the conclusion.
Figure out your role. For every high-risk system — are you the provider or the deployer? Did you build it? Did you modify it? Did you retrain it on your own data? Did you change what it’s used for? If you’re unsure, read the provider vs. deployer analysis before answering. The obligations are different enough that getting this wrong changes everything.
Start the compliance build now. If you have systems that are clearly high-risk — and after going through Annex III, most companies will find at least one — don’t wait for the guidelines, or the final Digital Omnibus timeline. Risk management systems, technical documentation, data governance processes, human oversight design — these take months to build properly. Starting late is a choice. It’s just not a good one.
Put legal and engineers in the same room. This cannot be a legal-only exercise. Legal can’t assess whether a system falls under Annex III without understanding what the system actually does. Engineers can’t assess whether “intended purpose” creates a classification risk without understanding what Article 3(12) requires. The classification has to be joint — and it has to be documented.
Back to You
You’re still at your desk. The meeting notes are still open. The system architecture diagram is still on your second screen.
You know three things now that you didn’t know an hour ago:
The system almost certainly falls within Annex III, Point 5(b) — creditworthiness evaluation.
The Article 6(3) escape hatch almost certainly doesn’t apply — the profiling kill-switch alone closes that door.
And the fact that a human reviews every output doesn’t make the system not high-risk. It means the human oversight requirement under Article 14 might be partially met. It doesn’t change the classification.
You also know that nobody on the project team — not the IT lead, not the business sponsor, not the procurement team that selected the underlying model — has considered any of this.
Eight months of development. Budget approved. Timeline set. And the compliance question that determines whether this system can legally operate in the EU is being asked for the first time on a Tuesday afternoon by the one person in the room who happened to have read Article 6.
You open a new email. Subject line: “AI Act classification — we need to talk about the credit scoring tool.”
Better late than never.