Accuracy, Robustness and Cybersecurity Requirements (Article 15)

Article 15 is the article engineers skim because it sounds like it is telling them to build a good system. Buried in the middle of it is a publication obligation: whatever accuracy the system achieves, and the metrics used to say so, go into the instructions for use, where a customer and a market surveillance authority can both read them.

Three properties, one lifecycle standard

Article 15(1) of Regulation (EU) 2024/1689 requires that high-risk AI systems be designed and developed to achieve an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently in those respects throughout their lifecycle. The lifecycle qualifier is the part that binds this article to the rest of the Regulation: a system that met its accuracy claim at conformity assessment and has since drifted is not compliant simply because it was once tested. That is why Article 72 post-market monitoring exists and why Article 17(1)(h) requires the monitoring system to be part of the quality management system.

The word “appropriate” is doing a great deal of work and the Regulation does not define a floor. There is no percentage in Article 15. The level is appropriate relative to the intended purpose declared under Article 11 and Annex IV, which means a provider effectively sets its own bar and is then held to it — by the declaration duty below, by Article 9 risk management, and by Article 73 serious-incident reporting if the gap between claim and behaviour causes harm.

The disclosure duty in Article 15(3)

Article 15(3) says the levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use. Article 13(3)(b)(ii) says the same thing from the other direction: the instructions must state the level of accuracy, including its metrics, robustness and cybersecurity against which the system has been tested and validated and which can be expected, plus any known or foreseeable circumstances that may have an impact on that expected level.

Read together, these two provisions require three separate things that are commonly collapsed into one:

• The metric, named. Not “accuracy” but which one — and the choice is substantive. Precision, recall, F1, AUC, word error rate, equal error rate and top-1 accuracy answer different questions, and a system reported on the flattering one is still reported on a real metric.
• The level achieved, against a stated test and validation set. A number with no population attached is not a declaration, and Article 10 data governance requires the provider to be able to describe the validation data anyway.
• The circumstances that degrade it. This is the sentence most instructions leave out. Known and foreseeable conditions that move the number — a demographic the training data underrepresents, an input modality outside the tested range, a hardware configuration — are part of the required disclosure, not an optional caveat.

The practical consequence is that a deployer choosing between two high-risk systems is entitled to two comparable declarations, and a deployer running its own fundamental rights impact assessment has a documented starting point rather than a vendor conversation. It also means the accuracy claim in a sales deck and the accuracy claim in the instructions for use are now the same regulated statement; a gap between them is a problem under this Regulation and, separately, under consumer and advertising law.

Robustness, redundancy and feedback loops

Article 15(4) treats robustness as resilience to errors, faults and inconsistencies that may occur within the system or its environment, in particular from interaction with natural persons or with other systems. It names technical redundancy solutions, which may include backup or fail-safe plans, as a way of achieving it. This is the article’s most conventional safety-engineering paragraph and it maps cleanly onto existing practice: degrade gracefully, fail closed where failing open harms someone, and have a defined behaviour when a dependency is unavailable.

The distinctive sentence is the one about continuous learning. Systems that continue to learn after being placed on the market or put into service must 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, and to ensure that any such feedback loops are duly addressed with appropriate mitigation measures. That is a direct instruction about a specific failure mode: a model whose own decisions become its next training set converges on its own errors, and the people filtered out at step one never generate the evidence that would correct step two.

Any pipeline that retrains on accepted outputs, on operator confirmations, or on downstream outcomes that the system itself gated, is in scope of that sentence. The mitigation the article expects is not named, which leaves counterfactual sampling, holdout cohorts exempted from the system’s influence, and independent ground-truth collection as the obvious candidates — all of which are design decisions taken long before a compliance review.

The four AI-specific attack classes

Article 15(5) requires resilience against attempts by unauthorised third parties to alter the system’s use, outputs or performance by exploiting vulnerabilities, and then does something unusual for a statute: it names the attack classes. The technical solutions must include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate:

• the training data set — data poisoning;
• pre-trained components used in training — model poisoning, which is the supply-chain case and the reason the provenance of a base model or an adapter is a security question and not only a licensing one;
• inputs designed to cause the model to make a mistake — adversarial examples, or model evasion;
• confidentiality attacks and model flaws — membership inference, model inversion and extraction sit here.

Naming them in the instrument matters because it forecloses the argument that a generic information-security programme discharges the duty. An ISO 27001 control set does not, on its own, address data poisoning or model inversion; those require controls over the training pipeline and over what the inference endpoint reveals. The five verbs — prevent, detect, respond to, resolve, control for — also rule out a purely preventative posture: detection and response are named separately, so a system with no way to observe an attack in progress is short of the requirement.

What is still missing: the measurement methods

Article 15(2) asks the Commission, working with relevant stakeholders and bodies such as metrology and benchmarking authorities, to encourage the development of benchmarks and measurement methodologies for accuracy and robustness. That is a work item, not an obligation on providers, and it is the honest weak point of this article: until the harmonised standards being developed under the Commission’s standardisation request to CEN-CENELEC arrive, “appropriate accuracy” has no external referent, and two providers can declare numbers that are not comparable while both complying.

Until then, the defensible position is the one the article’s own structure suggests: declare the metric you chose, declare why it is the right metric for the intended purpose, declare the population you measured on, and declare where it breaks. See what compliance evidence looks like and how the standards layer fits under the Act.