Article 15(5) of the EU AI Act runs to three sentences and most summaries quote only the first. High-risk AI systems must be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. The technical solutions aiming to ensure the cybersecurity of high-risk AI systems must be appropriate to the relevant circumstances and the risks. The technical solutions to address AI specific vulnerabilities must include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set, which the provision calls data poisoning; manipulate pre-trained components used in training, which it calls model poisoning; inputs designed to cause the model to make a mistake, which it calls adversarial examples or model evasion; confidentiality attacks; and model flaws.
The second and third sentences matter more than the first. The Act asks for cybersecurity appropriate to the circumstances and the risks, and it introduces its list of attack classes with where appropriate. That is a proportionality standard, and the list is illustrative.
Here is the sentence for your CISO. Article 15 requires an appropriate level of robustness and nothing in the Act, in any harmonised standard, or in the adversarial machine learning literature tells a provider what appropriate means or how to demonstrate they reached it. If you are building an Annex III system for December 2027, the artefact that decides your conformity assessment is a defensible record of the threat model. Name the attacker you assumed, give the reasoning, and record the testing you ran against it.
What the provision requires
Article 15 sets accuracy, robustness and cybersecurity together. Article 15(1) requires design and development achieving an appropriate level of all three, with consistent performance throughout the lifecycle. Article 15(3) requires accuracy levels and metrics to be declared in the instructions for use. Article 15(4) requires systems to be as resilient as possible regarding errors, faults or inconsistencies. Article 15(5) covers attacks.
Article 15(2) is where the Act contemplates fixing the measurement problem. It provides that the Commission, in cooperation with relevant stakeholders and organisations such as metrology and benchmarking authorities, shall encourage, as appropriate, the development of benchmarks and measurement methodologies for the levels of accuracy and robustness set out in paragraph 1.
No such benchmark or measurement methodology has been published. The obligation is satisfiable in principle, so the problem here is a failure of measurement and not an impossible legal standard. Nobody can currently show, on any accepted measure, that they satisfied it.
Why an adaptive attacker defeats published defences
The pattern in this literature has repeated for a decade. Someone proposes a defence, evaluates it against known attacks, and reports a high robust accuracy figure. An attacker who knows the defence then designs an attack against that specific defence, and the figure drops toward zero.
Carlini and Wagner demonstrated this in 2017 against ten proposed methods for detecting adversarial examples and bypassed all ten. Athalye, Carlini and Wagner showed in 2018 that seven of nine non-certified white-box defences accepted at that year’s ICLR relied on obscuring the gradient signal an attacker uses; new attacks circumvented six of them completely and the seventh partially. Tramèr, Carlini, Brendel and Madry published a systematic version in 2020 and circumvented thirteen defences from ICLR, ICML and NeurIPS by tailoring the attack to each defence.
securing.ai/ has covered the mechanisms in adversarial attacks on AI models, gradient-based attacks, perturbation attacks and adaptive attacks against intrusion detection.
Two families of defence have held up better than the others, and neither produces a number a conformity assessment can use.
Adversarial training
Training on adversarial examples produces real robustness within the perturbation budget used during training. It increases training cost and commonly trades some clean accuracy for that robustness, though the size of the trade varies by regime. The robustness does not transfer to perturbations outside the trained budget or to a different threat model. A model adversarially trained against small pixel-space perturbations offers no protection against a semantically valid input that a human would classify the same way.
Certified defences
Certification produces a mathematical guarantee that no perturbation within a stated radius changes the prediction for a given input. Randomised smoothing scales furthest among these techniques. Cohen, Rosenfeld and Kolter reported at ICML 2019 a certified top-1 accuracy of 49 per cent on ImageNet at an L2 radius of 0.5, against 67 per cent standard accuracy for the same smoothed classifier. That is a canonical historical result and not current state of the art, though the shape of it has not changed. The guarantee is genuine and the radius is small. Certified accuracy runs roughly eighteen points below clean accuracy.
Both families answer a narrower question than Article 15(1) asks. They establish resistance to one named attacker inside one stated budget. Article 15(1) asks for an appropriate level, and no mapping exists between the two.
Access assumptions decide the number
Robust accuracy figures in this literature depend on what the attacker is assumed to have. A white-box attacker has the weights, the architecture and the gradients. A black-box attacker sees outputs. Between them are the query-limited attacker, the one working from a similar model as a proxy, and the one who has obtained the weights.
Published robust accuracy figures are usually white-box, the conservative assumption and the right one for a defender to plan against. The same figure quoted for a deployment where the attacker has authenticated API access only describes a different and easier problem. Any Article 15 claim that omits its access assumption cannot be assessed.
Deployment changes the access question. A model behind an authenticated API with rate limiting faces a different attacker from the same weights shipped inside a customer appliance. Article 15 applies to the high-risk system, so deployment context forms part of the assessment, and a model-level robustness result does not establish a system-level property. Model extraction and query attacks are how black-box access degrades toward white-box over time, which means an access assumption expires.
A standard can define the process, not the threat model
CEN-CENELEC Joint Technical Committee 21 was created in 2021 and has drafted the harmonised standards under standardisation request M/593, Commission Decision C(2023)3215 of 2023, which M/613, Decision C(2025)3871, replaced in 2025. EN 18286:2026, covering quality management in support of Article 17, was published in July 2026 and is the first European Standard developed in support of the AI Act.
Publication is not the step that matters legally. Under Article 40, presumption of conformity attaches when a harmonised standard’s reference is cited in the Official Journal, and no JTC 21 deliverable has reached that point. CEN and CENELEC adopted acceleration measures in October 2025 targeting availability of the priority deliverables by the fourth quarter of 2026, and M/613 expires on 28 February 2027.
Two things follow that are commonly confused. Harmonised standards give a presumption of conformity and are not a precondition for compliance, and the Act provides assessment routes where no standard exists. And no standard now in preparation supplies a robustness metric for Article 15, because writing one would require the field to agree a threat-model-independent measure of robustness that does not exist.
The Digital Omnibus, Regulation (EU) 2026/1744, deferred the Annex III obligations to 2 December 2027. The Commission’s original proposal made that deferral conditional on standards becoming available and the co-legislators deleted the condition, so 2 December 2027 applies whether or not a standard is cited.
What a defensible Article 15 file contains
Five things make a file defensible.
State the threat model explicitly. Name the attacker’s access level, the perturbation budget or its equivalent, how many queries are allowed, and what the attacker knows about the defence. Recording that a system was tested for robustness without those parameters records nothing.
Justify the threat model against the deployment. Article 15(5) asks for measures appropriate to the relevant circumstances and the risks, so the file has to connect the attacker you assumed to the deployment you are actually shipping. That connection is the closest thing the provision offers to a threshold.
Test adaptively. Commission testing where the tester knows the defence and is instructed to defeat it. Testing against a standard attack library the defence was tuned against measures the tuning.
Record the failures. Article 15 asks for prevention, detection, response, resolution and control. Detection and response are achievable where prevention is not, and a file showing that attacks succeed under stated conditions and are then detected and contained is better evidence than an assertion that they never succeed.
Label each result by whether it came from the model or from the deployed system, and re-test on a trigger. Say which results came from the model in isolation and which from the deployed system with its input validation, rate limiting, monitoring and the human oversight Article 14 requires. New attack techniques against your model class are the trigger for re-testing. Annual review will miss them.
Say the gap out loud
Providers will want to write Article 15 files asserting robustness. The first sentence of Article 15(5) reads like a demand for it. An unqualified robustness assertion invites a market surveillance authority to ask which attacks were tried, and an honest answer shows the property does not hold in general.
Documenting the limits is the stronger position, and the text supports it. A provider who states the threat model, justifies it against the deployment, shows adaptive testing, reports the failures, and describes the detection and containment operating where prevention fails has materially stronger evidence for the appropriate level Article 15(1) requires than a provider asserting resilience without qualification.
Nolte, Rateike and Finck examined the robustness and cybersecurity provisions in work published at ACM FAccT 2025 and observed that complete protection against a specific attack cannot be guaranteed. The Act does not require that guarantee. It requires an appropriate level, and until the Commission encourages the benchmarks Article 15(2) contemplates, appropriate is a judgement each provider makes and documents.
The other four provisions of the AI Act that touch a security function are covered in the EU AI Act for security teams.
In the early 2000s, running emerging-technology risk labs at CyberAgency, a defence client asked my team to break the AI systems they planned to put into weapons. We did. That is where my work on AI security started, two decades before the current wave of attention. I kept at it through risk labs at IBM, Accenture, PwC and KPMG. In 2016 I co-wrote a book on AI and leadership. My commercial work today is quantum, at Applied Quantum, which is why this site sells nothing.
