EU AI Act Article 15: Accuracy, Robustness and Cybersecurity Requirements

What Article 15 Covers

Article 15 of Regulation (EU) 2024/1689 sets the technical performance requirements for high-risk AI systems. Article 15(1) requires such systems to be designed and developed in a way that they achieve an appropriate level of accuracy, robustness and cybersecurity, and that they perform consistently in those respects throughout their lifecycle. The word appropriate signals proportionality: the required level depends on the intended purpose and the risks at stake, assessed through the Article 9 risk management system and against the state of the art referenced in Article 8.

The lifecycle language is equally important. A system that was accurate at launch but degrades silently as input distributions drift does not comply. Article 15 therefore presupposes ongoing measurement, which connects it to the logging required by Article 12 and the post-market monitoring required by Article 72.

Accuracy: Measured and Declared

Article 15(3) requires the levels of accuracy and the relevant accuracy metrics of high-risk AI systems to be declared in the accompanying instructions for use. This turns accuracy from an internal engineering matter into a public, verifiable commitment to deployers. Providers must choose metrics honestly suited to the task, such as error rates per class or per population subgroup where the system affects people differently, and must report the conditions under which the figures were obtained.

To support comparability, Article 15(2) tasks the Commission, in cooperation with relevant stakeholders and organisations such as metrology and benchmarking authorities, with encouraging the development of benchmarks and measurement methodologies for accuracy, robustness and cybersecurity.

Robustness: Errors, Faults and Feedback Loops

Article 15(4) requires high-risk AI systems to be as resilient as possible regarding errors, faults or inconsistencies that may occur within the system or in the environment in which it operates, in particular due to their interaction with natural persons or other systems. Technical and organisational measures shall be taken in this regard.

The provision names concrete engineering strategies: robustness may be achieved through technical redundancy solutions, which may include backup or fail-safe plans. For a system that screens loan applications, that could mean a deterministic fallback rule set and a queue for human review when the model is unavailable or returns low-confidence outputs.

Article 15(4) also contains one of the regulation's most operationally significant clauses for adaptive systems: high-risk AI systems that continue to learn after being placed on the market shall be developed in such a way as to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations, known as feedback loops, and to ensure that any such feedback loops are duly addressed with appropriate mitigation measures. A recommendation or scoring system that learns from its own past decisions must therefore be designed to detect and dampen self-reinforcing bias.

Cybersecurity: AI-Specific Attack Surfaces

Article 15(5) requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. Technical solutions must be appropriate to the relevant circumstances and risks, and must include, where appropriate, measures to prevent, detect, respond to, resolve and control attacks specific to AI, namely:

• Data poisoning: attempts to manipulate the training dataset.
• Model poisoning: attempts to manipulate pre-trained components used in training.
• Adversarial examples or model evasion: inputs designed to cause the model to make a mistake.
• Confidentiality attacks: attempts to extract sensitive information from the model or its data.
• Model flaws exploited by attackers.

This list goes beyond classical IT security. Providers need machine-learning-specific threat modelling covering the training pipeline, the supply chain of pre-trained models and the inference interface, in addition to conventional access control and infrastructure security.

How to Implement Article 15 in Practice

1. Define target levels per metric in the risk management system, justified by the intended purpose and the consequences of errors, and record the rationale in the Article 11 technical documentation.
2. Build an evaluation harness that runs on every release: accuracy on representative test sets, subgroup performance where relevant, stress tests with corrupted and out-of-distribution inputs, and regression checks.
3. Engineer graceful degradation: input validation, confidence thresholds, fallback behaviour, redundancy and clearly defined fail-safe states.
4. For continuously learning systems, separate the learning signal from the system's own outputs where possible, monitor for feedback-loop drift and document the mitigation design.
5. Run AI-specific security testing, including adversarial evaluation and provenance checks on third-party models and datasets, alongside standard penetration testing.
6. Declare results honestly in the instructions for use under Articles 13 and 15(3), including known conditions that degrade performance.

A Concrete Example

A provider of a facial-recognition-free identity verification system that examines document authenticity for bank onboarding, a use that can fall under Annex III depending on configuration, would set target false-acceptance and false-rejection rates, evaluate them across document types and lighting conditions, implement a fail-safe route to manual review, test the model against manipulated document images designed to evade detection, and verify that a third-party pre-trained vision model in its pipeline has documented provenance. Each step maps directly onto a paragraph of Article 15.

How Article 15 Connects to Other Provisions

Article 15 operationalises the performance dimension of the Article 9 risk management system and feeds the declarations required by Article 13. Evidence of testing belongs in the Annex IV technical documentation under Article 11. Degradation discovered in the field flows through Article 72 post-market monitoring into Article 20 corrective actions, and severe failures may constitute serious incidents reportable under Article 73. Compliance may also draw on horizontal cybersecurity law: the Cyber Resilience Act and harmonised standards under Article 40 will be relevant tools for demonstrating conformity.

Actions to Take Before August 2, 2026

Providers should establish their evaluation and security-testing infrastructure now, because credible accuracy declarations require accumulated test evidence, not a single late benchmark run. Teams using third-party or open-source pre-trained models should inventory them and assess model poisoning and provenance risk. Deployers should ask candidate providers for their declared metrics and the conditions behind them. The requirements apply to high-risk AI systems from August 2, 2026. This article provides general information about Regulation (EU) 2024/1689 and is not advice on any specific system.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.