Applying ISO/IEC 23894 risk treatment with runtime controls

Where runtime controls fit in risk treatment

ISO/IEC 23894:2023 is guidance for organizations that develop, produce, deploy or use AI products, systems and services. It aims to help them integrate risk management into AI-related activities and functions. Most regulated enterprises already record their treatment decisions in a risk register: avoid the risk, modify it, share it, or retain it. The recurring gap is that those decisions describe intent, while the AI system keeps operating on live prompts, data and tool calls that no register entry touches.

A runtime control closes that gap for one class of risk. It sits in the execution path and applies a rule to each interaction or tool call as it happens. That makes the treatment verifiable, because a decision either was or was not enforced. It is one class of treatment among several. Organizational policy, design choices and pre-deployment testing remain necessary, and this guide treats runtime enforcement as an addition to them, not a substitute.

The EU AI Act raises the stakes for regulated enterprises. The Commission lists adequate risk assessment and mitigation systems among the obligations for high-risk AI systems before they are placed on the market. As of November 2026, the Commission describes high-risk obligations as applying from 2 December 2027, a change from the original date of 2 August 2026. Plan mappings against the current timeline and revisit them as standards are published.

Which risks are treatable per interaction or tool call

The scoping question is whether the risk can be judged from the content and context of a single interaction or tool call. Examples that often can: sensitive data appearing in a prompt or output, an agent invoking a tool it should not use, an action outside the caller's authorization, or a burst of calls beyond an expected rate. Each of these has an observable moment where a rule can allow, redact, block, rate limit or escalate.

Other risks do not have that moment. Bias in a model's outputs across a population, weaknesses in training data, an inappropriate use case, and poor accountability structures are properties of design, data or organization. A runtime rule may reduce exposure at the edges, but it should not be recorded as the treatment. Testing before deployment and governance decisions carry those risks.

A practical test is to write the control as a sentence a machine can evaluate: when this identity calls this tool with this kind of data, do this. If you cannot write that sentence without referring to something outside the interaction, the treatment belongs elsewhere or needs a different control alongside it.

For tool calls, start with classification. OWASP agent guidance sets unknown tools to fail closed and lets only explicitly low-risk tools skip review. Adopting the same default means a newly added tool cannot act until someone has classified it.

Evidence for treatment effectiveness and residual risk

A treatment is only as credible as the record that it operated. For a given interaction, a reviewer needs to see which policy applied, what the AI was permitted to do, what action the control took, and what the AI then did. Where a human approved or rejected an action, that outcome belongs in the same record. A policy document alone cannot show any of this.

This evidence also supports residual risk review. NIST AI RMF defines residual risk as risk remaining after risk treatment, citing ISO Guide 73, and says documenting it requires the provider to fully consider the risks of deploying the AI product. Enforcement data gives that review something concrete to examine: how often rules blocked or redacted, how many actions were escalated and how they were resolved, which exceptions were granted, and whether the volume and pattern of activity stays inside the tolerance you set.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, for individual interactions and tool calls. Enforcement generates continuous audit-ready evidence, mapped to NIST and the EU AI Act. The mapping helps teams relate treatment verification to the frameworks they report against. It does not replace the judgment needed to decide whether the residual risk is acceptable.

Limits and review practices

Runtime controls have boundaries that should be stated in the treatment plan itself. Over-reliance is the main hazard: a plan that lists a runtime rule as the sole treatment for a design-level risk will look complete and still leave that risk untreated.

• Record runtime enforcement as one control among organizational, design-time and testing controls for each risk.
• Name the residual risk after treatment, with an owner and a review date.
• Keep an explicit stop condition for risk that exceeds tolerance, not only a rule that limits it.
• Revisit EU AI Act and NIST mappings when standards, timelines or use-case lists change.
• Test rules against real tool and data patterns before relying on them as treatment evidence.
• Re-review exceptions on a fixed cycle so temporary approvals do not become permanent.