Articles 9–15: Reading the High-Risk Obligations as an Engineering Backlog

Legal teams read Articles 9 to 15 as obligations. Engineering teams should read them as acceptance criteria — because that is the only form in which they can actually be satisfied.

The seven, restated

• Art. 9 — Risk management. A continuous system across the lifecycle, not a one-time assessment filed before launch.
• Art. 10 — Data governance. Training, validation and test sets must be relevant, representative and examined for bias.
• Art. 11 — Technical documentation. Annex IV content, complete before the system is placed on the market.
• Art. 12 — Record-keeping. Automatic logging sufficient to reconstruct what the system did and why.
• Art. 13 — Transparency. Instructions for use that let a deployer operate the system correctly.
• Art. 14 — Human oversight. Designed-in ability to intervene, override and stop.
• Art. 15 — Accuracy, robustness, cybersecurity. Declared performance metrics, resilience to error and adversarial input.

Where the cost actually lands

In our engagements, Articles 10 and 12 consume the majority of remediation effort — data lineage and logging are rarely retrofitted cheaply. Article 14 is the one most often mistaken for solved: a human in the loop who cannot realistically overrule the system within the operational tempo is not oversight, it is decoration.

Sequencing that works

Classify first — a meaningful share of systems assumed to be high-risk are not, and the inverse is also true. Then close data governance and logging, because they gate everything downstream. Documentation is written last, from evidence that already exists, rather than written first and reverse-engineered into reality.

If you already hold ISO/IEC 42001, roughly two-thirds of this is assembly rather than construction. If you do not, the standard is still the cheapest scaffolding available.