EU AI Act Article 15: A Plain-English Guide to Accuracy, Robustness and Cybersecurity for High-Risk AI
If your AI system is high-risk under the EU AI Act, Article 15 is where the engineering rubber meets the regulatory road. It is the provision that turns abstract obligations - "be safe," "be reliable" - into concrete technical requirements: declare your accuracy metrics, build for robustness, and defend against AI-specific cyberattacks. And it applies throughout the system's entire lifecycle, not just at launch.
This guide unpacks each of Article 15's three pillars - accuracy, robustness, and cybersecurity - in plain English, explains how they connect to the rest of the high-risk framework, and gives you a practical checklist to work through before the deadline arrives.
Not sure whether your system is high-risk in the first place? Start with our plain-English classification guide before reading on.
What Article 15 Actually Says
Article 15 sits inside Chapter III, Section 2 of Regulation (EU) 2024/1689 - the cluster of technical requirements that every high-risk AI provider must satisfy. The opening paragraph sets the tone for everything that follows.
High-risk AI systems must be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity, and to perform consistently in those respects throughout their lifecycle (Art. 15(1)).
Three words in that sentence deserve attention: appropriate, consistently, and lifecycle. "Appropriate" means the standard is context-dependent - a medical imaging system and a CV-screening tool face different accuracy expectations. "Consistently" means a one-time benchmark is not enough; performance must hold up in production. "Lifecycle" means the obligation does not end at conformity assessment - it runs until the system is withdrawn from service.
Pillar 1 - Accuracy
What the law requires
Article 15(3) is short and specific: the levels of accuracy and the relevant accuracy metrics of high-risk AI systems must be declared in the accompanying instructions for use.
This is a documentation obligation as much as a technical one. Regulators and deployers need to know which metrics you chose (precision, recall, F1, AUC, error rate, etc.) and what performance levels you have declared. If your system underperforms against those declared levels in the field, you have a compliance problem - not just an engineering one.
What "appropriate" accuracy means in practice
The law does not set a universal accuracy threshold, and for good reason: accuracy is a context-dependent performance target that must be justified against the system's intended purpose, the state of the art, and the risks involved - not a single universal percentage.
Article 15(2) tasks the European Commission, working with metrology and benchmarking authorities, to encourage the development of benchmarks and measurement methodologies. Those sector-specific benchmarks do not yet exist in final form, but the direction of travel is clear: your chosen metrics must be defensible, and your declared performance levels must be honest.
Practical implication for ML engineers: Choose metrics that reflect real-world risk. For a binary classifier used in a high-stakes decision (credit, employment, law enforcement), accuracy alone is almost always the wrong metric - it hides class imbalance. Precision, recall, and their trade-offs are what matter. Document your choice and the rationale in the Annex IV technical documentation.
Pillar 2 - Robustness
What the law requires
Article 15(4) requires high-risk AI systems to be "as resilient as possible" to errors, faults, or inconsistencies that may occur within the system or its environment - including interactions with natural persons or other systems. Technical redundancy solutions, including backup or fail-safe plans, are explicitly mentioned as a way to achieve this.
The paragraph also addresses a specific risk that is easy to overlook: high-risk AI systems that continue to learn after being placed on the market or put into service must be developed to eliminate or reduce as far as possible the risk of biased outputs influencing input for future operations - so-called feedback loops.
What robustness testing looks like
Standard quality assurance is not enough. Providers should conduct stress-testing, out-of-distribution testing, and - where the system is exposed to user-controlled inputs - adversarial red-teaming. Where a system incorporates feedback loops (for example, a hiring algorithm that learns from recruiter decisions), providers must map and mitigate the risk that biased outputs corrupt future training cycles.
Think about robustness across three dimensions:
- Input robustness: Does the system degrade gracefully when inputs are noisy, incomplete, or outside the training distribution?
- Environmental robustness: Does performance hold when the operating context shifts - different hardware, different user populations, different data pipelines?
- Temporal robustness: Does the system drift over time, and if so, how is that detected and corrected?
Fail-safe design is not optional. Article 15(4) explicitly mentions backup and fail-safe plans as a mechanism for achieving robustness. For high-stakes systems — medical diagnosis, infrastructure control, law enforcement — document what happens when the AI output is unavailable or unreliable. The fallback must be defined, tested, and described in the instructions for use. This connects directly to the human oversight requirements in Article 14.
Pillar 3 - Cybersecurity
This is where Article 15 breaks new ground. Most organisations have cybersecurity programmes. Most of those programmes are not designed to address AI-specific attack surfaces. Article 15(5) changes that - it makes AI-specific security a legal requirement, not a best practice.
What the law requires
High-risk AI systems must be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities (Art. 15(5)). Technical solutions must be appropriate to the circumstances and risks.
Crucially, the Regulation names the specific attack types that providers must address. This is not a vague "be secure" mandate - it is a list:
| Attack type | What it means |
|---|---|
| Data poisoning | Manipulation of the training dataset to corrupt model behaviour |
| Model poisoning | Tampering with pre-trained components used in training |
| Adversarial examples / model evasion | Inputs crafted to cause the model to make a mistake |
| Confidentiality attacks | Extracting sensitive information from the model (e.g. training data membership inference) |
| Model flaws | Vulnerabilities in the architecture or design itself |
These are not hypothetical attack vectors. They are documented, reproducible, and in some cases already being exploited in the wild. The Act does not prescribe specific technical controls, but it does require that providers demonstrate through conformity assessment that their system is resilient against these threats.
Traditional security is necessary but not sufficient
Firewalls, access management, encryption, and patch management remain important. But they do not address the model layer. A system can be perfectly hardened at the infrastructure level and still be vulnerable to a carefully crafted adversarial input that causes it to misclassify a malignant tumour as benign, or approve a fraudulent loan application.
Article 15 requires providers to think about security at the model level, not just the infrastructure level. That means:
- Threat modelling at design stage - identifying which attack vectors are relevant to the system's architecture and use case
- Adversarial testing before launch - structured testing against evasion, poisoning, and extraction techniques
- Training data integrity controls - provenance tracking, access controls, and anomaly detection in the data pipeline
- Monitoring in deployment - detecting distributional shift and potential adversarial activity in production
- Incident response for AI systems - processes for detecting, investigating, and remediating AI-specific security events
The lifecycle requirement in Article 15 means that cybersecurity must be maintained and reassessed as the system evolves - it is not a one-time exercise.
The Cyber Resilience Act overlap
If your high-risk AI system is also a product with digital elements, the Cyber Resilience Act (CRA) applies in parallel. High-risk AI systems must address AI-specific threats - data poisoning, adversarial examples, model manipulation - alongside the standard vulnerability handling and patch management requirements of the CRA. Cybersecurity obligations under Article 15 should also be read alongside the provider's broader information security posture, and where systems process personal data or connect to critical infrastructure, NIS 2 obligations may compound the picture.
How Article 15 Connects to the Rest of the Framework
Article 15 does not stand alone. It is one spoke in a wheel of interconnected obligations:
- Article 9 (Risk Management System): Testing and metrics gathered under Article 9 should directly evidence your Article 15 claims. Cybersecurity risks belong in the risk management system - not in a separate silo.
- Article 10 (Data Governance): Dataset quality underpins both accuracy and robustness. Weak data governance is a root cause of both poor accuracy and vulnerability to data poisoning.
- Article 13 (Transparency / Instructions for Use): The instructions for use must include the accuracy metrics and declared performance levels required by Article 15(3), as well as known circumstances that may affect performance.
- Article 14 (Human Oversight): Robustness and human oversight are complementary. When a system fails or produces uncertain outputs, the human oversight mechanisms defined under Article 14 are the safety net. Design them together.
- Article 17 (Quality Management System): The QMS must cover the processes by which accuracy, robustness, and cybersecurity are achieved, tested, and maintained. Article 15 compliance is not a one-off engineering task - it is a process.
- Annex IV (Technical Documentation): Everything above must be documented. The conformity assessment - whether self-assessed or third-party - will scrutinise this documentation. See our conformity assessment and CE marking guide for the full picture.
Harmonised standards: the gap to watch
CEN-CENELEC's Joint Technical Committee 21 (JTC 21) is developing harmonised standards that will cover accuracy, robustness, and cybersecurity for high-risk AI systems. Once published in the Official Journal of the EU, these standards will provide companies with a legal presumption of conformity. JTC 21 includes specific work items on cybersecurity and robustness for AI systems. However, the standards development process has run behind schedule, with CEN-CENELEC harmonised standards now tracking toward Q4 2026 delivery. Until harmonised standards are formally referenced in the OJEU, providers must demonstrate compliance through other means - common specifications, existing international standards (ISO/IEC), or documented technical justification.
The Deadline and the Stakes
When does Article 15 apply?
Article 15 applies to Annex III high-risk AI systems from 2 August 2026, and to Annex I (Union harmonisation legislation) high-risk AI systems from 2 August 2027, subject to transitional provisions.
Important update: A provisional political agreement known as the Digital Omnibus, reached in May 2026 and pending formal adoption, would push the Annex III application date back to 2 December 2027. Until that agreement is formally adopted, 2 August 2026 remains the operative deadline. Treat it as your planning anchor and monitor the legislative process closely.
What non-compliance costs
Article 15 is a technical requirement for high-risk AI systems. Non-compliance flows through the provider obligations in Article 16, which sit in the middle tier of Article 99's penalty structure. Non-compliance with provider obligations falls under Article 99(4): fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. For large organisations, that is the higher of the two figures. For SMEs and start-ups, it is the lower - a proportionality mechanism built into the Regulation.
Beyond the fine, there is the conformity assessment. A system that cannot demonstrate Article 15 compliance cannot lawfully carry the CE marking. Without the CE marking, it cannot be placed on the Union market as a high-risk AI system.
Your Article 15 Compliance Checklist
Use this interactive tool to assess your readiness across all three pillars of Article 15.
Before the Deadline: A Practical Action Plan
Even if the Digital Omnibus deadline extension is formally adopted, starting now is the right call - the work is substantial and the conformity assessment clock starts ticking from whenever the rules apply to your system.
Choose metrics that reflect real-world risk for your use case — not just overall accuracy. Document the metric, the declared performance level, and the rationale. This must appear in the instructions for use and the Annex IV technical documentation.
Go beyond standard QA. Include edge cases, out-of-distribution inputs, stress tests, and — where the system accepts user-controlled inputs — adversarial red-teaming. Define and test your fail-safe behaviour. Document results.
Commission adversarial testing covering the five attack types named in Article 15(5): data poisoning, model poisoning, model evasion, confidentiality attacks, and model flaws. This is distinct from standard penetration testing and requires ML security expertise.
Audit pre-trained components, third-party datasets, and fine-tuning pipelines. Model poisoning attacks target these upstream components. Implement provenance tracking and integrity checks for all training inputs.
If your system continues learning after deployment, map every point where its outputs could influence future training data. Implement safeguards — human review gates, output filtering, retraining governance — and document them.
Article 15 evidence should flow into your risk management system (Article 9) and quality management system (Article 17). Cybersecurity risks belong in the risk register. Accuracy and robustness test results belong in the QMS. Siloed compliance does not survive a market surveillance audit.
Everything above must be evidenced in writing. The conformity assessment — self-assessed or third-party — will scrutinise this file. Review our conformity assessment guide for the full documentation structure.
Frequently Asked Questions
Does Article 15 apply to SMEs?
Yes. Article 15 does not provide a general exemption for SMEs. However, the AI Act includes proportionality mechanisms — the 'appropriate level' standard means smaller systems with lower risk profiles may face less demanding technical requirements. And if fines are imposed, SMEs face the lower of the fixed euro amount or the turnover percentage, not the higher.
Does Article 15 apply to general-purpose AI models?
No. Article 15 sits within Title III, Chapter 2, which applies exclusively to high-risk AI systems. General-purpose AI model providers are governed by Chapter V (Articles 51–55). However, if a GPAI model is integrated into a high-risk AI system, the provider of that system must ensure the combined system meets Article 15 requirements.
What if harmonised standards are not available before my deadline?
You can still demonstrate compliance without harmonised standards. Options include relying on existing international standards (such as ISO/IEC 42001 for AI management systems or ISO/IEC 27001 for information security), common specifications issued by the Commission, or a documented technical justification showing how your design choices satisfy the legal requirements. The absence of harmonised standards does not suspend the obligation.
How does Article 15 relate to the Cyber Resilience Act (CRA)?
If your high-risk AI system is also a product with digital elements, the CRA applies in parallel. The CRA covers standard vulnerability handling and patch management; Article 15 adds AI-specific attack surfaces on top. Both sets of requirements must be satisfied. Where they overlap, satisfying the more demanding requirement typically satisfies both.
What is the difference between robustness and cybersecurity under Article 15?
Robustness (Art. 15(4)) covers resilience against unintentional errors, faults, and inconsistencies — things that go wrong without a malicious actor. Cybersecurity (Art. 15(5)) covers resilience against deliberate attacks by unauthorised third parties. In practice, the controls overlap: adversarial testing addresses both. But the legal obligations are distinct, and your documentation should address each separately.
Free tools on AI Act Navigator:
- Risk-Tier Classifier - answer a short questionnaire and get a provisional tier assessment for your AI system, with a plain-English rationale you can share with stakeholders.
- Obligations Checker - once you know your risk tier, this page maps every relevant obligation - including Article 15 - to practical compliance steps.
- The AI Act Brief - a free newsletter tracking regulatory developments, including the Digital Omnibus timeline and harmonised standards progress.
This guide is for informational purposes only and does not constitute legal advice. The EU AI Act is a complex regulation and its application depends on the specific facts of your system and organisation. Consult qualified legal counsel for advice specific to your situation. Regulatory timelines referenced in this post reflect the position as of July 2026; monitor official sources for updates on the Digital Omnibus formal adoption.
Related reading
Harmonised Standards and Presumption of Conformity Under the EU AI Act: A Plain-English Guide to Articles 40 and 41
What "presumption of conformity" actually buys you under Articles 40 and 41, why the CEN-CENELEC standards are delayed, and what high-risk AI providers must do right now.
EU AI Act Article 9: A Plain-English Guide to the Risk Management System for High-Risk AI
Article 9 of the EU AI Act requires a continuous, lifecycle-wide risk management system for every high-risk AI system. Here's exactly what that means and how to build one.
Article 22 EU AI Act: The Plain-English Guide to Authorised Representatives for Non-EU Providers
If you build high-risk AI outside the EU and want to sell into the EU market, Article 22 requires you to appoint an EU authorised representative by written mandate - before you go live. Here's exactly what that means.