Wiki · Concept · Last reviewed July 1, 2026

ISO/IEC 23053

ISO/IEC 23053:2022 is an international framework standard for describing artificial intelligence systems that use machine learning, including their components, functions, interfaces, lifecycle context, and place in the broader AI ecosystem.

Category: AI governance Published: June 25, 2026 Modified: July 1, 2026 Last reviewed: July 1, 2026 Tags: ISO, IEC, machine learning, AI governance, standards

Definition

ISO/IEC 23053:2022, Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML), is an International Standard from ISO and IEC. ISO lists it as Edition 1, published in June 2022, with ISO/IEC JTC 1/SC 42 as the responsible technical committee. The ISO page marks the standard as published and identifies it as a 36-page document.

The standard gives a conceptual framework and shared terminology for describing AI systems that use machine learning. ISO's public summary says it defines components and functions of ML-based AI systems inside the broader AI ecosystem, with the aim of helping both technical experts and non-specialists describe these systems in a structured and consistent way.

Its practical role is descriptive. It helps an organization state what the AI system is before arguing whether it is safe, compliant, fair, effective, or worth deploying. That matters because AI products are usually systems, not isolated model files: data sources, training processes, runtime infrastructure, interfaces, humans, monitoring, updates, and downstream services all affect behavior.

Snapshot

Current Context

As of this review on July 1, 2026, ISO and IEC list the base ISO/IEC 23053:2022 standard as published. ISO also lists two amendments to the base standard as under development: ISO/IEC 23053:2022/DAmd 1, Amendment 1: Generative AI, and ISO/IEC 23053:2022/AWI Amd 2, Amendment 2. The ISO page for Amendment 1 says it is a Draft Amendment in the enquiry phase and at close-of-voting stage; the page for Amendment 2 says it is an approved work item at the new-project stage.

Those amendment pages are important current context, but they should not be cited as if they were already part of the published base standard unless and until ISO/IEC publishes them. They show that the framework is being extended for generative AI, while the stable citation for the base framework remains ISO/IEC 23053:2022.

The standard is also part of a denser AI-standards stack than it was at publication. By 2026, organizations commonly need to connect system description to ISO/IEC 23894 risk management, ISO/IEC 42001 AI management systems, ISO/IEC 42005 impact assessment, ISO/IEC 5259 data quality, and the NIST AI Risk Management Framework. ISO/IEC 23053 is the map of the system; those adjacent frameworks ask what evidence, controls, and decisions attach to the map.

Scope

ISO/IEC 23053 is a description standard, not a certification badge, risk score, safety case, or legal permission slip. Its value is that it gives teams a common system map before they argue about risk, impact, procurement, or assurance. If a buyer, auditor, regulator, engineer, and product owner use different words for the model, data pipeline, human interface, monitoring process, or deployment environment, the governance conversation is already unstable.

ISO says the standard is intended for organizations of any size or sector that design, develop, deploy, or evaluate AI systems using machine learning. It also says deep learning is covered because deep learning is a subset of machine learning. That makes the entry relevant to contemporary generative-AI systems, but it does not turn a framework document into proof that a specific model or agent is trustworthy.

For governance, the useful unit is the deployed AI system, not the most visible model brand. A system description should capture training or adaptation data, model artifacts, prompts, retrieval stores, evaluation data, runtime services, user interface, APIs, tool access, monitoring, human oversight, update process, and third-party dependencies where those components materially affect behavior.

Boundary Tests

Relationship to Other Standards

ISO/IEC 23053 sits between terminology and governance. ISO/IEC 22989 establishes AI terminology and concepts. ISO/IEC 23053 uses that kind of shared vocabulary to describe ML-based AI systems. ISO/IEC 23894 then gives AI risk-management guidance, ISO/IEC 42001 specifies an artificial intelligence management system, ISO/IEC 42005 gives AI system impact-assessment guidance, and ISO/IEC 42006 addresses bodies that audit and certify AI management systems.

That sequence matters. A serious organization should not jump from "we use AI" to "we have governed AI" without first describing the system. The descriptive layer names what exists: data sources, ML components, operating context, interfaces, humans in the loop, deployment boundaries, and evaluation hooks. The governance layer decides what to do about those things.

The standard also sits near lifecycle and supply-chain records. A lifecycle process can say when the system is designed, acquired, operated, monitored, changed, or retired. An AI Bill of Materials can identify concrete components and suppliers. ISO/IEC 23053 helps those records avoid a basic error: treating the model as the whole system.

Governance and Safety

The strongest use of ISO/IEC 23053 is system inventory discipline. A model-mediated service is rarely just a model. It may include training data, evaluation data, feature pipelines, prompts, retrieval indexes, ranking logic, model routers, monitoring dashboards, human escalation, access controls, third-party APIs, logs, and post-deployment update paths. A shared framework pushes the organization to identify the whole AI system rather than governing the visible chatbot or score alone.

For agents, the need is sharper. An ML component may sit inside a workflow that can read files, call tools, spend money, send messages, or write to institutional records. ISO/IEC 23053 does not solve agent authorization or prompt injection. It helps identify the components and functions that later controls must govern. The standard becomes useful when it forces the question: which part of the system made the decision, which part took the action, and which part preserves evidence?

For safety work, the key implication is traceability across boundaries. A system map should distinguish model inference, retrieval, ranking, tool selection, human approval, credential use, logging, monitoring, and escalation. If those functions are collapsed into "the AI," incident reviewers cannot tell whether failure came from data, model behavior, interface design, tool authorization, human workflow, or a vendor update.

Evidence Record

An ISO/IEC 23053-informed system description should identify the AI system boundary, ML components, data sources, model-development path, evaluation setup, deployment context, human roles, external services, monitoring signals, update process, and retirement or rollback conditions. For high-impact deployments, it should also distinguish the model artifact from the surrounding product, operator workflow, user interface, and organizational policy.

The practical test is reconstructability. If a system fails, a reviewer should be able to trace what was in the AI system, what was outside it, what evidence existed before deployment, and which assumptions connected the technical components to the human process.

Limits

Descriptive, not dispositive. A clear map can still describe a dangerous system. ISO/IEC 23053 supports governance, but it does not decide whether a use case is justified, lawful, accessible, fair, secure, or proportionate.

Paid standard, partial public text. ISO and IEC publish title, status, summary, page count, committee, and lifecycle metadata publicly, but the full standard text is not freely available from ISO/IEC. Public summaries should not be treated as a substitute for the full document in formal conformity, procurement, or audit work.

Fast-moving architecture. Generative AI and agent systems often add prompts, retrieval, tool access, memory, policy layers, and vendor updates after an initial system map is written. A static description can become false evidence unless it is tied to change management.

Certification overclaim. ISO/IEC 23053 is not a certification scheme. Claims that a product is "ISO/IEC 23053 compliant" should be treated cautiously unless they specify the reviewed system boundary, evidence, reviewer, and decision consequence.

Source Discipline

Use the official ISO and IEC pages for the title, reference number, publication date, edition, committee, status, page count, public summary, and ISO's description of scope. Use ISO/IEC 22989 for terminology claims, ISO/IEC 23894 for AI risk-management claims, ISO/IEC 42001 for AI management-system claims, ISO/IEC 42005 for impact-assessment claims, ISO/IEC 42006 for certification-body claims, and ISO/IEC 5259 for data-quality claims. Do not cite ISO/IEC 23053 as evidence that a deployed AI system is safe; cite it as a framework for describing what the system is.

For current claims, preserve amendment status. ISO/IEC 23053:2022/DAmd 1 and ISO/IEC 23053:2022/AWI Amd 2 are under development on the ISO pages reviewed for this entry. They are useful signals about generative-AI and future framework work, not final base-standard text.

Spiralist Reading

ISO/IEC 23053 is a map ritual. Before an institution can govern the machine, it has to say where the machine is. The danger is not only that AI systems are opaque. It is that organizations routinely misname them: calling a workflow a model, a vendor integration a feature, a monitoring gap a launch issue, or an agent action a user action.

Spiralism reads the standard as a check against that drift. A named system can still be dangerous, unfair, brittle, or unnecessary. But an unnamed system cannot be seriously audited. The first governance act is drawing the boundary clearly enough that responsibility has somewhere to land.

Open Questions

Sources

Return to Wiki