What Art. 15 actually requires
Art. 15(1) AI Act obliges providers of high-risk AI systems to design and develop them so that they “achieve an appropriate level of accuracy, robustness and cybersecurity” and do so consistently “throughout their lifecycle”. This is not a one-off check before placing the system on the market, but an ongoing obligation – accuracy and robustness must still hold up after months of live operation, not just during testing.
The provision is deliberately technology-neutral: what counts as “appropriate” depends on the specific system, its context of use and the risks involved. In practice, this means you must be able to justify and document yourself why the level of accuracy, robustness and cybersecurity you have chosen is sufficient for the given use case.
Accuracy: metrics belong in the instructions for use
Art. 15(3) requires that the levels of accuracy and the relevant accuracy metrics be “declared in the accompanying instructions of use”. This is a very concrete documentation obligation that is often neglected in practice: many technical documentation packages contain training and validation results, but no statement, comprehensible to deployers, of what accuracy can be expected under which conditions.
Under Art. 15(2), the Commission is to encourage the development of benchmarks and measurement methodologies, in particular through metrology and benchmarking authorities. Until such standards are established, however, the choice of suitable metrics remains yours as provider – and that choice must be traceable.
Robustness: errors, faults and feedback loops
Art. 15(4) requires high-risk AI systems to be “as resilient as possible regarding errors, faults or inconsistencies” – expressly including those arising from interaction with natural persons or other systems. Technical and organisational measures are called for; the provision cites technical redundancy and backup or fail-safe plans as possible approaches.
One point often overlooked in practice concerns systems that continue to learn after deployment. For these, Art. 15(4) explicitly requires that the risk of biased outputs caused by feedback loops – self-reinforcing error patterns that influence future decisions – be eliminated or minimised, using appropriate mitigation measures. If you operate a continuously learning system without a process for detecting such feedback loops, you have a clear gap here.
Cybersecurity: AI-specific attack vectors
Art. 15(5) requires resilience against attempts by unauthorised third parties to alter “the use, outputs or performance” of the system by exploiting its vulnerabilities. The technical solutions must be appropriate to the relevant circumstances and risks – again, there is no blanket standard, but a risk-based duty to justify your approach.
What is particularly relevant is that the provision names specific AI-specific types of attack for which measures to prevent, detect, respond to, resolve and control must be in place:
- Data poisoning: manipulation of the training dataset
- Model poisoning: manipulation of pre-trained components used in training
- Adversarial examples / model evasion: input data designed to make the model err
- Attacks on confidential data or model flaws
This is where classic IT security concepts often fall short. A penetration test that only checks conventional network and application security typically does not cover data poisoning scenarios or adversarial attacks on the model itself. Anyone wishing to demonstrate cybersecurity for a high-risk AI system needs a concept that explicitly addresses these attack vectors.
Common gaps in practice
Three patterns keep recurring. First, instructions for use lack traceable accuracy metrics because development and documentation run separately. Second, continuously learning systems have no defined process for monitoring feedback loops. Third, cybersecurity is treated as a purely IT matter, without AI-specific threats such as data or model poisoning being factored into the risk analysis. All three gaps can be closed with reasonable effort – provided they are identified before a market surveillance authority or a customer asks about them.
Whether your system qualifies as high-risk AI under the AI Act at all, and which obligations under Art. 15 apply to you in detail, can be assessed in a few minutes using our free risk check at /einstufung.