Is ISO/IEC 23894 Mandatory? How Regulators Treat Voluntary AI Standards

The formal status of the two standards

ISO/IEC 23894:2023 is titled "Information technology, Artificial intelligence, Guidance on risk management." It is published as Edition 1 (2023) and describes processes for implementing and integrating AI risk management. Its title and purpose make it guidance for an organisation's own risk processes. It is not a statute, and nothing in the material reviewed identifies it as a legal requirement in any jurisdiction.

ISO/IEC 42005 covers AI system impact assessment. It sits in the same family of guidance and should be classified the same way: as a reference for how to structure an assessment, not as a rule that a regulator enforces on its own authority.

The AI Act makes the distinction explicit. Recital 46 says high-risk AI systems should only be placed on the Union market, put into service or used if they comply with certain mandatory requirements. Those requirements are in the Regulation. A compliance team therefore has two separate questions. Which regime applies to us? And which standards have we chosen to follow?

A related point: ISO/IEC 42001 is a separate standard. ISO describes it as a management framework that helps organisations meet compliance obligations more effectively. That is not the same as legal compliance, and it is not interchangeable with 23894 or 42005.

Where harmonised standards fit, and why dates moved

The AI Act does give standards a defined role, but through harmonised standards specifically. The European Commission states that harmonised standards will offer legal certainty under the Act. The Act text also provides that when a reference to a harmonised standard is published in the Official Journal, the Commission repeals the implementing acts, or the parts of them, that cover the same requirements. That publication step is the mechanism to watch. A voluntary ISO/IEC standard does not acquire this status merely by being well regarded.

Standards availability has also affected the timeline. The Commission says delayed standards jeopardised the original 2 August 2026 application date for the high-risk rules. The Digital Omnibus on AI, which the Commission reports entered into force on 27 July 2026, moves the dates to 2 December 2027 for high-risk AI systems and 2 August 2028 for AI embedded in products. Roadmaps should use these dates. They should also be kept under review, since the Act can be amended by delegated and implementing acts and will be evaluated periodically.

The Act also encourages providers of non-high-risk AI systems to create codes of conduct that foster voluntary application of some or all of the high-risk requirements, adapted to intended purpose and lower risk. Voluntary practice is therefore recognised in the framework, but as an option, not an obligation.

How a voluntary standard can still carry weight

Formal status and practical influence are different things. A standard that no law mandates can still matter through several routes, and each needs to be confirmed for your own situation rather than assumed.

The first is incorporation by reference, where a law or regulation names a standard or treats conformity with it as a route to meeting a requirement. Harmonised standards under the AI Act are the clearest example of this idea. The second is supervisory expectation, where a sector regulator or auditor uses a recognised standard as a benchmark when judging whether a process is reasonable. The third is contract or procurement, where a customer or counterparty requires alignment with a named standard as a condition of doing business.

In each case the weight comes from the specific instrument that references the standard, not from the standard itself. That is why the governance record should note, for each standard, whether it is voluntary guidance or a legal requirement, and document any contractual or regulatory reference separately. A standard is not a certification or a legal safe harbor unless a specific regime says so.

What a standard recommends versus what must be shown

A standard describes a process: identify risks, assess impact, treat what you find, monitor and review. Following that process produces policies, risk registers and assessment records. These are useful, and they show intent and structure. They do not show what an AI system was actually permitted to do on a given day.

That is the gap regulators and auditors tend to probe. A documented risk assessment says a control should exist. Evidence that the control operated shows that it did: which request was evaluated, which policy applied, what was allowed or stopped, and who approved an exception. Adoption of a standard supports the first kind of claim. Only operational records support the second.

For compliance leaders, the practical implication is to test each documented control with one question: what record would exist if someone asked us to prove this ran last month? Where the honest answer is "none, only the policy," the control is documented but not demonstrable.

Where runtime enforcement produces evidence

Risk and impact assessments decide what AI should be allowed to do. Evidence of operation comes from the point where those decisions are applied. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit or escalate an individual interaction or tool call for human approval. Because policy is enforced at runtime, not reviewed after the fact, each decision generates audit-ready evidence of what AI was allowed to do and what it did. That evidence is mapped to frameworks including the EU AI Act and NIST.

This complements a standards-based program and does not replace it. The standard shapes the assessment process, and enforcement evidence shows that the resulting controls ran. Trussed does not make an organisation compliant with any standard, and no standard makes enforcement unnecessary.