What Article 15 actually asks for
Article 15(1) requires an appropriate level of accuracy, robustness and cybersecurity, performed consistently throughout the lifecycle — so one pre-release evaluation does not satisfy it. Article 15(3) turns the internal number into a public commitment: the levels of accuracy and the relevant accuracy metrics must be declared in the instructions for use.
Monday's LinkedIn post mapped the six obligations to owners. Here are the three places teams actually fail.
Every artefact below carries the same header, stated once: system and version, date executed, who executed it, method, findings, mitigation decision, residual risk with a named accepting owner, next review date. Undated evidence is not evidence.
Part 1 — Measurement: choosing a metric you can defend
The metric-declaration trap. Article 15(3) requires the metric, not just the score. Once "F1 = 0.91 on the intended-purpose evaluation set" sits in the instructions for use, deployers configure around it, market surveillance can test against it, and drift becomes a documented deviation from your own declared performance. "High accuracy" is not a softer commitment — it is an unbounded one. Declare only a metric you can re-measure on a schedule.
"Appropriate" has no number in the Act. It is set through the Article 9 risk management system, which requires testing against prior defined metrics and probabilistic thresholds appropriate to the intended purpose (Article 9(8)). The chain: intended purpose → foreseeable harm → the error type causing it → the metric measuring it → the threshold. A memo that skips a link gives an auditor nothing to assess.
Base rates. Where the event is rare, aggregate accuracy is meaningless. Declare per-class performance — sensitivity and specificity, or precision and recall, and the base rate measured at — plus the operating point, since the threshold converting score to decision sets the real error profile. If the deployer can move that threshold, say what it does to accuracy; that is what makes Article 26 deployer obligations operable.
Distribution shift. Two further entries: a re-measurement cadence tied to the post-market monitoring plan (Article 72), and a deviation threshold triggering action when live performance moves off the declared level. Without the second, monitoring produces charts nobody must act on.
Artefact — Accuracy Declaration Record, one per system:
Field | Content |
|---|---|
Intended purpose | As stated in the technical documentation |
Harm-to-error mapping | Which error (FP / FN / ranking / calibration) causes which foreseeable harm |
Selected metrics + why | Metric per error type, with rejection reasons for the alternatives |
Evaluation dataset | Provenance, size, class base rates, representativeness vs the intended population |
Declared level + operating point | The number entering the instructions for use, and the threshold it holds at |
Known limiting circumstances | Conditions under which the declared level does not hold — Article 13(3)(b)(ii) requires these stated |
Re-measurement cadence + deviation threshold | Next measurement date; the number that triggers escalation |
Owner, approver, date | Named person, named approver, ISO date |
Part 2 — Robustness testing: what a defensible Article 15(4) plan looks like
Article 15(4) requires systems to be as resilient as possible regarding errors, faults or inconsistencies arising in the system or its environment, particularly through interaction with natural persons or other systems, offering technical redundancy solutions, which may include backup or fail-safe plans. Not a question about model quality — a question about system behaviour when things go wrong around the model.
So validation-set performance is not robustness evidence. "We tested robustness in dev" usually means "we measured accuracy on a held-out split" — a split sharing training's collection process, preprocessing and assumptions. It cannot show resilience to a malformed feed or a confused user. Instead, enumerate the real operating environment and define an injected failure and expected response for each:
Class | Example injection | Expected, testable behaviour |
|---|---|---|
Input errors | Missing fields, out-of-range values, wrong encoding, truncation | Explicit rejection — never silently imputed into a confident output |
Upstream faults | Feature service timeout, stale store, partial batch | Documented degraded mode or refusal; no silent fallback to defaults |
Inconsistencies | Contradictory records, duplicate IDs, schema drift | Detected and surfaced, with a named owner for the alert |
Human interaction | Misuse, out-of-scope inputs, overrides, automation bias | Bounded behaviour; overrides logged (Article 12) |
System-to-system | API contract change, retry storms, out-of-order delivery | Idempotent; no duplicated decisions |
Load and latency | Peak volume, cold start, partial outage | Declared performance holds, or degrades to a declared fallback |
Redundancy and fail-safe are design decisions, not aspirations. The artefact is a fallback specification: per class above, what the system does instead (human review, prior model version, rule-based fallback, refusal), who is notified, and what accuracy is expected in fallback mode. A fallback never exercised in a test is not a fail-safe — it is an assumption.
The feedback-loop problem. Article 15(4) also requires systems that continue to learn after being placed on the market to eliminate or reduce as far as possible the risk of biased outputs influencing input for future operations (feedback loops) — the article's most under-documented obligation. If the system's own decisions shape the data it later trains on (a screening tool that only sees outcomes for candidates it advanced), the loop exists by construction. Two questions, in writing: is the training data conditioned on past model output, and if so what corrects it — held-out random exploration, counterfactual labelling, exogenous ground truth, or a documented decision to freeze learning? And what signal would show the loop closing? Drift on the input distribution, not only output accuracy; loops show up upstream first.
Artefact — Robustness Test Plan plus dated Test Report, to the standard above, adding results per class and defects raised. A report that does not name the system version it ran against is not evidence.
Part 3 — Cybersecurity evidence: Article 15(5) is specific, so your evidence must be too
Article 15(5) requires resilience against unauthorised third parties altering the use, outputs or performance of the system by exploiting vulnerabilities, and names five AI-specific attack classes to address where appropriate: data poisoning (training set), model poisoning (pre-trained components used in training), adversarial examples / evasion (inputs designed to cause a mistake), confidentiality attacks, and model flaws.
This is why "cybersecurity is IT's job" fails. Access management, segmentation, patching and SIEM address none of the first four directly — necessary, insufficient. What each demands:
Attack class | Minimum evidence an auditor can read |
|---|---|
Data poisoning | Provenance record per training source; integrity hashes at ingestion; documented review of third-party or user-contributed data; dated anomaly screen of the training set |
Model poisoning | Inventory of pre-trained components, base models and weights with source, version and checksum; supply-chain acceptance criteria; record of what was verified before use |
Adversarial examples / evasion | Dated adversarial test campaign: methods attempted, threat assumptions (what the attacker can see and change), success rates, mitigations, residual risk accepted by a named person |
Confidentiality attacks | Assessment of membership-inference and model/data extraction exposure, especially where training used personal data; rate limiting and output-granularity controls, with reasoning recorded |
Model flaws | Intake path for AI-specific defects; triage SLA; linkage to serious-incident reporting under Article 73 |
Artefact — the AI threat model, which almost no team has. It states, for this system: what an attacker wants, which surfaces they can reach (training pipeline, model registry, inference API, feedback channel, deployer configuration), what capability is assumed, and which of the five classes are in scope — with written reasons for anything excluded. "Where appropriate" is not a licence to skip; it is an invitation to justify.
Ownership: artefacts, owners, cadence
Monday's post assigned owners to the six obligations. Same discipline, one level down:
Artefact | Owner | Approver | Cadence |
|---|---|---|---|
Accuracy Declaration Record | ML lead | Product owner + Compliance lead | Per release + scheduled re-measurement |
Metric-selection memo (harm → error → metric) | ML lead + Risk owner | Compliance lead | On change of intended purpose |
Instructions-for-use accuracy section | Product / technical writer | Compliance lead | Per release |
Robustness Test Plan | Engineering lead | Product owner | Annual; on architecture change |
Robustness Test Report | QA lead | Engineering lead | Per release |
Fallback specification | Engineering lead + Operations | Product owner | On architecture change |
Feedback-loop assessment | ML lead | Risk owner | Quarterly, if the system keeps learning |
AI threat model | Security lead + ML lead | CISO or equivalent | Annual; on new attack surface |
Adversarial test campaign report | Security lead | CISO or equivalent | Annual; before major model change |
Data/model provenance register | Data engineering | ML lead | Continuous; audited quarterly |
Apply Monday's pass test to each row — CAPACITY ∧ AUTHORITY ∧ EVIDENCE. An artefact with no approver is a governance gap; an approver with no last date is an evidence gap. Both fail.
Three questions to run against one system this week
Answer in writing for your highest-risk system. If an answer takes more than a sentence to locate, that is the gap.
What exact accuracy metric and level would we put in the instructions for use today, on what dataset, and at what base rate?
When did we last inject a fault into this system on purpose, and what did it do?
Which of the five Article 15(5) attack classes have we tested against, on what date, and who accepted the residual risk?
What remains uncertain
There is no numeric accuracy threshold in the Act. Anyone citing a specific percentage as satisfying Article 15 is inventing it. "Appropriate" is argued and documented, not looked up.
Article 15(2) tasks the Commission — cooperating with relevant stakeholders and organisations such as metrology and benchmarking authorities — with encouraging the development of benchmarks and measurement methodologies for the technical aspects of accuracy and robustness. Until those exist, metric selection is your reasoning to defend, not a standard to cite.
Harmonised standards are still in development. Citing any specific standard as "the" Article 15 route is premature, and presumption of conformity (Article 40) only follows once a standard is cited in the Official Journal. As of July 2026 no such harmonised standard has been cited there for Article 15 — the slow finalisation of these standards is itself one of the reasons the high-risk timeline moved — so no specific standard designation is named here.
The applicability date for high-risk obligations changed after Issue #2. The Digital Omnibus, adopted by the Parliament and Council in June 2026, deferred the high-risk obligations: stand-alone Annex III systems now apply from 2 December 2027 and Annex I embedded systems from 2 August 2028, replacing the original 2 August 2026 date. Article 15's substantive requirements are unchanged — only the date by which they bind has moved. Build the evidence now; the extra time is for doing it properly, not for deferring it.
The direction of travel is not uncertain. Accuracy, robustness and cybersecurity are the three Article 15 words most likely to be tested by evidence rather than argument, because all three are measurable — and measurable obligations are where "we take it seriously" fails fastest.
Sources
Regulation (EU) 2024/1689 (EU AI Act), Article 15 — accuracy, robustness and cybersecurity. EUR-Lex consolidated text: https://eur-lex.europa.eu/eli/reg/2024/1689/oj (verified 2026-07-21).
Regulation (EU) 2024/1689, Articles 9(8), 12, 13(3)(b)(ii), 26, 40, 72 and 73 as cross-referenced above — all article and paragraph numbers confirmed against the EUR-Lex consolidated text on 2026-07-21.
Digital Omnibus on AI (adopted by the European Parliament 16 June 2026 and Council 29 June 2026) — deferral of the high-risk applicability dates (Annex III to 2 December 2027; Annex I to 2 August 2028).