What makes an AI system high-risk?
Article 6 has two separate high-risk routes. Article 6(1) covers an AI system that is itself an Annex I product or is intended as a safety component of one, where the relevant product must undergo third-party conformity assessment under that product legislation. Article 6(2) covers an AI system whose intended purpose matches a use case listed in Annex III. A broad sector label or serious impact alone does not settle classification.
Assess each route independently:
Annex I route: AI systems that serve as safety components of products already regulated under Union harmonisation law, or are themselves such products, and require third-party conformity assessment. Under the consolidated AI Act, the relevant Article 6(1)/Annex I high-risk provisions apply from 2 August 2028.
Annex III route: An AI system referred to in a listed Annex III use case is high-risk unless the narrow Article 6(3) derogation applies. The area heading alone is not enough; assess the exact intended purpose. The relevant high-risk provisions for Article 6(2)/Annex III systems apply from 2 December 2027.
Article 6(3) applies only to an Annex III system that does not pose a significant risk of harm and meets at least one listed task condition. Profiling of natural persons prevents reliance on that derogation for an Annex III system. The provider must document an Article 6(3) conclusion under Article 6(4) and register under Article 49(2). A deployer may request that record, compare it with actual use, retain evidence and escalate discrepancies, but its internal note does not replace the provider's assessment. Use the Article 6(3) Filter Decision Record to structure that review.
The Material Influence Evaluator is a subordinate evidence aid for one part of Article 6(3). A lower-influence result does not establish that a system is non-high-risk.
The Digital Omnibus is now Regulation (EU) 2026/1744. Under the consolidated law, the relevant Article 6(2)/Annex III high-risk provisions apply from 2 December 2027. For the full picture across all risk levels, see our complete EU AI Act compliance guide.
Annex III: the 8 high-risk use case areas explained
Under the EU AI Act, a deployer is any natural or legal person that uses an AI system under its authority, except where it is used in a personal non-professional activity (Article 3(4)). Annex III is organised under eight area headings, but classification depends on whether the system's intended purpose matches a use case actually listed under the relevant heading.
Use the summaries below to identify candidates for closer review, not to classify every system in a sector.
Area 1: Biometric identification and categorisation
Listed uses include certain remote biometric identification, biometric categorisation based on sensitive or protected attributes, and emotion recognition, subject to Article 5 prohibitions and the precise Annex III conditions and exclusions. Biometric functionality alone does not place every system in this area. Use the Biometric Identity Validator to structure an initial review.
Area 2: Critical infrastructure management
Point 2 covers AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. A system used in the sector is not enough unless its intended purpose matches the listed safety-component use. Use the IIoT Safety Component Validator for an initial operational review.
Area 3: Education and vocational training
Listed uses include determining access or admission, assigning people to institutions, evaluating learning outcomes for specified purposes, assessing the appropriate level of education, and monitoring or detecting prohibited behaviour during tests. An education label alone is not determinative. The EdTech Assessment Validator can support the intended-purpose review.
Area 4: Employment, workers management, and self-employment access
Listed uses include recruitment or selection, such as targeted job advertising, analysing or filtering applications and evaluating candidates, as well as specified decisions about work relationships, task allocation, monitoring and performance. Assess the feature's intended purpose rather than treating every HR system as high-risk. The Promotion & Termination Validator can support that review.
Area 5: Essential private and public services
5(a) — Public assistance: specified systems used by or on behalf of public authorities to evaluate eligibility for essential public assistance benefits and services. 5(b) — Creditworthiness: systems intended to evaluate a natural person's creditworthiness or establish a credit score, excluding systems used to detect financial fraud. 5(c) — Insurance: systems intended for risk assessment and pricing for natural persons in life and health insurance. 5(d) — Emergency services: specified call classification, dispatch prioritisation and emergency healthcare triage systems. Use the Fraud vs Credit Scoring Delimiter for financial services and the Insurance Underwriting Assessor for insurance.
Area 6: Law enforcement
Polygraphs, deception detection, evidence reliability assessment, crime prediction, and profiling during investigations. Most SMEs won't deploy these — included for completeness.
Area 7: Migration, asylum, and border control
Risk assessment tools, polygraphs, document authenticity verification, and residence permit evaluation. Again, primarily a government and large-agency concern.
Area 8: Administration of justice and democratic processes
AI assisting judicial fact-finding, law application, and dispute resolution, plus AI systems that could influence elections. Narrow applicability for most commercial deployers.
⚖ Which Annex III area applies to you?
Not sure which Article 6 route applies? Start with the High-Risk Classification Router →
For the full checklist of Annex III systems with examples, see our Annex III high-risk AI systems checklist.
Provider vs deployer: which obligations are yours?
The EU AI Act assigns different obligations to providers and deployers. The same organisation can hold more than one role, including where Article 25 causes a distributor, importer, deployer or other third party to assume provider obligations.
The provider bears the heaviest burden: risk management system, data governance, technical documentation, logging design, transparency to users, human oversight design, accuracy and robustness testing, conformity assessment, CE marking, applicable EU database registration, quality management, and post-market monitoring.
The deployer owns operational accountability under Article 26: use the system according to provider instructions, implement human oversight, monitor operations, retain logs for at least 6 months, conduct a FRIA where required (Article 27), inform employees about workplace AI, ensure input data quality, and take proportionate Article 4 AI-literacy measures. Article 4 applied from 2 February 2025 and was amended from 27 July 2026.
⚠ The "accidental provider" trap (Article 25)
You may assume provider obligations under Article 25 if you put your name or trademark on a high-risk system, make a substantial modification, or change the intended purpose of a system so that it becomes high-risk. Configuration or fine-tuning requires a fact-specific assessment; it is not automatically a substantial modification. Review whether your role may have changed →
Your vendor being "EU AI Act compliant" does not make you compliant.
A SOC 2-compliant SaaS vendor doesn't make you SOC 2 compliant. Same principle here. The vendor provides components and documentation. You still own your operational controls, oversight, monitoring, incident handling, and evidence.
Use the Deployer Obligation Self-Assessment to map your gaps, and the Article 26 Operations Scorer to benchmark your readiness.
Article 26 obligations: what deployers must do, point by point
Article 26 is the operational core of what deployers owe. Here's each obligation with practical guidance on what "good" actually looks like. Are you confident you can demonstrate compliance for each one?
1. Use in accordance with instructions (Art. 26(1))
Obtain and retain the provider's instructions for use. Don't deploy the system for purposes outside the provider's stated intended purpose. If you change the intended purpose, you risk triggering Article 25 and becoming a provider yourself.
2. Human oversight (Art. 26(2))
Assign named individuals responsible for oversight. Those people need the competence, authority, and resources to override or intervene. Document everything: who reviews AI outputs, what triggers human review, how overrides are escalated. Use the Human Oversight Log to structure this.
3. Input data relevance (Art. 26(4))
Ensure data fed into the AI system is relevant to the intended purpose. If you control input data, it must be sufficiently representative. The Input Data Validator helps you assess this.
4. Monitoring and logging (Art. 26(5))
Monitor AI system operation for risks, anomalies, or incidents. Retain automatically generated logs for at least 6 months — or longer if sector-specific EU or national law requires it. If you detect a serious incident or malfunction, report to the provider AND the relevant national authority.
5. Fundamental Rights Impact Assessment (Art. 27)
Article 27 does not require every Annex III deployer to conduct a FRIA. Before deploying an Article 6(2) system, the duty applies to bodies governed by public law and private entities providing public services, except for systems in Annex III point 2, and it also applies to deployers of systems in Annex III points 5(b) and 5(c). The assessment addresses affected persons, context of use, specific risks, human oversight and response measures. Use the FRIA Generator as a planning aid, then validate scope with qualified counsel or the relevant authority.
6. Transparency to affected persons (Art. 26(11))
For Annex III high-risk systems that make decisions or assist in making decisions related to natural persons, inform those persons that they are subject to the use of the high-risk AI system, except where the law provides otherwise.
7. Workplace notification (Art. 26(7))
Inform employees or worker representatives before deploying a high-risk AI system in the workplace. This applies specifically to workplace management, task allocation, monitoring, and termination decisions.
8. AI literacy (Art. 4)
Providers and deployers must take measures supporting sufficient AI literacy among relevant staff and other persons dealing with AI on their behalf, taking account of their knowledge, experience, education and training, the context of use and the persons or groups on whom the system is used. Article 4 applied from 2 February 2025 and was amended from 27 July 2026. This is a proportionate measures duty, not a guaranteed individual outcome. The AI Literacy Training Planner helps you structure a programme.
The deployer evidence pack: what documentation you need under the current consolidated AI Act
The operational question is whether the organisation can produce evidence for the duties it has mapped. A policy or checklist is not enough by itself; the evidence file should show owners, instructions, oversight, logs, monitoring, notices, assessments and decisions.
| Evidence Item | EU AI Act Source | What It Contains | Who Owns It |
|---|---|---|---|
| AI system inventory | Articles 26, 4 | Complete register of all AI systems in use, providers, intended purposes, risk classifications | Deployer |
| Risk classification decision log | Article 6, Annex III | Deployer use-case and classification record, plus the provider Article 6(4) assessment and Article 49(2) registration evidence where Article 6(3) is claimed | Provider for the legal Article 6(4) assessment; deployer retains use-case and vendor evidence |
| Provider instructions for use | Art. 13 (provider), Art. 26(1) (deployer) | Intended purpose, limitations, human oversight specs, performance metrics | Provider delivers; Deployer retains |
| Human oversight arrangements | Art. 14 (design), Art. 26(2) (implementation) | Named oversight persons, competence requirements, review triggers, escalation paths, override procedures | Deployer |
| Input data governance records | Article 26(4) | Data quality checks, representativeness assessment, bias review for deployer-controlled input data | Deployer |
| System operation logs | Art. 12 (design), Art. 26(5) (retention) | Automatically generated logs, retained minimum 6 months | Provider designs logging; Deployer retains logs |
| FRIA documentation | Article 27 | Impact assessment on fundamental rights, context analysis, risk mitigation measures | Deployer |
| Incident response plan | Art. 26(5), Art. 62 | Serious incident definition, reporting workflow (provider + national authority), timelines, responsible persons | Deployer |
| AI literacy training records | Article 4 | Training programme description, completion records, competence assessment results | Deployer |
| Vendor due diligence records | Articles 25, 26 | Provider's conformity declaration, CE marking, EU database registration confirmation, contract terms covering AI Act obligations | Deployer verifies; Provider supplies |
| Monitoring & performance records | Article 26(5) | Ongoing performance monitoring results, drift detection, accuracy checks, bias monitoring outputs | Deployer |
That's 11 evidence items. How many can you produce right now, in a format that would satisfy a regulator?
📦 Need More Practical Guidance?
Explore the free EU AI Compass tools and guides to classify your use case, understand your obligations, and move to the next compliance step.
The 11-item deployer evidence pack: most mid-market organisations have fewer than 3 items in audit-ready condition.
What your AI vendor covers — and what they don't
This is the most dangerous misconception in the market right now. I've sat across from compliance teams who genuinely believed their vendor's "EU AI Act ready" badge covered their obligations. It doesn't. Here's the split.
| Your vendor (provider) should deliver | You (deployer) still own |
|---|---|
| Technical documentation describing the system | Your AI system inventory and classification decisions |
| Instructions for use (intended purpose, limitations) | Using the system per those instructions |
| Conformity assessment and CE marking | Verifying the vendor completed conformity assessment |
| Risk management system design | Implementing human oversight in YOUR context |
| Logging system design | Retaining logs for at least 6 months |
| Accuracy and robustness testing | Monitoring performance in YOUR production environment |
| Post-market monitoring system | Reporting serious incidents to vendor AND authority |
| EU database registration | FRIA (if you're in a triggering category) |
| AI literacy training for YOUR staff | |
| Workplace notification to YOUR employees | |
| Vendor due diligence documentation |
The provider's conformity assessment covers the system as designed. It doesn't cover how you deploy it, what data you feed it, what decisions you make based on its output, or whether your staff has the competence to oversee it.
Contract review is critical: your vendor agreement should explicitly address which AI Act obligations the vendor fulfils and which fall to you. If the contract is silent on this, you've got a gap. And if the vendor updates the system, you need to assess whether the change triggers a re-classification or additional obligations.
Use the AI Vendor Risk Screener to evaluate your vendor's posture. And run the Accidental Provider Classifier to check if any modifications you've made have shifted your role.
Annex III intended-purpose examples for deployers
Use the examples below to test whether a system's intended purpose matches a listed Annex III use case. An industry or product label is not enough.
AI in recruitment and employment (Annex III Area 4)
Annex III point 4 lists specified recruitment and selection uses, including targeted job advertising, application analysis or filtering and candidate evaluation. It also lists specified work-relationship decisions, task allocation based on individual behaviour or personal traits, and performance or behaviour monitoring and evaluation. Assess the intended purpose of the relevant feature. The organisation using the system under its authority is generally the deployer; the vendor may be the provider. Use the Promotion & Termination Validator to structure the review.
AI in credit scoring and lending (Annex III point 5(b))
Annex III point 5(b) covers systems intended to evaluate the creditworthiness of natural persons or establish a credit score and expressly excludes systems used to detect financial fraud. Assess the intended purpose rather than the product label. Article 27 includes point 5(b) systems in its FRIA scope. The Fraud vs Credit Scoring Delimiter helps structure that review.
AI in insurance pricing and underwriting (Annex III point 5(c))
Annex III point 5(c) covers systems intended for risk assessment and pricing in relation to natural persons in life and health insurance. Other insurance functions or product lines are not brought into point 5(c) by an insurance label alone; assess any other applicable listed use case separately. Article 27 includes point 5(c) systems in its FRIA scope. Run the Insurance Underwriting Assessor to structure that review.
AI in education (Annex III Area 3)
Annex III point 3 lists specified systems for access, admission or assignment to education, evaluating learning outcomes for the listed purposes, assessing the appropriate level of education, and monitoring or detecting prohibited behaviour during tests. Do not classify every proctoring, grading, admissions or learning-analytics feature from its label alone. The EdTech Assessment Validator can support the intended-purpose review.
Conformity assessment: it's the provider's job, but you need to verify it
Article 43 assigns conformity assessment to the provider. For systems listed in point 1 of Annex III, a provider that applies applicable harmonised standards or common specifications may choose Annex VI internal control or the Annex VII procedure involving a notified body. Annex VII is required where relevant standards or common specifications are unavailable, where the provider does not apply or only partly applies the harmonised standard, where available common specifications are not applied, or for the restricted part of a standard published with a restriction.
For systems referred to in points 2 to 8 of Annex III, including critical infrastructure in point 2, the provider follows Annex VI internal control, which does not involve a notified body. Critical-infrastructure classification does not itself create a notified-body requirement.
For high-risk systems covered by Union harmonisation legislation in Section A of Annex I, the provider follows the conformity-assessment procedure required by that product legislation, with the AI Act Section 2 requirements included in the assessment. Including high-risk AI as a safety component does not by itself require third-party assessment where the applicable product legislation does not require it.
The deployer's role is due diligence, not performance of the provider's Article 43 assessment unless the deployer has assumed provider status. Obtain and review the provider's instructions, EU Declaration of Conformity, CE marking and applicable registration evidence, and escalate missing or inconsistent evidence before deployment.
When do high-risk obligations apply?
Here's the timeline that matters for deployers of Annex III high-risk AI systems:
2 February 2025: Article 4 applied
Already live. Providers and deployers must take measures supporting sufficient AI literacy among relevant staff and other persons operating or using AI on their behalf, calibrated to knowledge, experience, education, training, context of use and affected persons.
2 December 2027 — Annex III high-risk obligations apply
Article 50 generally applied from 2 August 2026. Relevant Article 6(2)/Annex III high-risk provisions, including associated Article 26 and 27 routes, apply from 2 December 2027; check the exact scope and transition.
2 August 2028 — Annex I high-risk obligations apply
For the Article 6(1) route covering an AI system that is itself an Annex I product or is intended as a safety component of one, where the relevant product must undergo third-party conformity assessment under that product legislation.
⚠ Penalties for high-risk violations
Up to €15 million or 3% of worldwide annual turnover — whichever is higher (Article 99). SMEs pay the lower of the two amounts. Enforcement infrastructure and national competent-authority arrangements should be monitored separately. Do not rely on an old “no fines yet” statement as a planning control.
For the full enforcement picture, see: Current statutory timeline · National enforcement tracker · current SME application-date guide
How to start: a step-by-step roadmap for high-risk AI deployers
If you're reading this and realising you have gaps, here's the sequence that works. I've walked multiple organisations through this process, and the order matters more than most people think.
Inventory all AI systems.
Start with procurement records, SaaS subscriptions, and vendor contracts. Don't forget embedded AI in tools your team uses daily. Use the Shadow AI Discovery Protocol to find what's hidden.
Assess each system against the Article 6 routes.
Use the High-Risk Classification Router, then the relevant intended-purpose validator where an Annex III route is indicated. Preserve the route, facts and uncertainty in the classification record.
Request provider documentation.
For each high-risk system, obtain the provider instructions, EU Declaration of Conformity, CE marking confirmation and registration evidence applicable to its route. Escalate missing or inconsistent evidence before deployment.
Conduct a deployer obligation gap assessment.
Use the Deployer Obligation Self-Assessment to identify which obligations you've met and where the holes are.
Implement human oversight.
Name oversight individuals, define review triggers and escalation paths, document the arrangements. Use the Human Oversight Log.
Conduct FRIA (if required).
Check the exact Article 27 scope. It covers specified public-law and public-service deployers, except Annex III point 2 systems, and deployers of systems in Annex III points 5(b) and 5(c). Use the FRIA Generator as a planning aid.
Build your evidence pack.
Assemble all 11 evidence items from the matrix above. This is what an auditor, regulator, or procurement team will ask for.
Establish ongoing monitoring.
Post-deployment monitoring isn't optional. Define what you check, how often, and what triggers escalation.
🚀 Start your high-risk compliance journey
EU AI Compass tools for high-risk deployers
Every tool below runs in your browser, collects zero data, and requires no login. They're organised by the stage of your EU AI Act compliance checklist — from initial classification through to evidence documentation.
Stage 1: Classify your systems
EU AI Act Compliance Checker
Quick classification against the full regulation
Quick Risk Quiz
5-minute risk-level assessment
Detailed Applicability Scorer
In-depth applicability analysis
Accidental Provider Classifier
Check if modifications made you a provider
Stage 2: Validate sector classification
Biometric Identity Validator
Area 1: Biometric identification
EdTech Assessment Validator
Area 3: Education and vocational training
Promotion & Termination Validator
Area 4: Employment and workers management
Fraud vs Credit Scoring Delimiter
Point 5(b): Creditworthiness assessment
Insurance Underwriting Assessor
Point 5(c): Insurance risk and pricing
Article 6(3) Filter Decision Record
Record the provider/deployer evidence split
Stage 3: Assess and document obligations
Deployer Obligation Self-Assessment
Map your compliance gaps against Article 26
Article 26 Operations Scorer
Benchmark your operational readiness
Local FRIA Generator
Generate fundamental rights impact assessment
Human Oversight Log
Structure oversight arrangements
Input Data Validator
Assess data relevance and representativeness
Automation Complacency Assessor
Evaluate oversight effectiveness
AI Literacy Training Planner
Plan Article 4 literacy programme
Related tools and references
FAQ: high-risk AI deployer compliance
AI systems intended to be used for recruitment or selection, including placing targeted job advertisements, analysing or filtering applications and evaluating candidates, are listed in Annex III point 4(a). An ATS or HR product is not high-risk merely because it uses AI; assess the intended purpose of the relevant feature. The organisation using the system under its authority is generally the deployer, while the vendor may be the provider.
No. Provider conformity assessment and documentation do not discharge the deployer's duties under Article 26. The deployer must use the system according to instructions, implement oversight, monitor operation, retain logs and meet notification duties where applicable. A FRIA is required only where Article 27 applies. If the deployer assumes provider status under Article 25, provider obligations may also apply.
Article 27 does not apply to every Annex III deployer. Before deploying an Article 6(2) system, it applies to bodies governed by public law and private entities providing public services, except for systems in Annex III point 2, and to deployers of systems in Annex III points 5(b) and 5(c). The assessment addresses the specific deployment context and affected persons.
Article 25 may make you the provider if you put your name or trademark on a high-risk system, make a substantial modification, or change the intended purpose of a system so that it becomes high-risk. Configuration or fine-tuning is not automatically a substantial modification; assess the facts against the statutory tests.
At least 6 months, or longer if required by sector-specific EU or national law (Article 26(5)). Financial services, healthcare, and employment regulations may impose longer retention periods. Establish a log retention policy aligned with the strictest applicable requirement.
No. Annex III point 5(b) lists systems intended to evaluate creditworthiness or establish a credit score and expressly excludes systems used for detecting financial fraud. Assess the system's intended purpose. A fraud tool may still require review under another listed use case, but point 5(b) is not triggered merely because the tool affects access to a service.
Annex III is only the Article 6(2) route. Also assess whether Article 6(1) applies to an Annex I product or safety component. If neither route applies on the available facts, the system is not high-risk under Article 6, but other AI Act duties may still apply. The Commission's current classification guidelines remain draft and non-binding.
Abhishek G Sharma
Founder & CEO, Move78 International Limited
20+ years in cybersecurity and risk management. Certifications: ISO 42001 LA, ISO 27001 LA, CISA, CISM, CRISC, CEH, CCSK, CAIGO, CAIRO.
Need More Practical Guidance?
From self-service templates to guided workshops and full advisory engagements — we meet you where you are.
Disclaimer
This guide is for educational and informational purposes only. It does not constitute legal advice. The EU AI Act is complex and its interpretation may evolve as implementing acts, guidelines and enforcement decisions are published. Consult qualified legal counsel for advice specific to your organisation's circumstances. Regulatory references were reviewed on 4 September 2026 against the consolidated Regulation (EU) 2024/1689 dated 27 July 2026, Regulation (EU) 2026/1744 and the Commission's draft, non-binding high-risk classification guidelines.
Sources & legal basis
Binding baseline: consolidated Regulation (EU) 2024/1689, 27 July 2026
Binding amendment: Regulation (EU) 2026/1744
Draft Commission high-risk classification guidelines, non-binding
Operational steps and evidence suggestions on this page are practitioner recommendations, not additional legal requirements.