Skip to main content

EU AI Act Article 15: Accuracy, Robustness and Cybersecurity

Article 15 requires high-risk AI systems to reach appropriate accuracy, robustness and cybersecurity. This guide covers what it requires and common ways to test it.

Providers of high-risk AI systems must design them to reach an appropriate level of accuracy, robustness and cybersecurity throughout their lifecycle (Article 15).

Providers must declare accuracy levels and metrics in the instructions for use (Article 15(3)). This applies from 2 December 2027 (Annex III) and 2 August 2028 (Annex I) to systems placed on the EU market or put into service. Fines reach up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: choose your accuracy metrics and test them.

Article 15 in five points

Article 15(1) requires an appropriate level of accuracy, robustness and cybersecurity, and consistent performance throughout the lifecycle. The five points below group paragraphs 3 to 5. The Act sets goals, not test methods or thresholds. The Commission is to encourage benchmarks and measurement methods together with metrology and benchmarking authorities (Article 15(2)).

Declared accuracy levels and metrics

Declare the levels of accuracy and the relevant accuracy metrics in the instructions for use (Article 15(3)).

Resilience to errors and faults

Make the system as resilient as possible to errors, faults or inconsistencies in the system or its environment, including its interaction with people or other systems. Take technical and organisational measures; technical redundancy, such as backup or fail-safe plans, can achieve robustness (Article 15(4)).

Control of feedback loops

If the system keeps learning after it is placed on the market or put into service, eliminate or reduce, as far as possible, the risk that biased outputs influence future inputs (feedback loops). Address these loops with mitigation measures (Article 15(4)).

Resilience against unauthorised third parties

The system must resist attempts by unauthorised third parties to alter its use, outputs or performance by exploiting vulnerabilities. Cybersecurity solutions must fit the circumstances and the risks (Article 15(5)).

Measures against AI-specific attacks

Where appropriate, include measures to prevent, detect, respond to, resolve and control the attacks and flaws that Article 15(5) names. They are data poisoning (manipulated training data), model poisoning (manipulated pre-trained components), adversarial examples or model evasion (inputs built to cause errors), confidentiality attacks and model flaws.

Four engineering steps that support Article 15

Article 15 prescribes no test method. These steps are common ways to show that the requirements are met.

Adversarial testing in CI

Run adversarial robustness tests in your CI/CD pipeline: generate adversarial examples, test model boundaries and check defences against known attack patterns.

Accuracy benchmarking

Measure accuracy with the metrics you declared, for every model version, dataset and deployment environment, to detect degradation.

Redundancy and fail-safe design

Build fallbacks for critical paths: backup models, safety monitors and a hand-off to a person when confidence drops below a threshold you set.

Model supply chain security

Scan dependencies and base models for vulnerabilities, and verify the provenance of external models and the integrity of training pipelines.

Instructions for use state the tested and expected levels

The instructions for use must state the level of accuracy, robustness and cybersecurity the system was tested and validated against and which can be expected. They must also state the known circumstances that can affect that level (Article 13(3)(b)(ii)). Keep the test results that back each declared level.

Article 15 applies to high-risk AI systems only

A system is high-risk if it falls into an Annex III area, unless an Article 6(3) exemption applies. A system that profiles natural persons is always high-risk. A system is also high-risk if it is, or is a safety component of, an Annex I product needing third-party conformity assessment (Article 6). Providers are covered when they place a system on the EU market or put it into service in the EU, wherever they are established (Article 2(1)(a)). Providers and deployers in a third country are also covered when the system’s output is used in the EU (Article 2(1)(c)). High-risk systems tied to products under the Annex I Section B laws are outside Article 15 (Article 2(2)). For Annex I Section A products, some requirements may be limited (Article 2(13)). This concerns Articles 9 to 15 and 17 to 25, where sector law gives equivalent or higher protection. Delegated acts due by 2 August 2027 will specify which. The Act excludes military, defence and national security uses, systems developed solely for scientific research, and research and testing before market placement (Article 2(3), (6) and (8)). Systems already on the market or in service before the application date are covered only after significant design changes. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)).

Common questions: thresholds, testing, certification and fines

What accuracy threshold is “appropriate”?

The Act gives no number and does not say which level is appropriate for which use. It requires an appropriate level, declared with its metrics in the instructions for use (Article 15(1) and (3)). Declare the metric you use and the result you measured.

Does this require formal red-teaming?

No. Article 15 names no test method. Article 15(5) requires measures against attacks such as data poisoning and adversarial examples, and adversarial testing is one way to show those measures work.

How is robustness tested in practice?

Common methods are fault injection, adversarial example generation, boundary tests and degradation scenarios, using corrupted inputs, distribution shifts and edge cases. Article 15 names none of them. Choose methods that fit the risks you found under Article 9.

Do existing cybersecurity certificates or laws cover Article 15?

Only in two defined cases. Systems certified, or with a statement of conformity issued, under a cybersecurity scheme of Regulation (EU) 2019/881 are presumed to comply with the Article 15 cybersecurity requirements (Article 42(2)). This holds if the scheme’s references are published in the Official Journal, and only as far as the certificate or statement covers them. Systems within the scope of the Cyber Resilience Act (Regulation (EU) 2024/2847) that meet the conditions of its Article 12(1) are deemed to comply (Article 42(3)). Both concern cybersecurity only, not accuracy or robustness.

What documentation is expected for accuracy and robustness?

Declare accuracy levels and metrics in the instructions for use (Article 15(3)). The technical documentation must also describe the validation and testing procedures, the metrics for accuracy and robustness, the test reports and the cybersecurity measures (Annex IV, point 2(g) and (h)).

What are the fines, and is the cap lower for SMEs?

Fines for providers (Article 16) and deployers (Article 26) reach up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). For SMEs, including start-ups, and small mid-caps, the cap is the lower of the two amounts (Article 99(6) and (6a)). Member States lay down the penalty rules (Article 99(1)).

Read next: how Article 15 connects to Articles 9, 10, 11 and 13

Scanara prepares evidence from your repositories

Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.