ISO/IEC 23894:2023 — AI Risk Management Explained
-
- Name
- Keenfunnel
- GitHub
- @GitHub
ISO/IEC 23894:2023 — AI Risk Management gives organizations a structured way to identify, assess, treat, and monitor risks tied to artificial intelligence. It is not a checklist for approving every AI tool. It is guidance for making defensible decisions as AI systems affect customers, employees, operations, data, and business outcomes.
For many organizations, the hard part is not recognizing that AI has risks. It is connecting those risks to real decisions: whether an AI assistant can access customer data, who approves a model’s use in sales, what happens when outputs become unreliable, and when a system should be paused. We can use ISO/IEC 23894:2023 to turn those questions into a repeatable operating process.
Table Of Contents
• Key Takeaways
• What ISOIEC 238942023 Means In Practice
• How To Apply The Standard To A Real AI System
• Frequently Asked Questions• Sources
Key Takeaways
• ISO/IEC 23894:2023 is AI risk management guidance, not a standalone certification standard. It helps organizations apply a structured risk process to AI activities.
• The standard applies beyond AI developers. Organizations that deploy, operate, buy, or use AI can apply it, including teams using third party foundation models.
• AI risk management should reuse existing enterprise risk practices where possible. It should add AI specific analysis where existing methods do not capture issues such as hallucinations, model drift, biased outputs, data leakage, or weak human oversight.
• A useful AI risk record needs more than a risk score. It should document the system purpose, affected stakeholders, risk scenario, controls, decision owner, residual risk, and review trigger.
• ISO/IEC 23894 and ISO/IEC 42001 serve different purposes. ISO/IEC 23894 supports the risk process, while ISO/IEC 42001 provides a broader AI management system structure.
A risk register without named owners, decision evidence, and monitoring triggers is usually a record of concern rather than a working control system.
What ISO/IEC 23894:2023 Means In Practice
Guidance For Organizations Using AI
ISO/IEC 23894:2023 was published in February 2023 by ISO/IEC JTC 1/SC 42. The official ISO/IEC 23894:2023 standard overview describes guidance for organizations that develop, produce, deploy, or use AI enabled products, systems, and services. It is designed to be customized to an organization’s context.
That scope matters. A company does not need to train a large language model to have AI risk obligations. A sales team using an AI meeting assistant, a support department using a chatbot, or an operations team automating document classification all make decisions about data, outputs, oversight, and business impact.
We should treat the AI system boundary broadly enough to include more than the model. The practical boundary often includes:
• The business process the AI affects• The data entering and leaving the system• The model, vendor, prompts, integrations, and user interface• The people who review, act on, or rely on outputs• The customers, employees, partners, or communities affected by decisions
A narrow scope creates blind spots. Consider a customer support chatbot powered by a third party model. The model may be supplied by a vendor, but the deploying organization still controls the knowledge base, permissions, escalation path, customer notices, and service recovery process. Those local decisions can create much of the actual risk.
Why AI Risks Need More Than A Generic Register
Traditional enterprise risk methods remain useful. Organizations already understand concepts such as likelihood, impact, ownership, controls, and escalation. AI changes the evidence needed to make those judgments.
An AI output can be plausible but wrong. A model may perform well in testing, then degrade when customer behavior, source data, or the operating environment changes. A user may treat a generated recommendation as a decision rather than a draft. These are not always separate categories of risk, but they change how risk scenarios should be described and tested.
A practical AI risk taxonomy can include the following categories:
Risk Category | What Can Fail | Example Control |
|---|---|---|
Data and privacy | Sensitive data is exposed, retained, or used beyond its approved purpose | Data classification, access controls, approved vendor terms |
Output quality | The system produces false, incomplete, or misleading output | Human review, source citation checks, test cases |
Fairness and harm | Outputs disadvantage groups or create inappropriate outcomes | Scenario testing, escalation paths, impact review |
Security and misuse | Users or attackers manipulate inputs or misuse capabilities | Permission limits, input filtering, logging |
Operational resilience | The service fails, changes behavior, or becomes unavailable | Fallback process, vendor monitoring, continuity plan |
Governance and accountability | No one owns approval, monitoring, or corrective action | Named system owner and decision authority |
We should avoid creating a separate AI risk universe for every low impact tool. If an AI feature only drafts internal meeting summaries and cannot access sensitive systems, an existing technology risk process may be enough. Create AI specific assessment steps when the use case affects regulated decisions, confidential information, public outputs, financial commitments, customer treatment, or safety.
Risk Management Guidance Is Not Certification
A common misunderstanding is that ISO/IEC 23894:2023 itself creates a certification path. It does not function as a certifiable AI management system standard. It provides guidance on managing AI related risk.
This distinction affects purchasing and governance decisions. If leadership wants a repeatable way to assess a new AI feature, ISO/IEC 23894 can guide the risk workflow. If leadership wants a full management system with policy, roles, objectives, internal review, corrective action, and continual improvement, ISO/IEC 42001 is the more relevant framework.
ISO identifies ISO/IEC 42001:2023 as an AI management system standard and lists ISO/IEC 23894 among the standards that can help organizations mitigate AI risks and maximize value. In practice, we can think of the relationship this way:
Need | ISO/IEC 23894 Contribution | ISO/IEC 42001 Contribution |
|---|---|---|
Assess an AI use case | Risk identification, analysis, evaluation, and treatment | Governance context and organizational controls |
Define accountability | Risk owners and treatment decisions | Roles, policies, management responsibility |
Monitor deployed AI | Ongoing review of risk and controls | Management system review and improvement |
Demonstrate structured governance | Evidence of risk decisions | Broader management system evidence |
Neither standard removes the need for legal, security, privacy, procurement, or sector specific review. They help organize those responsibilities.
How To Apply The Standard To A Real AI System
Establish Context Before Scoring Risk
The AI risk process described by the IEC’s guidance on AI related risk management adapts ISO 31000 principles for AI. It includes establishing context, identifying risks, analyzing risks, evaluating risks, treating risks, and monitoring and reviewing risks.
Context setting is where teams often save or lose time. Start by writing down the actual business decision. “Use generative AI for customer support” is too broad. “Use an external language model to draft replies to billing questions, with an agent approving every response before sending” is specific enough to assess.
For each system, document:
Purpose and expected benefit: What work is the system improving, and what outcome matters?
System boundary: Which data sources, integrations, vendors, models, users, and outputs are in scope?
Stakeholders: Who may benefit or be harmed if the system fails?
Risk criteria: What level of error, data exposure, delay, or unfair treatment is unacceptable?
Decision authority: Who can approve deployment, accept residual risk, or stop the system?
Fair warning: a generic risk threshold can fail when applied to AI. A small error rate may be acceptable for internal content drafting but unacceptable for a system that prioritizes urgent customer complaints. The same technical failure can have different business consequences.
Identify, Analyze, And Treat Concrete Scenarios
Risk identification works best when it describes a chain of events, not a vague concern. “Hallucination” is not yet a complete risk statement. A stronger statement is: “The chatbot may provide an invented refund policy, causing customers to receive inaccurate commitments and creating financial loss or complaint risk.”
The analysis should consider likelihood, impact, and consequences. It should also test how quickly the organization can detect and correct the issue. A low frequency failure can still be severe if it affects many customers before anyone notices.
A useful treatment decision can follow this sequence:
Avoid the risk by removing the use case or restricting the AI from a high consequence task.
Reduce the risk through controls such as human approval, narrower permissions, testing, retrieval limits, or output filters.
Transfer part of the exposure through contracts, insurance, or vendor commitments, while recognizing that accountability may still remain internally.
Accept residual risk only when the owner understands the remaining exposure and the organization has documented why it is tolerable.
Consider a foundation model used to summarize legal documents. Full automation may be inappropriate if summaries drive contract approval. A proportionate treatment could limit the tool to first drafts, prohibit it from making legal conclusions, require reviewer approval, and retain the source documents beside each summary. The control is not “use AI safely.” It is a specific change to how people rely on the output.
Build An Evidence Log And Monitoring Plan
The standard emphasizes monitoring and review, but it does not prescribe a universal review interval or threshold. That is reasonable because a public facing chatbot and an internal writing assistant do not carry the same exposure. We should define review timing based on consequence, system change, and observed performance.
A lightweight evidence log can make risk decisions traceable without creating unnecessary paperwork. For every material risk, retain these fields:
Evidence Record | What To Capture |
|---|---|
System profile | Purpose, owner, vendor, model version, data inputs, affected process |
Risk scenario | Failure event, affected party, business consequence, existing controls |
Assessment | Likelihood, impact, uncertainty, residual risk, decision rationale |
Treatment plan | Control, accountable owner, due date, validation method |
Approval record | Person or group that accepted, escalated, reduced, transferred, or avoided risk |
Monitoring record | Metrics, thresholds, incidents, changes, review date, corrective action |
Monitoring should combine scheduled reviews with event driven triggers. Scheduled review may be quarterly for a stable internal use case and more frequent for a high impact customer facing system. Event driven review should occur after material model updates, changes in data sources, security incidents, recurring user complaints, a sharp quality decline, or a new integration that expands system access.
For example, a recruiting assistant may initially be approved only to summarize candidate notes. If the team later uses it to rank applicants, the context has changed. The organization should reopen the assessment because the output now influences employment decisions. Reusing the old approval would be weak governance, even if the same vendor and model remain in place.
Frequently Asked Questions
What Is ISO/IEC 23894:2023?
ISO/IEC 23894:2023 is international guidance for managing risks related to AI systems. It supports organizations that develop, produce, deploy, or use AI enabled products and services. Its core value is a structured process for connecting AI risks to organizational objectives, stakeholders, controls, and decisions.
Is ISO/IEC 23894:2023 Certifiable?
No. It is guidance rather than a standalone certification standard. Organizations can use it to design and improve their AI risk process, but they should not represent simple use of the document as certification. Where a formal AI management system is needed, ISO/IEC 42001 is the more relevant companion standard.
Who Should Use ISO/IEC 23894:2023?
Developers, vendors, deployers, and users can all use it. A company buying a third party AI system still needs to assess its intended use, data flows, contractual protections, access permissions, human oversight, and monitoring approach. Vendor supplied technology does not remove deployment risk.
How Does ISO/IEC 23894:2023 Relate To ISO 31000?
ISO 31000 provides broad risk management principles and a general process. ISO/IEC 23894 applies that type of process to AI related risks. It helps teams account for AI specific uncertainty, changing behavior, data dependencies, and the gap between technical performance metrics and real world business effects.
What Risks Should A Third Party Foundation Model Assessment Cover?
Start with the use case rather than the model brand. Assess data disclosure, retention, permissions, output accuracy, prompt injection, vendor changes, service availability, intellectual property concerns, human reliance on outputs, and exit options. Ask what happens if the vendor changes model behavior with little notice. If the answer is “we would not know,” monitoring and fallback controls need work.
How Often Should AI Risks Be Reviewed?
There is no single required cadence in the guidance. Review frequency should match impact and rate of change. High consequence systems may need ongoing operational metrics and formal reviews after every material change. Lower risk internal tools may be reviewed on a scheduled basis and whenever data, scope, model, vendor terms, or user permissions change.
When Should An Organization Accept AI Risk?
Risk acceptance is appropriate only after the remaining risk is understood, within approved tolerance, and owned by a person with authority to make that decision. Acceptance should not mean “the project needs to launch.” It should state what could still go wrong, why controls are sufficient for now, what evidence supports the decision, and what event would force reassessment.
Sources
• ISO.org — ISO/IEC 23894:2023: https://www.iso.org/standard/77304.html
• IEC blog — Essential guidance on AI-related risk management: https://www.iec.ch/blog/essential-guidance-ai-related-risk-management
• ISO.org — ISO/IEC 42001:2023: https://www.iso.org/standard/42001
Partager cet article