What is the difference between high-risk requirements and actor obligations?

What do Articles 9 to 15 require of the system?

Articles 9 to 15 set the substantive standard for the system itself: a risk management system, data governance, technical documentation, logging capability, transparency to deployers, human oversight design, and accuracy, robustness and cybersecurity. Those requirements are assessed by reference to the system's design, development, testing and operation, and the evidence is found in the system's technical file, test results and monitoring data. A requirement is met when the system, as designed and operated, achieves the standard the article sets, in light of its intended purpose. The requirement does not, by itself, name the filing, the registration, or the process by which an actor demonstrates that the standard is met; those steps belong to the obligations layer.

What do Articles 16 to 27 require of actors?

Articles 16 to 27 set obligations for actors. Providers must, in outline, ensure the system meets Articles 9 to 15, operate a quality management system, keep documentation and logs, carry out conformity assessment, draw up a declaration of conformity, affix CE marking, register the system where required, take corrective action, and inform authorities and deployers as the Act provides. Authorised representatives, importers and distributors have verification and cooperation duties. Deployers must use the system in accordance with instructions, assign competent oversight, monitor operation, keep logs, inform workers and affected persons where required, and carry out a fundamental rights impact assessment where Article 27 applies. Each obligation has an owner, a timetable, and a record, and the absence of a record for an obligation is a gap even where the system design is sound.

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

How do the two layers interact in conformity assessment?

Conformity assessment under Article 43 tests whether the system meets the Section 2 requirements, using the quality management system and the technical documentation as evidence. The assessment therefore bridges the two layers: the requirements supply the standard, and the obligations supply the process and the file by which the standard is shown to be met. A provider that has built a sound system but has no quality management system, no controlled documentation, or no conformity procedure will struggle to pass an assessment, because the assessor cannot verify the requirements from an uncontrolled file. Conversely, a provider with a polished quality system but a system that fails its accuracy or robustness thresholds will not pass, because the process does not cure a substantive failure. Both layers must be ready at the same time.

How should a team map both layers for one system?

A team should create a two-layer map for each system: one column listing each requirement in Articles 9 to 15 with the design, testing and documentation evidence for that requirement, and a second column listing each obligation for each actor with the owner, the action, the timetable and the record. The map should show the links between the layers, for example where a risk management measure in Article 9 is evidenced by a document that the provider must keep under Article 18, or where an oversight design in Article 14 is operated by a deployer under Article 26. Gaps should be visible as empty cells, not hidden in narrative. The map should be reviewed when the system, the actors, or the deployment changes, because a role change under Article 25 can move obligations between actors while the requirements stay with the system.

What happens when roles change?

Roles can change during the lifecycle, and a role change moves obligations even where the system requirements are unchanged. Under Article 25, a deployer, importer, distributor or other third party can become the provider of a high-risk system where it puts its name or trademark on the system, makes a substantial modification, or changes the intended purpose so that the system becomes high-risk. That new provider then faces the provider obligations, including quality management and conformity assessment, for the system as modified. The requirements in Articles 9 to 15 must then be met for the modified system, with new documentation and testing as needed. Teams should record role assessments at each change, and should not assume that the original provider's obligations continue to cover a system that another party has substantially modified or repurposed.

Continue with Conformity assessment and CE marking.

What does this guide not decide?

This guide does not decide whether a particular system meets a requirement, whether an actor has met an obligation, or whether a role has changed under Article 25. It does not allocate obligations for a specific product chain or assess a conformity file. Those questions depend on the system, the actors, the changes made, and the consolidated legal text. A team should confirm the two-layer map for each system with a competent authority or legal adviser, keep the map current, and revisit it whenever the system, the actors, or the deployment changes.

Frequently asked questions

Continue through this AI Act cluster

• High-risk requirements overview
• Conformity assessment and CE marking
• Provider responsibilities
• Deployer responsibilities
• High-risk AI systems
• What risk management system does Article 9 require?