ISO/IEC 23053: ISO/IEC 23053 – Tutorial (about 60 minutes)

ISO/IEC 23053 is the international standard that gives a common technical picture of an artificial intelligence (AI) system built with machine learning (ML): which parts such a system has, what each part does, which ways of learning exist and which phases turn raw data into a model that runs in production. Architects, data scientists, engineers, product owners, buyers, risk managers and auditors use it so they can describe, compare and question ML systems in the same terms. After this tutorial you will be able to break any ML-based system down into the components the standard names, place its development and operation on the ML pipeline, and use that description in design reviews, supplier questions and risk or impact assessments.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC 23053:2022, Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML), the first edition, published in 2022 by ISO and the International Electrotechnical Commission (IEC) through their joint technical committee ISO/IEC JTC 1, subcommittee SC 42 (Artificial intelligence). It is a published International Standard and no revised edition has replaced it. Its only normative reference is the AI vocabulary standard ISO/IEC 22989, and it has been adopted in Europe as EN ISO/IEC 23053. Two amendments are in progress: Amendment 1, Generative AI, is at the final draft (FDAmd) approval stage, registered in August 2026 and not yet published, and Amendment 2 was registered as a new work item in October 2025. This tutorial teaches the published 2022 text; check the ISO catalogue for published amendments before you rely on a detail. Verified 2026-10-29.

Who it is for: software, data and ML engineers, solution architects, product managers, quality and test professionals, security, privacy, risk and compliance staff, procurement teams and auditors who work with ML-based products and are new to formal AI standards. It is especially useful before you study ISO/IEC 5338 (AI life cycle processes), ISO/IEC 23894 (AI risk management) or ISO/IEC 42001 (AI management systems), because those documents assume you can describe an ML system clearly.

Prerequisites: none. You do not need to be able to write code or train a model. Each ML term is explained the first time it appears. If you have studied ISO/IEC 22989 you will recognise the vocabulary, but that is not required.

Learning objectives. After this tutorial you will be able to:

Explain why a framework for ML-based AI systems exists, what ISO/IEC 23053 covers and what it deliberately leaves out.
Describe an ML system in terms of its task, model, data and tools, and explain how a trained model differs from the algorithm that produced it.
Distinguish supervised, unsupervised, semi-supervised, self-supervised, reinforcement and transfer learning and choose a fitting approach for a problem.
Walk through the ML pipeline from data acquisition to operation and name the evidence each phase should produce.
Explain how the standard is used in design reviews, procurement, risk and impact assessments and audits, even though no one is certified against it.
Apply the framework to a realistic project and document it in a way other teams can review.
Relate ISO/IEC 23053 to ISO/IEC 22989, ISO/IEC 5338, ISO/IEC 23894, ISO/IEC 42001 and the NIST AI Risk Management Framework.

Lesson 1 – Origins, purpose and scope

Why ML systems needed a shared description

Ask five people to describe the same machine learning product and you may get five different pictures. The data scientist talks about a gradient-boosted tree with a certain accuracy. The platform engineer talks about a container that answers calls on an API. The product owner talks about a feature that "predicts churn". The risk manager wants to know where the training data came from, and the buyer wants to know what happens when the supplier retrains the model. Each view is correct, but none of them is complete, and the gaps between them are exactly where problems hide: data nobody checked, a model that silently drifted, a retraining step nobody approved, or a performance claim measured on the wrong data.

Traditional software engineering has well-known ways to describe systems: architecture views, interface specifications, requirements and test plans. ML systems need all of those, but they add something different. Part of their behaviour is not written by a programmer; it is learned from data. That means the data, the learning procedure and the measures used to judge the result are as much a part of the system as the code. A shared description therefore has to name those parts explicitly.

Where the standard comes from

In 2017 ISO and IEC created a joint subcommittee for AI, SC 42, inside JTC 1, their joint committee for information technology. Its plan was a family of AI standards covering vocabulary, risk, trustworthiness, data quality, life cycle processes, management systems and more. Two foundational documents came first and were published in 2022: ISO/IEC 22989, which defines AI concepts and terminology, and ISO/IEC 23053, which takes those concepts and builds a technical framework specifically for AI systems that use machine learning. A simple way to remember the pair is that 22989 gives the words and 23053 gives the picture.

Figure 1 – ISO/IEC 22989 supplies the vocabulary for the SC 42 family; ISO/IEC 23053 builds on it and is itself a normative reference of the life cycle (5338) and impact assessment (42005) standards.

What the standard is for

The scope of ISO/IEC 23053 can be summarised in three points. It establishes a framework for describing a generic AI system that uses ML technology. It describes the components of such a system and their functions, placing them in the wider AI ecosystem. And it is meant for every kind of organisation that implements or uses AI systems: companies of all sizes, government bodies and not-for-profit organisations. The word "generic" matters. The standard does not describe a particular product, cloud platform or algorithm; it describes the parts that every ML system has in some form, so that any specific system can be mapped onto it.

What it is not

ISO/IEC 23053 is a descriptive framework. It explains structures and concepts; it does not set requirements an organisation must meet, it contains no list of controls and it does not grade maturity. It does not tell you which algorithm to use, which library to install or what accuracy is good enough. It is not a risk management method (that is ISO/IEC 23894), not a set of life cycle processes (that is ISO/IEC 5338) and not a management system (that is ISO/IEC 42001). It also does not decide what is legal; regulations such as the EU AI Act do that. Keeping these boundaries in mind prevents a common mistake: treating a framework that helps you describe a system as if it were a checklist that proves the system is good.

Why you should care

The practical value of the standard is that it turns vague conversations into structured ones. If a design document, a supplier answer or an assessment report describes the task, the model, the data, the tools, the learning approach and the pipeline in consistent terms, reviewers can see what is missing. A security reviewer can ask where the training data is stored. A fairness reviewer can ask which population the test data represents. A buyer can ask who runs the retraining phase. Without a shared frame these questions are often never asked.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 23053 reuses the terminology of ISO/IEC 22989 and adds terms specific to machine learning. The definitions below are explanations in plain language, not the official wording; use them to understand the concepts, and consult the standards themselves when you need the exact text.

AI system – an engineered system that produces outputs such as predictions, recommendations, content or decisions for a given set of objectives. An ML system is one kind of AI system; rule-based expert systems are another.
Machine learning (ML) – the process of optimising the parameters of a model, by computation, so that the model's behaviour reflects patterns in data or experience rather than rules written by hand.
Task – the kind of problem the ML system is meant to solve, such as predicting a number, assigning a category or grouping similar items. The task links the business objective to a technical formulation.
ML algorithm – the procedure that determines how a model's parameters are learned from data, for example the procedure that grows a decision tree or adjusts the weights of a neural network.
ML model – the mathematical construct that produces an output (an inference) from input data. Before training it is a structure with parameters; after training its parameters hold what was learned.
Trained model – the result of applying an ML algorithm to training data: a model whose parameters are fixed and which can now be verified, deployed and used.
Parameter and hyperparameter – parameters are learned during training (for example the weights of a network); hyperparameters are chosen by people or tools before or around training (for example the learning rate or the depth of a tree) and shape how learning happens.
Training data – data used to train the model, that is, to fit its parameters.
Validation data – data used during development to tune hyperparameters and compare candidate models.
Test data – data held back and used only to estimate how the finished model performs on data it has never seen.
Production data – the real input data the deployed model receives during operation. Its statistical properties can drift away from those of the training data.
Feature – a measurable property of the input used by the model, such as a customer's tenure or the average pressure in a pipe last week. Feature engineering is the work of creating useful features from raw data.
Label – the known answer attached to an example in supervised learning, such as "defaulted" or "not defaulted".
Inference – the act of using a trained model to produce an output for new input; in many products this is called prediction or scoring.
ML pipeline – the connected sequence of phases that turns data into a trained, verified and deployed model and keeps it running, from data acquisition through modelling to operation.
Retraining – training a model again, usually with newer data, to restore or improve performance; when it happens automatically during operation it is often called continuous learning.

Three distinctions worth remembering

Algorithm versus model. The algorithm is the recipe; the trained model is the dish. Two teams can use the same algorithm and produce very different models because their data and hyperparameters differ. Reviews, documentation and contracts should therefore identify the trained model version, not only the algorithm name.

Development versus use. The model is created in a development context with training, validation and test data, but it does its real work in an operational context with production data. Many failures come from differences between the two contexts, which is why the framework treats operation and monitoring as part of the system rather than an afterthought.

System versus model. The model is only one component of the ML system. The system also includes data pipelines, pre-processing code, the serving infrastructure, user interfaces, monitoring and the human processes around it. An excellent model inside a badly designed system can still produce harmful results.

Lesson 3 – Structure of the standard

ISO/IEC 23053 is a compact document. After the usual opening clauses it is organised around three big ideas: the components of an ML system, the approaches to machine learning, and the ML pipeline. Knowing this structure helps you find your way in it and also gives you a ready-made outline for describing your own systems.

Opening clauses

Clause 1 sets out the scope described in Lesson 1. Clause 2 names ISO/IEC 22989 as the normative reference, which means its terms and concepts are needed to apply this document. Clause 3 adds ML-specific terms and definitions, grouped under model development and use, tools and data, and Clause 4 lists abbreviated terms. Clause 5 is an overview that introduces the framework and points out which later clauses go into more technical depth, because the document is written for non-practitioners as well as experts. Deep learning is treated as one of the ML methods the document addresses.

Clause 6 – The machine learning system

Clause 6 describes the main building blocks that every ML system has. The standard groups them broadly as follows (paraphrased):

Task – what the system has to accomplish. The standard describes common ML tasks: regression (predicting a numeric value), classification (assigning one of several categories), clustering (finding groups of similar items without predefined categories), anomaly detection (spotting unusual cases) and dimensionality reduction (compressing many variables into fewer), and it notes that other tasks exist. Choosing the task is the first technical decision and shapes everything after it.
Model – the construct that performs the task, and how it is developed and then used. The standard distinguishes the model as built during development from the trained model used in operation, and explains that the same task can be addressed by different kinds of models.
Data – the different roles data plays: training, validation, test and production data, plus the importance of data quality, representativeness and preparation. The framework makes clear that in ML, data is not just an input to the system; it shapes the system's behaviour.
Tools – the techniques that help build and run the system, in four groups: data preparation techniques (cleaning, transforming and engineering features), the main categories of ML algorithms, optimisation methods that adjust parameters (gradient descent is the best-known example), and evaluation metrics that tell you how well a model performs.

Figure 2 – The ML system components: a task defines what to learn, the algorithm turns data and a model structure into a trained model, evaluation checks it, and the deployed model turns production data into outputs.

Clause 7 – Machine learning approaches

Clause 7 explains the main ways an ML system can learn. The approach is chosen according to the task and, above all, according to the data available. Lesson 4 explains each approach in more depth; in summary the standard covers supervised, unsupervised, semi-supervised, self-supervised and reinforcement learning, and it explains transfer learning as a way to reuse what a model learned on one problem for another.

Clause 8 – The machine learning pipeline

Clause 8 describes the pipeline: the phases data and models pass through, from acquiring data, through preparing it and building models, to checking them, deploying them and operating them. It closes with an example ML process built on the pipeline, and an informative Annex A gives an example of how data flows and how data use can be documented in a supervised learning process. The pipeline is the part of the standard most practitioners recognise immediately, because it matches the way ML teams already work. Its value lies in making each phase, and the hand-overs between phases, explicit.

How the parts fit together

Think of the three big clauses as three questions. Clause 6 answers "what is this system made of?" Clause 7 answers "how does it learn?" Clause 8 answers "how does it get built and kept running?" A good description of any ML system answers all three. If a design document explains the model architecture in detail but says nothing about where production data comes from, you have found a gap in the Clause 6 view. If it describes training but not monitoring, the Clause 8 view is incomplete.

Lesson 4 – How it works in practice

Choosing a learning approach

The learning approach follows from the task and from what data you can realistically obtain. The standard's approaches can be understood like this:

Supervised learning – the model learns from examples that carry labels, so it can map inputs to known answers. It suits classification and regression when you have a reliable history of outcomes, for example past transactions marked as fraudulent or genuine. Its main cost is obtaining enough correct labels.
Unsupervised learning – the model learns structure from data without labels. It suits clustering, anomaly detection and dimensionality reduction, for example grouping customers by behaviour or flagging unusual sensor readings. Its outputs need human interpretation, because the model does not know what the groups mean.
Semi-supervised learning – a combination: a small labelled set and a large unlabelled set are used together. It helps when labelling is expensive, such as medical images that need an expert to annotate them.
Self-supervised learning – the model creates its own training signal from the data, for example by learning to predict a hidden word in a sentence or a missing part of an image. This is how many large language and vision models are pre-trained on huge unlabelled collections.
Reinforcement learning – an agent learns by acting in an environment and receiving rewards or penalties, gradually improving a policy that chooses actions. It suits sequential decision problems such as controlling a robot, tuning a process or managing traffic signals, and it needs a safe environment (often a simulation) in which to explore.
Transfer learning – knowledge a model gained on one task is reused for a related task, typically by taking a pre-trained model and fine-tuning it on a smaller, specific dataset. It reduces the data and computing needed, but it also imports whatever the original model learned, including its biases and blind spots.

Figure 3 – The learning approaches described in ISO/IEC 23053, with the kind of data or feedback each one depends on.

The ML pipeline phase by phase

The pipeline is where the framework becomes a working method. The phases below follow the standard's description in simplified form. For each one, think about who is responsible and what evidence the phase should leave behind.

1. Data acquisition. Data is identified, collected or obtained from internal systems, sensors, partners or public sources. Questions to answer here include: is the organisation allowed to use this data for this purpose, does it represent the population and conditions the system will face, and how will its origin (provenance) be recorded? Evidence: a data inventory, sources, licences or legal bases, and a description of known gaps.

2. Data preparation. Often called pre-processing in practice. Raw data is cleaned, transformed and prepared: duplicates are removed, missing values handled, formats aligned, features engineered, labels created or checked, and the data split into training, validation and test sets. This phase usually takes more effort than modelling and has a large effect on the result. Evidence: documented transformations, labelling instructions and quality checks, and the rules used to split the data so that test data stays truly unseen.

3. Modelling. Candidate models are chosen, trained with the ML algorithm and optimisation method, tuned through hyperparameters, and compared on validation data. Evidence: the experiments run, the hyperparameters chosen, the reasons for selecting the final candidate, and the exact versions of data and code used, so the training can be reproduced.

4. Verification and validation. The selected model is checked against its requirements. Verification asks whether the model was built correctly (for example, whether it meets the agreed performance measures on the test data); validation asks whether it is the right model for the intended use and users (for example, whether it behaves acceptably for different groups and in realistic conditions). Evidence: test results with the measures and thresholds agreed beforehand, results broken down by relevant subgroups, robustness checks and a sign-off decision.

5. Model deployment. The trained model is packaged and placed into the operational environment, together with the pre-processing it needs, so that it can receive production data. Evidence: the model version deployed, the configuration, the rollout method (for example a gradual rollout) and a rollback plan.

6. Operation. The model produces outputs for real use while its inputs, outputs and performance are monitored. Over time the world changes: customer behaviour shifts, sensors are replaced, a new product is launched. When production data no longer resembles the training data (data drift) or the relationship the model learned no longer holds (concept drift), performance falls. Monitoring detects this and triggers retraining, which sends the system back through the pipeline. Evidence: monitoring dashboards, alert thresholds, incident records and retraining decisions.

Figure 4 – The ML pipeline: data flows from acquisition to deployment, failed checks loop back to modelling, and monitoring in operation triggers new data collection and retraining.

Roles and artefacts

ISO/IEC 23053 is not a process standard, so it does not prescribe roles. In practice, however, the pipeline maps naturally onto the AI stakeholder roles in ISO/IEC 22989, such as the AI provider who offers the system, the AI producer who builds it, the AI customer who uses it and the AI partner who supplies data, tools or infrastructure. For each phase you should be able to say which organisation, and which person inside it, owns the work. Typical artefacts include a system description (task, model, data and tools), a data sheet for each dataset, a model card for each trained model version, test reports and a monitoring plan. None of these document names is mandated by the standard; they are a common, practical way of capturing the information its framework asks you to think about.

Implementing the framework in an organisation

Organisations usually adopt ISO/IEC 23053 in four steps. First, they add the framework's vocabulary to their internal glossary, aligned with ISO/IEC 22989. Second, they create a system description template whose headings follow the components and pipeline. Third, they require that template for new ML projects and for significant changes to existing ones, so reviewers always see the same structure. Fourth, they connect the description to their other processes: risk assessment, impact assessment, security review, procurement and change management. The framework then becomes the shared map that all those processes use.

Lesson 5 – Assessment, certification and compliance

There is no certification against ISO/IEC 23053

Because ISO/IEC 23053 describes rather than requires, there is no ISO/IEC 23053 certificate and no accredited certification scheme for it. A product or organisation cannot honestly claim to be "ISO/IEC 23053 certified". Be wary of any offer that suggests otherwise. What organisations can say truthfully is that their documentation or architecture is described using the ISO/IEC 23053 framework, or that a review checked their description against it.

How the standard is still used in assessments

Even without certification, the framework plays a real role in conformity and assurance work:

Management system audits. Organisations certified to ISO/IEC 42001 must understand and control their AI systems. Auditors often ask for system descriptions, data documentation and monitoring arrangements; a description structured along the 23053 components makes that evidence easy to follow.
Life cycle and impact work. ISO/IEC 5338 (AI system life cycle processes) and ISO/IEC 42005 (AI system impact assessment) both list ISO/IEC 23053 as a normative reference, so applying them properly includes using its concepts.
Risk assessment. ISO/IEC 23894 and the NIST AI Risk Management Framework both start by understanding the system and its context. Walking through the task, model, data, tools and pipeline phases is an efficient way to find where risks such as bias, drift, data poisoning or misuse can enter.
Procurement and supplier assurance. Buyers can structure questionnaires around the framework: which task and learning approach, which data sources and splits, which evaluation measures, who retrains and how changes are notified.
Regulatory documentation. Laws such as the EU AI Act require technical documentation for some AI systems, covering for example the data used, how the system was developed and how it is monitored. The framework does not satisfy legal obligations by itself, but its structure maps well onto such documentation.

What a reviewer looks for

When a description is reviewed against the framework, the questions are about completeness and consistency rather than pass marks. Is the task stated in a way that links to the business objective? Is the trained model identified by version? Are the roles of the different datasets clear, and is the test data really independent? Are the evaluation measures appropriate for the task and agreed before testing? Is every pipeline phase covered, including operation and monitoring? Does someone own retraining decisions? A useful review records each gap with a recommendation, for example "no subgroup results in the test report" or "retraining is automatic but no approval or rollback step exists".

Making claims carefully

If you write that a system "follows ISO/IEC 23053", say what that means: for example, that its documentation describes all the components and pipeline phases using the standard's concepts. Avoid wording that implies a quality or safety guarantee. The framework helps people see a system clearly; whether the system is accurate, fair, secure or lawful has to be shown with evidence and, where they exist, with requirements from other standards and laws.

Lesson 6 – Worked example

NorthRiver Water is a regional water utility with about 4,000 kilometres of pipes. Bursts are expensive and disruptive, so the asset team wants an ML system that ranks pipe segments by their likelihood of failing in the next twelve months, and a second capability that spots unusual pressure patterns that may indicate a leak. The data team has never documented an ML system formally, and the regulator has asked how investment decisions are made. The chief engineer decides to describe the project using ISO/IEC 23053.

Step 1 – State the tasks

The team writes down two tasks. Ranking pipes by failure likelihood becomes a classification task: for each segment, estimate the probability that it will fail within a year. Spotting unusual pressure patterns becomes an anomaly detection task. Writing the tasks this way immediately clarifies what success means: for the first, how well the predicted probabilities separate pipes that failed from those that did not; for the second, how many real leaks are caught and how many false alarms engineers must investigate.

Step 2 – Identify the data and its roles

The data inventory lists ten years of failure records, pipe attributes (material, diameter, age, soil type), traffic and ground-movement data, and minute-by-minute pressure readings from 600 sensors. For the classification task, past failures provide labels, so supervised learning fits. The team splits the history by time: years one to seven for training, year eight for validation and years nine and ten as test data, so the model is always judged on a period it has not seen. For anomaly detection there are very few labelled leaks, so the team chooses unsupervised learning on the sensor data, with the handful of known leaks used only to check results. Production data will be the current pipe register and the live sensor feed.

The data review finds two problems. Failure records before year four were kept in a different system and often lack the exact location, and sensors were installed mainly in urban districts. The team records both as known limitations: the model may be weaker for rural networks, and early records are used with caution.

Step 3 – Choose model, algorithm and tools

For classification the data scientists compare a logistic regression, which is easy to explain, with a gradient-boosted tree model, which captures more complex patterns. For anomaly detection they use a method that learns normal daily pressure profiles and flags large deviations. The tools section of the system description names the libraries, the optimisation method, the hyperparameter search and the evaluation measures agreed with the asset team before any testing: discrimination between failing and non-failing pipes, the share of next year's failures that fall in the top 10 % of the ranking, and the false-alarm rate per week for the leak detector.

Step 4 – Run the pipeline and keep evidence

The team follows the pipeline phases. In data acquisition it records sources and permissions. In data preparation it documents how missing pipe ages were estimated and how sensor gaps were filled, and it keeps the code under version control. In modelling it logs each experiment, and the gradient-boosted model performs best on validation data. In verification and validation it evaluates the selected model once on the test years: 58 % of the failures in the test period fall in the top tenth of the ranking, which meets the agreed threshold. Results broken down by district confirm the earlier suspicion that performance is lower in rural areas. The engineers also review the twenty highest-ranked pipes and judge the reasons plausible, which validates that the output is useful for their work.

The sign-off decision is to deploy, with a condition: for rural districts, the ranking is combined with engineering judgement and the limitation is shown on the dashboard. In deployment the model version, data version and configuration are recorded, and the previous manual ranking method is kept available as a fallback.

Step 5 – Operate, monitor and retrain

The monitoring plan checks monthly whether the distribution of pipe attributes and sensor readings has shifted, compares predicted with actual failures each quarter, and tracks the leak detector's alerts and the share confirmed by field crews. After a new sensor model is installed in one district, the false-alarm rate there doubles. Monitoring catches this within two weeks; the team retrains the anomaly model with the new sensor data, validates it again and redeploys it through the same pipeline. Retraining of the failure model is planned yearly and requires the asset manager's approval.

Step 6 – Use the description

The finished system description, organised by task, model, data, tools, approaches and pipeline, serves several audiences at once. The risk team uses it for an assessment following ISO/IEC 23894 and finds that a poisoned or corrupted sensor feed could hide a real leak, so it adds data integrity checks. The regulator receives a clear explanation of how investment priorities are informed. When the utility later buys a commercial leak detection service, procurement sends the supplier a questionnaire built on the same headings, and the answers can be compared side by side with the in-house system. None of this required a certificate; it required a shared, complete description.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 23053 is most useful when you understand where it sits among neighbouring documents. It is a technical foundation: other standards describe processes, risks, management controls or quality characteristics, and they rely on a clear picture of the ML system that this framework provides.

Standard or framework	Main purpose	Relationship to ISO/IEC 23053
ISO/IEC 22989	AI concepts and terminology	Its only normative reference: 23053 uses its terms and concepts and specialises them for ML; its stakeholder roles are a useful way to assign pipeline ownership.
ISO/IEC 5338	Life cycle processes for AI systems, based on ISO/IEC/IEEE 15288 and 12207	Describes the processes an organisation runs; references 23053 for the technical concepts those processes act on, such as data and model development.
ISO/IEC 23894	Guidance on managing AI risks, built on ISO 31000	Supplies the risk method; the 23053 description shows where in the system each risk can arise.
ISO/IEC 42001	Certifiable AI management system requirements	Sets organisational requirements; 23053-based system descriptions are useful evidence but are not themselves required by name.
ISO/IEC 42005	Guidance for AI system impact assessment	Lists 23053 as a normative reference; impact assessments need a clear description of the system being assessed.
ISO/IEC 5259 series	Data quality for analytics and ML	Goes deep on the data component that 23053 introduces, with quality measures and processes.
NIST AI Risk Management Framework	Voluntary US framework for managing AI risk (Govern, Map, Measure, Manage)	Its Map function asks you to understand the system and its context, which a 23053 description supports.

How to combine them

A practical combination looks like this. Use ISO/IEC 22989 for words and roles, ISO/IEC 23053 to describe each ML system, ISO/IEC 5338 to organise the work around it, ISO/IEC 5259 to manage data quality, ISO/IEC 23894 or the NIST AI RMF to assess risk, ISO/IEC 42005 to assess impacts on people and society, and ISO/IEC 42001 to run all of it as a management system that can be audited. Regulations sit on top and decide which obligations apply to which systems. ISO/IEC 23053 is the layer that makes every other layer concrete: without a shared picture of the system, processes, risk assessments and audits have nothing precise to attach to.

A note on generative AI

The 2022 framework was written before large generative models became mainstream, but its concepts still apply. A large language model is typically pre-trained with self-supervised learning, adapted with transfer learning and sometimes refined with reinforcement learning from human feedback; it has training data, a trained model, evaluation measures and an operational phase that needs monitoring. Topics such as prompts, retrieval of external content and the risks of generated output are not the focus of the 2022 text. Amendment 1 to ISO/IEC 23053, titled Generative AI, was at final draft stage when this tutorial was checked, which is why checking the current status matters.

Common pitfalls and best practices

Common pitfalls

Claiming certification. Describing a product as "certified to ISO/IEC 23053" misrepresents a descriptive framework that has no certification scheme.
Describing only the model. Documentation that covers the algorithm and architecture but not data sources, pre-processing, deployment and monitoring leaves most of the risk unexamined.
Letting test data leak. Reusing test data during tuning, or splitting time-ordered data at random, produces optimistic results that collapse in production.
Treating deployment as the finish line. Without monitoring for data and concept drift, performance decays quietly until a visible failure occurs.
Identifying the algorithm instead of the trained model. Saying "we use gradient boosting" says little; reviewers need the trained model version and the data it was trained on.
Choosing the approach before looking at the data. Planning supervised learning when reliable labels do not exist leads to weak models or expensive late changes.
Ignoring what transfer learning imports. A fine-tuned pre-trained model inherits the original model's biases and limitations, which must be assessed too.

Best practices

Use one description template. Structure every ML system description by task, model, data, tools, learning approach and pipeline phase, so reviewers always know where to look.
Agree evaluation measures before testing. Decide which measures and thresholds matter for the task and its users, then evaluate once on independent test data.
Break results down by subgroup and condition. Overall accuracy can hide poor performance for specific regions, populations or operating conditions.
Version everything. Record data versions, code, hyperparameters and trained model versions so any result can be reproduced and any deployment rolled back.
Assign an owner to each pipeline phase. Make clear who approves deployment and who decides on retraining, especially across organisations.
Plan operation from the start. Define monitoring signals, alert thresholds and a retraining procedure before the first deployment.
Connect the description to other processes. Feed it into risk and impact assessments, security reviews, procurement and change management instead of keeping it as a stand-alone document.

Summary and key takeaways

ISO/IEC 23053:2022 is the SC 42 framework for describing a generic AI system that uses machine learning; it builds on the vocabulary of ISO/IEC 22989.
It is descriptive: it has no requirements, no controls and no certification scheme, but it gives everyone a shared, complete picture of an ML system.
An ML system can be described through its task, model, data and tools; the trained model is only one component of the wider system.
The learning approach – supervised, unsupervised, semi-supervised, self-supervised, reinforcement or transfer learning – follows from the task and the data available.
The ML pipeline runs from data acquisition and data preparation through modelling, verification and validation and deployment to operation, with monitoring feeding retraining.
Training, validation, test and production data play different roles; keeping test data independent and watching for drift are essential.
The framework adds value when it feeds life cycle processes, risk and impact assessments, procurement and management system audits under standards such as ISO/IEC 5338, 23894, 42005 and 42001.

Reflection questions

Pick an ML-based feature you use or build. Describe its task, model, data and tools in one paragraph each. Which part was hardest to describe, and what does that tell you?
For the same system, which learning approach is used, and what would change if reliable labels suddenly became available or disappeared?
Which pipeline phase in your organisation has the weakest evidence today, and what single artefact would improve it most?
How would you detect that the production data of one of your models has drifted away from its training data, and who should decide what happens next?
If a supplier claims their AI product is "ISO/IEC 23053 certified", what questions would you ask, and what evidence would actually reassure you?