ISO/IEC 23894 – AI Risk Management Across the Full Lifecycle

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated November 2025 • ISO 31000, ISO/IEC 42001, EU AI Act • Quality, IT, Data Science, Manufacturing, Regulatory

ISO/IEC 23894 (AI risk management) is the standard that tells you how to treat artificial intelligence as a managed risk source rather than an experiment happening in the shadows. It specializes ISO 31000 principles for AI systems and forces organizations to ask, for every AI use case: what could go wrong, who gets hurt, and which controls keep the model inside a proven envelope? For regulated manufacturing and healthcare, ISO/IEC 23894 is the missing connective tissue between corporate AI strategy, the EU AI Act, and hard evidence inside your QMS, QRM, CSV, and GAMP 5 lifecycles. Slides and AI policies do not count unless the model, data, and workflow are governed like any other GxP-relevant system—with traceable decisions and records that satisfy Data Integrity and ALCOA+.

“If your AI can change a batch, a label, a release decision, or a safety barrier and there’s no ISO/IEC 23894-style risk record behind it, you’re not innovating—you’re gambling with compliance.”

1) Where ISO/IEC 23894 Lives Across the Lifecycle

ISO/IEC 23894 applies to any organization that develops, deploys, or uses AI, from in-house models to third-party tools embedded in instruments, cloud apps, or shop-floor controllers. Upstream, it shapes how you define AI use cases, classify their risk (e.g., EU AI Act categories), and decide whether AI is even appropriate. In development, it governs data selection, labeling quality, algorithm choice, and explainability expectations. In validation, it dictates how you design tests, stress scenarios, and acceptance criteria. In deployment, it defines how AI connects into MES, LIMS, WMS, and ERP so AI cannot silently override existing controls. Downstream, it feeds QRM, APR/PQR, and CPV, closing the loop from risk assessment to ongoing evidence.

2) Regulatory Anchors & System Controls

No regulator mandates “ISO/IEC 23894 certification,” but the behaviors it describes are exactly what inspectors and notified bodies are starting to ask for. Under 21 CFR Part 11 and Annex 11, user authentication, e-signatures, and audit trails are mandatory whenever AI output influences electronic records or critical decisions. Under the EU AI Act, high-risk AI systems will need documented risk management, monitoring, and incident handling aligned with standards like ISO/IEC 23894. Your QMS, ISO 9001, ISO 13485, and FDA’s QMSR already require documented risk and change control. ISO/IEC 23894 simply makes “AI risk” auditable instead of hand-waved inside a data-science notebook.

3) The Standard ISO/IEC 23894 Path—From Use Case to Control

Detection: you identify where AI is actually used—in visual inspection, anomaly detection, forecasting, document classification, copilots, and embedded OEM tools. Classification: each AI system is risk-ranked using agreed criteria (impact on safety, quality, data protection, and fundamental rights), aligned with QRM and, where relevant, EU AI Act categories. Assessment: for higher-risk cases, you build structured risk assessments (e.g., FMEA, HAZOP, threat modeling) targeting AI-specific failure modes—drift, bias, hallucination, security threats. Treatment: you select controls such as human-in-the-loop, thresholds, dual-channel checks, and hard gates in MES or equipment. Monitoring & review: AI performance and incidents feed into Deviations/NCR, CAPA, and management review. The path is boring on purpose—repeatable, recorded, and testable.

4) Data Integrity First—Before Any “Smart” Feature

Before you ask what AI can do, you check whether the underlying data meets ALCOA+. Are training and validation datasets traceable to controlled sources, with documented labeling processes and approvals? Are inference inputs coming from calibrated instruments, qualified interfaces, and authenticated users? Are AI-relevant events captured in tamper-evident GxP audit trails with time sync across MES, LIMS, historians, and cloud services? If not, ISO/IEC 23894 says your first “AI control” is to fix data governance—because untrusted data plus a powerful model is just a faster route to bad decisions.

5) Risk Criteria & Appetite—Rules, Not Roulette

Risk appetite for AI cannot live in PowerPoint. ISO/IEC 23894 expects defined criteria for likelihood and severity, explicit thresholds for what is “acceptable,” and clear mapping to your risk register. AI that can change a setpoint or disposition a batch belongs in a different risk class than a search helper in your DMS. Temporary relaxations (e.g., expanded indications, new populations, novel sensors) must be time-boxed, justified, and re-reviewed. Decisions to deploy or scale AI are taken by cross-functional governance—not by whoever writes the best demo. When a model is pushed into production without passing these gates, that is not agility; it is unmanaged risk.

6) AI Risk Types—And the Controls That Actually Bite

ISO/IEC 23894 pushes you to be specific about AI risk types and matching controls. Safety and quality risk: controlled via human-in-the-loop, dual checks, and hard stops in MES or equipment when AI confidence is low or inputs are out of range. Bias and fairness: controlled via diverse data, subgroup performance analysis, and use-case limits (e.g., prohibiting AI from making irreversible patient or batch decisions alone). Security and abuse: controlled via hardened APIs, authentication, network segmentation, and defense against prompt injection or adversarial samples. Explainability and accountability: controlled by documenting model rationale, providing meaningful operator context, and recording who accepted or overrode AI advice. Without these kinds of controls, your “AI adoption” is just wishful thinking wrapped in marketing language.

7) Typical Root Causes—And How to Evidence Them

Model drift: process, product mix, or population shifts away from training conditions. Evidence via time-segmented performance metrics, SPC charts on model outputs, and change logs in upstream processes. Data bias or gaps: over-representation of certain lots, sites, or populations. Evidence through data lineage, class distribution analysis, and targeted test sets. Over-automation: operators treating AI as authoritative. Evidence via user behavior in MES/HMI audit trails and near-miss investigations. Security weaknesses: exposed endpoints, missing input validation, or shared credentials. Evidence through penetration tests, access logs, and incident reports. Opaque models in high-impact roles: situations where no one can explain why the AI behaved as it did. Evidence via model documentation gaps, missing interpretability tooling, and inspection observations. ISO/IEC 23894 expects these root causes to show up in your risk records—not just in hallway conversations after something goes wrong.

8) Disposition of AI Risk—Risk First, Not Cosmetics

AI risk treatment is not about publishing an ethics statement; it is about changing how the system behaves. Technology controls include thresholds, confidence bands, fallback modes, redundancy with non-AI logic, and enforced human approvals in high-risk paths. Process controls include updated SOPs, competency-based training, and checklists that force challenge questions before acting on AI suggestions. Governance controls include AI review boards, structured go/no-go decisions, and periodic re-approval of high-risk AI systems. Each treated risk in the ISO/IEC 23894 framework should trace to a specific control, owner, due date, and verification step—otherwise the same AI behavior will resurface in the next audit with a new incident number.

9) CAPA, Change Control & Model Lifecycle—Make the Fix Durable

Significant AI issues belong in your CAPA system with hard targets (e.g., reduce mis-classification rate by 40% in three months across all sites) and effectiveness checks (sustained performance, stable variance, no new bias introduced). Model re-training, architecture changes, and major data updates run through Change Control and, where GxP-relevant, through updated CSV/IQ/OQ/PQ. Retirement of AI models is documented too—conditions for sunset, data retention, and migration to successor systems. ISO/IEC 23894 treats AI models as living systems with lifecycles, not one-off projects that disappear as soon as the project team moves on.

10) Prevention by Design—From Use-Case Choice to Human Factors

ISO/IEC 23894 leans hard into prevention: choose use cases, architectures, and interfaces that are hard to misuse. Start by refusing AI where risks are disproportionate or where data cannot reach basic integrity. Design HMIs and MES screens so AI recommendations are clearly labeled as such, with confidence indicators and supporting context instead of cryptic scores. Keep critical kill switches and manual overrides physically and logically accessible. Apply Human Factors Engineering (HFE) so that under stress, operators are more likely to challenge questionable AI outputs than to blindly accept them. And encode “do not automate this” rules in your AI governance so the riskiest shortcuts never make it into code.

11) Trending & Early Warning—Reduce AI Risk via SPC and OOT

AI risk is dynamic, so ISO/IEC 23894 pushes you toward continuous monitoring. Trend key metrics with SPC control limits and Out-of-Trend (OOT) analysis: accuracy, false-positive/negative rates, confidence distributions, subgroup performance, override frequency, and time-to-decision. Feed these signals into CPV for manufacturing and into data-science ops for model stewardship. Good monitoring means AI incidents become rare and small—and when they happen, they are detected by your own metrics, not by patients, customers, or inspectors.

12) Metrics That Demonstrate Control

Track AI use cases per domain with risk class, decision criticality, and lifecycle status. Measure coverage: what percentage of AI systems in production have a current ISO/IEC 23894-style risk assessment and named owner? Monitor model changes per year and the proportion that passed full impact assessment and validation. Trend AI-linked Deviations/NCR, complaints, and near misses. Track override rates (too low may mean blind trust; too high may mean poor performance or poor UX). Use training metrics from the Training Matrix to show that people using or approving AI have completed required courses before go-live. When these numbers are visible and stable, “AI risk under control” stops being a slogan and becomes an auditable reality.

13) Validation of AI-Enabled Workflows

For GxP-relevant AI systems, validation is non-negotiable. Define requirements for functional behavior, performance thresholds, security, explainability, and auditability across data pipelines, models, and consuming systems (MES/eBMR, LIMS, WMS, devices). During IQ/OQ/PQ and CSV, challenge key scenarios: (a) AI failure or uncertainty leads to safe fallback; (b) out-of-spec data is rejected or quarantined; (c) audit trails show which model version and data were used; (d) security controls protect endpoints and credentials; and (e) retention rules for AI-relevant data and logs support Data Retention & Archival. If these scenarios fail, your AI deployment will fail an inspection long before the model fails a benchmark.

14) How ISO/IEC 23894 Fits Operationally Across Systems

Execution (MES and shop floor). Register AI-enabled logic as part of the route, phase, or work instruction stack. Use risk assessments to decide where AI can propose versus where it can decide. Enforce human review steps and hard gates for high-risk actions (setpoints, batch dispositions, override of alarms). Make AI behavior visible on the HMI so operators see context, not mysterious numbers.

Quality (QMS and QRM). Treat AI systems as risk objects inside your QMS. Link ISO/IEC 23894 assessments to risk registers, Deviations, and CAPA. Include AI risk status and performance in management review and APR/PQR. When inspectors ask about AI, you point to controlled records, not marketing pages.

Data & IT (platforms and integrations). Standardize AI pipelines, model registries, and monitoring so every AI system has the same basic plumbing for logging, security, and versioning. Integrate ISO/IEC 23894 outputs (risk levels, controls, monitoring plans) into platform templates so each new use case starts with a compliant skeleton instead of reinventing the wheel under time pressure.

Continuous improvement. Use AI to improve operations, but hold the bar: no production AI without an inventory entry, risk assessment, owner, and monitoring plan. Start with a few high-value use cases, close the loop from risk to evidence, then scale. ISO/IEC 23894 becomes the way the organization says “yes” to AI—safely, repeatedly, and defensibly.

15) FAQ

Q1. Is ISO/IEC 23894 certifiable like ISO/IEC 42001?
No. ISO/IEC 23894 is a guidance standard for AI risk management, not a certifiable management-system standard. You can be audited against it and claim alignment, but formal certification is associated with standards like ISO/IEC 42001, which can use ISO/IEC 23894 as its risk engine.

Q2. If we already follow ISO 31000 and QRM, do we still need ISO/IEC 23894?
Yes. ISO 31000 and pharmaceutical QRM provide general principles but do not cover AI-specific hazards like model drift, bias, adversarial manipulation, or black-box behavior. ISO/IEC 23894 specializes those risk concepts for AI and ties them to the AI system lifecycle.

Q3. Does ISO/IEC 23894 cover generative AI and foundation models?
It is technology-agnostic, so any product, system, or service that uses AI—including generative models and foundation models—is in scope if its outputs influence decisions or outcomes that can create risk. The same risk process applies; only the failure modes and controls differ.

Q4. How does ISO/IEC 23894 relate to the EU AI Act?
The EU AI Act sets legal obligations and risk categories for AI systems; ISO/IEC 23894 provides a structured, lifecycle-based way to identify, assess, treat, and monitor AI risks inside your organization. Implementing ISO/IEC 23894 does not guarantee legal compliance, but it gives you a defensible framework regulators will recognize.

Q5. Who should own ISO/IEC 23894 implementation?
Ownership should sit inside your existing governance—typically Quality, Risk, or Compliance—working with IT/Data, Operations, and Regulatory Affairs. If AI risk lives only in a data-science or innovation team, it will not survive contact with inspections, incidents, or turnover.

Related Reading
• AI Governance & Trustworthiness:
ISO/IEC 42001 |
ISO/IEC TR 24028 |
GxP
• Risk & Quality Frameworks:
QRM |
QMS |
ISO 9001 |
ISO 13485 |
GAMP 5
• Validation & Data Integrity:
CSV |
VMP |
Audit Trail |
Data Integrity |