A high-risk AI system is permitted under the EU AI Act, but it must meet extensive requirements before it is placed on the market or put into service and throughout its lifecycle.
High-risk status is not determined by how advanced, expensive or generative a system is. The classification depends principally on intended purpose and follows one of two routes:
- the AI is a safety component of, or itself constitutes, a regulated product listed in Annex I and is subject to third-party conformity assessment; or
- the intended use appears in one of the sensitive areas listed in Annex III.
The 2026 Digital Omnibus changed the implementation calendar. The main requirements for Annex III systems apply from December 2, 2027. The corresponding requirements for Annex I product-related systems apply from August 2, 2028.
For the law’s overall structure, start with our complete EU AI Act guide. For the full decision sequence, use the EU AI Act risk-categories guide. For dates and legacy transitions, see the EU AI Act timeline.
High-risk AI at a glance
| Question | Practical answer |
| Is high-risk AI banned? | No. It is allowed if applicable requirements and operator obligations are met |
| What are the two routes? | Annex I regulated products and Annex III sensitive use cases |
| Who classifies the system? | The provider must perform and document the classification, with deployers validating their own intended use |
| Can an Annex III-listed system be non-high-risk? | Sometimes, through Article 6(3), if it does not pose significant risk and meets a listed condition; profiling remains high-risk |
| What must the system meet? | Risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity |
| What else must providers do? | Quality management, conformity assessment, registration, CE marking where applicable, post-market monitoring and incident response |
| What must deployers do? | Follow instructions, assign oversight, monitor, control input data, retain logs and meet notices or impact-assessment duties where applicable |
| When do Annex III rules apply? | December 2, 2027 |
| When do Annex I rules apply? | August 2, 2028 |
| Are Commission classification guidelines final? | No. As of August 7, 2026, the guidance was still draft and expected later in 2026 |
The first rule: test Article 5 before high-risk status
A prohibited practice cannot be rescued through conformity assessment. Screen the system against Article 5 first.
Examples:
- workplace emotion recognition can be prohibited except for medical or safety purposes;
- sensitive biometric categorization can be prohibited;
- certain criminal-risk prediction can be prohibited;
- and most real-time remote biometric identification by law enforcement in public spaces is prohibited.
Only a permitted use moves to the high-risk analysis. Our prohibited-practices guide explains the sequence.
Route 1: Annex I regulated products
Article 6(1) treats an AI system as high-risk when both conditions are met:
- the AI is intended as a safety component of a product, or is itself a product, covered by EU harmonization legislation listed in Annex I; and
- that product or AI system must undergo a third-party conformity assessment before market placement or service under the relevant sectoral law.
Potential sectors include medical devices, machinery, vehicles, aviation, rail, marine equipment, toys, lifts, pressure equipment and other categories listed in Annex I. The exact sectoral legislation and assessment route must be mapped; an AI tool does not become Annex I high-risk merely because it is used somewhere in healthcare or manufacturing.
The amended safety-component definition
The 2026 Omnibus clarified that a safety component fulfills a safety function or is a component whose failure or malfunction endangers health and safety of people or property. For this purpose, a component performs a safety function where its intended purpose is to prevent or mitigate health-and-safety risks.
AI used only for convenience, productivity, quality control or performance optimization is not necessarily a safety component. The question is what function the component performs and what happens if it fails.
Interaction with product law
The Omnibus also allows the application of specified AI Act requirements or obligations for Article 6(1) systems to be limited where Annex I product law already provides equivalent or higher protection and the overall level of protection is not reduced. The Commission is to specify the affected systems, requirements and conditions through delegated acts.
Product manufacturers should therefore build one integrated compliance map rather than duplicate documentation blindly. Until the delegated measures are adopted, do not assume an overlap is automatically removed.
Route 2: Annex III sensitive use cases
Annex III lists high-risk intended uses across eight areas.
1. Biometrics
This includes specified remote biometric identification, biometric categorization based on sensitive or protected attributes, and emotion recognition, to the extent the use is not already prohibited.
Teams must distinguish identification, verification and categorization. A one-to-one identity check is not the same as remote one-to-many identification.
2. Critical infrastructure
AI intended as a safety component in managing or operating critical digital infrastructure, road traffic or the supply of water, gas, heating or electricity can be high-risk where failure or malfunction risks life or health.
Ordinary billing analytics or office assistants used by a utility are not high-risk on sector alone.
3. Education and vocational training
Listed uses include systems intended for:
- determining access or admission;
- assigning people to educational institutions or programs;
- evaluating learning outcomes where the output steers learning;
- assessing the appropriate educational level;
- and monitoring prohibited behavior during tests.
A grammar checker used by students is different from an admissions or exam-proctoring system.
4. Employment, worker management and self-employment
Potentially high-risk uses include:
- targeted job advertising;
- application analysis and filtering;
- candidate evaluation;
- promotion or termination decisions;
- task allocation based on behavior, traits or characteristics;
- and worker-performance or behavior monitoring.
A generic writing assistant used by HR is not automatically high-risk. A system scoring candidates for a vacancy may be.
5. Essential private and public services
Annex III covers defined uses involving:
- eligibility for public assistance and benefits;
- creditworthiness evaluation or credit scoring of natural persons, subject to listed exceptions;
- risk assessment and pricing for life and health insurance;
- and emergency-call evaluation, classification or dispatch prioritization.
The exact decision and affected person matter. Back-office forecasting by a bank is not automatically a high-risk credit system.
6. Law enforcement
Specified uses can include systems supporting evidence assessment, victim risk, polygraphs, profiling and investigation functions, where the practice is permitted under Article 5 and other law.
These uses require particularly careful necessity, data-protection and fundamental-rights analysis.
7. Migration, asylum and border control
The list includes specified uses for polygraphs, risk assessment, application examination and identification in migration, asylum and border contexts.
8. Justice and democratic processes
Systems assisting judicial authorities with researching and interpreting facts and law or applying law to concrete facts can be high-risk. Certain systems intended to influence election or referendum outcomes also appear in Annex III, subject to the exact terms and exclusions.
The Article 6(3) exclusion
Not every system touching an Annex III process is necessarily high-risk. Article 6(3) allows an Annex III-listed system to be treated as non-high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including because it does not materially influence decision-making outcomes.
The route applies where the system is intended to:
- perform a narrow procedural task;
- improve the result of a previously completed human activity;
- detect decision patterns or deviations without replacing or improperly influencing the completed human assessment and with proper human review;
- or perform a preparatory task for an Annex III assessment.
A system performing profiling of natural persons remains high-risk notwithstanding this route.
Documentation is mandatory
A provider relying on Article 6(3) must document the assessment before market placement or service and meet the relevant registration requirement. The file should explain:
- exact intended purpose;
- output and decision influence;
- affected people;
- harm pathways;
- why the task is narrow, preparatory or otherwise within a listed condition;
- human-review design;
- profiling analysis;
- and foreseeable misuse.
The exclusion should not be reduced to “a human makes the final decision.” Nominal review may still leave the system materially influential.
The core requirements: Articles 8 to 15
High-risk systems must satisfy an integrated set of requirements.
Risk management
A documented, iterative risk-management system must run throughout the lifecycle. It should identify and analyze known and reasonably foreseeable risks, evaluate risks during intended use and foreseeable misuse, adopt controls and test residual risk.
Risk management is not a pre-launch spreadsheet. It must connect to design, testing, incidents, monitoring and change control.
Data and data governance
Where training, validation or testing datasets are used, they must meet quality and governance requirements appropriate to the intended purpose. Controls can include:
- data origin and collection;
- preparation and labeling;
- assumptions and representativeness;
- bias detection and correction;
- gaps and limitations;
- relevance to geography and affected groups;
- and governance over special-category data where the Act and other law permit its processing.
“Unbiased data” is not a realistic binary claim. The provider should show how relevant biases and performance disparities are identified, evaluated and mitigated.
Technical documentation
Documentation must demonstrate compliance and give authorities and, where applicable, notified bodies enough clear information to assess the system. Annex IV defines minimum content.
The file should remain synchronized with the actual released system, not a prototype described months earlier.
Record keeping and logs
The system must technically allow automatic recording of events over its lifetime to a level appropriate for traceability, risk identification and post-market monitoring.
Providers and deployers have separate log responsibilities. Contracts and architecture should establish who can access, retain, export and interpret the necessary logs.
Transparency and instructions for use
The system must be sufficiently transparent for deployers to interpret output and use it appropriately. Providers must supply concise, complete, correct and clear instructions covering intended purpose, performance, limitations, input specifications, oversight, maintenance and other required information.
This is different from Article 50’s notice and synthetic-content rules. Article 13 is operational transparency for high-risk deployers.
Human oversight
High-risk systems must be designed so natural persons can effectively oversee them during use. Oversight measures should match autonomy, context and risk.
The overseer needs:
- competence and training;
- authority and time;
- access to relevant information;
- understanding of limitations;
- ability to disregard, override or stop the system;
- and protection against automation bias.
Accuracy, robustness and cybersecurity
The system must achieve appropriate accuracy, robustness and cybersecurity and perform consistently throughout its lifecycle.
This includes resilience to errors, faults, inconsistencies and attempts by unauthorized third parties to exploit vulnerabilities or alter use. High-risk security should be integrated with the wider AI security framework.
Provider obligations
Providers of high-risk AI systems must do more than build the Articles 8–15 controls. Their duties include:
- ensuring compliance with the requirements;
- identifying themselves on the system or documentation;
- operating a quality-management system;
- keeping required documentation;
- retaining automatically generated logs under their control;
- completing conformity assessment;
- drawing up the EU declaration of conformity;
- affixing CE marking where required;
- registering the system in the EU database;
- conducting post-market monitoring;
- reporting serious incidents;
- taking corrective action;
- and cooperating with competent authorities.
The exact conformity route depends on whether the system falls under Annex I product law, Annex III and any special biometric provisions.
Deployer obligations
Deployers must control the system in its real operational context. Depending on the use, duties include:
- following the instructions for use;
- assigning competent human oversight;
- ensuring input data under their control is relevant and sufficiently representative;
- monitoring operation;
- acting when risk, non-compliance or serious incidents appear;
- suspending use where necessary;
- keeping logs under their control for the required period;
- supporting data-protection impact assessment where applicable;
- informing workers and representatives before workplace deployment;
- informing affected persons when the system makes or assists decisions about them;
- and registering use by public authorities or entities acting on their behalf where required.
Deployers should not accept a provider’s high-risk classification without testing whether their own configuration or purpose changes it.
Fundamental-rights impact assessment
Article 27 requires a fundamental-rights impact assessment for specified deployers before first use of certain Annex III high-risk systems. The covered groups include bodies governed by public law, private entities providing public services and defined deployers of creditworthiness and life or health insurance systems.
The assessment addresses matters such as:
- the deployer’s processes and period of use;
- affected categories of people and groups;
- specific risks to fundamental rights;
- human-oversight measures;
- mitigation and governance;
- and complaint mechanisms.
Where relevant work already appears in a GDPR data-protection impact assessment, the Omnibus permits cross-references or inclusion of relevant parts. A DPIA and FRIA are still different legal instruments.
Conformity assessment, CE marking and registration
Before market placement or service, the provider must demonstrate that the high-risk system meets applicable requirements.
Depending on the system, this can involve:
- internal control;
- assessment under Annex I product legislation;
- or a notified body.
A substantial modification can require a new assessment. After successful conformity work, the provider completes the required declaration, marking and registration steps.
Harmonized standards can provide a presumption of conformity once adopted and referenced. Their use is generally voluntary, but they are likely to become the most predictable implementation route. Standards work remained ongoing in August 2026.
Post-market monitoring and incidents
Compliance continues after launch. Providers need a post-market monitoring system that actively and systematically collects, documents and analyzes relevant performance data.
The system should connect:
- deployer feedback;
- complaints;
- performance drift;
- bias and error metrics;
- security vulnerabilities;
- incidents and near misses;
- corrective action;
- and model or software updates.
Deployers need contractual routes to report problems quickly and receive provider corrections. Incident responsibility should be agreed before deployment, not improvised during harm.
High-risk implementation timeline
| System category | Main requirements apply |
| Article 6(2) and Annex III use cases | December 2, 2027 |
| Article 6(1) and Annex I product-related systems | August 2, 2028 |
| Certain high-risk systems intended for public-authority use already on the market | Transition through August 2, 2030, subject to Article 111 |
Legacy treatment is conditional. Systems already on the market do not receive an unlimited exemption, especially after significant design changes. Public-sector systems have a specific 2030 transition.
Status of the Commission’s high-risk guidance
As of August 7, 2026, the Commission’s classification guidance remained draft. The targeted consultation closed on July 23, 2026, and final guidance was expected by the end of the year.
The draft is useful for examples and Commission interpretation, but it should be labeled as draft in internal decisions. The Regulation and Omnibus remain controlling.
A high-risk readiness plan
Classification
- Define the intended purpose and users.
- Complete Article 5 screening.
- Test Annex I product legislation and third-party assessment.
- Test every Annex III use case.
- Document any Article 6(3) conclusion.
- Assign operator roles.
System requirements
- Build lifecycle risk management.
- establish dataset governance and bias testing;
- maintain technical documentation;
- design logging and traceability;
- prepare instructions for use;
- engineer effective human oversight;
- and define accuracy, robustness and cybersecurity targets.
Organizational controls
- Create a quality-management system.
- Map conformity assessment and standards.
- appoint documentation and post-market owners;
- prepare registration and declarations;
- establish incident and corrective-action procedures;
- and contract for upstream and downstream evidence.
Deployer readiness
- Validate the provider package.
- Configure the system within intended purpose.
- train oversight staff under Article 4;
- perform FRIA and DPIA where needed;
- prepare notices and worker information;
- and test stop, override and complaint routes.
The full program can be managed through the EU AI Act compliance checklist.
Common high-risk mistakes
Classifying by sector
Not every AI system in healthcare, finance or employment is high-risk. The intended use and exact legal route matter.
Assuming a human final decision removes high-risk status
Material influence, profiling and the actual quality of review matter more than a formal sign-off.
Using Article 6(3) without documentation
The provider must make the assessment before market placement or service and retain evidence.
Waiting until the application date
Data, documentation, conformity and contract work can take years. The delayed dates are preparation time.
Treating provider compliance as deployer compliance
The provider controls product design; the deployer controls context, people, local data and operation.
Calling draft guidance final
Draft examples may change and are not legally binding.
Frequently asked questions
What makes an AI system high-risk?
It is high-risk when it meets the Article 6(1) product route or is intended for an Annex III use, unless a valid Article 6(3) exclusion applies.
Is generative AI automatically high-risk?
No. A generative model or assistant becomes high-risk only through the relevant intended-purpose classification. GPAI and Article 50 can apply separately.
Are recruitment systems high-risk?
Systems intended to analyze, filter, rank or evaluate candidates can fall within Annex III. Narrow procedural tools require a fact-specific Article 6(3) analysis.
Are medical AI systems high-risk?
Some are, particularly where the AI is a regulated product or safety component subject to third-party conformity assessment. General administrative tools are not automatically high-risk.
Can a high-risk system legally be sold?
Yes, after it meets applicable requirements, conformity assessment, registration and other provider obligations.
Who conducts the conformity assessment?
The route depends on system and product law. It can involve internal control, sectoral assessment or a notified body.
When do the high-risk rules apply?
December 2, 2027 for Annex III systems and August 2, 2028 for Annex I product-related systems.
Does Article 4 already apply to future high-risk systems?
Yes. The general AI-literacy duty has applied since February 2025, and high-risk oversight training adds further requirements when Chapter III applies.
Are the Commission’s classification guidelines final?
No. They remained draft on August 7, 2026 following a consultation that closed in July.
Do existing systems need to comply?
Article 111 provides transitional treatment, but significant design changes and public-authority use can trigger requirements. Review each system and date individually.
Bottom line
High-risk classification is built around intended purpose, not technological prestige. Test both Article 6 routes, document any exclusion and assign provider and deployer responsibilities before designing the control program.
The 2027 and 2028 deadlines should be treated as delivery dates, not start dates. Data governance, technical documentation, human oversight, conformity assessment and post-market infrastructure need to be built while the standards and final guidance are still developing.
byDavid Porter
Popular news
Senator Josh Hawley Launches Massive Investigation Into OpenAI After Critical Hugging Face Breach
Anthropic Researchers Warn Advanced AI Models Could Trigger Human Extinction
Andy Burnham Faces Urgent Demands to Block Artificial Superintelligence in Manchester
UK Computer Science Graduates Face a Massive Job Market Shift Driven by AI
Anthropic Researchers Issue Urgent Warning Regarding Elon Musk and Global AI Safety Risks
OpenAI Board Member Paul Christiano Warns AI Control Could Be Lost Forever
Latest comments
Loading