How to Evaluate and Accept Residual AI Risk Under ISO/IEC 23894

Where residual risk sits in the AI risk management process

ISO/IEC 23894:2023 is guidance on managing AI-specific risk for organizations that develop, produce, deploy or use AI-based products, systems and services. It is guidance, not a certifiable requirements standard. It is meant to help integrate risk management into AI-related activities and functions. ISO 31000, the general risk management standard it builds on, addresses integrating risk-based decision making into governance, planning, management and reporting.

Most programs complete identification, analysis and a treatment plan. The gap appears at the next step. Finishing a treatment plan does not tell you what risk remains, whether that level is tolerable, or who is entitled to say so. Acceptance should be a distinct, recorded decision at the end of the assess and treat cycle, not an implied result of closing the last action item.

The method below is a working approach that follows the assess, treat, record, monitor and review logic common to ISO 31000 based processes. Map the terms to your own risk framework, and to your AI management system and NIST AI RMF practices where you use them.

Acceptance authority and the decision record

Acceptance authority is a governance choice, and it should be written down before any specific decision needs it. A workable pattern ties authority to residual severity. Lower residual levels may be accepted by the business owner of the AI system. Moderate levels go to a risk function or committee. Levels near the top of appetite, or any residual risk affecting health, safety or fundamental rights, go to executive or board-level risk owners. Whatever structure you choose, it should be consistent with the risk appetite statement and approved by the same body that approved that statement.

The decision record is what an auditor or regulator will read. It should identify the system and its intended purpose, the risks assessed, each treatment relied on and its owner, the residual rating under both the working and degraded assumptions, and any conditions of acceptance, such as a restricted user group or a required human approval step. It should also name the evidence examined and the date by which the decision expires or is reviewed.

Conditions matter. Many acceptances are really conditional: the risk is tolerable only if a given control keeps operating. A record that states the condition makes it possible to test later whether the acceptance still holds.

An acceptance is only as sound as the evidence behind the controls

A common failure is accepting residual risk on the strength of a pre-deployment assessment and never checking that the treatments run in production. The residual rating then describes a design, not an operating system.

The EU AI Act points in the same direction for high-risk systems. It requires a risk management system that is established, implemented, documented and maintained, and describes it as a continuous, iterative process run throughout the lifecycle, with regular systematic review and updating. It also requires testing to identify appropriate and targeted risk management measures and to confirm consistent performance for the intended purpose, and it requires technical documentation to be kept up to date. Read together, these support treating acceptance as a decision that is reviewed, not a one-time sign-off. As of November 2026, Commission material cites 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for those embedded in products, following the Digital Omnibus on AI proposed on 19 November 2025. Dates should be rechecked before you plan against them.

It helps to separate two kinds of evidence. Design evidence shows a control exists: policies, configurations, test results. Operating evidence shows it acted: records of what was permitted, blocked, escalated or approved, and incident records. Acceptance decisions should cite both. Not every treatment produces operating evidence at runtime. Training data quality, model design choices, staff training and procurement controls are assessed through other means, and the record should say which kind of evidence supports each one.

Where runtime enforcement supports the acceptance record

Some treatments can be enforced in the execution path rather than only specified in policy. Trussed enforces policy at runtime across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval. Enforcement generates continuous, audit-ready evidence, mapped to frameworks including the EU AI Act and NIST. For a risk leader, that evidence can show that a condition of acceptance, such as a human approval step for a sensitive tool call, was applied in operation and not only designed.

The scope is specific. This covers policy decisions on individual interactions and tool calls. It does not provide transaction-level governance across tasks and agents, model or dataset provenance, or end-to-end tracing of agentic workflows. It also does not replace pre-deployment testing or organizational controls. Residual risks that depend on those areas need their own evidence in the acceptance record.

The approach is useful when a treatment can be expressed as a rule applied to an interaction. It adds little where the risk sits in training data, model design or business process outside the AI execution path.