Summary: The seven design and process requirements every high-risk AI system must meet. Article 15 is the security one and has its own page.
Sources: raw/AI-regulations/Regulation - EU - 2024_1689.md (Chapter III Section 2, Articles 8–15)
Last updated: 2026-07-28
Art 8 — Compliance baseline
Requirements apply “taking into account their intended purpose as well as the generally acknowledged state of the art on AI and AI-related technologies,” with the Art 9 risk management system “taken into account when ensuring compliance” (source: Regulation - EU - 2024_1689.md).
“State of the art” is the moving part. It means the compliance bar rises as the field advances — including as attack techniques advance. A system compliant at launch is not necessarily compliant two years later, which is consistent with Art 15(1)‘s lifecycle framing.
Art 8(2) allows integration with existing product-safety documentation to “avoid duplication and minimise additional burdens” for products already under Annex I Section A legislation.
The seven requirements
| Art | Requirement | Note |
|---|---|---|
| 9 | Risk management system | Continuous, iterative, across the lifecycle |
| 10 | Data and data governance | Training/validation/test sets must meet quality criteria |
| 11 | Technical documentation | Annex IV contents, drawn up before placing on market |
| 12 | Record-keeping | Automatic event logging over the system’s lifetime |
| 13 | Transparency to deployers | Output must be interpretable and usable |
| 14 | Human oversight | Effective oversight by natural persons during use |
| 15 | Accuracy, robustness, cybersecurity | article-15-cybersecurity |
Art 10 — Data governance
Applies to “high-risk AI systems which make use of techniques involving the training of AI models with data,” which must be “developed on the basis of training, validation and testing data sets that meet the quality criteria referred to in paragraphs 2 to 5” (source: Regulation - EU - 2024_1689.md).
Security-relevant because data provenance and integrity are the precondition for defending against the data poisoning that Art 15(5) requires measures against. A provider who cannot say where its training data came from cannot demonstrate it was not poisoned.
Art 12 — Record-keeping is the forensic requirement
“High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system” (source: Regulation - EU - 2024_1689.md).
This is the article that makes AI incident investigation possible at all. Microsoft’s IR pattern identifies telemetry gaps as one of four properties that break traditional IR for AI — “Standard security monitoring doesn’t capture anomalous output patterns, classifier confidence shifts, or unexpected post-update behavior. Privacy-by-design defaults further narrow the forensic record” (source: raw/AI-incident-response/Incident response for AI systems.md).
The same source flags the tension explicitly as a trade-off: “Forensic-grade telemetry may conflict with privacy-by-design defaults; deliberate compromise in both directions is required.” Art 12 sets a floor; it does not resolve that tension. See Microsoft IR readiness.
Art 11 — Technical documentation, with an SME carve-out
Must be drawn up before market placement and kept up to date, containing at minimum the Annex IV elements. “SMEs, including start-ups, may provide the elements… in a simplified manner,” using a simplified form the Commission must establish, and “Notified bodies shall accept the form” (source: Regulation - EU - 2024_1689.md, Art 11(1)). See ai-act-and-smes.
Art 13 and 14 — Transparency and oversight are coupled
Art 13(1) requires operation “sufficiently transparent to enable deployers to interpret a system’s output and use it appropriately.” Art 14(1) requires design “including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.”
These are the same requirement from two sides: oversight without interpretability is a rubber stamp. The staffing analysis puts it bluntly — “Human oversight is not optional” (source: raw/Laws/What the EU AI Act Means for Staffing Businesses...md).
Compare NIST’s Explainable and Interpretable characteristic and OECD Principle 1.3 on transparency and explainability — see Trustworthy AI characteristics.
Art 15 — Feedback loops
Worth surfacing here because it is easy to miss inside Art 15: systems that “continue to learn after being placed on the market” must be developed to eliminate or reduce “the risk of possibly biased outputs influencing input for future operations (feedback loops)” (source: Regulation - EU - 2024_1689.md, Art 15(4)).
This is a security requirement as much as a fairness one — a feedback loop is a persistence mechanism for a poisoning attack.
Related pages
- article-15-cybersecurity
- high-risk-ai-systems — who this applies to
- serious-incident-reporting — the post-market half
- NIST AI RMF — the voluntary framework covering the same ground