What Is High-Risk AI Under the EU AI Act?
High-risk AI is the central compliance category of the EU AI Act. A system classified as high-risk must satisfy obligations under Articles 9–15 of Chapter III, covering risk management, data governance, technical documentation, logging, transparency, human oversight, and accuracy/robustness, before deployment. Under the Digital Omnibus (adopted by Parliament 16 June 2026, Council adoption 29 June 2026), full compliance is required by 2 December 2027 for Annex III standalone systems (moved from 2 August 2026, a 16-month deferral). Annex I embedded high-risk systems apply from 2 August 2028.
High-risk classification occurs through two routes: Route A, Annex I regulated product AI (medical devices, machinery, vehicles); Route B, Annex III domain AI (eight specified high-impact domains). An important nuance: Article 6(3) provides that a system in an Annex III domain is not automatically high-risk if it does not pose a significant risk of harm, but providers invoking this exception must document their justification and may be challenged by regulators.
The Eight Annex III High-Risk AI Domains
Biometric Identification and Categorisation
Post-prohibition remote biometric identification systems; emotion recognition in professional contexts; biometric categorisation based on sensitive attributes where not prohibited under Article 5.
Critical Infrastructure
AI safety components for transport, utilities (water, gas, electricity, heating), and digital infrastructure. Must be a safety-critical function, administrative AI for non-safety operations may not qualify.
Education and Vocational Training
AI determining access to educational institutions; AI assessing students or evaluating examination integrity; AI monitoring prohibited behaviours in tests. High-stakes educational decisions affecting life trajectories.
Employment and Workforce Management
AI for recruitment and candidate selection (CV screening, interview analysis); AI influencing promotion or termination; AI for task allocation based on personal characteristics; AI monitoring work performance and behaviour.
Essential Private and Public Services
AI for creditworthiness and credit scoring; AI evaluating life, health, and liability insurance risks; AI determining access to public benefits; AI dispatching or prioritising emergency services.
Law Enforcement
AI assessing individual risk of crime victimisation or perpetration; polygraph and truth-verification tools; evidence reliability evaluation; profiling in crime prevention and detection contexts.
Migration, Asylum, and Border Management
AI risk-assessing persons at borders; document and identity verification in migration contexts; AI assessing asylum applications; AI detecting illegal crossings.
Administration of Justice and Democratic Processes
AI assisting judicial fact-finding; AI influencing elections or voting behaviour; targeted political advertising AI; AI used in administration of justice by judicial or prosecutorial authorities.
High-Risk AI Provider Obligations: Articles 9–15
| Article | Obligation | Key Requirements |
|---|---|---|
| Art. 9 | Risk Management System | Continuous, iterative: risk identification, estimation, evaluation, mitigation. Residual risk assessment. Documented throughout full lifecycle. |
| Art. 10 | Data Governance | Training, validation, testing datasets must be relevant, representative, error-free. Documented data collection, processing, annotation practices. Known limitations noted. |
| Art. 11 | Technical Documentation | Complete Annex IV documentation: system description, design specs, purpose, training methodology, datasets, testing results, performance metrics, post-market monitoring plan. |
| Art. 12 | Record-Keeping | Automatic logging of system operation. Must function without manual activation. Minimum 6-month log retention (longer per national law). |
| Art. 13 | Transparency | Instructions for deployers: capabilities, limitations, accuracy, monitoring requirements, output interpretation. Clear, accessible language. |
| Art. 14 | Human Oversight | Designed-in monitoring, interpretation, override, and interrupt capabilities. Automation bias prevention. Named oversight roles with documented authority. |
| Art. 15 | Accuracy & Cybersecurity | Demonstrated accuracy throughout lifecycle. Robustness against errors, adversarial attacks, and inconsistencies. Cybersecurity measures implemented. |
| Art. 17 | Quality Management System | Documented QMS covering compliance strategy, design processes, testing, post-market monitoring. Proportionate to organisation size. |
Deployer Obligations for High-Risk AI
Deployers, organisations that use high-risk AI built by others, have their own distinct obligations:
- Use the system in accordance with the provider's instructions for use
- Assign qualified human oversight personnel with authority to intervene
- Monitor system operation and report serious incidents to the provider and competent authority (Art. 73)
- Conduct a Fundamental Rights Impact Assessment (FRIA) under Article 27 where applicable, mandatory for public sector deployers and specific private sector uses (credit scoring, insurance, recruitment)
- Where deployers substantially modify a high-risk AI system, they take on provider-equivalent obligations for the modified version
Conformity Assessment and EU Database Registration
Before deployment, providers must conduct a conformity assessment (Art. 43), self-assessment for most Annex III systems, third-party notified body assessment for biometric identification systems. All high-risk AI systems must be registered in the EU AI public database before deployment, capturing: provider identity, system name and version, intended purpose, Annex III domain, conformity assessment status, and member states of deployment.
Yes. If an AI component within a larger system performs a high-risk function, a credit scoring module within a banking platform, or a CV screening component within an HR system, that component is subject to high-risk obligations regardless of the broader system's classification. The classification applies where the AI decision-making occurs, not at the level of the overall application.
Technical documentation and conformity assessment records must be kept for 10 years after the system is placed on the market or put into service, or longer if required by sector-specific legislation. Logs must be retained for the period specified in national law or a minimum of 6 months.