High-Risk AI Systems Under the EU AI Act: Is Your AI Tool Affected?
One of the most consequential determinations an organization must make under the EU AI Act is this: does the AI system we are building or using qualify as high-risk?
The answer determines whether you face a minimal compliance burden or a rigorous certification regime involving risk management systems, technical documentation, mandatory logging, and in some cases third-party conformity assessments. Getting this classification wrong — in either direction — carries significant consequences.
This article walks through the classification logic step by step, explains each Annex III domain in operational detail, and provides a structured self-assessment checklist you can apply to any AI system in your portfolio.
🛡️ AI Act Ready by Design Knowlee implements audit-trail-by-default, human-in-the-loop on high-risk processes, and risk-classified job metadata at runtime — not bolted on. See the 25-point High-Risk AI Systems Checklist and the AI Act Compliance Software Guide for the full operational framework.
Why Classification Is the Starting Point for Everything
The EU AI Act's compliance obligations are not uniform. They scale with risk. A company deploying a chatbot for internal HR questions faces transparency obligations under Article 50. A company deploying an AI system that influences credit decisions faces the full high-risk regime under Articles 9–17 plus deployer obligations under Article 26.
The high-risk classification is therefore the inflection point that determines your compliance workload. The Act creates two pathways into high-risk classification.
Two Routes to High-Risk Classification
Route 1: AI as a Safety Component in a Regulated Product (Article 6(1))
If your AI system is itself a safety component of a product that is already subject to EU harmonization legislation listed in Annex I of the Act — and that product requires a third-party conformity assessment under that legislation — the AI component is automatically classified as high-risk.
The Annex I product categories include:
- Machinery (Machinery Regulation (EU) 2023/1230)
- Medical devices (Regulation (EU) 2017/745)
- In vitro diagnostic medical devices (Regulation (EU) 2017/746)
- Aviation systems
- Motor vehicles and their trailers
- Agricultural machinery
- Toys, lifts, explosives, radio equipment
Practical example: An AI-based diagnostic tool integrated into a Class IIb medical device is automatically high-risk because the underlying device requires notified body assessment.
Route 2: Annex III Application Domains (Article 6(2))
AI systems listed in Annex III are high-risk regardless of whether they are part of a regulated product. This is the route that affects most enterprise software companies. We examine each domain in detail below.
Important nuance — Article 6(3): Even if an AI system falls within an Annex III domain, it is not classified as high-risk if it does not pose a significant risk of harm to the health, safety, or fundamental rights of natural persons. The burden of demonstrating this exception is on the provider, and the Commission has published guidelines on the criteria. This exception is narrow and fact-specific.
Deep Dive: All Eight Annex III High-Risk Domains
Domain 1: Biometric Identification and Categorization of Natural Persons
What is covered: Remote biometric identification systems (systems that identify individuals at a distance by comparing against a database); AI systems used to make biometric categorizations (inferring or sorting people by sensitive attributes).
What is NOT covered under this domain: Biometric verification systems that confirm whether a person is who they claim to be (one-to-one matching, e.g., Face ID on a phone) — these are not Annex III high-risk systems unless they fall elsewhere.
Enterprise relevance: Employee attendance systems using facial recognition, visitor management systems with biometric enrollment, HR tools that analyze facial expressions during interviews.
Compliance trigger questions:
- Does your system match individuals against a database of stored biometric data?
- Does it operate on video feeds or images from publicly accessible areas?
- Does it categorize people based on biometric data in a way that infers sensitive characteristics?
Domain 2: Critical Infrastructure Safety Components
What is covered: AI systems intended to be used as safety components in the management and operation of road traffic, water supply, gas, heating, and electricity supply.
Enterprise relevance: Energy management platforms, smart grid controllers, water treatment optimization systems, traffic management systems.
Compliance trigger questions:
- Does your system make or recommend decisions that could directly affect the safe operation of energy, water, or traffic infrastructure?
- Is system failure likely to result in physical harm or service interruption at infrastructure scale?
Domain 3: Education and Vocational Training
What is covered: AI systems used to determine access to or assign persons to educational and vocational training institutions; to evaluate learning outcomes; to assess the appropriate level of education; to monitor and detect prohibited behavior of students during tests.
Enterprise relevance: Admissions screening tools, automated grading and assessment systems, proctoring software, learning analytics platforms that influence progression decisions.
Compliance trigger questions:
- Does your system produce outputs that directly influence whether a student is admitted, advanced, or rejected?
- Does it assess or score student performance in a way that affects their educational trajectory?
- Does it monitor students during examinations?
Domain 4: Employment, Worker Management, and Access to Self-Employment
What is covered: AI systems used for recruitment or selection of natural persons, particularly to filter job applications and to evaluate candidates; to make decisions affecting terms and conditions of work, including promotions, termination, performance assessment, and task allocation.
Enterprise relevance: This is arguably the highest-relevance domain for enterprise software companies. ATS (Applicant Tracking Systems) with AI screening, performance management platforms that generate ratings, workforce optimization tools that allocate tasks, HR analytics that inform termination decisions.
Compliance trigger questions:
- Does your AI system rank, filter, or score job applications?
- Does it generate performance scores or ratings that managers use to make promotion or termination decisions?
- Does it allocate work or monitor worker productivity in a way that generates consequences for workers?
- Does it influence pay decisions?
Domain 5: Access to Essential Private and Public Services and Benefits
What is covered: AI systems used to evaluate the creditworthiness of natural persons or to establish their credit score; to assess and price risk in life and health insurance; to evaluate eligibility for public assistance benefits; to assess emergency service dispatch priority.
Enterprise relevance: Credit scoring models, insurance underwriting AI, lending decision tools, benefits administration platforms.
Compliance trigger questions:
- Does your system produce a score or recommendation that influences whether a person receives credit, insurance coverage, or benefits?
- Does it assess risk in a way that affects pricing or access to financial or insurance products?
Domain 6: Law Enforcement
What is covered: AI systems intended to be used by law enforcement authorities to assess the risk of an individual offending or reoffending; to be used as polygraphs; to evaluate the reliability of evidence in criminal proceedings; for profiling of natural persons in the course of detection, investigation, or prosecution of criminal offences; to predict the occurrence or reoccurrence of crime based on profiling of persons or areas.
Enterprise relevance: Primarily relevant to legal tech companies, public sector vendors, and criminal justice software providers. Commercial enterprises rarely operate in this domain directly.
Domain 7: Migration, Asylum, and Border Control
What is covered: AI systems intended for use by competent authorities in examining applications for asylum, visa, and residence permits; to assess associated risks; to verify the authenticity of travel documents; used in migration control contexts.
Enterprise relevance: Primarily government and public sector. However, any vendor selling technology to border agencies, immigration authorities, or asylum processing bodies must assess this domain carefully.
Domain 8: Administration of Justice and Democratic Processes
What is covered: AI systems intended to be used by judicial authorities to research and interpret facts and the law, and to apply the law to a concrete set of facts; AI systems used to influence the outcome of elections or referendums, including targeted political advertising.
Enterprise relevance: Legal research AI (when used by courts), judicial decision support tools, and any political advertising platform using AI for targeting. For commercial enterprise software, this domain is typically not relevant unless selling to courts or election campaigns.
Self-Assessment Checklist: Is Your AI System High-Risk?
Use this checklist to structure your internal assessment. Document your answers — they form the basis of your compliance reasoning.
Step 1: Regulated Product Safety Component Check
- Does the AI system form part of a product covered by EU harmonization legislation listed in Annex I of the EU AI Act?
- Does that product require third-party conformity assessment under the applicable legislation?
If both answers are YES: Your AI system is high-risk under Article 6(1). Proceed to compliance requirements.
If NO to either: Proceed to Step 2.
Step 2: Annex III Domain Screening
For each domain below, answer: does your AI system's primary or significant use fall within this domain?
- Biometrics: Does it perform remote identification or categorization of individuals using biometric data?
- Critical Infrastructure: Is it a safety component in water, energy, or traffic systems?
- Education: Does it influence admission, assessment, or monitoring of students?
- Employment: Does it screen, rank, score, or influence decisions about workers or candidates?
- Essential Services: Does it influence access to credit, insurance, benefits, or emergency services?
- Law Enforcement: Is it sold to or used by police, prosecutors, or criminal justice bodies?
- Migration/Border: Is it sold to or used by immigration or border control authorities?
- Justice/Democracy: Is it used by courts, or does it target voters with AI-generated political content?
If any answer is YES: Proceed to Step 3 before concluding classification.
Step 3: Article 6(3) Exception Assessment
Even if your system falls within an Annex III domain, it may not be high-risk if all of the following are true:
- The AI system is intended to perform a narrow procedural task.
- Its output does not directly influence decisions with significant impact on persons.
- A human reviews and interprets the output before any consequential decision is made.
- The risks to fundamental rights are demonstrably low based on the use context.
Critical warning: This exception is narrow. The burden of proof rests with the provider. Regulators will scrutinize self-declarations. If there is material doubt, treat the system as high-risk.
Step 4: Document Your Classification Decision
Regardless of outcome, document:
- Which domains were assessed and why
- The conclusion reached and the legal basis
- Any Article 6(3) exception relied upon and the evidence supporting it
- Who reviewed and approved the classification decision
- Date of assessment and planned review date
What High-Risk Classification Means for Your Compliance Program
If your system is classified as high-risk, you face a specific set of obligations. Here is the provider obligation stack in summary:
| Obligation | Legal Basis | Summary |
|---|---|---|
| Risk management system | Article 9 | Continuous, documented, lifecycle-spanning |
| Data governance | Article 10 | Training/validation/test data quality and documentation |
| Technical documentation | Article 11 + Annex IV | Comprehensive pre-market documentation |
| Automatic logging | Article 12 | Immutable event logs for traceability |
| Transparency to deployers | Article 13 | Instructions for use covering all material system properties |
| Human oversight design | Article 14 | System must be technically capable of human intervention |
| Accuracy and robustness | Article 15 | Declared performance metrics, cybersecurity |
| Conformity assessment | Article 43 | Self-assessment or third-party (depending on domain) |
| EU database registration | Article 49 | Before market placement |
| Post-market monitoring | Article 72 | Continuous monitoring plan |
For deployers of high-risk systems:
| Obligation | Legal Basis | Summary |
|---|---|---|
| Use per instructions | Article 26(1) | Follow provider's use instructions strictly |
| Human oversight assignment | Article 26(2) | Qualified persons assigned to oversight |
| Data quality for own inputs | Article 26(5) | Where deployer controls input data |
| FRIA (where applicable) | Article 27 | Fundamental rights impact assessment |
| Registration | Article 49(3) | Deploy uses EU database entries |
Conformity Assessment: Self-Declaration vs. Third-Party
Not all high-risk AI systems require third-party assessment. The Act distinguishes:
Third-party assessment required: AI systems used for remote biometric identification (with exceptions), and AI systems that are safety components of products that already require third-party conformity assessment.
Self-assessment allowed: Most other Annex III high-risk systems — the provider conducts their own conformity assessment against the requirements, documents it, and affixes the CE marking.
Self-assessment does not mean minimal scrutiny. It means the provider bears full responsibility for ensuring compliance. Market surveillance authorities can and will audit self-assessed systems.
How Knowlee Addresses High-Risk AI Compliance
For organizations deploying AI tools in employment, customer service, or data-driven decision-making, Knowlee's architecture supports the key compliance requirements:
Audit-trail logging: Every AI inference, input, and output in Knowlee is logged automatically and immutably. This directly supports Article 12 logging obligations that apply to high-risk systems.
Human oversight controls: Knowlee's workflow engine includes configurable approval gates — consequential outputs require human review before execution. This supports Article 14 human oversight requirements.
Explainability layer: Knowlee surfaces reasoning chains alongside outputs, enabling compliance teams to demonstrate that decisions are not opaque black-box outcomes.
Data provenance tracking: Knowlee maintains metadata about the sources and quality of data used in AI processes, supporting Article 10 data governance documentation requirements.
[link:/glossary/ai-act] | [link:/glossary/trustworthy-ai] | [link:/glossary/iso-42001]
FAQ: High-Risk AI Classification
Q: My AI tool only assists humans — it never makes final decisions. Is it still high-risk?
Assistance does not automatically exclude a system from high-risk classification. The Act covers systems whose outputs influence decisions, even when a human makes the final call. If the AI output materially shapes the human's decision (e.g., a ranked shortlist that the recruiter follows without meaningful independent review), it may still be high-risk. The quality of human oversight matters — a rubber-stamp review does not satisfy the Article 14 requirements.
Q: We are a startup using a third-party AI API. Are we considered a provider?
If you integrate third-party AI capabilities into your own product and that product is made available to others, you are likely acting as a provider of a new AI system — even if the underlying model is third-party. The provider classification is not about who built the model; it is about who places the integrated system on the market. You should conduct your own classification assessment.
Q: Can an AI system change its risk classification over time?
Yes. If you significantly modify a high-risk AI system, or if the Commission amends Annex III to add new domains, your system's classification can change. Providers must monitor for changes in the regulatory landscape and reassess their systems when modifications occur. Article 6(3) also requires reassessment when context of use changes.
Q: What is the difference between biometric identification and biometric verification?
Biometric identification (one-to-many matching) identifies an unknown individual from a database — high-risk. Biometric verification (one-to-one matching) confirms a claimed identity — not automatically high-risk under Annex III Domain 1. However, verification systems may still be high-risk if they fall under another domain or under the Article 6(1) product safety pathway.
Q: Is our AI recruitment tool definitely high-risk even if it only filters CVs?
CV-filtering AI that determines which candidates advance to the next stage falls squarely within Annex III, Domain 4. The exception under Article 6(3) is available only if the tool performs a genuinely narrow procedural task with minimal impact on individuals — unlikely for a tool that gates access to employment opportunities. The safe assumption is that recruitment screening AI is high-risk and should be treated accordingly until legal counsel confirms otherwise.