What requirements must high-risk AI systems meet?

Which systems face Articles 9 to 15?

Articles 9 to 15 apply to high-risk AI systems as classified under Article 6. That includes systems covered by Article 6(1), where an AI system is a safety component of a product or is itself a product under the Union legislation in Annex I and third-party conformity assessment is required, and systems covered by Article 6(2), where the use case is listed in Annex III. The route matters because it affects the conformity procedure and the application date, but the Section 2 requirements themselves form a single package for high-risk systems. A team should first record the classification route, the Annex relied on, and any Article 6(3) analysis, before mapping the requirements. Starting with the requirements before settling classification risks building controls for the wrong route or missing a route-specific step.

How do Articles 9 to 15 work as a package?

The seven articles are interdependent. Risk management in Article 9 identifies and evaluates risks and sets the measures that the other articles must support. Data governance in Article 10 governs the data on which the system is developed and tested. Technical documentation in Article 11 records how the requirements are met. Record-keeping in Article 12 creates the logs that make operation traceable. Transparency in Article 13 gives deployers the information they need to use the system correctly. Human oversight in Article 14 designs the human role that the other controls assume. Accuracy, robustness and cybersecurity in Article 15 set the performance and resilience standard the system must achieve. A gap in one article therefore weakens the others: a risk measure that is not documented, logged, explained to the deployer, or overseen cannot be shown to work.

For the broader regulatory framework, see High-risk requirements overview.

What is the difference between requirements and obligations?

Requirements in Articles 9 to 15 describe what a high-risk system must achieve in design, development and operation. Obligations in Articles 16 to 27 describe what particular actors must do, such as operating a quality management system, carrying out conformity assessment, registering a system, or, for deployers, using the system in accordance with instructions and carrying out a fundamental rights impact assessment where required. The distinction matters for evidence: a requirement is evidenced by design, testing and documentation for the system, while an obligation is evidenced by a process, a decision or a filing by the actor. Teams should map both layers for each system, name the owner for each obligation, and link the requirement evidence to the obligation record, so that neither layer is mistaken for the other.

When do the high-risk requirements apply?

Following Regulation (EU) 2026/1744, which entered into force on 27 July 2026 and amended the application dates in Article 113, Chapter III Sections 1 to 3 high-risk rules apply for Annex III systems from 2 December 2027 and for Annex I product-embedded systems from 2 August 2028. Those later dates do not postpone the earlier duties for prohibited practices, AI literacy, general-purpose AI models or transparency, which apply from their own earlier dates. Teams should record the provision alongside its application date for each system, check transitional rules in Article 111 where a system was already placed on the market, and plan the evidence work well before the applicable date. A plan that starts only when the date arrives will not have the testing and documentation the requirements call for.

How should a provider plan the requirements work?

A provider should plan the work as a lifecycle programme, not as a release checklist. The programme should start with intended purpose and classification, move through risk management and data governance, produce documentation and logging design, design oversight and deployer information, and test accuracy, robustness and cybersecurity against pre-set thresholds. Each stage should have an owner, a review point, and a link to the quality management system. The programme should also plan for post-market monitoring and for reassessment when the system, its data, or its deployment changes. A staged plan with dated milestones, named reviewers and a single evidence index is easier to audit than a set of disconnected documents produced at the end of development.

Continue with Article 9 risk management for high-risk systems.

What does this overview not decide?

This overview does not decide whether a particular system is high-risk, which Annex route applies, whether any requirement has been met, or what conformity route must be followed. It does not set a risk threshold, a data standard, or a performance level for a specific system. Those questions depend on the system's intended purpose, its classification analysis, its design and testing evidence, and the consolidated legal text. A provider or deployer should confirm the classification and the requirements programme with a competent authority or legal adviser, keep the reasoning and evidence together, and revisit the overview whenever the system or the official guidance changes.

Frequently asked questions

Continue through this AI Act cluster

• High-risk requirements overview
• Article 9 risk management for high-risk systems
• Article 10 data and data governance
• High-risk AI systems
• Conformity assessment and CE marking
• What technical documentation does Article 11 require?