ISO/IEC 23894:2023 gives guidance, not requirements, for managing AI risk using the ISO 31000 process. For AI agents that act, it helps most in three places: setting risk criteria around how reversible an action is, identifying risks per action rather than per system, and treating them with limits on what the agent may do.
What does ISO/IEC 23894 set out?
The standard adapts general risk management guidance to AI. It follows the familiar structure, in substance:
- Principles: risk management should be integrated, structured, customised, inclusive, dynamic, based on the best available information, attentive to human and cultural factors, and continually improved.
- Framework: leadership commitment, integration into governance, design, implementation, evaluation and improvement.
- Process: communication and consultation; scope, context and criteria; risk assessment, made up of identification, analysis and evaluation; risk treatment; monitoring and review; recording and reporting.
Its annexes add AI-specific material: common AI-related objectives such as accountability, fairness, privacy, safety, security, transparency and robustness; common risk sources such as the level of automation, lack of transparency, complexity of the environment and life cycle issues; and a mapping of risk management activities to the AI system life cycle.
It is guidance. You cannot be certified to it. How it relates to the certifiable standard is covered in ISO/IEC 23894 vs ISO/IEC 42001.
Who does it apply to?
Any organisation that develops, provides or uses AI and wants a structured risk process. Firms building an AI management system under ISO/IEC 42001 often use it to shape their risk assessment, and firms with an ISO 31000-based enterprise risk framework use it to extend that framework to AI. Our explainer on what AI risk management is covers the basics.
What does the guidance mean when the system is an agent that acts?
The standard's risk sources include the level of automation. For agents, that is the risk source that changes everything else, because an agent does not only produce an output for a person to use; it can take the action itself. Three parts of the process need sharper treatment.
Context and criteria. Set risk criteria around the action, not the model. A useful scale asks: can this action be undone, by whom, and how fast? Reading a record is fully reversible. Sending a letter is not, but the harm is limited. Releasing a payment or closing an account may be hard to undo and harmful. Criteria that rank actions this way tell you where tolerance is low.
Identification. Identify risks per capability and per action. A complaints agent that reads, drafts and files has three action types, each with different failure modes: reading the wrong customer's file, drafting a misleading response, filing the complaint under the wrong category so a deadline is missed. Listing "hallucination" as a single system-level risk misses all three.
Treatment. ISO 31000 offers options such as avoiding the risk, changing its likelihood or consequences, sharing it and retaining it. For agents those become concrete:
| Treatment option | Agent control |
|---|---|
| Avoid the risk | The action is not available to any agent |
| Change the likelihood | Narrow sources, better instructions, testing on real cases |
| Change the consequences | Limits on amounts and volumes; held for a person above a threshold |
| Share the risk | Contractual terms with the platform; insurance |
| Retain the risk | Accept with monitoring, recorded by the risk owner |
How do you apply it in practice?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Communication and consultation | Process owners, compliance and IT involved in each agent assessment | Workshop records; sign-offs |
| Scope, context and criteria | Risk criteria based on reversibility and harm of actions | Approved criteria |
| Risk identification | Risks listed per capability and action, using the standard's risk sources | Risk register by capability |
| Risk analysis | Likelihood informed by test results on the firm's own cases | Test evidence linked to risk entries |
| Risk evaluation | Each risk compared with criteria; decision recorded | Evaluation records |
| Risk treatment | Treatment chosen per risk, with limits enforced at the moment of action | Treatment plans; limit configuration |
| Monitoring and review | Outcome monitoring; reassessment on change or incident | Monitoring reports; review records |
| Recording and reporting | Agent risk reported to management | Risk reports |
The analysis row is where many firms rely on vendor claims. The guidance calls for the best available information. For an agent, that is evidence of how it performs on your own cases, not a vendor's benchmark. ISO/IEC 42001 makes a similar demand in its risk assessment requirement; see ISO/IEC 42001 AI risk assessment for AI agents.
What will an auditor or supervisor ask?
- What risk criteria did you use, and how do they reflect the actions the agent can take?
- Show us the risks identified for this capability. Are they specific to what it does?
- What evidence supports your likelihood estimates?
- Which treatments are enforced by the system and which rely on people remembering?
- When was the assessment last reviewed, and what triggered it?
What does the standard not cover?
It does not set requirements or thresholds. It does not cover information security in depth; that is the domain of ISO/IEC 27001, discussed in does ISO/IEC 27001 cover AI agents. It does not satisfy legal requirements such as the EU AI Act's risk management duty on its own, though it can help evidence them. Our longer explainer on how ISO/IEC 23894 applies to AI agents gives more examples. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is ISO/IEC 23894 useful without ISO 31000?
Yes, but it assumes the ISO 31000 process. If your organisation uses a different enterprise risk framework, map the steps across rather than running a parallel process.
How often should agent risk assessments be reviewed?
On any material change to the agent's brief, sources, model or actions, after incidents, and on a fixed cycle. Agents change more often than traditional systems, so event-driven review matters most.
Does the guidance tell you which agent actions to forbid?
No. It gives the method for deciding. Firms usually conclude that some actions, such as reversing settled payments, should not be available to agents at all.