Art 15: accuracy, robustness, and cybersecurity
Lesson 5 of 6 in Inside the High-Risk Rulebook: Arts 8–15 Article by Article.
Art 15 closes the rulebook with the engineering trio: high-risk systems must achieve appropriate levels of accuracy, robustness and cybersecurity, and — the clause teams underweight — must perform consistently in those respects throughout their lifecycle. Drift is a compliance failure, not just an ML nuisance.
Three commitments give the article teeth. Accuracy is declared, not implied: the levels and the relevant accuracy metrics go into the instructions for use (Art 15(3)), turning a marketing claim into a checkable specification a deployer and a market surveillance authority can both hold you to. Robustness is engineered: resilience to errors, faults and inconsistencies — whether from the environment, from people, or from other systems — through technical redundancy, which may include backup or fail-safe plans. And for systems that continue learning after deployment, the feedback-loop risk returns as a named duty: outputs that contaminate future inputs must be eliminated or reduced as far as possible, and any residual loop addressed with mitigation measures.
Then comes AI-specific security. Art 15(5) requires resilience against unauthorised third parties attempting to alter the system’s use, outputs or performance by exploiting its vulnerabilities — and it names the attack classes, which means your threat model is partially written by statute:
| Attack | What the attacker does | Lifecycle stage hit | Named control direction |
|---|---|---|---|
Data poisoning | Corrupts the training data so the model learns attacker-chosen behaviour — e.g. seeding a fraud dataset so certain transaction patterns are always scored clean | Data collection & preparation | Provenance tracking and dataset integrity checks (ties back to Art 10 governance) |
Model poisoning | Manipulates pre-trained components — a downloaded foundation model or library carrying a backdoor into your supply chain | Development & integration | Vetting and integrity verification of third-party components; supply-chain controls |
Adversarial examples / model evasion | Crafts inputs designed to cause a mistake — the stop sign with stickers a vision model reads as a speed limit, the résumé stuffed with invisible keywords | Operation (inference time) | Adversarial testing and robustness training; input sanitisation |
Confidentiality attacks | Extracts what should stay secret — model stealing via mass queries, or membership inference revealing whether a person’s data was in the training set | Operation (via the query interface) | Rate limiting, output perturbation, monitoring of query patterns |
Model flaws | Exploits defects in the model itself — the catch-all for vulnerabilities that need no data or input manipulation | Any stage | Testing, red-teaming, and the security-by-design measures of Art 15(5) |
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.