Skip to content
AIAssuranceLabs
Menu

Art. 15: Accuracy, robustness and cybersecurity under the EU AI Act

Art. 15 requires the provider to design and develop a high-risk AI system so that it achieves an appropriate level of accuracy, robustness and cybersecurity. The system performs consistently in those respects throughout its lifecycle. The provider declares the accuracy levels and metrics in the instructions for use. In this mapping, seven elements are testable, six are documentation and four are process. Regulation (EU) 2026/1744 moved the Annex III application date Deferred and the Annex I date, and left the content unchanged.

Where this applies

What the text requires

The accuracy levels and metrics declared under Art. 15(3) are the same values the instructions for use carry under Art. 13(3). The testing data sets that produce the accuracy result meet the quality criteria of Art. 10. Testing under Art. 9(8) runs against prior defined metrics and probabilistic thresholds, and the accuracy metrics declared under Art. 15(3) belong to that set.

What the text requires and how each element is verified
RequiresTestableDocumentationProcess
  1. Art. 15(1)The provider designs and develops the high-risk AI system so that it achieves an appropriate level of accuracy, robustness and cybersecurity. The system performs consistently in those respects throughout its lifecycle.
  2. Art. 15(2)The Commission encourages, as appropriate, the development of benchmarks and measurement methodologies. The Commission does this in cooperation with relevant stakeholders and organisations such as metrology and benchmarking authorities. The benchmarks and methodologies address the technical aspects of how to measure the appropriate levels of accuracy and robustness set out in Art. 15(1) and any other relevant performance metrics. This paragraph places a task on the Commission, not on the provider.
  3. Art. 15(3)The provider declares the levels of accuracy and the relevant accuracy metrics of the high-risk AI system in the accompanying instructions for use.
  4. Art. 15(4)The high-risk AI system is as resilient as possible regarding errors, faults or inconsistencies that may occur within the system or in the environment in which the system operates, in particular due to its interaction with natural persons or other systems. The provider takes technical and organisational measures in this regard. The provider may achieve robustness through technical redundancy solutions, which may include backup or fail-safe plans. A high-risk AI system that continues to learn after being placed on the market or put into service is developed so that it eliminates or reduces as far as possible the risk of possibly biased outputs influencing input for future operations (feedback loops). The provider addresses any such feedback loops with appropriate mitigation measures.
  5. Art. 15(5)The high-risk AI system is resilient against attempts by unauthorised third parties to alter its use, outputs or performance by exploiting system vulnerabilities. The technical solutions for the cybersecurity of the system are appropriate to the relevant circumstances and the risks. The technical solutions that address AI-specific vulnerabilities include, where appropriate, measures to prevent, detect, respond to, resolve and control attacks of five kinds: attacks that manipulate the training data set (data poisoning); attacks on 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; and model flaws.
  • Accuracy on a held-out test set, measured with the metrics declared in the instructions for use, is at or above the declared level (Art. 15(1) and 15(3))
  • Accuracy holds on a distribution-shifted set and across the released model versions, so that the system performs consistently throughout its lifecycle (Art. 15(1))
  • Outputs stay within the declared performance under input perturbation, noise, malformed input, edge cases and inconsistent signals from natural persons or connected systems (Art. 15(4), first subparagraph)
  • The technical redundancy, backup or fail-safe solution takes over and holds the declared behaviour when a component fault is injected, where such a solution exists (Art. 15(4), second subparagraph)
  • For a system that continues to learn, feeding its own possibly biased outputs back as inputs does not move performance beyond the declared level, and the mitigation measure activates as documented (Art. 15(4), third subparagraph)
  • The system resists each attack class named in Art. 15(5), third subparagraph: data poisoning of the training set, model poisoning of pre-trained components, adversarial examples or model evasion, confidentiality attacks such as model extraction and membership inference, and exploitation of model flaws, with prompt injection included for systems built on a language model
  • The cybersecurity measures detect, respond to, resolve and control a simulated unauthorised attempt to alter the use, outputs or performance of the system (Art. 15(5), first and third subparagraphs)
  • Declaration of the accuracy levels and the relevant accuracy metrics in the instructions for use, with the metric definitions, the test-set description and the measurement conditions (Art. 15(3))
  • Rationale for the level of accuracy, robustness and cybersecurity chosen as appropriate for the intended purpose, with the source of each target (Art. 15(1))
  • Description of the technical and organisational measures taken for resilience to errors, faults and inconsistencies (Art. 15(4), first subparagraph)
  • Description of the technical redundancy solution and the backup or fail-safe plan where one is used (Art. 15(4), second subparagraph)
  • Design description of how a continuously learning system limits feedback loops and the mitigation measures that address them (Art. 15(4), third subparagraph)
  • Cybersecurity risk assessment that shows the technical solutions are appropriate to the relevant circumstances and the risks, and that records, for each attack class in Art. 15(5), whether a measure applies and the reason where one is omitted as not appropriate (Art. 15(5), second and third subparagraphs)
  • Re-measurement of accuracy, robustness and cybersecurity after each model, data or operating-environment change, with a defined trigger, so that consistent performance is shown across the lifecycle (Art. 15(1))
  • Operation of the organisational measures for resilience: fault handling, incident escalation and the operating procedures that respond to errors and inconsistencies in service (Art. 15(4), first subparagraph)
  • Operation of the feedback-loop mitigation measures while the system continues to learn, with periodic review of learned behaviour (Art. 15(4), third subparagraph)
  • Ongoing prevention, detection, response, resolution and control of AI-specific attacks: vulnerability management, threat monitoring and the response path for a detected attack (Art. 15(5))

Metrics and where thresholds come from

Threshold sources, in order of precedence

  1. A harmonised standard cited in the Official Journal (none as of the anchor date)
  2. A JTC 21 draft standard (prEN), with its stage
  3. An ISO/IEC standard or technical report, with its stage
  4. A Commission guideline or code of practice, with its date from the standards data
  5. NIST AI RMF or a sector framework
  6. The state of the art, which the provider justifies and documents

Regulation (EU) 2024/1689 sets no numeric threshold for accuracy, robustness or cybersecurity in Art. 15. Art. 15(1) requires an appropriate level, and Art. 15(3) requires the provider to declare the level and the metrics in the instructions for use. Art. 15(2) assigns benchmarks and measurement methodologies to the Commission, working with metrology and benchmarking authorities, and none is published as of the anchor date. No harmonised standard is cited in the Official Journal, so the first level of the source hierarchy is empty and no presumption of conformity exists. The level in use today is the JTC 21 draft standards: prEN 18229-2 at draft stage for accuracy and robustness, and prEN 18282 at enquiry stage for cybersecurity. Below them sit ISO/IEC TR 24029-1:2021 and ISO/IEC 24029-2:2023 for robustness methods, and NIST AI RMF 1.0 for metric selection rationale. None of these documents publishes a numeric threshold for a high-risk system; the provider justifies the target against the context of use. The acceptance-criteria step of PR-15-ROB records that justification with the metric definition, the test set and the measurement conditions.

Metric sources and their stage
Source and stageTitleWhat it provides hereVerified on
prEN 18229-2DraftAI trustworthiness framework, part 2: accuracy and robustnessaccuracy and robustness metric categories, the structure of the accuracy declaration for the instructions for use, and the perturbation classes a robustness assessment covers

Verified on kla.digital, JTC 21 Standards Tracker (updated 29 June 2026)

prEN 18282EnquiryCybersecurity for AI systemsthe AI-specific threat list behind Art. 15(5) (data poisoning, model poisoning, model evasion, confidentiality attacks) and the specification of the measures a cybersecurity test checks

Verified on kla.digital, JTC 21 Standards Tracker (updated 29 June 2026)

ISO/IEC TR 24029-1:2021PublishedAssessment of the robustness of neural networks, overviewrobustness assessment method categories (statistical, formal, empirical) and the terminology for stating a robustness property and its test

Verified on ISO catalogue, ISO/IEC TR 24029-1:2021

ISO/IEC 24029-2:2023PublishedRobustness of neural networks, formal methodsthe formal-method procedure for showing a robustness property over a bounded input region and the content of a formal robustness result report

Verified on ISO catalogue, ISO/IEC 24029-2:2023

NIST AI RMF 1.0PublishedAI Risk Management FrameworkMeasure function: metric selection rationale, and the valid and reliable and secure and resilient characteristics used to structure Art. 15 evidence

Verified on NIST, AI Risk Management Framework

Procedures

Each protocol is versioned; its page states the derivation from the standards above. PR-15-ROB v1.0 covers the seven testable elements, from held-out accuracy to the attack classes named in Art. 15(5).

What an assessor asks for

  • Accuracy test report on held-out and distribution-shifted sets (PR-15-ROB output)
  • Accuracy declaration in instructions for use (Art. 15(3) and Art. 13(3)(b)(ii))
  • Robustness test report with perturbation, fault-injection and fail-safe results (PR-15-ROB output)
  • Adversarial and cybersecurity test report covering the Art. 15(5) attack list (PR-15-ROB output)
  • Feedback-loop mitigation test record for a continuously learning system (PR-15-ROB output)
  • Validation and testing procedures description with metric definitions (Annex IV section 2(g))
  • Cybersecurity measures description with the risk-appropriateness rationale (Annex IV section 2(h))
  • Lifecycle performance monitoring record with re-test triggers

Common findings

  • Accuracy is declared as a single number without the metric definition, the test set or the conditions under which it was measured
  • The declared accuracy comes from the development validation set, and no held-out or distribution-shifted measurement exists
  • Robustness is asserted from the model architecture, and no perturbation or fault-injection result is recorded
  • The cybersecurity evidence covers the hosting platform and not the AI-specific attack classes named in Art. 15(5)
  • A system that continues to learn has no test that feeds its own outputs back as inputs and measures the drift
  • Performance is measured once before release, and no trigger re-runs the tests after a model, data or environment change

Questions

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

Art. 15(1) requires the provider to design and develop a high-risk AI system so that it achieves an appropriate level of accuracy, robustness and cybersecurity. The same paragraph requires consistent performance in those respects throughout the lifecycle. Art. 15(3) requires the accuracy levels and metrics to be declared in the instructions for use. Art. 15(4) requires resilience to errors, faults and inconsistencies, and control of feedback loops in systems that continue to learn. Art. 15(5) requires resilience against unauthorised attempts to alter use, outputs or performance, with measures against data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws where appropriate. Regulation (EU) 2026/1744 did not change this text.

What is Article 15 of the EU AI Act?

Article 15 is the accuracy, robustness and cybersecurity requirement for high-risk AI systems in Chapter III, Section 2 of Regulation (EU) 2024/1689. It applies to providers of systems classified as high-risk under Art. 6 and Annex I or Annex III. It has five paragraphs. Paragraphs 1, 3, 4 and 5 place duties on the provider. Paragraph 2 asks the Commission to encourage benchmarks and measurement methodologies with metrology and benchmarking authorities. The application date follows the Annex III or Annex I entry on the regulation page.

How is Article 15 accuracy, robustness and cybersecurity testing carried out?

Accuracy is measured on a held-out set and a distribution-shifted set with the metrics declared under Art. 15(3). Robustness is measured under input perturbation, noise, malformed input and injected faults, using the statistical, formal and empirical method categories of ISO/IEC TR 24029-1:2021. Formal robustness properties follow the procedure in ISO/IEC 24029-2:2023. Cybersecurity is tested against each attack class in Art. 15(5), with the threat list in the draft prEN 18282 as the reference. A continuously learning system is tested by feeding its outputs back as inputs and measuring the drift under Art. 15(4). Every step is written in PR-15-ROB with its source clause.

Does AI Act Article 15 set a numeric accuracy threshold?

No. Art. 15(1) requires an appropriate level of accuracy and does not state a number. Art. 15(3) requires the provider to declare the level and the metrics in the instructions for use. Art. 15(2) assigns benchmarks and measurement methodologies to the Commission, and none is published as of the anchor date. No harmonised standard is cited in the Official Journal for Art. 15. The draft prEN 18229-2 supplies metric categories and the declaration structure, not a threshold. The provider sets the target from the context of use and records the justification, which the acceptance-criteria step of PR-15-ROB captures.

How we test this

We test high-risk AI systems against Art. 15(1), 15(4) and 15(5): accuracy on held-out and distribution-shifted sets with the declared metrics, robustness under input perturbation and injected faults, and resistance to each attack class in Art. 15(5). We prepare the test reports and the accuracy declaration an assessor asks for; the scope limits are stated on what we cannot do.

What we cannot do

  • We do not perform conformity assessments where a notified body is required.
  • We do not issue CE marking or the EU Declaration of Conformity.
  • We are not a notified body.
  • We do not give legal opinions on classification or liability.
  • We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.

Read the full statement