What does Article 15 of the EU AI Act require for accuracy, robustness and cybersecurity?

Updated 9 August 2026 for Regulation (EU) 2026/1744.

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" — with the accuracy levels and metrics declared in the instructions of use.

Quick answer

• Who it binds: The provider — under Article 16, point (a), providers must "ensure that their high-risk AI systems are compliant with the requirements set out in Section 2", which includes Article 15.
• The standard: "An appropriate level", not a number. Article 15 sets no threshold; Article 15(2) only tasks the Commission with encouraging benchmarks and measurement methodologies.
• The declaration: "The levels of accuracy and the relevant accuracy metrics" must be declared in the accompanying instructions of use (Article 15(3)).
• The attack list: Resilience against unauthorised third parties, with AI-specific measures — data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks or model flaws — "where appropriate" (Article 15(5)).
• From when: Article 15 applies from 2 December 2027 to systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 to systems high-risk under Article 6(1) and Annex I (Article 113, third paragraph, point (c), as amended by Regulation (EU) 2026/1744).

What level of accuracy is "appropriate"?

Article 15(1) requires that high-risk AI systems "achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle." Two duties sit in that sentence. The first is a design standard — appropriate, judged against the system and its intended purpose, not a universal bar. The second is temporal: consistency "throughout their lifecycle" makes post-launch degradation — model drift, a broken data pipeline, a silently failing integration — a compliance question, not merely an engineering one.

The Act does not define "appropriate", and no accuracy floor appears anywhere in Article 15. Instead, Article 15(2) hands the measurement problem to the Commission: "in cooperation with relevant stakeholders and organisations such as metrology and benchmarking authorities", it "shall … encourage, as appropriate, the development of benchmarks and measurement methodologies." Note the verb — encourage, not adopt or mandate. The Article 40 harmonised standards expected to concretise the Section 2 requirements were still incomplete at the time of writing, and Article 15(2) itself promises facilitation rather than binding benchmarks. Until standards land, choosing the metrics and justifying the levels is the provider's own documented judgement — which is exactly what the technical documentation demands: point 4 of Annex IV requires "a description of the appropriateness of the performance metrics for the specific AI system."

Where do the accuracy metrics have to be declared?

In the document your customers read. Article 15(3): "The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use."

That declaration is not free-floating — it locks into two other provisions:

• Article 13 fixes what the declaration must say. Under Article 13(3), point (b), the instructions for use must state "the level of accuracy, including its metrics, robustness and cybersecurity referred to in Article 15 against which the high-risk AI system has been tested and validated and which can be expected", plus "any known and foreseeable circumstances that may have an impact" on that expected level. The full instructions-for-use regime is covered in the transparency obligations guide.
• Article 9 fixes where the numbers come from. Testing under Article 9(8) runs "against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose" — the testing regime belongs to the risk management guide.

The practical consequence is a three-way consistency check. The metric you tested against (point 2(g) of Annex IV requires the "metrics used to measure accuracy, robustness" and "test logs and all test reports dated and signed by the responsible persons"), the level you declare in the instructions of use, and the appropriateness rationale in the technical documentation must all carry the same numbers. A declared accuracy figure that cannot be traced to a signed test report is the kind of gap a market surveillance authority finds first — see the technical documentation guide for the Annex IV structure.

What does robustness require under Article 15(4)?

Article 15(4) requires high-risk AI 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." Two things are easy to miss. The trigger set includes the environment — an upstream API change or a user typing garbage is inside scope, not an excuse. And the response must span "technical and organisational measures" — monitoring rotas and escalation paths count alongside input validation.

The second subparagraph is permissive, not mandatory: robustness "may be achieved through technical redundancy solutions, which may include backup or fail-safe plans." Redundancy is one accepted route, never an obligation in itself.

The third subparagraph targets systems that "continue to learn after being placed on the market or put into service": they must be developed "to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations (feedback loops)", and any such feedback loops must be "duly addressed with appropriate mitigation measures." If your model retrains on its own outcomes — a screening tool learning from the hires it produced — Article 15(4) demands designed-in controls against that spiral, not an after-the-fact patch.

Which attacks must the system withstand?

Article 15(5) requires resilience "against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities." The second subparagraph adds proportionality: the technical solutions must be "appropriate to the relevant circumstances and the risks" — a sealed on-premise model and a public-facing API do not owe the same defences.

The third subparagraph is what makes this an AI provision rather than generic IT security. Solutions addressing AI-specific vulnerabilities "shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for" attacks that manipulate "the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws." Read the qualifier where it stands: "where appropriate" conditions which measures the named attack classes require in your circumstances — it does not delete the list. A perimeter firewall answers none of these; poisoned training data or an adversarial input walks straight through it.

Does an existing cybersecurity certificate help?

It can — within narrow limits. Under Article 42(2), high-risk AI systems "that have been certified or for which a statement of conformity has been issued under a cybersecurity scheme pursuant to Regulation (EU) 2019/881", with references published in the Official Journal, "shall be presumed to comply with the cybersecurity requirements set out in Article 15" — but only "in so far as the cybersecurity certificate or statement of conformity or parts thereof cover those requirements."

Three limits follow directly from the text: the presumption attaches only to schemes under the EU Cybersecurity Act (Regulation (EU) 2019/881) with Official Journal-published references; it covers only what the certificate actually covers; and it reaches only the cybersecurity requirements — accuracy and robustness under Article 15(1), (3) and (4) are untouched. An ISO 27001 certificate sits outside Article 42(2) entirely: useful evidence, no presumption.

What this means for you

If you're a provider: Article 15 binds you, and it applies from 2 December 2027 to Annex III systems and from 2 August 2028 to Annex I systems (Article 113, third paragraph, point (c)) — the high-risk obligations overview maps the full set. Work backwards from the declaration:

• pick metrics you can defend and record the appropriateness rationale point 4 of Annex IV requires;
• test against them under Article 9(8) with signed reports;
• declare the same levels in the instructions of use per Article 15(3);
• stand up lifecycle monitoring so "perform consistently" survives contact with production;
• run the Article 15(5) attack list against your architecture and document, per class, either the measure or why it is not appropriate.

Complipath's requirements checklist tracks every obligation the classification triggers, with status, owner, evidence link and notes — so the accuracy declaration, the test reports and the cybersecurity measures each have an owner and a home.

If you're a deployer: Article 15 does not bind you, but its output is addressed to you. The declared accuracy levels and metrics arrive in the instructions of use — and under Article 26(1) you must take appropriate technical and organisational measures to use the system "in accordance with the instructions for use accompanying the systems, pursuant to paragraphs 3 and 6." Before purchase, ask for the declared metrics, the circumstances that affect them, and how continued-learning feedback loops are mitigated; a provider without answers has an Article 15 problem that becomes your operational one. Unsure which role you hold? See provider vs deployer.

Which of your systems carry Article 15 duties?

Classify your system now — 7 questions on the main line, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.

FAQ

Does the EU AI Act set minimum accuracy thresholds for high-risk AI? No. Article 15(1) requires "an appropriate level of accuracy", and no numeric threshold appears in Article 15. Article 15(2) tasks the Commission with encouraging, as appropriate, benchmarks and measurement methodologies in cooperation with bodies such as metrology and benchmarking authorities. Until standards exist, the provider defines and justifies the metrics.

Do accuracy metrics have to be made public? Article 15(3) requires the levels of accuracy and the relevant accuracy metrics to be declared in the accompanying instructions of use, which reach deployers under Article 13. Article 15 itself imposes no publication to the general public — the declaration travels with the system to the people who operate it.

Does an ISO 27001 certificate satisfy Article 15's cybersecurity requirement? Not by presumption. Article 42(2) presumes compliance with Article 15's cybersecurity requirements only for certificates or statements of conformity under a Regulation (EU) 2019/881 cybersecurity scheme with Official Journal-published references, and only in so far as they cover those requirements. ISO 27001 remains supporting evidence, nothing more.

What does Article 15 require for systems that keep learning after deployment? Under Article 15(4), 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 possibly biased outputs influencing input for future operations — feedback loops — and to ensure any such loops are duly addressed with appropriate mitigation measures.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Articles 9, 13, 15, 16, 26, 42 and 113, and Annex IV, as amended by Regulation (EU) 2026/1744 (EUR-Lex), which replaced Article 113, third paragraph, point (c). Article 15 itself is unamended; only its date of application moved. The Article 40 harmonised standards expected to concretise the Section 2 requirements were still incomplete at the time of writing, and the benchmarks and measurement methodologies contemplated by Article 15(2) are a facilitation mandate for the Commission, not adopted instruments; the Article 15 obligations apply regardless, and metric selection remains a provider judgement until standards or guidance say otherwise.