ISO/IEC 23894: AI Risk Management Guidance for Product Teams

ISO/IEC 23894 is the international guidance standard for managing risk in artificial intelligence. Published in February 2023 by the ISO and IEC committee on AI, it takes the well-established ISO 31000 approach to risk and adapts it to the particular problems AI brings: models that behave differently from what developers expect, outputs that are hard to explain, bias inherited from data, changing performance after deployment, and new security threats such as data poisoning.

It is guidance, not a certifiable standard, but it is the natural partner to ISO/IEC 42001, which requires an AI risk process, and it helps meet the risk management duties of the EU AI Act. This guide explains the standard's structure, the AI objectives and risk sources it highlights, how to run AI risk assessments across the lifecycle, and how it compares with ISO/IEC 42001 and the NIST AI Risk Management Framework.

What is ISO/IEC 23894?

ISO/IEC 23894 provides guidance on how organisations that develop, produce, deploy or use products, systems and services that use AI can manage risk specifically related to AI. It helps organisations integrate risk management into AI-related activities and functions, and describes processes for effective implementation. It is developed by ISO/IEC JTC 1/SC 42, the joint committee responsible for AI standards including ISO/IEC 42001 and the AI concepts standard ISO/IEC 22989.

The standard closely follows the structure of ISO 31000. For each part of ISO 31000, it explains what changes or needs extra attention when AI is involved. Organisations already using ISO 31000 or ISO/IEC 27005 can therefore extend their existing risk process rather than create a separate one.

History and current edition

ISO/IEC 23894:2023 is the first edition, published in February 2023. National bodies and regional organisations have since adopted it, and a work item for a revision has been registered by the committee. Until a new edition is published, the 2023 text applies.

Who should use it?

• AI product teams and ML engineers who need a structured way to identify and reduce risks in models and features.
• Risk, compliance and legal teams integrating AI into enterprise risk management.
• Organisations implementing ISO/IEC 42001, which requires AI risk assessment and treatment.
• Providers and deployers under the EU AI Act, where high-risk systems need a risk management system across the lifecycle.
• Software vendors answering customer questions about how they manage AI risks.

Is it mandatory or voluntary?

Voluntary. It becomes practically important where laws, certification or contracts require documented AI risk management. It is not certifiable on its own.

Principles applied to AI

ISO 31000's eight principles apply, with AI-specific notes. For example, risk management for AI should be integrated into product development rather than reviewed at the end; structured so that different teams assess AI risks consistently; customised to the type of AI and its use; inclusive of affected stakeholders and domain experts, not just data scientists; dynamic because models and data change; based on the best available information, recognising uncertainty in model behaviour; attentive to human and cultural factors such as over-reliance on AI outputs; and continually improved as incidents and monitoring reveal new risks.

Framework: leadership and integration

Top management should commit to managing AI risk, assign roles and responsibilities, and provide resources. AI risk management should be integrated into governance, product strategy, procurement of AI services, and change management. Organisations should consider their context, including legal requirements, stakeholder expectations, the organisation's AI policy and its role as developer, provider or user of AI.

Common AI-related objectives

An informative annex lists objectives that organisations often consider when managing AI risk. They include:

• Accountability for AI outcomes and decisions.
• AI expertise within the teams that design, deploy and oversee systems.
• Availability and quality of training and test data.
• Environmental impact of training and running models.
• Fairness and avoidance of unwanted bias.
• Maintainability of models and pipelines.
• Privacy of personal data used or inferred.
• Reliability under varied conditions, including unexpected inputs.
• Safety for people and property.
• Security against attacks on models and data.
• Transparency and explainability of how outputs are produced.

Risk, in ISO terms, is the effect of uncertainty on these objectives.

Common AI risk sources

Another annex lists sources of AI risk that organisations should consider when identifying risks:

• Complexity of the environment in which the system operates.
• Lack of transparency and explainability.
• Level of automation and how much humans can intervene.
• Machine learning specifics, such as data quality, data drift and overfitting.
• System hardware issues.
• System lifecycle issues, from design flaws to inadequate deployment and maintenance.
• Technology readiness and maturity of the techniques used.

The AI risk management process

1. Communication and consultation with developers, users, affected people and experts.
2. Scope, context and criteria: define the AI system's purpose, users, affected parties, legal context and risk criteria, including harms to individuals and society, not only to the organisation.
3. Risk identification: identify assets and their value, risk sources, potential events, controls and consequences, using the annexes as prompts.
4. Risk analysis: assess likelihood and consequences, considering that some AI failures are rare but severe, and that impacts may fall on people outside the organisation.
5. Risk evaluation: compare with criteria and decide on treatment.
6. Risk treatment: choose controls such as data quality checks, bias testing, human oversight, input and output filtering, monitoring, fallback behaviour, user information and, where needed, not deploying the system.
7. Monitoring and review: track model performance, drift, incidents and feedback, and reassess when models, data or uses change.
8. Recording and reporting of risk decisions and results.

Risk management across the AI lifecycle

An annex maps risk management activities to stages of the AI system lifecycle, based on ISO/IEC 22989. In practice:

Lifecycle stage	Typical risk activities
Inception	Define purpose and context, identify stakeholders, decide whether AI is appropriate, set risk criteria.
Design and development	Assess data sources and quality, choose model approaches, plan evaluation, design human oversight.
Verification and validation	Test accuracy, fairness, security and behaviour on edge cases; confirm risks are acceptable.
Deployment	Inform users, configure monitoring, set fallback and escalation procedures.
Operation and monitoring	Track performance and drift, handle incidents and complaints, retrain carefully.
Re-evaluation and retirement	Reassess after changes, retire systems safely and handle data appropriately.

AI-specific threats to include

Traditional security risk assessments may miss threats unique to AI. When applying ISO/IEC 23894, teams should consider data poisoning, where training data is manipulated to change model behaviour; adversarial inputs designed to cause wrong outputs; model extraction or theft through repeated queries; membership inference and other privacy attacks that reveal training data; prompt injection and jailbreaks in generative AI, where instructions hidden in user input or retrieved documents override intended behaviour; and insecure plugins or tools that let a model take harmful actions. These threats affect the security, privacy and safety objectives, and treatments range from input validation and output filtering to rate limiting, access control and isolation of tools the model can call.

Third-party and foundation models

Many products build on models from external providers. ISO/IEC 23894 still applies: the organisation remains responsible for the risks of its product, even if it did not train the model. Practical steps include reviewing the provider's documentation on intended use, limitations and evaluations; testing the model on your own use cases and languages; checking contractual terms on data use, retention and security; planning for provider changes such as model updates or deprecation; and monitoring outputs in production. Where a provider's model is updated without notice, results can shift, so version pinning and regression tests are useful controls.

Designing human oversight

Human oversight is a common treatment, but it only reduces risk if designed well. Reviewers need enough information to judge outputs, such as confidence levels and reasons; enough time and authority to override the system; training on the system's limitations; and protection against automation bias, the tendency to accept machine output without question. Logging when humans agree or disagree with the system also provides useful monitoring data. For high-impact decisions, organisations should define which cases must be reviewed and what reviewers must check.

Timeline, cost, benefits and limitations

Extending an existing ISO 31000 or ISO/IEC 27005 process to AI usually takes a few weeks of method design and training, then a few days per significant AI system for a first assessment. The larger effort is building controls such as evaluation suites and monitoring. The benefits are consistent decisions about AI, evidence for regulators, auditors and customers, and fewer surprises after launch. The limitations are that the standard is guidance rather than a checklist, so teams must interpret it, and it does not by itself prove compliance with any specific law.

How it relates to ISO/IEC 42001 and the NIST AI RMF

Aspect	ISO/IEC 23894	ISO/IEC 42001	NIST AI RMF
Type	Guidance on AI risk	Requirements for an AI management system	Voluntary framework
Certifiable	No	Yes	No
Basis	ISO 31000	ISO management system structure	Govern, Map, Measure, Manage functions
Use together	Defines the risk process	Requires a risk process and AI impact assessment	Provides practical actions and profiles

A common combination is ISO/IEC 42001 for the management system and certification, ISO/IEC 23894 for the risk method, and the NIST AI RMF playbook for practical actions.

How to apply it, step by step

1. Extend your risk policy to cover AI, with clear roles.
2. Inventory AI systems, including third-party models and APIs.
3. Define AI risk criteria that include harms to individuals and society.
4. Run risk assessments per system using the objectives and risk sources as prompts.
5. Select treatments and build them into the product, not just policies.
6. Set up monitoring for performance, drift, incidents and feedback.
7. Review on change and at planned intervals.
8. Document assessments and decisions for audits and regulators.

Setting AI risk criteria

Risk criteria tell teams which risks are acceptable. For AI, criteria should cover consequences for individuals, such as wrongful denial of a service, discrimination, privacy intrusion, physical harm or psychological harm, as well as consequences for the organisation such as legal liability, reputational damage and financial loss. Criteria may also reflect how reversible a harm is, how many people could be affected, and whether affected people can understand and challenge an outcome. Many organisations define a small number of AI risk tiers, with stricter testing, oversight and approval requirements for higher tiers. This approach mirrors risk-based laws such as the EU AI Act and makes it easier to show regulators that controls are proportionate.

Documentation you will need

• AI risk policy and criteria.
• AI system inventory with roles (developer, provider, user).
• Risk assessments per system and lifecycle stage.
• Treatment plans and evidence, such as evaluation results.
• Monitoring reports and incident records.
• Change and review records.

Common mistakes

• Assessing only organisational risk and ignoring harms to users and third parties.
• One-time assessments that are never updated after model changes.
• Ignoring third-party models because "the vendor handles it".
• Policies without product controls, such as evaluation and monitoring.
• Treating accuracy as the only metric.

Best practices, tools and technologies

• Build evaluation suites for accuracy, fairness, safety and security, and run them in CI.
• Red-team generative features for misuse and prompt injection.
• Log inputs and outputs where lawful to investigate incidents.
• Use model cards and data sheets to document systems.
• Monitor drift and set retraining and rollback procedures.
• Design human review for high-impact decisions.

We build evaluation pipelines, guardrails, human review steps and monitoring into AI features through our custom software development and SaaS product work.

Real-world example

A lending fintech in India uses a machine learning model to recommend credit limits. Using ISO/IEC 23894, it identifies risk sources including historical data reflecting past bias, drift as economic conditions change, limited explainability and over-reliance by credit officers. Treatments include fairness testing across groups, reason codes for each recommendation, a requirement that officers review edge cases, monthly drift monitoring and a rollback plan. The assessment is documented and feeds into its ISO/IEC 42001 management system and its responses to regulator questions.

Next steps

1. Extend your risk process to AI.
2. Inventory and classify AI systems.
3. Assess risks using AI objectives and sources.
4. Build controls into products.
5. Monitor and review continuously.

Frequently asked questions

What is ISO/IEC 23894?

International guidance on managing risks related to the development, provision and use of AI, based on ISO 31000.

Is ISO/IEC 23894 certifiable?

No. Organisations certify to ISO/IEC 42001 and use ISO/IEC 23894 for the risk process.

What is the difference between ISO 23894 and ISO 42001?

ISO/IEC 42001 sets requirements for an AI management system; ISO/IEC 23894 gives guidance on how to manage AI risk within it.

How does ISO 23894 relate to ISO 31000?

It follows ISO 31000's principles, framework and process and adds AI-specific guidance.

What AI risk sources does it list?

Environment complexity, lack of transparency, level of automation, machine learning issues, hardware, lifecycle issues and technology readiness.

Does it help with the EU AI Act?

Yes. It provides a structured way to meet the Act's risk management expectations, though it is not a harmonised standard on its own.

When was it published?

February 2023. A revision has been registered as a work item.

Can small teams use it?

Yes. The process scales; a small team can assess a few systems with simple criteria.

Does it cover generative AI?

Its process applies to any AI, including generative models, though specific risks such as prompt injection need additional practical guidance.

Is it the same as the NIST AI RMF?

No, but they are compatible; many organisations use both.

Who should own AI risk in an organisation?

Product owners should own risks for their AI systems, supported by risk, legal, security and data science specialists, with leadership setting criteria.