What accuracy, robustness and cybersecurity does Article 15 require?

How is an appropriate level of accuracy set?

An appropriate level of accuracy is set in light of the intended purpose, the people affected, and the consequences of error. It is not a universal percentage that applies to every system. The provider should define accuracy metrics and thresholds before testing, test against those thresholds using data that reflects the deployment context, and declare the levels achieved in the instructions for use. The declaration should state the conditions under which the levels were measured, including the data, the population, and any limitation that affects the result. A system whose accuracy is high on average but poor for a particular affected group has not been shown to be accurate for its intended purpose, and the testing and declaration should surface that difference rather than hide it behind an aggregate figure.

What does robustness require?

Robustness requires the system to be resilient to errors, faults and inconsistencies that may occur within the system or in the environment in which it operates, particularly due to interaction with people or other systems. That includes handling unexpected, incomplete or malformed inputs gracefully, maintaining safe behaviour when a component fails, and avoiding a single error cascading into a consequential wrong output. Robustness should be tested with realistic edge cases, degraded inputs, and operational faults, and the results should be recorded with the thresholds applied. The provider should also consider robustness across the lifecycle: a system that is robust at release but degrades as data or deployment conditions drift needs monitoring and a trigger for reassessment, linked to post-market monitoring.

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

How should adversarial threats be addressed?

Article 15 requires high-risk systems to be resilient, as far as possible, to attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. That includes, in outline, data poisoning, model poisoning, adversarial examples, model evasion, and confidentiality attacks, as relevant to the system. The provider should carry out a threat assessment for the system, test against the threats identified using appropriate technical solutions, and record the measures taken and their limits. Adversarial testing should be proportionate to the risk and the exposure of the system, and should be repeated when the threat landscape or the system changes. A security test that covers only one attack type, or that is carried out once and never revisited, will not support a continuing claim of resilience.

What cybersecurity protection is expected?

Cybersecurity protection under Article 15 must address the system's vulnerabilities and protect it against unauthorised alteration, in a way that is appropriate to the risks and the deployment context. In practice that includes secure development, access control, protection of models, data and logs, detection of compromise, and response and recovery arrangements. Cybersecurity measures should be documented, tested, and linked to the risk management file, so that a security weakness is treated as a risk to be managed rather than as a separate IT matter. The provider should also give deployers the information they need to operate the system securely, including configuration, update and access requirements, in the instructions for use. A system that is accurate in a laboratory but insecure in deployment has not met the Article 15 package as a whole.

How are accuracy, robustness and cybersecurity evidenced over time?

Evidence should cover the full lifecycle: pre-release testing against pre-set thresholds, deployment checks that the system performs as tested in its real context, and post-market monitoring that detects drift, new threats, or performance changes. Each stage should have named metrics, thresholds, owners and review dates, and the results should be linked to the risk management file and the technical documentation. Where a threshold is not met, the provider should record the decision taken, whether that is remediation, a limitation on use, or withdrawal, and should inform deployers where the change affects their operation. Performance claims in marketing or procurement material should match the declared levels in the instructions for use, so that a deployer is not led to rely on a level the testing does not support.

Continue with Testing and validation for high-risk systems.

What does this guide not decide?

This guide does not decide what accuracy level is appropriate for a particular system, whether a robustness or cybersecurity measure is sufficient, or whether a system has met Article 15. It does not set a metric, a threshold, or a security control for any system. Those questions depend on the intended purpose, the affected people, the threat model, the testing evidence, and the consolidated legal text. A provider should define metrics and thresholds before testing, have the testing and security work reviewed by competent reviewers, and confirm the position with a competent authority or legal adviser where the risk picture is contested.

Frequently asked questions

Continue through this AI Act cluster

• High-risk requirements overview
• Testing and validation for high-risk systems
• Article 9 risk management for high-risk systems
• High-risk AI systems
• Provider responsibilities
• What data and data governance does Article 10 require?