ISO/IEC 23894 vs EU AI Act Article 9: Does ISO Risk Management Meet the Requirement?

Legal requirement versus voluntary guidance

Article 9 of Regulation (EU) 2024/1689 requires a risk management system for high-risk AI systems. It is a legal obligation, and the system is to be taken into account when ensuring compliance with the Act's other mandatory requirements. The Act also expects providers' measures to reflect the generally acknowledged state of the art and to be proportionate and effective in meeting the Regulation's objectives.

ISO/IEC 23894 sits in a different category. It is guidance on AI risk management. It is not a certifiable specification, so there is no certificate to hold, and it is not a harmonised standard. The Commission describes harmonised standards as the instrument that offers legal certainty under the AI Act. A standard outside that category should not be assumed to give a presumption of conformity. The Commission's standardisation page describes one harmonised standard in terms of Article 17 requirements, not Article 9, so the route for risk management standards is something to monitor rather than assume.

The practical consequence is that ISO/IEC 23894 can structure your process, but the evidence you hold is judged against Article 9, not against the guidance.

Where the guidance helps and where gaps remain

The table treats the question as a gap analysis. Alignment is strongest where Article 9 asks for a defined risk process. It weakens where Article 9 asks for specific, testable, demonstrable outcomes. Validate each row against the full text of both documents before relying on it.

• Risk identification and analysis: Process guidance on identifying and analysing AI risks is a natural fit. Add system-specific risk records tied to the documented intended purpose.
• Intended use and foreseeable misuse: General risk-context guidance may only partly cover misuse. Add explicit misuse scenarios per system, with an owner and a disposition for each.
• Targeted risk management measures: Treatment guidance supports choosing measures. Add a rationale showing each measure is proportionate, effective and reflects the state of the art.
• Residual risk: A process standard does not decide what is acceptable under the Act. Add documented acceptance criteria, approvals and review triggers.
• Testing: Article 9 requires testing against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. Add a record that metrics and thresholds were set before each test cycle.
• Documentation: The Act requires a detailed description of the Article 9 risk management system. Maintain it as a current deliverable with a named owner.

Testing is where policy-level programs most often fall short

Article 9 testing must be carried out against metrics and probabilistic thresholds that are defined beforehand and appropriate to the intended purpose. A passing result is not sufficient evidence by itself. A reviewer will want to see that the criteria existed before the test, that they matched the system's purpose, and that the results were retained.

Article 9 also states that testing procedures may include testing in real-world conditions in accordance with Article 60. Test evidence can therefore come from more than pre-deployment lab work. If you use real-world testing, the plan must align with Article 60 conditions, and your architecture needs to capture and retain production test data and results.

This is a design-time and run-time boundary issue. Pre-deployment testing and risk assessment are design-time activities. Showing that a measure continues to work as intended in production requires evidence generated during operation.

From defined controls to demonstrable controls

A risk register and a set of policies describe intent. Article 9 measures must also be implemented and demonstrable during operation. The difference matters when a regulator or notified body asks what a control did on a specific occasion. We recommend treating the following as evidence expectations, not verified regulatory requirements.

One way to operationalise runtime risk treatment is to enforce policy in the execution path for each interaction and tool call: allow, redact, block, or escalate for human approval, with each decision recorded. That produces per-interaction evidence that a measure was applied, rather than a statement that it should have been. It addresses runtime treatment of individual interactions and tool calls. It does not replace risk analysis, test design, residual risk acceptance, or documentation, and it does not by itself cover model provenance, lineage, or end-to-end tracing of agentic workflows.

Deciding whether to use ISO/IEC 23894 as the basis

For most risk teams the answer is yes as a starting structure and no as a finished program. Using the guidance gives you a common vocabulary and a defensible process shape. Article 9 should be the audit criterion, with each paragraph traced to an owned artefact, and with additions for testing, residual risk acceptance and operational evidence.

Timing also needs care. The Commission's Digital Omnibus proposal of 19 November 2025 would set 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products. As of November 2026 this is a proposed amendment. Plan against the dates currently in force and track the proposal and the Commission's standardisation outputs, since both could change the compliance route and timing. Where a product falls under several Union harmonisation acts, coordinate the AI risk management system with the other conformity requirements.

For teams that need runtime enforcement and evidence, Trussed enforces policy in the execution path across models, agents and tools, and generates audit-ready evidence mapped to the EU AI Act among other frameworks. It addresses the operational layer described above, not the full Article 9 program.