ISO/IEC 23894 AI Risk Management Guidance and How Regulated Enterprises Apply It

What ISO/IEC 23894 covers, and what it does not

ISO/IEC 23894:2023 is titled "Information technology — Artificial intelligence — Guidance on risk management". ISO describes it as setting out processes for the effective implementation and integration of AI risk management. It sits alongside ISO/IEC 22989, which covers AI terminology and concepts, and ISO/IEC 23053, a framework for describing AI systems that use machine learning.

The operative word is guidance. The document helps an organization structure how it identifies, assesses, treats, monitors and communicates AI risk. It does not specify requirements for a management system, and it is not a regulation. For that reason, describe your program as aligned with the guidance, not as compliant with it. An auditor will test the controls and records you actually operate, not the standard's title.

The guidance also does not run your controls. It leaves open which treatments you choose, where they are enforced and what proof they leave behind. Those decisions fall to the enterprise, and they are where most programs stall. A risk register that records "restrict sensitive data in prompts" is a treatment decision. It becomes a control only when something enforces it on each interaction.

Teams should also connect the guidance to the enterprise risk process they already operate, so AI risk is rated, owned and escalated in the same way as other risk categories.

How ISO/IEC 23894 relates to adjacent standards and law

The common mistake is treating these documents as interchangeable. They play different roles, and a defensible program uses each for what it is. The EU AI Act timeline has also moved, so dates deserve care.

As of November 2026, the Digital Omnibus on AI is reported in force from 27 July 2026. It moves the high-risk rules from 2 August 2026 to 2 December 2027 for stand-alone high-risk AI systems and to 2 August 2028 for high-risk AI systems embedded in products. The AI Act can also be amended by delegated and implementing acts, so re-check dates before relying on them.

• ISO/IEC 23894:2023: Guidance on AI risk management processes. Use it to structure how risk is identified, treated, monitored and communicated.
• ISO/IEC 42001:2023: Specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. ISO describes it as an integrated approach from risk assessment to treatment of risks.
• NIST AI RMF: A risk management framework that many teams use alongside ISO guidance. Keep an explicit mapping from your controls and evidence to it.
• EU AI Act (Regulation (EU) 2024/1689): Binding law, dated 13 June 2024. Obligations and dates apply as written, regardless of which guidance you follow.

Runtime risk treatments and the evidence each should produce

The gap is widest at runtime. A treatment approved on paper has no effect until it is applied to an individual model call or tool call. Five treatments can be enforced in the execution path: allow, redact, block, rate limit and escalate for human approval. Enforcement happens before the action completes, not in a review afterward.

For each treatment, define the record it should produce before you deploy it. A useful record answers what the AI was allowed to do and what it did. At minimum it should carry a timestamp, the calling identity, the target model or tool, the policy version applied and the outcome. Retention and data residency for these records should be set by policy, not left to defaults.

• Allow: Record the request, the policy version that permitted it and the outcome. Allowed actions need evidence too, since they show what the AI was permitted to do.
• Redact: Record which data categories were detected, what was removed, and the rule applied. Avoid storing the sensitive value itself unless policy requires it.
• Block: Record the attempted action, the rule that triggered, and the response returned to the caller.
• Rate limit: Record the threshold, the subject limited, the time window and the requests affected.
• Escalate for human approval: Record the approval request, the approver identity, the decision, the time taken and what executed afterward.

Where Trussed fits

Trussed is control, provenance and evidence infrastructure for consequential AI, built for regulated enterprises that must show a regulator or auditor what their AI was allowed to do and what it did. It does not claim certification or compliance with ISO/IEC 23894. It supports the runtime part of the risk treatment step.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Treatments available are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. That enforcement generates continuous, audit-ready evidence mapped to NIST and the EU AI Act, among other frameworks. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

In production, Trussed has run continuously for 18+ months in a regulated enterprise at 99.95% uptime on live traffic, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day. It serves customers in four regulated verticals: insurance, pharma, healthcare and education.

Trussed does not replace the organizational half of the process. Scope, risk ownership, assessment and review cadence stay with your risk function.