ISO/IEC 23894 AI Risk Management Guidance: From Risk Treatment to Runtime Policy and Audit-Ready Evidence

What ISO/IEC 23894 is and is not

ISO/IEC 23894:2023, titled "Information technology, Artificial intelligence, Guidance on risk management", is developed under ISO/IEC JTC 1/SC 42. ISO describes it as setting out processes for the effective implementation and integration of AI risk management. NIST's crosswalk characterizes it as tailored guidance for AI systems based on the general risk management guidance in ISO 31000, with a structure that mirrors ISO 31000 and adds AI context and recommendations where needed.

Two practical consequences follow. First, ISO 31000 vocabulary and process stages carry over, so a risk function that already runs an ISO 31000-style program can extend it rather than build a parallel one. Second, the document is guidance. It tells you how to structure risk management for AI. It does not specify technical controls, and nothing in it is a runtime mechanism. Any claim of conformance should be treated with care, and this page makes none on behalf of any product.

The standard sits alongside the NIST AI Risk Management Framework, which is voluntary and divided into two parts. NIST publishes a crosswalk between AI RMF 1.0 and ISO/IEC 23894:2023, and a revised version carries the identifier ai-2025-00109. For programs that report against both, that crosswalk is a better starting point than a home-built mapping. As of November 2026, NIST states that AI RMF 1.0 is being updated and that the Playbook will follow the revision, so any mapping you maintain should be reviewed when the revised framework appears. The 2023 edition is the one listed in the ISO/IEC JTC 1/SC 42 catalogue as of November 2026.

Process elements and what can operate at runtime

Because the structure follows ISO 31000, the process elements familiar to risk teams apply: establishing context, risk assessment, risk treatment, monitoring and review, communication and consultation, and recording and reporting. The table below is the author's interpretation of where runtime enforcement can contribute. It is not a statement of what the standard requires.

• Context: Organizational. Defining objectives, scope, and risk criteria happens before any policy exists.
• Risk assessment: Largely organizational. Runtime data on actual interactions can inform it, but judgment stays with people.
• Risk treatment: Partly runtime. Treatments that act on a single interaction or tool call can be enforced as policy.
• Monitoring and review: Shared. Enforcement produces continuous data, while review and reassessment remain organizational.
• Communication: Organizational. Reporting to stakeholders and decision makers is outside the execution path.
• Records: Shared. Evidence of enforcement can be generated automatically, but it must link to decisions made elsewhere.

The gap between documented treatment and runtime behavior

Most regulated enterprises can produce a risk register, treatment decisions, and approval records. The harder question from an auditor or regulator is whether the AI system was actually prevented from doing what the treatment decision said it should not do. A document that states that customer identifiers must not leave the environment does not stop a prompt, an agent step, or a tool call from carrying one.

This gap widens as AI systems take actions. A model that only answers questions presents one kind of exposure. An agent that calls tools, reads internal systems, or writes code presents another, because each call is a point where a treatment decision either holds or does not. Review after the fact can detect a failure, but it cannot undo the action.

Runtime enforcement closes part of this gap, and only part. It acts on individual interactions and tool calls. It does not decide risk appetite, set context, accept residual risk, or run stakeholder communication. A sound program states this boundary explicitly so that nobody assumes enforcement substitutes for governance, and nobody assumes governance documents substitute for enforcement.

Translating treatment decisions into runtime policy

The steps below describe an approach, offered as the author's interpretation. The aim is traceability: every runtime policy should point back to an assessment and a treatment decision, and every decision that cannot be enforced at runtime should say who owns it instead.

• Classify each treatment decision: Mark whether it can be applied to a single interaction or tool call, or whether it is organizational, such as risk acceptance or review cadence.
• Select the enforcement action: Choose among allow, redact, block, rate limit, or escalate for human approval, based on the severity and reversibility of the risk.
• Define scope precisely: Specify which models, agents, tools, and users the policy covers, so that coverage gaps are visible rather than assumed.
• Link policy to decision: Give each policy a reference to the assessment and treatment decision it implements, so an auditor can trace it in both directions.
• Test before relying on it: Confirm that the policy produces the intended action and the intended record on representative interactions.
• Review on a schedule: Revisit policies when assessments change, when models or tools change, or when a mapped framework such as NIST AI RMF is revised.

Designing audit-ready evidence

What an auditor accepts depends on the audit and the regulator, so evidence should be designed against the questions likely to be asked rather than against a single checklist. The reasonable questions are consistent: what policy applied, which decision it implements, what action was taken on a given interaction, who approved any escalation, and whether the policy was operating throughout the period in question.

Evidence is most useful when it is a by-product of enforcement rather than a separate reporting exercise. A record written at the moment a policy allows, redacts, or blocks an interaction describes what actually happened. A summary assembled afterward describes what someone believes happened. The first is stronger because it is produced by the same mechanism that applied the control.

Evidence also needs to be durable and governed. Retention periods and data residency should be configurable to match your obligations, and the evidence itself may contain sensitive material that deserves the same handling as the interactions it describes. Finally, evidence of enforcement does not replace records of the organizational process, such as assessment outcomes, risk acceptance, and review minutes. The two sets of records should reference each other.

Where Trussed fits

Trussed is one way to enforce policy in the execution path. It applies policy across models, agents, tools, MCP servers, AI sites, and coding assistants, with the actions allow, redact, block, rate limit, and escalate for human approval. Its scope is individual interactions and tool calls. Enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

In operating terms, Trussed has run continuously in production at a regulated enterprise for more than 18 months, and customers span insurance, pharma, healthcare, and education.

The boundaries matter. Trussed does not claim ISO/IEC 23894 certification or conformance, and it does not perform organization-level risk governance. Context setting, risk acceptance, and stakeholder communication remain with the organization. What it supports is the narrower task this page describes: making treatment decisions that apply to individual interactions and tool calls enforceable at runtime, and producing the evidence that they operated.