Why Article 15 matters
Article 15 is the last of the requirements for high-risk AI systems and the one that looks most familiar to engineers, which is why it is often handled badly. Accuracy, robustness and cybersecurity are things every serious software business already works on. The difference is that Article 15 turns them into legal obligations with an evidential burden attached, and names a set of attacks most conventional security programmes do not address at all.
Article 15 is also the only requirement in the set with a genuine shortcut, through the Cyber Resilience Act. The Digital Omnibus, Regulation (EU) 2026/1744, left Article 15 untouched while giving the Commission a new power to limit requirements in Articles 9 to 15 for products already covered by sectoral law. The obligations apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those under Article 6(1) and Annex I.
What Article 15 requires, and of whom
Article 15 has five paragraphs and binds providers of high-risk AI systems through Article 16. The overarching duty in paragraph 1 is that such systems “shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle”. Nothing in it was changed by the Omnibus. Two features of that wording drive everything else. The standard is appropriateness rather than a fixed threshold, so the provider must define and defend what is appropriate for this system and this intended purpose. And the duty runs throughout the lifecycle, not only at the point of placing on the market, which links Article 15 to post-market monitoring and to Article 9.
The four duties inside Article 15
Accuracy, and the duty to declare it
The Act sets no accuracy figure. What it does instead is force disclosure: Article 15(3) requires that the levels of accuracy and the relevant accuracy metrics be declared in the accompanying instructions of use. Read with Article 13, this converts an internal engineering number into a representation the deployer relies on and a regulator can test. Choosing the metric is therefore a legal decision as much as a technical one, and a single headline figure for a system whose errors fall unevenly across groups will be difficult to defend. There is no official benchmark to measure against. Article 15(2) does no more than require the Commission, in cooperation with relevant stakeholders and organisations such as metrology and benchmarking authorities, to encourage the development of benchmarks and measurement methodologies. Commentary frequently attributes that task to the AI Office or to ENISA; neither is named in the adopted text.
Robustness, redundancy and fail-safe design
Article 15(4) requires high-risk systems to be “as resilient as possible regarding errors, faults or inconsistencies that may occur within the system or the environment in which the system operates, in particular due to their interaction with natural persons or other systems”, and states that technical and organisational measures shall be taken in this regard. The second subparagraph adds that robustness may be achieved through technical redundancy solutions, which may include backup or fail-safe plans. The permissive drafting matters: redundancy is an illustration, not a mandate. What is mandated is resilience as far as possible, and the reference to interaction with people and other systems puts integration failures and user error squarely inside the analysis.
Feedback loops in systems that keep learning
The third subparagraph of Article 15(4) addresses systems that continue to learn after being placed on the market or put into service. These must be developed so 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. The second limb is the one that gets forgotten: it is not enough to argue that a feedback loop is unlikely, because where one can occur it has to be actively addressed. Any business retraining a model on data generated by its own decisions should read this paragraph carefully.
The cybersecurity paragraph, and the attacks it names
Article 15(5) requires high-risk systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities, with technical solutions appropriate to the circumstances and the risks. The third subparagraph is the operative one for planning. Technical solutions addressing 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, described in the text as data poisoning; attacks on pre-trained components used in training, described as model poisoning; inputs designed to cause the model to make a mistake, described as adversarial examples or model evasion; confidentiality attacks; and model flaws. Very little of that list is covered by a standard security programme: data poisoning is a supply chain problem, model poisoning a third-party component problem, and confidentiality attacks concern inference of training data or model parameters from outputs.
The Cyber Resilience Act shortcut
Article 12 of Regulation (EU) 2024/2847, the Cyber Resilience Act, contains a deeming rule worth understanding before building anything twice. Where high-risk AI systems and the processes put in place by manufacturers meet the essential cybersecurity requirements of that Regulation, they are deemed to comply with the cybersecurity requirements of AI Act Article 15, so far as those requirements are covered by the EU declaration of conformity issued under it. The Digital Omnibus recitals record that this rule should also be reflected in the AI Act itself, to make the interplay more visible.
Three qualifications keep this from being a free pass. The deeming is limited to the cybersecurity limb, so accuracy and robustness are untouched. It extends only so far as the requirements are actually covered by the declaration of conformity, so a partial declaration produces partial relief. And it depends on the product falling within the Cyber Resilience Act at all. The timing is worth planning around: that Regulation entered into force on 10 December 2024, its reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and its main obligations apply from 11 December 2027. For many manufacturers the cybersecurity work will therefore be done under it first and reused for the AI Act second. A separate route may open later: the new Article 2(13) of the AI Act allows requirements in Articles 9 to 15 to be limited for Article 6(1) systems where Annex I Section A legislation provides equivalent or higher protection, with delegated acts due by 2 August 2027.
Practical example
An Uppsala company develops diagnostic imaging software that flags suspected findings for a radiologist. The software is a medical device, so it is high-risk under Article 6(1) and Annex I, Läkemedelsverket is the Swedish market surveillance authority, and Article 15 applies from 2 August 2028. The company already runs a mature quality system under the medical device rules and holds a security certification.
Neither of those answers Article 15. The company has to fix which accuracy metrics it will declare in the instructions for use, and sensitivity and specificity reported as single figures will not survive contact with a regulator if performance varies materially by scanner or patient group. It has to show resilience to the environment it runs in, which includes malformed image files and integration failures with hospital systems. If it retrains on data influenced by radiologists who saw the model’s own flags, it has a feedback loop to address rather than merely note. On cybersecurity it has to consider whether its training data supply chain could be poisoned, whether pre-trained components it did not build are trustworthy, and whether the model can be induced to misclassify by crafted inputs. Because the software is also a product with digital elements, the sensible order is to do the cybersecurity work under the Cyber Resilience Act and then rely on the Article 12 deeming rule for what the declaration of conformity covers.
Common mistakes companies make
The first is treating Article 15 as satisfied by an existing security certification. Conventional certifications address confidentiality, integrity and availability of systems, not poisoning, evasion or model inversion, which Article 15(5) names specifically. The second is declaring a single headline accuracy figure in the instructions for use, which is easy to write and hard to defend when performance varies across the population the system is used on. The third is picking metrics for a marketing claim rather than the intended purpose, so that the Article 9 risk analysis and the Article 13 instructions tell inconsistent stories. The fourth is treating the feedback loop paragraph as inapplicable because the system is not formally described as continuously learning, when in substance it is retrained on its own influenced outputs. The fifth is assuming the Cyber Resilience Act deeming rule covers the whole of Article 15, when it reaches only the cybersecurity requirements and only so far as the declaration of conformity covers them.
Recommended actions
Begin with the declaration, because it disciplines everything upstream. Decide what accuracy metrics you will publish in the instructions for use, at what granularity and on what evaluation data, and make sure the answer is consistent with the thresholds fixed under Article 9 before testing. Then run an adversarial review of the model itself rather than only the infrastructure around it, using the attack categories named in Article 15(5) as the agenda, and record what you found and did. That record is the evidence that the appropriateness standard was met.
In parallel, work out which other regime already covers you. If your product falls within the Cyber Resilience Act, sequence the work so the cybersecurity evidence is produced once and reused, and check exactly which requirements your declaration of conformity covers, because that scope is the boundary of the deeming rule. And keep the analysis live after launch: the duty to perform consistently throughout the lifecycle means an accuracy claim that was true at release and drifts afterwards is a compliance problem, not just a quality problem.
Frequently asked questions
If we comply with the Cyber Resilience Act, are we compliant with Article 15?
Partly, and only on cybersecurity. Article 12 of the Cyber Resilience Act deems high-risk AI systems that meet its essential cybersecurity requirements to comply with the cybersecurity requirements of AI Act Article 15, but only so far as those requirements are covered by the EU declaration of conformity issued under that Regulation. The accuracy and robustness duties in Article 15(1), (3) and (4) sit outside the deeming rule entirely, as does everything else in Chapter III.
What level of accuracy does the AI Act require?
None in numerical terms. Article 15(1) requires an appropriate level of accuracy for the system and its intended purpose, and Article 15(3) requires the levels and the relevant metrics to be declared in the instructions of use. What counts as appropriate is for the provider to determine and justify, informed by the risk analysis under Article 9 and by the state of the art.
Does Article 15 apply to our chatbot or to the AI models we build?
Article 15 is a requirement for high-risk AI systems, so it applies only if the system is classified as high-risk under Article 6. A customer service chatbot will usually not be, though it will attract the transparency obligations in Article 50, which have applied since 2 August 2026. General-purpose AI models are governed by a separate regime in Chapter V rather than by Article 15. If you supply a model a customer builds into a high-risk system, expect Article 15 to reach you contractually even where it does not reach you directly.
Conclusion
Article 15 asks for three things that cannot be bought off the shelf: an accuracy claim you are prepared to publish and defend, resilience to the messy environment the system actually runs in, and protection against attacks aimed at the model rather than the network. The Cyber Resilience Act offers a real shortcut on the third, but only within the scope of a declaration of conformity and only for products it covers. With the deadlines set at 2 December 2027 and 2 August 2028, and no harmonised standard yet cited in the Official Journal, the businesses in the best position will be those that documented their own reasoning rather than waiting to be told what good looks like. Lawgent helps businesses meet AI Act accuracy, robustness and cybersecurity requirements and align them with Cyber Resilience Act compliance.
