EU AI Act Article 15: Accuracy, Robustness, Cybersecurity

Article 15 of the EU AI Act turns accuracy, robustness and cybersecurity into legal requirements for high-risk AI systems, but it says what must be achieved, not how to prove it. Most compliance programmes summarise the article in a line and move on, which leaves engineering and security teams to guess what evidence an assessor or market surveillance authority will expect. This guide takes the article paragraph by paragraph and turns each one into design decisions, tests, metrics and documentation. It is for providers building high-risk systems, security teams asked to "cover Article 15", and deployers who need to check what a provider has declared. For the wider regime, start with the EU AI Act High-Risk AI Systems Guide.

Key takeaways

Five paragraphs, three duties. Article 15 requires an appropriate and consistent level of accuracy, robustness and cybersecurity across the lifecycle, declared accuracy metrics in the instructions for use, and resistance to tampering by unauthorised third parties.
"Appropriate" is set by your risk management. The article does not set numbers. Your Article 9 risk management system and its predefined metrics and probabilistic thresholds decide what appropriate means, so write them down before testing.
The cybersecurity paragraph names AI-specific attacks. Data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws are named, so a conventional penetration test alone will not evidence compliance.
The dates moved, the article did not. Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026 according to EUR-Lex, moved high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems, according to law firm summaries from Cooley and Lewis Silkin. Confirm against the official text before relying on it. The extra time is for building evidence, not for waiting.
Identity is part of robustness. Many poisoning and confidentiality attacks start with an over-privileged pipeline credential or a leaked model API key, so access to training data, model registries and inference endpoints belongs in your Article 15 evidence.

What Article 15 says, paragraph by paragraph

The text below is a close paraphrase of Regulation (EU) 2024/1689 as published on EUR-Lex, checked in November 2026. Article 15 sits in Chapter III, Section 2, alongside risk management (Article 9), data governance (Article 10), technical documentation (Article 11), record keeping (Article 12), transparency (Article 13) and human oversight (Article 14).

Paragraph	What it requires	Who acts	Evidence that answers it
15(1)	High-risk systems are designed and developed to achieve an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently in those respects throughout their lifecycle.	Provider	Requirements with target values, test results against them, post-market monitoring that shows performance holds
15(2)	The Commission, with stakeholders such as metrology and benchmarking authorities, encourages benchmarks and measurement methodologies.	Commission	Track published benchmarks and adopt them when they appear; record which you used and why
15(3)	The levels of accuracy and the relevant accuracy metrics are declared in the instructions for use.	Provider	Instructions for use with metric names, values, test conditions and known limits
15(4)	Systems are as resilient as possible to errors, faults and inconsistencies, including from interaction with people or other systems, through technical and organisational measures. Redundancy, including backup or fail-safe plans, may be used. Systems that continue to learn after deployment must eliminate or reduce the risk of biased outputs influencing future inputs (feedback loops) and address them with mitigations.	Provider	Fault and edge case test results, fail-safe design, feedback loop analysis for online learning
15(5)	Systems resist attempts by unauthorised third parties to alter their use, outputs or performance by exploiting vulnerabilities. Measures are appropriate to the circumstances and risks and, where appropriate, address data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws.	Provider	AI threat model, adversarial and security test results, access controls on data and model assets, vulnerability handling

The duties fall on the provider. Deployers meet Article 15 indirectly: they must use the system in line with the instructions for use, so they need to read the declared accuracy metrics and limits and operate inside them. See the EU AI Act Provider vs Deployer Obligations Guide.

Accuracy: choosing and declaring metrics

Article 15(3) is the most concrete obligation: accuracy levels and metrics go in the instructions for use. The hard part is choosing metrics that mean something for the intended purpose. Article 9(8) adds that testing is carried out "against prior defined metrics and probabilistic thresholds" appropriate to the intended purpose, so the metric and the pass mark must exist before the test, not after.

System type	Metrics worth declaring	What to state alongside
Classifier (credit, recruitment screening, triage)	Precision, recall, false positive and false negative rates, per relevant subgroup	Test set origin and date, class balance, decision threshold, subgroups tested
Scoring or ranking model	Calibration error, ranking quality measures, stability of scores between versions	Score range and how scores should and should not be used
Biometric or vision system	False match and false non-match rates at the operating threshold, performance by capture condition	Image quality, lighting and device conditions covered by testing
Generative component inside a high-risk system	Task success rate on a defined evaluation set, rate of unsupported or fabricated outputs, refusal accuracy	Evaluation set design, grading method (human, rules or model graded) and grader agreement

Declare the conditions, not just the number: an accuracy figure without the data, population and threshold behind it does not help a deployer operate the system safely.
Show consistency: Article 15(1) asks for consistent performance through the lifecycle. Keep the evaluation set under version control and re-run it on every model, prompt or data change.
State known limits: inputs or populations where performance drops are part of an honest declaration. Deployers need them to set human oversight under Article 14.

Robustness: errors, faults and feedback loops

Robustness in Article 15(4) covers accidental failure: noisy inputs, missing fields, out-of-distribution data, operator mistakes and failures in connected systems. Treat it as a reliability engineering problem with test evidence.

Input perturbation tests: measure how far accuracy falls under realistic noise, truncation, format changes and missing values. Record the degradation curve, not a single pass or fail.
Out-of-distribution handling: detect inputs unlike the training data and route them to a human or a conservative default instead of producing a confident answer.
Interaction with people and systems: test malformed upstream data, timeouts and partial responses from integrated systems, and common operator errors.
Fail-safe design: the article names redundancy, backup and fail-safe plans. Define what the system does when a component fails: stop, fall back to a rule-based path, or hand over to a person. Test the fallback.
Feedback loops: for systems that keep learning after deployment, document how outputs could flow back into training data, then add controls such as holding out human-labelled data, monitoring drift in output distributions, and gating retraining on review.

The Adversarial Robustness Toolbox Guide covers one open source way to run perturbation tests.

Cybersecurity: the AI-specific attacks Article 15(5) names

Article 15(5) is the security paragraph. It asks for resilience against unauthorised third parties who exploit vulnerabilities to change the system's use, outputs or performance, and it names five AI-specific threat classes. Map each to a recognised taxonomy so testers and assessors share a vocabulary. NIST AI 100-2 E2025 gives the terminology; MITRE ATLAS gives technique IDs.

Named in Article 15(5)	MITRE ATLAS technique	Controls that produce evidence
Data poisoning	AML.T0020 Poison Training Data	Write access control and logging on training data stores, dataset hashing and provenance, poisoning detection tests
Model poisoning	AML.T0018 Manipulate AI Model; AML.T0010 AI Supply Chain Compromise	Signed model artefacts, registry access control, pre-trained model scanning, change approval for weights
Adversarial examples or model evasion	AML.T0015 Evade AI Model; AML.T0043 Craft Adversarial Data	Adversarial robustness testing at declared perturbation budgets, input validation, ensemble or detection layers
Confidentiality attacks	AML.T0024 Exfiltration via AI Inference API; AML.T0057 LLM Data Leakage	Inference API authentication and rate limits, output filtering, membership inference and extraction tests
Model flaws (including in LLM components)	AML.T0051 LLM Prompt Injection; AML.T0054 LLM Jailbreak	Red team results, guardrail tests, privilege separation for tool-using components

Conventional security still applies: the system's APIs, hosting, CI/CD and dependencies need the same controls as any critical application. Article 15(5) adds the AI layer on top. For deeper treatment see the AI Data Poisoning and Backdoors Guide, the Adversarial Examples and Evasion Attacks Guide and the Adversarial ML Taxonomy Guide.

Where identity fits

Several Article 15(5) threats are, in practice, access control failures. A poisoned dataset usually means someone or something had write access it should not have. A swapped model usually means a pipeline token could push to the model registry. A confidentiality attack is easier when the inference endpoint accepts a long-lived API key shared across teams.

Training data stores: separate read and write identities, give pipelines short-lived workload credentials, and log every write.
Model registry and artefacts: only the release pipeline identity can promote a model; promotions need a recorded approval.
Inference endpoints: authenticate every caller, scope keys per consumer, rate limit, and alert on extraction-like query patterns.
Agents inside the system: if a high-risk system uses an AI agent with tools, its credentials and permissions are part of the attack surface. See the AI Model Security Guide.

Standards, presumption of conformity and certification

Article 15 does not prescribe techniques, so harmonised standards will carry most of the detail. Three routes give providers more certainty.

Route	Legal basis	Status as of November 2026	What to do now
Harmonised standards	Article 40: conformity with standards published in the Official Journal gives a presumption of conformity	The Commission's standardisation request covers accuracy, robustness and cybersecurity among ten areas. CEN-CENELEC JTC 21 is developing prEN 18282, Cybersecurity specifications for AI systems, listed as under development.	Track the draft; design controls that will map to it; do not claim conformity with a draft
Cybersecurity certification	Article 42(2): systems certified, or covered by a statement of conformity, under a scheme adopted under Regulation (EU) 2019/881 are presumed to meet Article 15 cybersecurity requirements, in so far as the certificate covers them	Depends on a scheme whose scope covers those requirements and whose reference is published	Check scheme scope before relying on it; the presumption covers cybersecurity only, not accuracy or robustness
Common specifications	Article 41: the Commission may adopt implementing acts where harmonised standards are unavailable or inadequate	A fallback mechanism	Watch for Commission implementing acts on Section 2 requirements

For how these fit into the conformity procedure, see the EU AI Act Conformity Assessment and Harmonised Standards Guide.

Deciding how far to go

These are NHI Mgmt Group recommendations, not requirements of the Act.

Annex III stand-alone system, internal control route: you sign your own assessment, so the quality of your test evidence is the whole defence. Invest in a reproducible evaluation harness and an independent internal red team.
Annex I product with notified body involvement: align Article 15 evidence with the sectoral assessment so the notified body sees one test record, not two.
Systems built on third-party foundation models: you remain the provider of the high-risk system. Test the system as deployed, with your prompts, retrieval and tools, rather than relying on the model provider's general evaluations.
Small providers: scale the method, not the coverage. A smaller evaluation set and a focused threat model are acceptable if they address each paragraph and are documented.

Implementing Article 15 in phases

Classify and scope: confirm the system is high-risk and which date applies (2 December 2027 for Annex III, 2 August 2028 for Annex I, under Regulation (EU) 2026/1744, as reported by Cooley and Lewis Silkin; confirm against the official text before relying on it). See the EU AI Act Implementation Timeline Tracker.
Set targets: in the Article 9 risk management file, define accuracy metrics, robustness tolerances and security objectives with thresholds, approved before testing.
Threat model: map the five named threat classes and conventional threats to your architecture, including data, model, inference and agent identities.
Build the harness: versioned evaluation sets, perturbation tests and adversarial test suites that run in CI on every change.
Test and red team: run the suites, then a time-boxed adversarial exercise. The OWASP GenAI Red Teaming Manual Guide covers a structured method.
Remediate and retest: fix, retest against the same thresholds, and record residual risk with an owner.
Document: put metrics and limits in the instructions for use (15(3)) and test evidence in the technical documentation.
Monitor in production: feed accuracy drift, anomaly and attack signals into post-market monitoring. Roll back to the last validated model version if declared performance is no longer met.

Detection and measurement

Article 15(1) asks for consistent performance across the lifecycle, so the evidence does not stop at release.

Accuracy drift: declared metric versus live or sampled metric, with an alert threshold set in the risk file.
Robustness margin: accuracy under the standard perturbation suite, tracked per release.
Adversarial test pass rate: share of security test cases passed at the declared budget, per release.
Write events on training data and registry: count of writes by unexpected identities (target zero).
Inference abuse signals: query volume and pattern anomalies per API consumer.
Time to remediate AI vulnerabilities: from finding to validated fix.

Framework mapping

Article 15 element	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Targets and threat model	RA-3 Risk Assessment; SA-8 Security and Privacy Engineering Principles	GV.OC-03
Testing and red teaming	SA-11 Developer Testing and Evaluation; CA-8 Penetration Testing	ID.RA-01
Data and model integrity	SI-7 Software, Firmware, and Information Integrity; SR-3 Supply Chain Controls and Processes; AC-6 Least Privilege	PR.DS-01
Input handling and fail-safe	SI-10 Information Input Validation; CP-2 Contingency Plan	PR.PS-04
Lifecycle consistency	CA-7 Continuous Monitoring; SI-4 System Monitoring	DE.CM-09

The mapping is NHI Mgmt Group's editorial judgement, not an official crosswalk.

Common failure patterns

A number without conditions: declaring "95% accurate" with no test set, threshold or population makes the 15(3) declaration useless to deployers.
Thresholds set after testing: Article 9(8) expects predefined metrics and thresholds. Moving the bar to match results undermines the whole file.
Penetration test only: an infrastructure test does not address poisoning, evasion or confidentiality attacks named in 15(5).
Testing the model, not the system: a foundation model's published evaluations say little about your prompts, retrieval and tools.
Open write paths: pipeline credentials with write access to training data and the model registry turn data poisoning into a credential problem. Check every identity that can write to these stores, including CI/CD tokens and publishing credentials.
No production evidence: passing tests at release but not monitoring drift leaves 15(1) lifecycle consistency unevidenced.

Practitioner checklist

Confirm high-risk classification and the applicable date under Regulation (EU) 2026/1744.
Record accuracy, robustness and security targets with thresholds in the risk management file before testing.
Build a threat model covering all five threat classes in Article 15(5).
Run versioned evaluation, perturbation and adversarial suites on every change.
Restrict and log write access to training data and model registries; use short-lived workload identities for pipelines.
Authenticate, scope and rate limit inference endpoints.
Define and test fail-safe behaviour and, for online learning, feedback loop controls.
Declare metrics, test conditions and known limits in the instructions for use.
Track prEN 18282 and any Article 42(2) certification scheme before relying on either.
Feed drift and attack signals into post-market monitoring with a rollback path.

Standards and references

This guide summarises Article 15 of the EU AI Act and is not legal advice. Related NHI Mgmt Group resources: EU AI Act Compliance Guide, EU AI Act High-Risk AI Systems Guide, AI Red Teaming Guide, AI Incident Reporting Guide.

EU AI Act Article 15 Guide: Accuracy, Robustness and Cybersecurity Requirements