AI Act technical requirements: Articles 15 and 17, explained
Article 15 gets cited constantly as if it were one requirement. It's actually three separate things — accuracy, robustness and cybersecurity — each proven differently. And Article 17 is the system that ties them together. Here's what each one demands and how it's documented.
The mistake of treating Article 15 as a single requirement
"We comply with Article 15" means nothing on its own, because the article imposes three technical obligations that are measured, tested and documented in different ways:
| Requirement | What it proves | How it's evidenced |
|---|---|---|
| Accuracy | That the system gets it right, and how often | Justified metrics, strict dataset separation, subgroup breakdown |
| Robustness | That it keeps getting it right over time and under fault | Error resilience, redundancy, degradation control |
| Cybersecurity | That no outside party can alter its use or outputs | Measures against data and model poisoning, adversarial examples, confidentiality breaches |
Three details in Article 15 almost nobody documents
1. Accuracy must be declared, not just measured
Article 15(3) requires that the level of accuracy and the relevant metrics be declared in the instructions for use accompanying the system. An internal report isn't enough: whoever deploys the system has to be able to read it. It's a transparency obligation towards the next link in the chain, not only towards the regulator.
2. Feedback loops in systems that keep learning
Article 15(4) contains a very specific and rarely-cited requirement: systems that continue to learn after being placed on the market must be developed so as to eliminate or reduce as far as possible the risk of biased outputs influencing input for future operations — so-called feedback loops — and to ensure such loops are addressed with appropriate mitigation measures.
In practice, if your system retrains on its own outputs, you need explicit, documented control of that drift. It's where most systems fail silently.
3. Article 15 cybersecurity isn't general cybersecurity
Article 15(5) addresses AI-specific threats: training-data and model poisoning, adversarial examples designed to fool the system, and attacks on model confidentiality. Your corporate security policy (or your NIS2 compliance) covers infrastructure, but not necessarily these vectors.
Article 17: the system that holds it all together
Article 17 requires providers of high-risk systems to have a documented quality management system with at least 13 elements. The key to not duplicating work: most of those elements should already exist elsewhere in your documentation — risk management (Art. 9), data governance (Art. 10), post-market monitoring (Art. 72), incident reporting (Art. 73). Article 17 doesn't ask you to rebuild them: it asks you to connect them into a single coherent framework, and add what's missing.
Three elements are typically uncovered in almost every organisation: design control and verification, quality assurance during development, and resource management and security of supply (what happens if your model or compute provider becomes unavailable).
Article 17 does not require ISO/IEC 42001 certification. That standard is a reasonable way to structure the system, but it isn't a legal requirement — here we compare ISO 42001 with ISO 27001, and here with ISO 23894.
When it has to be ready
Both articles apply to high-risk systems. Following the Digital Omnibus (Regulation EU 2026/1744, in force since 27 July 2026), Annex III high-risk obligations were postponed to December 2027. That's enough time to do it properly, and far too little to start in the final quarter.
Sources
Regulation (EU) 2024/1689, Arts. 13, 15 and 17 · EUR-Lex · AESIA Guides 4, 9 and 10 (Quality management system, Accuracy and Robustness).
A checklist per requirement
One document per requirement, aligned with the AESIA guides — including the record tables an auditor will ask for. Currently available in Spanish.