The crosswalk: Arts 9–15 meet ISO 42001 and NIST — and the evidence pack
Lesson 6 of 6 in Inside the High-Risk Rulebook: Arts 8–15 Article by Article.
Here is the practitioner’s secret: if your organisation already runs an ISO/IEC 42001 AI management system or works the NIST AI RMF, you have met Arts 9–15 before under different names. The EU wrote legal requirements; ISO wrote management-system controls; NIST wrote voluntary functions — but all three descend from the same risk-management logic, and mature programmes maintain exactly this mapping so one body of work serves three masters.
The mapping is a working aid, not a legal equivalence — certification against ISO 42001 does not create a presumption of conformity with the AI Act (only harmonised standards cited in the OJEU will do that, and none had been as of this writing). Use it to find reusable evidence, not to skip the statute.
| AI Act requirement | ISO/IEC 42001 anchor | NIST AI RMF anchor |
|---|---|---|
Art 9 — risk management system | Clause 6.1 (risk & opportunity assessment), Clause 8.2–8.3 (AI risk assessment & treatment in operation), Annex A.5 (AI system impact assessment) | MAP (context & risk identification) → MEASURE (risk analysis) → MANAGE (prioritise, respond, monitor) — the whole core loop |
Art 10 — data & data governance | Annex A.7 (data for AI systems: acquisition, quality, provenance, preparation) | MAP (data provenance & suitability); MEASURE — incl. fairness/bias evaluation (e.g. MEASURE 2.11) |
Art 11 — technical documentation | Clause 7.5 (documented information), Annex A.6 (AI system life-cycle documentation) | GOVERN (policies, accountability records); MAP documentation outputs — the RMF Playbook’s “document the system” actions |
Art 12 — record-keeping / logging | Annex A.6 life-cycle controls (event logging & traceability through operation and monitoring) | MEASURE (tracking metrics in production); MANAGE 4 (post-deployment monitoring & incident capture) |
Art 13 — transparency to deployers | Annex A.8 (information for interested parties: documentation, instructions, reporting) | GOVERN & MAP transparency outcomes — the “transparent & accountable” trustworthiness characteristic |
Art 14 — human oversight | Annex A.9 (responsible use of AI systems), Annex A.3 (roles, responsibilities & competence) | GOVERN 3 (workforce & human-AI configurations); MANAGE (intervention & override procedures) |
Art 15 — accuracy, robustness, cybersecurity | Annex A.6 (verification & validation across the life cycle) + the ISO/IEC 27001 interface for security controls | MEASURE 2 (“valid & reliable”, “secure & resilient” characteristics); adversarial testing under MEASURE/MANAGE |
The final skill: knowing which artifact proves which article. When a market surveillance authority — or a notified body, or your own internal auditor — asks ‘show me Art 10 compliance’, the answer is a document with a date and an owner, not a paragraph of assurance. Sort the evidence pack:
Interactive sorting exercise: An auditor requests evidence article by article. Match each artifact to the requirement it primarily proves.
One closing question the whole module has been building to: whose job is all of this? Art 16(a) answers in five words — providers of high-risk AI systems shall ensure their systems comply with Section 2. The deployer duties, importer checks and the strange alchemy by which a distributor becomes a provider are the next module’s territory. But the rulebook you now know article by article is, first and always, the provider’s to satisfy — and the evidence pack you just sorted is what satisfying it looks like on paper.
Tool: AIMS Builder & Audit — Put the crosswalk to work: assemble a management system whose controls generate the Art 9–15 evidence pack as a by-product.