Article 15: accuracy, robustness and cybersecurity
The only article in the high-risk regime that is squarely an engineering obligation. It sets no numeric threshold: it requires you to declare your own, justify it against intended purpose, sustain it across the lifecycle, and defend the system against five named classes of attack.
Three obligations in one article
1. Accuracy
An appropriate level in view of the intended purpose, performing consistently across the lifecycle. The levels and the relevant metrics must be declared in the instructions for use.
There is no threshold in the Regulation. That is not leniency: it moves the burden onto your justification. You choose the metric, you state the number, and both become claims an authority can test. The Commission is to encourage development of benchmarks and measurement methodologies with relevant stakeholders.
The trap in “consistently”
Consistent performance throughout the lifecycle means the declared figure has to keep being true. Model drift is not an operational inconvenience under Article 15; it is a route to non-conformity. This is why Article 15 and Article 72 post-market monitoring are effectively one obligation split across two articles. Article 72 →
2. Robustness
- Resilience regarding errors, faults and inconsistencies that may occur within the system or its environment, in particular due to interaction with natural persons or other systems.
- Technical redundancy solutions where appropriate, backup or fail-safe plans.
- For systems that continue to learn after deployment: developed to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations, with feedback loops duly addressed with appropriate mitigation measures.
The feedback-loop provision is the one most likely to catch a modern deployment. Any system whose own decisions shape the data it later trains on, recommendation, ranking, fraud scoring, triage, is in scope, and the mitigation has to be designed rather than asserted.
3. Cybersecurity
Systems must be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting vulnerabilities. Technical solutions must be appropriate to the relevant circumstances and risks, and must address AI-specific vulnerabilities. The Regulation names five:
| Named in Art. 15 | What it targets |
|---|---|
| Data poisoning | Manipulating the training data set. |
| Model poisoning | Manipulating pre-trained components used in training. |
| Model evasion | Inputs crafted to cause the model to err: adversarial examples. |
| Confidentiality attacks | Extracting training data or model parameters, membership inference, model inversion, extraction. |
| Model flaws | Defects in the model itself. |
Because these are named in the Regulation, they are the baseline threat model. An assessor comparing your security documentation against Article 15 will look for each of the five, and a generic application-security programme addresses at most one.
Where this usually goes next
Three situations account for most people reading this page. Each has a different answer.
A deal is blocked on an AI questionnaire
Legal will not sign until you can evidence how AI is governed. HumanAudit’s AI Trust Package is a fixed $3,500 over five business days: a public trust page, a pre-filled SIG Lite / CAIQ / SSPA Section K questionnaire bank, and your AI inventory and classification.
You need ISO/IEC 42001 documentation
23 clause-mapped AIMS documents with all 38 Annex A controls pre-populated, editable and yours to keep, from $199. Or score your gaps first: 18 questions, free, no signup to begin.
You are not sure what reaches you
Twenty minutes with the founder. No prep, no deck, straight to the person accountable for the work. If none of this applies to you, you get told that on the call.
This reference is published by HumanAudit Inc. Not a law firm, not an accredited certification body, not a registered auditor. We build documentation, your counsel interprets it, and an accredited body of your choosing certifies you. How this is funded →
Where ISO/IEC 27001 helps and where it stops
An ISMS gives you the vulnerability management, secure development, access control and incident response machinery. It does not, out of the box, cover data poisoning, model evasion or membership inference, those sit outside the classic confidentiality-integrity-availability frame and outside most existing control sets. ISO 42001 vs 27001 →
Status labels on this page
Verified fact: The accuracy declaration duty, the robustness and redundancy requirements, the feedback-loop provision, and the five named attack classes.
Expert analysis: The reading that drift creates a route to non-conformity, and the assessment of where an ISMS stops.
Unsettled: What an ‘appropriate level’ of accuracy means in the absence of benchmarks. Harmonised standards addressing this remain in development.
Declared metrics need a monitoring plan behind them
The moment you declare an accuracy figure in the instructions for use, you have committed to sustaining it. That commitment is only credible with post-market monitoring that measures the same metric on live data.
Not sure where you sit?
The classifier maps your system against Articles 5, 6, 50 and Annex III. Twelve questions, no email.
Questions
What does Article 15 of the EU AI Act require?
Article 15 requires high-risk AI systems to 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 levels of accuracy and the relevant accuracy metrics must be declared in the accompanying instructions for use.
What cybersecurity threats does the EU AI Act name?
Article 15 requires technical solutions aimed at addressing AI-specific vulnerabilities, and names measures to prevent, detect, respond to, resolve and control for data poisoning, model poisoning, model evasion, confidentiality attacks and model flaws. These are named in the Regulation itself, which makes them the baseline threat model an assessor will expect to see addressed.
What does the EU AI Act say about feedback loops?
Article 15 requires that high-risk AI systems that continue to learn after being placed on the market or put into service are 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.
Does the EU AI Act require a specific accuracy level?
No. The Act does not set numeric thresholds. It requires an appropriate level in view of the intended purpose, consistent performance across the lifecycle, and declaration of the accuracy levels and metrics in the instructions for use. The obligation is to declare, justify and sustain your own figure, not to hit a figure set by the Regulation. The Commission is to encourage the development of benchmarks and measurement methodologies.
Obligations, article by article
- Art. 5 prohibitions
- Art. 4 AI literacy
- Art. 50 transparency
- Art. 9 risk management
- Art. 10 data governance
- Art. 11 / Annex IV
- Arts. 12–13 logging
- Art. 14 human oversight
- Art. 17 QMS
- Arts. 43–48 conformity
- Art. 49 registration
- Art. 57 sandboxes
- Open source
- Art. 72 monitoring
- Art. 73 incidents
- Arts. 51–56 GPAI
- Art. 99 penalties
- Compliance checklist
- FRIA template (Art. 27)
- When Annex III does not apply →