Article 15, line by line.

Designed in. Held over the lifecycle.

One sentence does the structural work for the entire article. It binds the system as designed, not the operator's process. It uses the operative shall. It scopes the holding horizon to the lifecycle of the system, not the date of placement on the market.

The three nouns are not synonyms. Accuracy attaches to the predictive or decisional output of the system against the task it was designed for. Robustness, in the statutory sense, attaches to fault tolerance and resilience under perturbation, error, fault, and inconsistency · the article unpacks the meaning across paragraphs (4) and (5). Cybersecurity attaches to resistance against unauthorised third parties altering use, outputs, or performance through exploitation of system vulnerabilities. Three pillars, one design discipline.

The phrase perform consistently in those respects throughout their lifecycle is the load-bearing piece. It rules out the deployment pattern in which a system is benchmarked at conformity assessment, placed on the market, and never re-evaluated. The standard is held continuously. The evidence required is therefore continuous.

Placement matters. Article 15 sits inside Section 2 of Chapter III · the requirements the provider must satisfy before placing the system on the Union market. Article 16(a) reads those requirements back as a provider obligation. Article 99(4)(a) reads Article 16 back as a fineable failure at EUR 15 million or 3 percent of global turnover. The route from one sentence in Article 15(1) to the EUR 15 million ceiling is three statutory steps.

Benchmarks and measurement methodologies.

Paragraph (2) is a delegation of the technical-method question to a slower, separate track. The verb is encourage, not adopt. The Commission does not, in this paragraph, fix the measurement floor by regulation. It instructs itself to coordinate the development of benchmarks and measurement methodologies with the bodies most likely to produce them.

Three institutions are operative in practice. The Joint Research Centre is the Commission's in-house science service and the natural anchor for AI benchmark work. ENISA, the European Union Agency for Cybersecurity, attaches to the cybersecurity dimension of paragraph (5). CEN and CENELEC, through Joint Technical Committee 21 on Artificial Intelligence, are the European standardisation organisations executing the Commission's standardisation request of 22 May 2023, which includes accuracy, robustness, and cybersecurity within scope.

Until a harmonised standard is published in the Official Journal of the European Union and triggers the presumption of conformity under Article 40, the operational picture is this · the provider declares the level, justifies the methodology, records the test set, and accepts that a regulator may, on review, find the methodology insufficient. The benchmark track is the long game. The Article 13 declaration is what binds today.

Accuracy declared in the instructions for use.

Paragraph (3) is short and operationally heavy. It binds the provider to declare both the levels and the metrics. Both. A declaration that the system achieves high accuracy without identifying the metric is non-compliant. A declaration that the metric is F1 without specifying the achieved level is non-compliant. The pair is the obligation.

The declaration sits inside the instructions for use, governed by Article 13. Article 13(3)(b)(ii) names the cross-reference directly · the instructions shall contain, where appropriate, 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, and any known and foreseeable circumstances that may have an impact on that expected level.

Two operational consequences follow. First, the declaration anchors what an Annex III deployer is entitled to expect. Second, it is the document a national competent authority will read first under Article 21. If the IFU declaration says 0.91 F1 against test set X under conditions Y, the regulator will ask for the test set, the conditions, and the production performance against the same metric.

Resilience against errors, faults, inconsistencies.

Paragraph (4) does the substantive work behind the word robustness in paragraph (1). The standard is as resilient as possible. The qualifier as possible is not an excuse. It is a proportionality test against the state of the art and the intended purpose of the system. The provider that deploys an architecture known to fail under a class of perturbation, without engineering against that class, is not as resilient as possible.

The text scopes the perturbation surface deliberately wide. Errors, faults or inconsistencies covers the internal failure modes of the system itself. The environment in which the system operates covers infrastructure faults, upstream data-source disruption, and clock skew. Interaction with natural persons or other systems covers the cases that matter most in 2026 · the agentic loop, the tool-use chain, the human-in-the-loop override.

The mechanism is mixed. Technical and organisational measures is the same construction the GDPR uses · the obligation is not satisfied by code alone, and not satisfied by policy alone. The article then names two technical patterns explicitly · technical redundancy solutions and backup or fail-safe plans. Either pattern, where the architecture supports it, is a positive evidence of compliance. Neither is mandatory in every case. The choice is the provider's, the justification is recorded.

Continuously learning systems and feedback loops.

This sentence sits inside paragraph (4). It addresses the deployment pattern in which the system continues to learn after being placed on the market · online learning, continuous fine-tuning on production data, retrieval-augmented generation pipelines that update an index from production traffic.

The drafters did not ban the pattern. They named the failure mode they want addressed · possibly biased outputs influencing input for future operations. The technical literature calls this concept drift, model collapse on synthetic data, or, in the specific case where production outputs become training inputs, a feedback loop. The statute uses the latter term in parentheses, which fixes the meaning.

The standard is the same proportionality construction as elsewhere in the article. Eliminate or reduce as far as possible. Plus a process step · any such feedback loops are duly addressed with appropriate mitigation measures. The mitigation regime that satisfies in practice has four parts. Drift detection on a held-out reference distribution. Sampling of production outputs against ground-truth labels. Retraining gates that block updates if a fairness or accuracy metric regresses. A documented bias control regime that reads against Article 10(2)(f) and Article 10(2)(g) on appropriate measures to detect, prevent, and mitigate biases.

Resilience against unauthorised third parties.

Paragraph (5) is the cybersecurity paragraph. The first sentence sets the standard · resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. The second sets the proportionality test · appropriate to the relevant circumstances and the risks. The third names the AI-specific threat surface that must be considered where appropriate.

Five threat classes are named in the text · data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks, and model flaws. The list is non-exhaustive. The phrase shall include, where appropriate makes the listed threats presumptive while leaving room for additional threats the system's threat model surfaces.

This is the only place in the AI Act where the AI-specific cybersecurity threat surface is enumerated as statute. Every Article 15(5) compliance file should map against the named five.

What Article 15(5) actually covers.

The five named threat classes are not novel terms invented by the drafters. Each maps to a body of academic and standards work that pre-dates the regulation.

Two reference texts are operative for any Article 15(5) compliance file. The OWASP Top 10 for Large Language Model Applications enumerates the LLM-specific risks the cybersecurity solutions must consider. NIST AI 100-2, the Adversarial Machine Learning taxonomy, provides the formal vocabulary for evasion, poisoning, privacy, and abuse attacks. Neither is named in Article 15. Both are the texts a regulator is most likely to read alongside the file.

What gets declared in the IFU.

The Article 15(3) declaration is short on its face and demanding in practice. The declaration that satisfies a reviewing authority has four components.

First, the metric. The metric must be the metric appropriate to the task. A binary classification system declared with accuracy on a class-imbalanced production distribution will be challenged. Precision, recall, F1, area under the receiver operating characteristic curve, calibration error · the choice is the provider's, the justification reads against the intended purpose under Article 13(3)(b)(i).

Second, the level. A point estimate alone is insufficient where the test methodology supports an interval. A 95 percent confidence interval, a per-population stratification, or a per-confidence-band breakdown is the operative declaration in most cases.

Third, the test methodology. The test set, the holdout strategy, the data freshness, the population covered. The Annex IV technical documentation under Article 11 is where the methodology lives in detail. The IFU declaration cross-references it.

Fourth, the conditions under which the declared level holds, and the conditions under which it does not. Article 13(3)(b)(ii) names the requirement explicitly · any known and foreseeable circumstances that may have an impact on that expected level. An IFU declaration that does not name the conditions under which performance degrades is incomplete by the statute's own terms.

Fail-safe and redundancy patterns.

Paragraph (4) names technical redundancy solutions, backup, and fail-safe plans as positive examples. Four patterns satisfy in practice, individually or in combination.

The pattern that fails in practice is the absence of any of the four · the system that has no graceful degradation, no fail-over, no watchdog, no out-of-distribution check. That system is exposed under Article 15(4) on its first review, regardless of the production accuracy it achieves on the happy path.

Article 15 and the rest of Section 2.

Article 15 does not stand alone. It reads against the rest of Chapter III, Section 2.

The picture is a closed loop. Article 9 sets the test plan. Article 10 underwrites the data. Article 15 sets the level. Article 13 declares it. Article 17 documents the procedures. Article 12 logs the runtime. Article 72 monitors after placement. Article 73 reports the failures. The loop is not optional. Each step is a separate provider obligation under Article 16.

Where Warrant maps Article 15.

Questions a compliance officer asks first.

Read the source directly.

• Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
• Article 15 accuracy, robustness and cybersecurity · annotated text
• Article 13 transparency and provision of information to deployers
• Article 40 harmonised standards and standardisation deliverables
• ENISA work on artificial intelligence cybersecurity
• NIST AI 100-2 · Adversarial Machine Learning · Taxonomy and Terminology
• OWASP Top 10 for Large Language Model Applications
• Per-obligation Warrant evidence field mapping

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotation of Article 15 reflects the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024.