Vigilis
EU AI Act

Accuracy, robustness, and cybersecurity requirements (Article 15)

Sourced from Regulation (EU) 2024/1689 (the EU AI Act), Article 15

In short

Article 15 is the technical backbone of the Act’s safety guarantees for high-risk systems. Accuracy must be tested and declared in the instructions for use, not just achieved. Robustness requires redundancy and fail-safes, plus controls against harmful feedback loops for systems that keep learning. Cybersecurity requires defences against the AI-specific attacks the Act names (data poisoning, model poisoning, adversarial examples, and confidentiality attacks) which generic IT security doesn’t automatically cover. Testing must be evidenced with real metrics and thresholds, reusing the Article 9 pre-deployment numbers.

Article 15 is the technical backbone of the Act’s safety guarantees for high-risk systems: accuracy and bias testing catch discriminatory outcomes, while robustness and cybersecurity testing prevent the system degrading or being manipulated once it is in real use.

Accuracy, tested and declared, not assumed

Article 15(1)-(2) requires the system to achieve an appropriate level of accuracy for its intended purpose, and requires that level to be tested and declared in the instructions for use. A system that performs well without a documented accuracy metric and test result does not satisfy this, the Act requires the claim to be evidenced, not just true.

Robustness, resilience to errors and drift

Article 15(4) requires technical redundancy (backup plans and fail-safe mechanisms) so the system remains resilient to errors, faults, or inconsistencies that may arise within its intended environment. Where a system continues to learn or update itself after deployment, specific controls are required to detect and correct harmful feedback loops, where the system’s own outputs bias its future training data; this control is not applicable to a system that is static once deployed.

Cybersecurity, the AI-specific attack categories

Article 15(5) requires controls against the attack categories the Act specifically names:

  • Data poisoning, tampering with training data to corrupt the model.
  • Model poisoning, tampering with pre-trained components the system relies on.
  • Adversarial examples, inputs deliberately crafted to fool the model.
  • Confidentiality attacks, extracting training data or model internals from the deployed system.

Generic IT security controls do not automatically cover these categories, access controls and network security are necessary but not sufficient; the testing has to specifically target the model and its training pipeline.

Evidence, not just the fact that testing happened

Accuracy, robustness, and cybersecurity testing results need to be recorded as evidence, a statement that “testing was conducted” does not substitute for the actual test results, metrics, and thresholds used, which is what a market surveillance authority or notified body will expect to review.

Article 15 obligations sit alongside, not instead of, the risk management system (Article 9) , the specific metrics and thresholds this article requires should be the same ones the Article 9(6)-(8) pre-deployment testing regime defines, rather than a separate parallel set of numbers.

Frequently asked questions

What does Article 15 of the EU AI Act require?
An appropriate, tested, and declared level of accuracy; robustness through redundancy and fail-safe mechanisms (plus controls against harmful feedback loops for self-learning systems); and cybersecurity against AI-specific attacks, with all testing evidenced by recorded metrics and thresholds.
What AI-specific cyberattacks does Article 15 name?
Data poisoning (corrupting training data), model poisoning (tampering with pre-trained components), adversarial examples (inputs crafted to fool the model), and confidentiality attacks (extracting training data or model internals). Generic IT controls are necessary but not sufficient to cover these.
Is it enough to state that testing was conducted?
No. Article 15 requires the actual test results, metrics, and thresholds to be recorded as evidence, and these should be the same metrics the Article 9(6)-(8) pre-deployment testing regime defines, not a separate parallel set.

Related guides

Not sure where your company stands?

Our free assessment gives you an indicative result in minutes (free and anonymous) no account needed.

Start the free check