ISO/IEC 23894 Explained: Managing AI-Specific Risk

An organization can have a mature enterprise risk process and still miss important artificial intelligence risks. The problem is rarely that it has forgotten concepts such as likelihood, impact, or treatment. The problem is that AI changes what must be observed, who may be affected, and how quickly the risk picture can change.

A model can degrade while the surrounding business process remains unchanged. A provider can alter a service without the organization controlling the change. A system can meet its technical performance target while creating unintended effects for customers, employees, or other groups. And a low-impact pilot can become material when its scale or purpose changes.

ISO/IEC 23894:2023 addresses that gap. It does not replace enterprise risk management or create a separate universe for AI. Its purpose is to help organizations integrate AI-specific considerations into existing risk-management activities and functions.

ISO/IEC 23894 is guidance, not a management-system certification

The first distinction is about authority and purpose.

ISO/IEC 23894 is a guidance standard for managing AI-related risk. ISO directs it to organizations that develop, produce, deploy, or use products, systems, and services that utilize AI. Its application can be customized to organizational context, and the standard is intended to be used in connection with ISO 31000:2018, the general risk-management standard.

That distinction should shape how auditors use it. ISO/IEC 23894 should not automatically become a conformity checklist. Its value is to deepen the risk method: broaden the sources considered, improve analysis of consequences, connect risk to the AI lifecycle, and strengthen monitoring and review.

Its relationship with ISO/IEC 42001:2023 is also complementary. ISO/IEC 42001 establishes requirements for an AI management system and requires organizations to perform AI risk assessment and risk treatment. The standard itself points to ISO/IEC 23894 for guidance on implementing AI risk management. In practical terms:

This matters because an organization can use ISO/IEC 23894 without implementing a certifiable ISO/IEC 42001 management system. An internal auditor can also use the guidance as a professional reference without presenting every recommendation as a mandatory requirement.

AI expands the object of risk assessment

A conventional risk assessment may start with a process: what could prevent procurement, credit, human resources, or customer service from achieving its objectives?

That question remains valid with AI, but it is no longer sufficient.

The analysis needs to consider how the system learns or generates outputs, what data it depends on, who provides it, how it is used, which decisions it influences, who may be affected, and how the system changes over time. The unit of analysis therefore extends beyond the process to a socio-technical system: technology, people, data, suppliers, decisions, and organizational context.

This wider view helps identify sources of risk that a generic “technology risk” category may conceal. Examples include:

• incomplete, unrepresentative, or unsuitable data;
• incorrect, inconsistent, or difficult-to-explain outputs;
• automation bias or ineffective human oversight;
• dependence on external providers, models, or infrastructure;
• changes in the operating context that invalidate original assumptions;
• adverse effects on individuals, groups, or society;
• security, privacy, or manipulation vulnerabilities;
• performance expectations that exceed what the system can reliably deliver.

The objective is not to create an endless catalog of “AI risks.” It is to strengthen the relationship between objective, context, risk source, and consequence.

An AI risk register is weak when it merely adds new labels. It becomes useful when it changes decisions about design, use, oversight, and treatment.

Risk identification must look beyond the model

A common mistake is to focus risk analysis on the algorithm itself. For many organizations, the most material risks arise not from the model in isolation but from how it is embedded in a business decision.

Consider a generative AI tool used to draft responses to customers. The risk is not limited to hallucination or factual error. It also depends on whether the employee can recognize a bad answer, whether authoritative sources are available, whether the system version and provider are traceable, whether sensitive information can enter the prompt, whether a customer can challenge a decision, and whether incidents lead to corrective action.

A mature risk-identification process should therefore connect at least five perspectives:

1. Objective and intended use. What the system is expected to achieve and which decisions it supports.
2. Data and technology. The information, models, infrastructure, and configurations on which it depends.
3. People and stakeholders. Who operates it, who relies on the output, and who may experience consequences.
4. Environment and third parties. Providers, obligations, jurisdictions, and external dependencies that shape exposure.
5. Lifecycle and change. What may change from design or acquisition through deployment, operation, modification, and retirement.

For internal audit, this structure is useful because it turns abstract responsible-AI language into evidence questions: is intended use documented? Are dependencies understood? Are acceptance criteria defined? Are risks reassessed after significant change?

Treatment should respond to the risk, not to a standard control list

Once risks are assessed, the next challenge is avoiding mechanical treatment.

Two applications using the same underlying model can require very different controls. A tool that summarizes public documents and a system that recommends credit decisions may share technology, but they differ substantially in consequence, stakeholder exposure, and risk tolerance.

ISO/IEC 42001 reinforces this risk-driven logic by requiring the organization to determine the controls necessary to implement selected treatment options and then compare them with its reference controls to verify that necessary controls have not been omitted. The more defensible sequence is:

risk → treatment decision → control → owner → evidence → residual risk

Not the reverse.

Treatment can include avoiding a use, changing the design, limiting the scope, introducing human review, improving data, adding validation, modifying supplier terms, restricting access, creating contestability mechanisms, increasing monitoring, or consciously accepting residual risk.

For auditors, a powerful test is to select material risks and trace that chain in both directions. If a control exists, management should be able to explain which risk it treats. If a risk has been accepted, authority, criteria, and evidence should support that decision.

Monitoring is where AI risk management stops being a snapshot

One of the most practical implications of AI-specific risk management is that an initial assessment can lose relevance quickly when either the system or its context changes.

ISO/IEC 42001 requires AI risk assessments at planned intervals and when significant changes are proposed or occur. It also requires organizations to implement the risk treatment plan and verify its effectiveness. This operationalizes a central idea behind ISO/IEC 23894: AI risk management requires continuing monitoring, review, recording, and communication.

What should trigger reassessment? Examples include:

• a new purpose or user population;
• material changes in data, model, provider, or configuration;
• deterioration in performance;
• incidents, complaints, or unexpected outcomes;
• regulatory or contractual changes;
• expansion into new jurisdictions or business processes;
• newly discovered vulnerabilities or attack techniques;
• evidence that existing treatment is ineffective.

This makes the risk register a governance mechanism rather than a periodic reporting artifact. The purpose is not merely to refresh a score each quarter. It is to detect when the assumptions supporting an earlier decision are no longer valid.

What internal audit should examine

For an assurance engagement, ISO/IEC 23894 is more valuable as a depth lens than as a checklist. Five questions often reveal the maturity of the process:

1. Is AI risk management integrated into enterprise risk activities, or does it operate as a separate technical exercise?
2. Does risk identification consider the system, data, people, third parties, intended use, and lifecycle in addition to traditional technology risks?
3. Are consequences considered for the organization and for relevant stakeholders?
4. Is there traceability from prioritized risks to treatment, controls, ownership, and residual-risk decisions?
5. Can changes, incidents, and monitoring results trigger genuine reassessment?

Evidence may include risk criteria, risk registers, assessments, approval decisions, treatment plans, testing results, metrics, incident records, committee minutes, supplier changes, and residual-risk acceptance.

Internal auditors do not need to become data scientists to assess this architecture. They do need to recognize when a conclusion depends on technical assertions —such as statistical robustness, model bias, or adversarial security— that require specialist support.

ISO/IEC 23894 makes visible what generic risk management can miss

AI risk management does not require abandoning familiar principles. It requires applying them to a more dynamic and interconnected object of risk.

ISO 31000 provides the general architecture. ISO/IEC 23894 adds AI-specific depth. ISO/IEC 42001 turns part of that logic into management-system requirements. Together they create a coherent progression: understand context, identify risk more completely, treat it proportionately, and reassess when reality changes.

For internal audit, that is the most important consequence. The question is not whether the organization has an “AI risk register.” The question is whether its risk process recognizes what makes AI different and whether those differences actually influence governance, control, and monitoring decisions.

Sources

• ISO, ISO/IEC 23894:2023 — Artificial intelligence — Guidance on risk management
• ISO, ISO 31000:2018 — Risk management — Guidelines
• ISO, ISO/IEC 42001:2023 — Artificial intelligence — Management system