EU AI Act Article 15. Accuracy, robustness and cybersecurity requirements for high-risk AI.

Article 15 addresses what a high-risk AI system must actually achieve, not just what documentation must surround it. A system that is well-documented under Articles 11 and 17 but performs poorly against its declared accuracy metrics, fails under adversarial conditions, or has cybersecurity vulnerabilities in its deployment environment is not compliant with Article 15. Deployers bear obligations here alongside providers, and those obligations are ongoing throughout the system's operational life.

What Article 15 requires: the three dimensions

Article 15(1) of Regulation (EU) 2024/1689 states that high-risk AI 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 with respect to those aspects throughout their lifecycle. The three dimensions are explicitly distinct and each carries its own set of requirements.

Accuracy, under Article 15(2), means that the performance of the AI system in terms of its ability to achieve its intended purpose must be validated against declared metrics. Those metrics must be included in the instructions for use that providers supply under Article 13 and Annex XIII. The metrics must reflect what the system is actually designed to do: a classification system is measured on its classification accuracy, a prediction system on its predictive validity, an image recognition system on its detection rate and false positive rate.

Robustness, addressed in Article 15(3), is the ability of the high-risk AI system to be resilient with regard to errors, faults, or inconsistencies that may occur within the system or in its environment, in particular those that may affect health and safety or fundamental rights. Robustness is a distinct property from accuracy: a system can be highly accurate on clean, well-formed inputs but brittle when inputs deviate from those conditions.

Cybersecurity, under Article 15(4), requires that high-risk AI systems be resilient against attempts by third parties to alter their use, outputs, or performance by exploiting vulnerabilities. This includes model-level vulnerabilities (adversarial inputs designed to cause misclassification), system-level vulnerabilities (unauthorised access to the AI system's operating environment), and infrastructure-level vulnerabilities (attacks on the data pipelines or logging systems that support the AI deployment).

The provider-deployer split under Article 15

The most practically important aspect of Article 15 for deployers is understanding which obligations fall on providers and which fall on deployers. Providers bear the primary design and development obligations: they must ensure that accuracy metrics are validated during development, that the system is tested for robustness against the failure modes in Article 15(3), and that cybersecurity protections are built into the system architecture. These obligations are satisfied through the conformity assessment under Article 43 and the technical documentation under Article 11.

Deployers have independent obligations that persist throughout the operational life of the deployment. First, deployers must use the system within the scope defined by the instructions for use, which specify the conditions under which the declared accuracy metrics are valid. Using the system outside those conditions may invalidate the accuracy declarations and create a compliance gap. Second, deployers must monitor actual system performance against declared accuracy metrics as part of their post-market monitoring obligation under Article 72. Where performance degrades below declared levels, the deployer must take corrective action under Article 20 and notify the provider under Article 26(6). Third, deployers must implement access management, authentication, and monitoring controls in their own infrastructure to protect the cybersecurity of the AI deployment from their end of the system boundary.

Accuracy requirements: what deployers must track

The accuracy metrics declared by the provider in the instructions for use are the baseline against which deployers must measure operational performance. Article 15(2) specifies that the levels of accuracy and the relevant accuracy metrics shall be stated in the accompanying instructions for use. For deployers, the practical implication is that they must establish a monitoring process capable of detecting when operational accuracy falls below the declared baseline.

What this looks like in practice depends on the specific system and use case. For a medical imaging AI, it may mean periodic audit of a sample of cases against expert review. For an employment screening tool, it may mean tracking the rate at which human reviewers override the system's recommendations. For a credit assessment model, it may mean comparing the model's predicted default rates against actual outcomes over time. The monitoring does not need to be continuous, but it must be systematic and documented.

When performance degrades, Article 26(1) requires that deployers take appropriate technical and organisational measures to address the deviation, and Article 26(6) requires notification to the provider so they can assess whether a conformity issue exists. The Article 12 logging requirements support this process: logs of AI system outputs provide the data necessary for post-market accuracy monitoring. A deployer that cannot demonstrate they track operational accuracy against declared metrics is in a structurally weak position for both regulatory compliance and for insurance claims arising from AI failures.

Robustness: three failure modes to address

Article 15(3) identifies robustness as the ability to withstand errors, faults, and inconsistencies that may occur within the system or in its environment. Reading the provision in light of the broader regulation, robustness for high-risk AI encompasses three distinct failure modes, each of which must be addressed through technical or organisational measures.

The first is random or incidental error in inputs or operating conditions. An AI system used in a production environment will inevitably encounter inputs that deviate from the clean, well-formed data on which it was trained or tested. A robust system must either handle these gracefully, providing a meaningful output with appropriate uncertainty indication, or fail safely, flagging the input for human review rather than producing a confident but unreliable output.

The second is systemic failure in the deployment environment. This covers scenarios where the infrastructure surrounding the AI system fails: sensor malfunctions, database connectivity issues, integration failures between the AI system and other systems it depends on. Robustness requires that the AI system degrade safely under these conditions rather than producing misleading outputs based on incomplete or corrupted information.

The third is deliberate adversarial manipulation, which Article 15(3) explicitly addresses by referencing attacks specifically designed to alter the use, outputs, or performance of the system. For high-risk AI systems, providers are required to implement protections against known adversarial attack vectors. Deployers must ensure that their operational environment does not introduce additional attack surfaces: for example, by allowing untrusted parties to directly inject inputs into the AI system without validation, or by exposing the AI system's API without authentication.

Cybersecurity obligations for deployers

Article 15(4) addresses cybersecurity specifically and assigns obligations to both providers and deployers. For deployers, the key obligations concern the operational environment in which the AI system runs, which is under the deployer's control rather than the provider's.

Access management is the most fundamental cybersecurity control at the deployer level. Only authorised users and systems should be able to interact with the AI system, submit inputs, retrieve outputs, or modify its configuration. This requires role-based access controls, authentication requirements, and audit logs of access. Network security controls are also a deployer responsibility: if the AI system is accessed over a network, the communication should be encrypted and authenticated. API keys and credentials should be stored securely and rotated periodically.

Supply chain cybersecurity is a less obvious but important category. High-risk AI deployments often involve multiple software components: the AI model itself, data preprocessing pipelines, output post-processing logic, integration layers connecting the AI system to other enterprise systems. Each component is a potential attack surface. Deployers should maintain a software bill of materials for their AI deployment and apply security patching to those components as vulnerabilities are disclosed.

The connection between Article 15 cybersecurity requirements and the broader EU cybersecurity framework is also relevant. The NIS2 Directive (Directive (EU) 2022/2555), which entered into force for essential and important entities in October 2024, imposes cybersecurity risk management requirements that overlap with Article 15 obligations for entities in its scope. Deployers of high-risk AI systems in NIS2-regulated sectors should treat Article 15 cybersecurity compliance as one component of their broader NIS2 programme rather than as a separate exercise.

Interaction with Articles 9, 12, and 72

Article 15 does not stand alone. Its practical implementation depends on three other articles that deployers need to understand in connection with it. Article 9 requires that deployers establish and maintain a risk management system throughout the lifecycle of the high-risk AI system. That risk management system must identify and evaluate known and foreseeable risks including risks to accuracy, robustness, and cybersecurity. The measures documented under Article 15 are the technical responses to those Article 9 risks.

Article 12 requires that high-risk AI systems be designed with logging capabilities enabling automatic recording of events throughout the operational life of the system. Those logs are the evidential foundation for Article 15 monitoring: accuracy monitoring requires a record of the system's outputs, robustness monitoring requires records of inputs that fell outside expected parameters, and cybersecurity monitoring requires access logs and anomaly detection records.

Article 72 requires deployers to establish a post-market monitoring system that actively monitors the performance of high-risk AI systems after deployment. Post-market monitoring for Article 15 purposes means tracking accuracy against declared metrics, testing robustness under operational conditions, and reviewing cybersecurity controls at periodic intervals or after significant changes. The Article 72 monitoring plan should explicitly reference Article 15 metrics and specify the frequency and methodology of performance review.

For the full context on deployer obligations under Article 26, which governs how Article 15 fits into the broader compliance programme, see the complete Article 26 guide. For the interaction between Article 15 and the risk management system, see the Article 9 deployer guide.

Insurance underwriting and Article 15

The requirements of Article 15 are directly material to the emerging AI liability insurance market in Europe. Underwriters assessing an enterprise's AI deployment examine accuracy, robustness, and cybersecurity as part of their risk assessment, because these are the properties that determine whether a deployment is likely to produce failures that generate insurable losses.

An AI deployment that can demonstrate strong Article 15 compliance produces a better underwriting profile. Documented accuracy metrics and monitoring records demonstrate that the deployer has a systematic understanding of when and how the system might fail. Robustness testing documentation shows that adversarial and edge-case failure modes have been identified and addressed. Cybersecurity controls documentation shows that the deployment environment is protected against the attack vectors most likely to produce AI-specific losses (data poisoning, model manipulation, output fabrication via prompt injection).

European AI liability products, including the Munich Re aiSure framework and coverage frameworks emerging from Lloyd's of London, are beginning to incorporate certification and compliance documentation as underwriting inputs. An enterprise that can provide its Article 15 compliance documentation, its accuracy monitoring records, and its cybersecurity controls inventory presents itself as a lower-risk proposition. Treating Article 15 compliance documentation as underwriting-ready material from the outset is a practical step that pays dividends in both premium and the availability of coverage. For the insurance implications of compliance documentation, see the analysis on building an insurance evidence chain from compliance documentation.

Frequently asked questions