High-risk AI systems

High-risk classification under Article 6 is the bulk of the substantive obligations in the EU AI Act. This page covers the two routes to high-risk under Article 6 (Annex I products and Annex III standalone use cases), the Articles 8–15 lifecycle obligations on providers, and the Article 27 fundamental-rights impact assessment on certain deployers.

This is one of four obligation regimes under the Regulation — see the overview for how high-risk classification interacts with Article 5 prohibited practices, Article 50 transparency duties, and Chapter V GPAI.

Quick decision

• You are building or shipping an AI system whose intended purpose falls under Annex III (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration / border, justice / democracy) → Article 6(2) applies. Check Article 6(3) derogation — but profiling is always high-risk.
• Your AI system is itself a product, or a safety component of a product, covered by Annex I Section A sectoral law (medical devices, machinery, lifts, toys, etc.) → Article 6(1) applies. The Articles 8–15 obligations integrate into the sectoral conformity-assessment regime under Article 43(3). For Annex I Section B products (motor vehicles, aviation security, marine equipment, etc.), only Article 6(1), Articles 102–109 (channelling into sectoral acts), Article 112 (and conditional Article 57) apply per Article 2(2) — Articles 8–15 do not directly apply.
• You are a public-sector deployer, a private entity providing public services, or a deployer using Annex III(5)(b) or (c) systems (credit / insurance risk pricing) → Article 27 FRIA applies before first use to Article 6(2) Annex III high-risk systems, with the exception of Annex III point 2 (critical infrastructure) which Article 27(1) excludes.
• Want to know if Article 50 transparency duties also apply → see Prohibited practices and transparency. The two regimes are independent and stack.

TL;DR

• Two routes to high-risk under Article 6: Annex I (regulated products) and Annex III (standalone use cases). They are not one bucket; they have different conformity-assessment paths.
• Article 6(3) derogation allows an Annex III system to escape high-risk classification if it does not pose a significant risk and any one of the conditions in Article 6(3)(a)–(d) is fulfilled (note: the conditions are alternative, not cumulative). Profiling of natural persons is always high-risk under Article 6(3) sub-paragraph 2. Article 6(4) (documentation) and Article 49(2) (EU-database registration of the not-high-risk determination) are in the published Regulation — not Omnibus-contingent — and apply from the general Article 113 dates (2 August 2026 for Annex III; deferred to 2 December 2027 if the Omnibus is adopted).
• Articles 8–15 set the lifecycle obligations on providers: risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy / robustness / cybersecurity.
• Article 27 imposes a separate fundamental-rights impact assessment on public-sector deployers and certain private deployers of Article 6(2) Annex III high-risk systems (excluding Annex III point 2 critical infrastructure) — before first use.
• Annex III obligations apply from 2 August 2026 (Omnibus would defer to 2 December 2027 if adopted); Annex I from 2 August 2027 (Omnibus would defer to 2 August 2028).

AI Omnibus provisional agreement (May 2026)

Status: provisional political agreement, pending formal adoption

On 7 May 2026 the Council presidency and European Parliament negotiators reached a provisional political agreement on the Digital Omnibus on AI (originally proposed by the Commission on 19 November 2025, part of the 'Omnibus VII' simplification package). The deal must still be formally endorsed by the Council and the Parliament and undergo legal/linguistic revision before adoption. This framework page will be updated once the Omnibus is formally adopted. Until then, the existing EU AI Act text remains legally binding.

Relevant to this page (all conditional on formal adoption):

• Annex III high-risk obligations would shift to 2 December 2027 (from 2 August 2026); Annex I would shift to 2 August 2028 (from 2 August 2027) — replacing the Commission's readiness-decision model with fixed application dates.
• Annex III non-high-risk registration model would be reinstated — the existing Article 49(2) duty for providers that determine an Annex III system is not high-risk under Article 6(3) to register in the EU database would be preserved (the Commission's proposal had removed it).
• Sensitive-data exemption for bias correction would be kept, with 'strict necessity' standard reinstated — Article 10(5) processing of GDPR Article 9 special-category personal data for bias detection and correction in high-risk AI systems would remain permitted, but only when strictly necessary.
• Simplified compliance for Small Mid-Caps (SMCs) — simplified documentation and QMS obligations would apply to SMCs as defined in Commission Recommendation (EU) 2025/1099 (final scope subject to consolidated text).

Until adopted, the published 2024/1689 dates remain the binding reference.

Primary source

Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 — EUR-Lex CELEX 32024R1689 · OJ L, 12.7.2024 · Articles 6–15, Article 27, Annex I, Annex III, Annex IV.

Article 6 — classification rules for high-risk AI systems

Article 6(1) — AI as part of a product covered by Annex I

Irrespective of whether an AI system is placed on the market or put into service independently of the products referred to in points (a) and (b), that AI system shall be considered to be high-risk where both of the following conditions are fulfilled:

(a) the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I;

(b) the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I.

— Article 6(1), Regulation (EU) 2024/1689

The two cumulative conditions matter. An AI system covered by Annex I sectoral law that is not required to undergo a third-party conformity assessment under that law is not high-risk under Article 6(1). The third-party-conformity-assessment trigger is the operative hook.

Annex I lists the Union harmonisation legislation in two sections, which the AI Act treats differently:

• Section A — sectoral regulations for which the AI Act applies in full: machinery, toys, recreational craft, lifts, equipment used in explosive atmospheres, radio equipment, pressure equipment, cableway installations, personal protective equipment, gas appliances, medical devices, in vitro diagnostic medical devices. AI systems falling under Section A go through both the AI Act Article 6(1) classification and the sectoral conformity-assessment regime, integrated under Article 43(3). Article 8(2) separately requires the AI Act technical-documentation and reporting obligations to be integrated with the sectoral documentation rather than duplicated.
• Section B — sectoral regulations covering products whose AI-system safety components fall under a partial AI Act regime. Under Article 2(2), only specific AI Act provisions apply: Article 6(1) (high-risk classification trigger), Articles 102–109 (which require the Chapter III Section 2 Articles 8–15 requirements to be taken into account when adopting delegated or implementing acts under the sectoral law), Article 112 (Commission evaluation and review), and Article 57 insofar as the high-risk requirements have been integrated into the Section B sectoral legislation. Section B covers civil aviation security, two- or three-wheel vehicles and quadricycles, agricultural and forestry vehicles, marine equipment, rail interoperability, motor vehicles type-approval, and civil aviation. The substantive Article 9–15 obligations are not directly applied to Section B AI systems — they are channelled into the sectoral act via Articles 102–109.

Article 6(2) — Annex III standalone use cases

In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk.

— Article 6(2), Regulation (EU) 2024/1689

Annex III — the eight standalone use-case categories

Annex III lists eight numbered categories. Each contains sub-points that specify the exact AI uses in scope. The category headings alone are not the operative trigger — the sub-points are. The eight category headings are: (1) Biometrics; (2) Critical infrastructure; (3) Education and vocational training; (4) Employment, workers' management and access to self-employment; (5) Access to and enjoyment of essential private services and essential public services and benefits; (6) Law enforcement; (7) Migration, asylum and border control management; (8) Administration of justice and democratic processes. Consult Annex III directly for the binding per-category list.

Article 6(3) — derogation for low-significant-risk Annex III systems

By derogation from paragraph 2, an AI system referred to in Annex III shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making. The first subparagraph shall apply where any of the following conditions is fulfilled:

(a) the AI system is intended to perform a narrow procedural task;

(b) the AI system is intended to improve the result of a previously completed human activity;

(c) the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review; or

(d) the AI system is intended to perform a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III.

Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons.

— Article 6(3), Regulation (EU) 2024/1689

The Article 6(3) derogation is narrow and conditional, but the conditions in (a)–(d) are alternative, not cumulative — the first sub-paragraph applies where any of them is fulfilled, provided the no-significant-risk threshold is met. The provider must document the assessment under Article 6(4) before placing the system on the market or putting it into service, and register the not-high-risk determination in the EU database under Article 49(2) — both obligations are in the published Regulation (not Omnibus-contingent) and apply from the Article 113 application dates (2 August 2026 for Annex III; deferred to 2 December 2027 if the Omnibus is adopted). Profiling of natural persons (Article 4(4) GDPR definition referenced) remains always high-risk regardless of the Article 6(3)(a)–(d) conditions.

Articles 8–15 — substantive obligations on providers

Article 8 — compliance with the requirements

High-risk AI systems shall comply with the requirements laid down in this Section, taking into account their intended purpose as well as the generally acknowledged state of the art on AI and AI-related technologies. The risk management system referred to in Article 9 shall be taken into account when ensuring compliance with those requirements.

— Article 8(1), Regulation (EU) 2024/1689

The "intended purpose" anchor and the "state of the art" qualifier run throughout Section 2. Both are operative: an obligation is not absolute but must be implemented in light of the specific system and the prevailing technical baseline.

Article 9 — risk-management system

A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.

The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating. It shall comprise the following steps:

(a) the identification and analysis of the known and the reasonably foreseeable risks that the high-risk AI system can pose to health, safety or fundamental rights when the high-risk AI system is used in accordance with its intended purpose;

(b) the estimation and evaluation of the risks that may emerge when the high-risk AI system is used in accordance with its intended purpose, and under conditions of reasonably foreseeable misuse;

(c) the evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system referred to in Article 72;

(d) the adoption of appropriate and targeted risk management measures designed to address the risks identified pursuant to point (a).

— Article 9(1) and (2), Regulation (EU) 2024/1689

The Article 9 risk-management system is continuous and iterative across the lifecycle — it is not a one-time pre-market document. The Article 9(2)(c) hook to Article 72 post-market monitoring is what closes the loop after deployment.

Article 10 — data and data governance

High-risk AI systems which make use of techniques involving the training of AI models with data shall be developed on the basis of training, validation and testing data sets that meet the quality criteria referred to in paragraphs 2 to 5 whenever such data sets are used.

— Article 10(1), Regulation (EU) 2024/1689

Article 10(2) sets data governance and management practices — design choices, data collection processes and provenance, preparation operations (annotation, labelling, cleaning, enrichment, aggregation), assumptions about what the data measures, assessment of data quantity, examination of possible biases and mitigation measures, identification of relevant data gaps. Article 10(3) sets the quality criteria for training, validation and testing data sets: relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Article 10(4) requires consideration of the geographical, contextual, behavioural or functional setting in which the high-risk AI system is intended to be used. Article 10(5) is the bias-correction carve-out — processing of GDPR Article 9 special-category personal data is permitted only when strictly necessary to ensure bias detection and correction, subject to safeguards.

Article 11 — technical documentation

The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up-to date.

The technical documentation shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in this Section and to provide national competent authorities and notified bodies with the necessary information in a clear and comprehensive form to assess the compliance of the AI system with those requirements. It shall contain, at a minimum, the elements set out in Annex IV.

— Article 11(1), Regulation (EU) 2024/1689

Annex IV specifies the content (general description, design specifications, data requirements, training methodologies, validation and testing procedures, risk-management documentation, post-market monitoring plan, etc.). The documentation is "drawn up before … and kept up-to-date" — a living artefact, not a one-off filing.

Article 12 — record-keeping (logging)

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

— Article 12(1), Regulation (EU) 2024/1689

Article 12(2) requires the logging to enable identification of situations that may result in the system presenting a risk under Article 79(1) or in a substantial modification, and facilitate the post-market monitoring under Article 72 and the deployer-side monitoring under Article 26(5). Article 12(3)(d) separately requires logging to verify the result for Annex III(1)(a) post-remote biometric identification systems and to support human verification.

Article 13 — transparency and provision of information to deployers

High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. An appropriate type and degree of transparency shall be ensured with a view to achieving compliance with the relevant obligations of the provider and deployer set out in Section 3.

— Article 13(1), Regulation (EU) 2024/1689

Article 13(2) requires accompanying instructions for use containing concise, complete, correct and clear information for deployers. Article 13(3) lists the minimum content (identity and contact details of the provider; characteristics, capabilities and limitations of performance of the system; changes to the system; human oversight measures; expected lifetime; maintenance and care measures).

Article 14 — human oversight

High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.

— Article 14(1), Regulation (EU) 2024/1689

Article 14(4) lists the oversight measures the system must enable: understand the relevant capacities and limitations; remain aware of automation bias; correctly interpret the output; decide not to use or override the output; intervene in or interrupt the system. Article 14 is provider-side design; deployer-side execution sits in Article 26(2). The duty is distinct from Article 22 GDPR — see the overview.

Article 15 — accuracy, robustness and cybersecurity

High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle.

— Article 15(1), Regulation (EU) 2024/1689

Article 15(2) requires the Commission to encourage development of benchmarks and measurement methodologies. Article 15(3) requires declared accuracy levels in the instructions for use. Article 15(4) requires resilience against errors, faults or inconsistencies. Article 15(5) sets the cybersecurity-of-AI obligation: technical solutions aimed at AI-specific vulnerabilities shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws.

Article 17 — quality-management system (QMS)

Article 17 requires providers of high-risk AI systems to put in place a quality-management system documenting strategies, techniques, procedures and systematic actions covering, among other things: regulatory-compliance strategy, design control, quality-control techniques, data-management procedures, the risk-management system of Article 9, post-market monitoring of Article 72, incident-reporting under Article 73, communications with notified bodies, record-keeping, resource management (including security-of-supply), and the accountability framework. The QMS is the provider-side governance layer that operationalises Articles 8–15.

Article 27 — fundamental-rights impact assessment (FRIA)

Article 27 imposes a separate obligation on certain deployers of high-risk AI systems:

Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area of critical infrastructure referred to in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in point 5(b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce.

— Article 27(1), Regulation (EU) 2024/1689

Article 27(1)(a)–(f) lists what the FRIA must include: (a) a description of the deployer's processes; (b) the period and frequency of use; (c) categories of natural persons and groups likely to be affected; (d) specific risks of harm; (e) human-oversight measures according to the instructions for use; (f) measures to be taken in case of materialisation of those risks, including the arrangements for internal governance and complaint mechanisms. Article 27(3) further requires the deployer to notify the market-surveillance authority of the results of the FRIA by submitting the filled-out template (the template is developed by the AI Office under Article 27(5)). Article 27(4) allows the FRIA to complement a DPIA under Article 35 GDPR or Article 27 of Directive (EU) 2016/680 where applicable, but the assessments remain separate legal duties.

FRIA ≠ GDPR DPIA. The two assessments can share evidence but address different legal frameworks. A DPIA under Article 35 GDPR is required where the processing is likely to result in high risk to data subjects; a FRIA under Article 27 EU AI Act is required for Article 6(2) Annex III high-risk systems (excluding Annex III point 2 critical infrastructure) where the deployer is a public-law body, a private entity providing public services, or a deployer of an Annex III(5)(b) / (c) system.

How to operationalise high-risk obligations in Modulos

The high-risk regime maps onto MFF-1 (per-AI-system) and OFF-1 (organisation-level) requirements:

Requirement	Description	OJ Article
MRF-38	AI System Classification	Article 6
MRF-111	AI System Classification Exemption	Article 6(3)
MRF-42	Choice for Handling Sectoral Requirements	Article 8
MRF-1, ORF-1	Risk Management System (app / org)	Article 9
MRF-2	Data and Data Governance	Article 10
MRF-3	Technical Documentation	Article 11 + Annex IV
MRF-4	Implementing Record-Keeping Capability	Article 12
MRF-10	Keeping Logs by Provider	Article 12 / 19
MRF-5, ORF-5	Transparency and Provision of Information to Deployers	Article 13
MRF-6, ORF-6	Human Oversight	Article 14
MRF-7	Accuracy	Article 15
MRF-40	System Testing	Article 9 / 15
MRF-64	Robustness	Article 15
MRF-65	Cybersecurity	Article 15(5)
MRF-39	Accessibility	Article 16 (Directives 2016/2102, 2019/882)
MRF-41	Disclosure of Contact Information	Article 16(b)
MRF-43	High-Risk AI System Integration Support	Article 25
MRF-14, ORF-14	Use and Oversight (deployer)	Article 26
MRF-48	Relevant and Representative Data in Use	Article 26(4)
MRF-50	Keeping Logs by Deployer	Article 26(6)
MRF-52	Transparent Deployment at Workplace	Article 26(7)
MRF-51	Using Provider-Supplied Information for DPIA	Article 26(9)
MRF-55	Transparent Automated Decision-Making	Article 26(11)
MRF-56	Explanation of Automated Decisions	Article 86
MRF-15	Fundamental Rights Impact Assessment	Article 27

Operating rules:

• Article 17 quality-management system (ORF-8) is recorded on OFF-1, with the QMS documents linked as control-level evidence.
• Article 6(3) derogation assessments (MRF-111) document the rationale, the conditions satisfied, and the profiling check as control-level evidence.
• Article 27 FRIA (MRF-15) — no dedicated FRIA workflow surface; the FRIA document, its update history, and the Article 27(3) market-surveillance-authority notification artefact are stored as control-level evidence linked to the requirement.
• Annex IV technical documentation (MRF-3) is assembled as evidence linked to MFF-1 controls. Modulos supports point-in-time exports of project, control, and evidence records; building the Annex IV technical file as a single document is the provider's authoring task, with the platform serving as the evidence library that backs each Annex IV element.

Platform Article-numbering caveat: MRF-46 (post-market monitoring) references Article 61 internally — the final OJ-published Article is 72. The docs use OJ numbers; the platform field uses the legacy label.

Go deeper: Operationalizing in Modulos.

Cross-framework mapping (preview)

EU AI Act	Adjacent provision
Article 9 risk-management system	NIST AI RMF Core Functions (Govern / Map / Measure / Manage); ISO 42001 Clauses 6–10; ISO 27001 Annex A risk treatment
Article 10 data and data governance	GDPR Articles 5, 6, 9, 10; ISO 42001 Annex A; ISO 27701 PIMS
Article 11 technical documentation	ISO 42001 documented information; CE-marking technical-file conventions
Article 13 transparency to deployers	ISO 42001 Annex A; ISO 9241 ergonomics analogy
Article 14 human oversight	NIST AI RMF MEASURE 2.6; ISO 42001 Annex A; distinct from GDPR Article 22
Article 15(5) cybersecurity of AI	NIS2 Article 21; ISO 27001 Annex A; MITRE ATLAS
Article 27 FRIA	GDPR Article 35 DPIA (different assessment, may share evidence)

Related pages

Prohibited practices and transparency

Article 5 + Article 50 — obligations independent of high-risk classification

Roles and responsibilities

Provider vs deployer duties; Article 25 accidental-provider trap

Conformity assessment and CE marking

Article 43 routes; Annex VI / VII; declaration; CE marking; EU database registration

General-purpose AI models

Chapter V (Articles 51–56); how GPAI interacts with high-risk classification

Post-market monitoring

Article 72 PMM plan; Article 73 serious incidents (distinct from GDPR Art 33)

Operationalizing in Modulos

OFF-1 + MFF-1 rollout, scoping, evidence

ISO/IEC 42001 (AIMS)

The certifiable AI management-system standard most often used to operationalise high-risk obligations

Commission draft guidance on high-risk classification

Article 6(1) / 6(2) / 6(3) decision framework + the profiling override — draft, consultation closes 23 June 2026

Commission draft worked examples

Annex I sectoral + Annex III per-sub-point worked examples — draft Commission guidance

Source attribution

Regulation (EU) 2024/1689 — Articles 6, 8–15, 17, 27 and Annexes I, III, IV — is published in the Official Journal of the European Union L of 12 July 2024 (CELEX 32024R1689). Verbatim blockquotes on this page reflect the OJ-published text. The AI Omnibus consolidated text, when published, will supersede where it amends.

Disclaimer

This page is for general informational purposes and does not constitute legal advice.