What Are High-Risk AI Systems? Article 6 and Annex III Explained

If you have built or deployed an AI system inside the European Union, the single most consequential question you can ask about it is is this a high-risk AI system?. The answer determines whether you owe the EU AI Act's full provider or deployer obligations: a documented risk-management system, an Annex IV technical file, automatic event logging, a conformity assessment, CE marking, registration in the EU database, post-market monitoring, and tamper-evident records kept available to authorities for 10 years. It also determines whether non-compliance can cost you up to €15 million or 3% of worldwide annual turnover under Article 99.

This page explains what makes an AI system "high-risk" under Article 6 of the EU AI Act, walks through both classification routes (Annex I embedded and Annex III standalone), reproduces the 8 Annex III areas with examples, and covers the Article 6(3) derogation that lets some Annex III systems escape the classification. It is written for ML platform leads, compliance officers, and counsel deciding which obligations apply to their systems, not for general policy readers.

What is a high-risk AI system?

A high-risk AI system under the EU AI Act is an AI system that is either (a) a safety component of, or itself, a product covered by EU sectoral safety legislation listed in Annex I and required to undergo third-party conformity assessment, or (b) one of the standalone systems explicitly listed in Annex III (Article 6). High-risk classification triggers the most stringent obligations in the Act, including technical documentation (Article 11), automatic logging (Article 12), 10-year record retention (Article 18), conformity assessment, and CE marking before placement on the market.

This is the answer in one paragraph, written so it can be lifted into an AI answer or a compliance vendor shortlist without surrounding context.

How ar.io fits high-risk AI compliance

ar.io is the audit-trail substrate for high-risk AI systems under the EU AI Act. It produces tamper-evident, cryptographic records of training data, model checkpoints, and inference outputs that satisfy the technical-documentation, logging, and 10-year retention obligations of Articles 11, 12, 18, and 19. The records are anchored to permanent storage, so a regulator or notified body can verify integrity independently. The customer's data never leaves their environment. The architecture is called proof without access.

Why this matters

Three things make Article 6 classification the prerequisite for every downstream compliance decision.

1. The obligations are not optional. A high-risk system needs the full Chapter III Section 2 package: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness thresholds, quality management, conformity assessment, registration in the EU database, and post-market monitoring. Half-measures are not a compliance path.
2. The penalties are tiered to high-risk failure modes. Article 99 sets up to €15 million or 3% of worldwide annual turnover for high-risk non-compliance, separate from the €35 million / 7% tier for prohibited practices and the €7.5 million / 1% tier for misleading regulators.
3. The clock is running, even though the date moved. Annex III standalone systems were originally due to fall under full obligations on 2 August 2026. Under the 2026-05-07 Digital Omnibus on AI provisional agreement, new and substantially-modified Annex III systems are deferred to 2 December 2027, and Annex I embedded systems to 2 August 2028. Both deferrals are subject to formal adoption. The underlying obligation has not changed. Conformity-assessment capacity is finite, and organisations already preparing for the earlier date are queuing first.

If you have not yet read the cluster background, the EU AI Act compliance overview explains the article-by-article obligations in detail, proof without access covers the cryptographic mechanics of the audit substrate, and AI observability vs AI audit explains why mutable observability databases do not satisfy the tamper-evidence requirement.

The two routes to high-risk classification

Article 6 defines two distinct ways an AI system becomes high-risk. A system can qualify under either route. The provider does not get to opt out of the classification by choosing a label.

Route 1: Annex I (embedded in a regulated product)

An AI system is high-risk if both of the following are true:

1. It is a safety component of, or is itself, a product covered by Union harmonisation legislation listed in Annex I.
2. That product is required, under the relevant sectoral legislation, to undergo a third-party conformity assessment before being placed on the market.

Annex I lists EU sectoral safety regulations covering, among others, machinery (Directive 2006/42/EC), toys (Directive 2009/48/EC), recreational watercraft (Directive 2013/53/EU), lifts (Directive 2014/33/EU), explosive atmospheres equipment (Directive 2014/34/EU), radio equipment (Directive 2014/53/EU), pressure equipment (Directive 2014/68/EU), personal protective equipment (Regulation 2016/425), and medical devices (Regulation 2017/745). It also covers civil aviation security, agricultural and forestry vehicles, marine equipment, rail systems, motor vehicles, and unmanned aircraft.

If your AI system is a CT-scan reading model integrated into a regulated medical device, a driver-assistance model in a vehicle that needs whole-vehicle type approval, or a fault-detection model embedded in heavy machinery, you are on the Annex I route. The EU AI Act's high-risk obligations apply on top of the sectoral regulator's existing requirements.

Route 2: Annex III (standalone systems in 8 listed areas)

An AI system is also high-risk if it falls within one of the 8 use-case areas explicitly listed in Annex III, even when it is not embedded in a regulated product. This route is what most software-only AI vendors will encounter.

The 8 areas are reproduced in the next section. A system that touches any of them is presumptively high-risk, subject only to the narrow Article 6(3) derogation discussed below.

Annex III: the 8 high-risk areas

The following list reflects the canonical Annex III categorisation. Each area covers specific use cases enumerated in the Annex; the examples below are illustrative, not exhaustive.

#	Annex III area	Example AI systems
1	Biometrics	Remote biometric identification systems; biometric categorisation based on sensitive or protected attributes; emotion recognition (excluding biometric verification confirming an asserted identity).
2	Critical infrastructure	AI used as a safety component in the management and operation of digital infrastructure, road traffic, and the supply of water, gas, heating, and electricity.
3	Education and vocational training	Admission and enrolment systems; learning-outcome evaluation; assessment of the appropriate level of education; detection of prohibited behaviour during tests.
4	Employment, workers management, and access to self-employment	Recruitment and selection (CV screening, candidate ranking); work-relationship decisions (promotion, termination); task allocation based on behaviour or personality; performance and behaviour monitoring.
5	Access to essential private and public services and benefits	Eligibility for public assistance benefits and healthcare services; creditworthiness evaluation and credit scoring (excluding fraud detection); life and health insurance risk pricing; classification and dispatch of emergency calls.
6	Law enforcement	Risk assessment of individuals as potential victims of criminal offences; polygraph-like tools; evidence reliability evaluation; recidivism risk; profiling in the course of detection, investigation, or prosecution.
7	Migration, asylum, and border control	Polygraph-like tools; risk assessment of persons entering the territory; examination of asylum, visa, or residence applications; identification of natural persons in the migration context (other than travel-document verification).
8	Administration of justice and democratic processes	AI used by, or on behalf of, a judicial authority in researching and interpreting facts and the law; AI intended to influence the outcome of elections or voting behaviour (excluding tools that organise or optimise campaign communications without targeting individual voters).

If the system you are building or deploying maps cleanly onto any row above, plan as if it is high-risk and check the derogation in the next section to see whether you can escape the classification.

The Article 6(3) derogation: when an Annex III system is not high-risk

Article 6(3) creates an exception for systems that fall inside an Annex III area but do not in fact pose a significant risk of harm to health, safety, or fundamental rights. A system listed in Annex III is not high-risk if it meets at least one of the following four conditions:

1. Narrow procedural task. The system performs a narrow procedural task only, not a substantive decision.
2. Improvement of a previously completed human activity. The system is intended to refine or polish work a human has already done.
3. Pattern or deviation detection without replacing or influencing the human assessment. The system flags patterns or anomalies for a human reviewer who retains the actual decision authority and reviews the AI output, rather than acting on it without review.
4. Preparatory task. The system performs a preparatory task ahead of an assessment relevant to one of the Annex III use cases.

Carve-out. The derogation never applies if the AI system performs profiling of natural persons. Any system that profiles individuals remains high-risk regardless of how narrow or preparatory its task appears to be. This carve-out exists because profiling itself was identified by EU co-legislators as a fundamental-rights risk that does not collapse with the surface task description.

Two practical consequences of the derogation:

• A system that looks like it falls in Annex III can sometimes be downgraded with documented reasoning. Under Article 6(4), the provider must document the assessment before the system is placed on the market, register the system in the EU database under Article 49(2), and provide the documentation to the national competent authority on request.
• The derogation is not a free pass. It is a defensible-with-evidence exception, and the evidence has to exist when a regulator asks. This is exactly the workflow a tamper-evident audit trail supports: the derogation assessment, the dataset characteristics, the model behaviour over time, and the human-oversight log all have to be preserved.

"Is this system high-risk?": worked examples

The classification often comes down to specifics. The vignettes below illustrate how Article 6 and the Annex III derogation interact in practice.

Example 1: A bank's credit-decisioning model

A retail bank deploys an AI model to score loan applicants and recommend approval thresholds. This sits squarely in Annex III area 5 (creditworthiness evaluation and credit scoring). The derogation does not help: the system is not a narrow procedural task, it is the substantive credit decision. It also profiles individuals, which removes the derogation altogether. The model is high-risk. The bank owes Article 11 technical documentation, Article 12 logging, conformity assessment, post-market monitoring, and 10-year record retention under Article 18.

Example 2: A hospital's medical-imaging assistant

A medical-imaging vendor sells a deep-learning model that highlights candidate regions on CT scans for a radiologist to review. The product is embedded in a medical device that already needs third-party conformity assessment under Regulation 2017/745. The system is on Route 1 (Annex I), high-risk by virtue of the host product's existing conformity-assessment regime, not because of Annex III. The 10-year retention under Article 18 sits on top of the medical-devices retention requirements; the more demanding rule wins per intersection. Note: if the model only highlights findings and the radiologist makes the diagnostic call, the Article 6(3) derogation argument is not available here because the Annex I route does not include that derogation. Annex I systems are high-risk by virtue of the host product, full stop.

Example 3: An HR vendor's CV-screening tool

A SaaS vendor sells a CV-screening tool that ranks candidates against a job description. Annex III area 4 (recruitment and selection). The vendor argues the system "merely flags patterns" and is therefore covered by derogation condition 3. The argument fails on the profiling carve-out: ranking candidates against criteria is, by definition, profiling. The system is high-risk and the vendor needs the full conformity-assessment package before placement on the EU market.

Example 4: A spelling-corrector inside an HR system

An HR product includes a spell-checker for hiring-manager comments. Technically inside the same product family as the CV-screening tool above, but its task is narrow procedural and improves a previously-completed human activity. It does not profile individuals. The Article 6(3) derogation applies, and the system is not high-risk. The provider should document the assessment under Article 6(4).

Example 5: A grid operator's load-forecasting model

A national grid operator runs an AI model to forecast load and schedule generation dispatch. Annex III area 2 (critical infrastructure, electricity supply). The model is a safety component because it influences automated control decisions. The derogation does not apply because the decision is substantive and outcomes affect public safety. The system is high-risk. Audit-trail retention has to span both EU AI Act requirements and any sectoral regulatory regime.

Example 6: A research lab's image-classification benchmark

An academic lab fine-tunes an image classifier on a public dataset for a benchmark paper. The system is not placed on the EU market or put into service. Article 6 does not apply at all; the AI Act's research carve-out covers this case. Note: the same model, retrained and deployed by a startup for commercial customer use, becomes a separate AI system and needs its own classification.

High-risk vs. other AI Act risk tiers

The EU AI Act sorts AI systems into four risk tiers. Knowing which tier your system sits in determines which obligations apply.

Risk tier	What it covers	Obligations	Relevant article
Unacceptable	Practices prohibited entirely (general-purpose social scoring of natural persons, real-time remote biometric identification in publicly accessible spaces for law enforcement with narrow exceptions, manipulative AI exploiting vulnerabilities, untargeted scraping of facial images, etc.)	None. The system cannot be placed on the market or used. Fines up to €35M or 7% of turnover.	Article 5
High	Annex I embedded + Annex III standalone (the subject of this page)	Full Chapter III Section 2 obligations: risk management, technical documentation, logging, conformity assessment, registration, post-market monitoring, 10-year retention. Fines up to €15M or 3%.	Article 6; Chapter III
Limited (transparency)	Systems interacting with humans (chatbots), emotion-recognition or biometric categorisation systems, AI-generated synthetic media (deepfakes), AI-generated text on matters of public interest	Disclosure obligations: users must be told they are interacting with AI; synthetic media must be marked as such.	Article 50
Minimal	Everything else (spam filters, AI-enabled video games, basic recommendation engines for non-sensitive content)	Voluntary codes of conduct. No mandatory obligations under the AI Act.	N/A

The high-risk tier is the only one with operational compliance work attached. A system classified as limited risk only owes user disclosure, not the technical-documentation and audit-trail apparatus. The cost asymmetry across tiers is why getting the Article 6 classification right is the highest-leverage diagnostic an AI team can run.

What being high-risk actually requires

Once a system is classified as high-risk, the operational consequences fall into seven categories. Each maps to a separate audit-trail design problem.

1. Risk-management system (Article 9): a documented, iterated process for identifying and mitigating known and foreseeable risks.
2. Data governance (Article 10): training, validation, and testing datasets must be relevant, representative, free of errors, and complete to the extent technically possible.
3. Technical documentation (Article 11 + Annex IV): a 9-section technical file covering system description, development process, monitoring and control, performance metric justification, risk management, lifecycle changes, applied standards, the EU Declaration of Conformity, and the post-market monitoring plan.
4. Record-keeping (Article 12): the system must technically allow automatic event logging over its lifetime.
5. Transparency and human oversight (Articles 13 and 14): instructions for use; oversight measures the deployer can act on.
6. Accuracy, robustness, and cybersecurity (Article 15): performance thresholds appropriate to the intended purpose.
7. Quality management system, conformity assessment, CE marking, registration, and 10-year retention (Articles 17, 43, 47, 49, 18).

Five of the seven map directly to evidence that has to exist at the time of the decision, has to remain unaltered for at least 6 months (Article 19 deployer logs) or 10 years (Article 18 technical documentation), and has to be presentable to a regulator on demand. A mutable observability database can do most of the operational job but cannot meet the tamper-evidence requirement that makes records audit-grade. This is the gap ar.io's Internal AI Audit product is designed for.

FAQs

What are high-risk AI systems under the EU AI Act?

High-risk AI systems are AI systems that fall within Article 6 of the EU AI Act, either because they are a safety component of, or themselves, a product covered by EU sectoral safety legislation listed in Annex I (and required to undergo third-party conformity assessment), or because they fall within one of the 8 standalone use-case areas listed in Annex III. The 8 Annex III areas are biometrics; critical infrastructure; education and vocational training; employment and workers management; access to essential private and public services and benefits; law enforcement; migration, asylum, and border control; and administration of justice and democratic processes. High-risk classification triggers the full Chapter III Section 2 obligation set.

Is my AI system high-risk?

Run the classification in this order. First, check Annex I: is the system a safety component of, or itself, a product on the Annex I list that requires third-party conformity assessment? If yes, the system is high-risk. Second, check Annex III: does the system's intended purpose fall in any of the 8 use-case areas? If yes, the system is presumptively high-risk. Third, check Article 6(3): does the system meet at least one of the four derogation conditions (narrow procedural task, improvement of completed human work, pattern detection without replacing human judgment, or preparatory task) and not perform profiling? If yes, you can rely on the derogation by documenting the assessment before market placement, registering the system under Article 49(2), and providing the documentation to the national competent authority on request (all under Article 6(4)). If the system performs profiling of individuals, the derogation never applies.

What is Article 6 of the EU AI Act?

Article 6 is the classification rule that determines whether an AI system is high-risk. It defines the two routes: Annex I embedded systems (Article 6(1)) and Annex III standalone systems (Article 6(2)), and the derogation that excludes some Annex III systems where they do not pose significant risk (Article 6(3)). Article 6(4) obliges providers who rely on the derogation to document the assessment before placing the system on the market, register the system in the EU database under Article 49(2), and provide the documentation to the national competent authority on request. Article 6 sits at the top of Chapter III, ahead of the obligations themselves, because everything that follows depends on whether the classification applies.

What are the Annex III high-risk AI categories?

Annex III lists 8 categories: (1) biometrics; (2) critical infrastructure; (3) education and vocational training; (4) employment, workers management, and access to self-employment; (5) access to essential private and public services and benefits; (6) law enforcement; (7) migration, asylum, and border control; (8) administration of justice and democratic processes. Each category contains specific enumerated use cases. The list is not aspirational, it is operational: a system that fits any enumerated use case is presumptively high-risk unless the Article 6(3) derogation applies.

When do the high-risk AI obligations apply?

Annex III standalone high-risk obligations were originally due to apply on 2 August 2026. Under the 2026-05-07 Digital Omnibus on AI provisional agreement, application for new and substantially-modified Annex III systems is deferred to 2 December 2027; Annex I embedded systems to 2 August 2028. The deferrals are still subject to formal adoption by the co-legislators. The substantive obligations themselves were not relaxed. See the EU AI Act compliance page for the article-by-article timeline.

Does the deferral mean I can wait to act?

No. Conformity-assessment capacity for high-risk AI is finite and notified bodies are scarce. Organisations that planned for the original 2 August 2026 date are already in the queue. Coming in late means competing for the same notified-body capacity with a year less runway. The audit-trail infrastructure also has to be in place before the system is placed on the market, not retrofitted after, because Article 11 technical documentation and Article 12 logging both require evidence captured at the time of the relevant event.

Do high-risk AI obligations apply to non-EU providers?

Yes, when the provider places the system on the EU market or the output is used in the EU. The AI Act has extraterritorial reach. Most large US and UK enterprises with European customers, employees, or suppliers will fall under it. Authorities can take enforcement action against non-EU providers through the EU representative the provider is required to designate under Article 22.

How does ar.io help with high-risk AI compliance?

ar.io produces tamper-evident, cryptographic audit trails of training data, model checkpoints, inference inputs and outputs, and the derogation-assessment evidence required under Article 6(4). The records are anchored to permanent storage. A regulator or notified body can verify integrity using only the artefact and the public anchored record, without needing the vendor's cooperation. This satisfies the Article 11 technical-documentation, Article 12 logging, Article 18 ten-year retention, and Article 19 deployer-log retention obligations on a single substrate. The integration is an MLflow plugin or a REST API call from inside the customer's environment. The underlying data never leaves the customer's perimeter. The architecture is called proof without access; the full mechanics are covered in the proof-without-access explainer.

Next step

The single highest-leverage diagnostic an AI team can run on any system shipping into the EU is the Article 6 classification. If the answer is high-risk, the obligations are full Chapter III Section 2; if the answer is high-risk under derogation, the assessment itself has to be evidenced and retained. Both paths need audit-grade records that exist at the time of the relevant event, cannot be silently altered, and are self-authenticating without vendor cooperation.

Book a demo to see what fingerprinting your training pipeline, model registry, and output stream looks like end to end, or read the EU AI Act compliance page for the article-by-article operational detail.