How do the high-risk requirements work together in a real system?

Where does the walkthrough start?

The walkthrough starts with a general example: a provider developing a system intended to support a consequential screening decision, with a defined intended purpose, a defined affected population, and a defined deployment context. The provider first records the intended purpose, the users, the affected people, and the decision the output will influence. Classification under Article 6 is recorded, with the Annex route and any Article 6(3) analysis. That starting record is the anchor for everything that follows: every risk, dataset, test and oversight measure is judged against that purpose and context, not against a generic idea of the system. If the purpose changes, the walkthrough must be restarted for the new purpose, because the requirements analysis does not transfer automatically.

How do risk and data work together in the example?

Risk management identifies the risks of the screening use, including errors that affect particular groups, misuse outside the intended purpose, and failure modes in the deployment workflow. Data governance then supplies the datasets needed to examine those risks: training, validation and testing data that are relevant and representative for the population and context, examined for bias, with assumptions recorded. Bias examination uses the Article 10 approach, and any special category processing is assessed under Article 4a before it begins. Testing is designed against the risks identified, with predefined thresholds for accuracy and for performance differences across groups. A risk that has no corresponding test, or a test that has no corresponding risk, is flagged as a gap in the evidence chain and must be closed before the system proceeds.

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

How do documentation, logging and deployer information connect?

Technical documentation records the risk analysis, the data governance, the design choices, the testing, and the oversight design, in the form Annex IV requires. Logging capability is designed so that each screening operation can be traced to the inputs, the version, and the oversight action taken. Instructions for use extract the deployer-facing part of that file: the intended purpose, the limitations, the accuracy levels, the oversight measures, and the input conditions, in a form the deployer can use. The deployer then assigns competent oversight, briefs staff, and monitors operation. If the deployer reports an unexpected pattern, the provider can follow the log and the documentation to the relevant risk entry and test, rather than starting a new investigation from scratch. That traceability is the practical value of keeping the three records linked.

How do oversight and performance testing interact?

Oversight design and performance testing are tested together, not separately. The provider tests the system with overseers in the real workflow, checking whether overseers can understand the output, detect anomalies, intervene, and override where needed, under realistic volumes. Performance testing checks accuracy and robustness, including adversarial resilience, against predefined thresholds. The combined test shows whether the human and system together achieve the intended outcome, and whether automation bias is undermining oversight. Where the combined test shows a weakness, the provider can change the design, the tools, the training, or the limitations on use, and can retest the affected part. The decision and the retest are recorded in the risk file, so that the final conformity conclusion rests on the tested configuration.

What happens after the system is placed on the market?

After placement, post-market monitoring reviews logs, deployer feedback, incident reports and performance data against the risk file and the thresholds. A drift in performance, a new deployment context, or a pattern of overseer overrides triggers a risk reassessment and, where needed, a corrective measure, a documentation update, and a new conformity assessment if the change is substantial. The evidence chain is updated with dated entries, earlier versions are retained, and deployers are notified of material changes with updated instructions. The walkthrough therefore does not end at placement: the requirements in Articles 9 to 15 are lifecycle requirements, and the file must show that they were maintained, not only that they were met once. A system whose file stops at release has not been shown to meet the lifecycle standard.

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

What does this walkthrough not decide?

This walkthrough does not decide whether any real screening system is high-risk, whether its risks have been correctly identified, whether its testing is sufficient, or whether it meets Articles 9 to 15. It does not set a threshold, approve a dataset, or design an oversight workflow for a specific deployment. The example is general and illustrative, and every step must be carried out on the facts of the actual system, with the consolidated legal text and qualified review where the position is contested. A team should use the walkthrough as a structure for its own file, not as a substitute for the analysis the file must contain.

Frequently asked questions

Continue through this AI Act cluster

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