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

ISO/IEC 5338 is the international standard that describes the life cycle processes for building, buying, running and retiring AI systems. Instead of inventing a new way of working, it takes the well-known system and software life cycle processes and shows what has to change, and what has to be added, when part of the system learns from data or reasons with encoded knowledge. It is used by engineering leads, data scientists, machine learning engineers, quality and risk people, and by organisations that acquire AI from suppliers. After this tutorial you will be able to explain its structure, recognise its three AI-specific processes, apply its ideas to a real project, and place it next to related AI and engineering standards.

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

Course overview

Edition and status: the current and only edition is ISO/IEC 5338:2023, Information technology — Artificial intelligence — AI system life cycle processes, Edition 1, published in December 2023 by ISO and the International Electrotechnical Commission (IEC) through their joint technical committee ISO/IEC JTC 1, subcommittee SC 42 (Artificial intelligence). The ISO catalogue lists it at stage 60.60 (International Standard published) with no amendment, revision or replacement in progress; the IEC webstore lists the same first edition (39 pages, dated 2023-12-20). Like every ISO standard it will be reviewed at least every five years, so its first systematic review falls due around 2028. Verified 2026-10-29 against the ISO committee catalogue entry and the IEC webstore record. The standard is a process description: it does not come with a certification scheme of its own.

Who it is for: engineering managers and architects who have AI components in their products; data scientists and machine learning engineers who want their work to fit into a disciplined engineering process; quality, security, risk and compliance professionals who must understand how an AI system is built and kept healthy; and procurement or vendor managers who acquire AI systems from suppliers. No background in AI standards is needed.

Prerequisites: none. It helps to know roughly what a software project looks like (requirements, design, build, test, release, operations). Machine learning terms are explained in Lesson 2.

Learning objectives. After this tutorial:

You will be able to explain why AI systems need adapted life cycle processes and what problem ISO/IEC 5338 solves.
You will be able to use the core vocabulary: AI system, life cycle stage, process, outcome, knowledge acquisition, AI data engineering, continuous validation, drift and tailoring.
You will be able to describe the four process groups and the three process types (generic, modified and AI-specific).
You will be able to walk through the AI system life cycle stages and say which processes matter most in each.
You will be able to explain what it means to "follow" or "conform to" ISO/IEC 5338 and how adoption can be checked, given that there is no dedicated certification.
You will be able to apply the standard step by step to a realistic AI project, from business analysis to disposal.
You will be able to position ISO/IEC 5338 next to ISO/IEC/IEEE 15288 and 12207, ISO/IEC 22989, ISO/IEC 23053, ISO/IEC 23894 and ISO/IEC 42001.

Lesson 1 – Origins, purpose and scope

Why AI systems stretch traditional engineering processes

For decades, organisations that build complex systems have described their work as a set of life cycle processes. A process is a defined piece of work with a purpose and expected results: planning the project, defining requirements, designing the architecture, implementing, integrating, verifying, deploying, operating, maintaining and finally disposing of the system. Two international standards are the backbone of this way of thinking. ISO/IEC/IEEE 15288 describes the processes for whole systems (hardware, software, people and procedures together), and ISO/IEC/IEEE 12207 describes the processes for software. Many organisations, especially in aerospace, defence, automotive, health and government, use them as the reference for their own engineering handbooks.

AI systems challenge those processes in several ways. In a traditional program, an engineer writes the logic and can read it. In a machine learning system, much of the behaviour comes from training data: the engineer chooses an algorithm and data, and the training step produces a model whose internal rules nobody wrote by hand. The result is often probabilistic, so "correct" becomes a statistical statement ("92 % of cases are classified correctly on representative data") rather than a yes-or-no test. Performance can decay after release because the world changes, even when nobody touched the code. New specialist roles appear (data scientists, data engineers, annotators), new resources are needed (large data sets, specialised compute) and new risks surface (unwanted bias, lack of transparency, use of personal data for purposes it was not collected for).

Teams reacted in two unhealthy ways. Some treated AI work as pure research, outside any engineering discipline: models were built in notebooks, handed over informally and never monitored. Others forced AI work into the classic process without adjustment, which failed because, for example, a test plan that expects deterministic answers cannot judge a model. ISO/IEC 5338 was written to bridge the gap: keep the proven life cycle processes, and add precisely the AI-specific changes.

Who wrote it and when

The standard was developed by ISO/IEC JTC 1/SC 42, the joint ISO and IEC committee responsible for AI standardisation. SC 42 also produced the AI vocabulary standard ISO/IEC 22989, the machine learning framework ISO/IEC 23053, the AI risk guidance ISO/IEC 23894 and the AI management system standard ISO/IEC 42001. ISO/IEC 5338 was published in December 2023 as a first edition.

Purpose

The standard's purpose is to give organisations a common, complete set of processes for the whole life of an AI system. Those processes support defining, controlling, managing, executing and improving the system across its life cycle stages. Because the processes extend the familiar ones, an organisation that already follows ISO/IEC/IEEE 15288 or 12207 can integrate AI work into its existing engineering system rather than running a parallel one. That integration brings efficiency, makes AI adoption easier and helps different stakeholders understand each other.

Scope

The scope covers AI systems based on machine learning and on heuristic systems. Heuristic systems are those that reason with encoded human knowledge, such as rule-based expert systems. The processes can be used by an organisation or a project that develops AI systems, and also by one that acquires them from a supplier. Importantly, an AI system is almost always a mix: a model sits inside an application with ordinary source code, databases, user interfaces and infrastructure. The standard says that the conventional elements can be handled with the normal processes from ISO/IEC/IEEE 15288 and 12207, while its own AI-specific guidance applies to the AI elements and to the system as a whole. Safety-critical AI, for example in health care or traffic control, needs additional attention beyond these general processes; SC 42's technical report on functional safety and AI systems (ISO/IEC TR 5469) is the companion document for that.

What the standard does not do is prescribe a development method. It does not tell you to use agile or waterfall, which tools to use, which algorithms to choose or what accuracy is good enough. It describes what needs to be achieved by each process and leaves how to the organisation.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 5338 reuses the vocabulary of ISO/IEC 22989 (AI concepts and terminology), ISO/IEC 23053 (framework for AI systems using machine learning) and the two life cycle standards. The terms below are explained in plain words; they are not the official definitions.

AI system – an engineered system that produces outputs such as predictions, recommendations, content or decisions for a given set of objectives, using techniques such as machine learning or encoded knowledge.
Machine learning (ML) model – the artefact produced by training an algorithm on data; at run time it takes inputs and produces outputs according to the patterns it learned.
Heuristic system – a system that solves problems with rules of thumb or encoded expert knowledge (for example, a rule-based expert system) rather than learning from data.
Life cycle – the evolution of a system from its conception through to its retirement.
Life cycle model – a framework of stages and processes that an organisation or project uses to organise the life cycle; for AI, ISO/IEC 5338 adopts the stage model of ISO/IEC 22989.
Life cycle stage – a period in the life of the system, such as inception, design and development, or operation and monitoring, with its own goals and decision points.
Process – a set of related activities that turns inputs into outputs; in this family of standards each process is described by its purpose, its outcomes and its activities and tasks.
Outcome – an observable result of performing a process successfully, such as "a training data set that meets the defined quality criteria is available". Outcomes are what an assessor looks for.
Knowledge acquisition – finding, collecting and refining knowledge and turning it into a form that a system can process. It is classic for expert systems, but also part of machine learning (for example, deciding what the labels mean).
AI data engineering – the work of obtaining, preparing, labelling, checking and managing the data used to train, validate, test and operate an AI system.
Training, validation and test data – three separate sets: training data teaches the model, validation data is used to tune it, and test data is held back to estimate how well it will perform on data it has never seen.
Continuous validation – the ongoing checking, while the system is in operation, that the AI system still performs as required, typically by monitoring its inputs and outputs and comparing performance against agreed thresholds.
Drift – a change over time in the input data (data drift) or in the relationship between inputs and the right answers (concept drift) that makes a once-good model less accurate.
Retraining – training the model again, usually with newer data that is more representative of current production conditions, to restore or improve performance.
Tailoring – adapting the processes (selecting, combining, adding detail or leaving parts out with justification) to fit a particular organisation or project.
Stakeholder – any individual or organisation with an interest in the system, including users, operators, affected people, regulators and the teams who build it.

Why vocabulary matters here

Life cycle standards are used to coordinate many people across organisations. When a buyer writes in a contract that the supplier must "validate the model before transition", both sides need the same meaning of validate and transition. In the 15288 family, verification asks "did we build the system right, according to its requirements?" while validation asks "did we build the right system, one that meets stakeholders' needs in its intended environment?". ISO/IEC 5338 keeps those meanings and adds continuous validation as a separate, ongoing activity after deployment. Remembering this distinction is one of the most useful things you can take from the standard.

Lesson 3 – Structure of the standard

The clauses

ISO/IEC 5338 is a compact document of about 40 pages. Its main clauses are:

Clauses 1 to 4 – scope, normative references, terms and definitions, and abbreviations. The normative references are ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207, ISO/IEC 22989 and ISO/IEC 23053, which means parts of those documents are needed to apply this one.
Clause 5, Key concepts – AI system concepts, the AI system life cycle model, and process concepts, including how processes were chosen, how each process is described and how conformance can be claimed.
Clause 6, AI system life cycle processes – the processes themselves, in four groups.
Annex A (informative) – observations drawn from the AI use cases collected in ISO/IEC TR 24030, showing how life cycle characteristics appear in real applications.

Four process groups

The process groups are the same four used in ISO/IEC/IEEE 15288, which makes the standard easy to map onto an existing engineering system. In total there are 33 processes.

Agreement processes (2) – acquisition and supply. They govern the relationship between a buyer and a supplier of an AI system or AI component.
Organizational project-enabling processes (6) – life cycle model management, infrastructure management, portfolio management, human resource management, quality management and knowledge management. They give projects the environment, people and policies they need.
Technical management processes (8) – project planning, project assessment and control, decision management, risk management, configuration management, information management, measurement and quality assurance. They steer a project.
Technical processes (17) – business or mission analysis, stakeholder needs and requirements definition, system requirements definition, architecture definition, design definition, system analysis, knowledge acquisition, AI data engineering, implementation, integration, verification, transition, validation, continuous validation, operation, maintenance and disposal. They build and run the system.

Three process types

The most useful structural idea in the standard is that every process is labelled with one of three types. This tells you how much of your existing practice you can keep.

Generic – the process is the same as in the system and software life cycle standards. Seven processes fall into this type: you apply them as you already do. According to the SC 42 overview of the standard, they are life cycle model management, infrastructure management, measurement, architecture definition, design definition, system analysis and integration.
Modified – the process exists in the traditional standards, but for AI systems some elements are changed, added or removed. Twenty-three processes are of this type. The standard explains the AI-specific considerations for each.
AI-specific – the process is new: it is needed because of the characteristics of AI systems and is not defined in the traditional standards. There are three: knowledge acquisition, AI data engineering and continuous validation.

Figure 2 – Every process is typed as generic, modified or AI-specific, which shows where existing practice can stay and where AI work changes it.

The numbers carry a message: most of good AI engineering is still good engineering. Only three processes are truly new, but most of the familiar ones need adjustment. A team that only adds an "ML step" to its pipeline and changes nothing else will miss most of the AI considerations, because they are spread across planning, risk, configuration, verification, operation and maintenance.

How each process is described

The life cycle standards describe a process by its purpose, its outcomes and its activities and tasks. ISO/IEC 5338 follows that pattern. For generic processes it points back to the source standard. For modified processes it describes what is different for AI, for example additional outcomes or activities. For the three AI-specific processes it gives a complete description. Readers should therefore keep ISO/IEC/IEEE 15288 or 12207 at hand: ISO/IEC 5338 is designed to be read with them, not instead of them.

The AI system life cycle model

Clause 5 adopts the life cycle stage model of ISO/IEC 22989. Stages are not the same as processes. A stage is a period of the system's life; processes are the work that happens, and most processes are used in several stages. The stages are summarised below and shown in Figure 3.

Inception – deciding whether there is a real need, whether AI is an appropriate answer and whether the idea is feasible.
Design and development – defining requirements and architecture, acquiring knowledge and data, building and training models and the surrounding software.
Verification and validation – checking that the system meets its requirements and is fit for its intended use.
Deployment – installing and releasing the system into its operational environment.
Operation and monitoring – running and maintaining the system and watching its behaviour.
Continuous validation – a stage that runs alongside operation where it applies, especially for systems that keep learning: repeatedly checking that the system still performs as required.
Re-evaluation – reviewing results against objectives and deciding whether to continue, change or stop.
Retirement – withdrawing the system, and dealing with its data, models and dependent processes.

In the ISO/IEC 22989 figure, a set of concerns runs across every stage rather than belonging to one: traceability, transparency and explainability; security and privacy; risk management; and governance. ISO/IEC 5338 also maps its processes onto the stages; for example, business or mission analysis and requirements definition belong mainly to inception, knowledge acquisition and AI data engineering to design and development, transition to deployment, and disposal to retirement.

Figure 3 – The AI system life cycle stages from ISO/IEC 22989: operation works with continuous validation and feeds re-evaluation, which can loop back to inception or development; retirement ends the life cycle.

The loop from re-evaluation back to inception or to design and development is what makes an AI life cycle feel different. A conventional system may stay stable for years after release. An ML system may need to be retrained several times a year because the data it sees in production no longer matches the data it learned from. The stage model makes that loop explicit and expected rather than an emergency.

Lesson 4 – How it works in practice

This lesson walks through the processes that matter most for AI work, beginning with the three AI-specific processes and then the modified processes where AI changes everyday practice. The descriptions are summaries in plain language, not the text of the standard.

The three AI-specific processes

Knowledge acquisition. Every AI system depends on knowledge: what the problem is, what counts as a correct answer, which factors matter, which rules experts use. In a heuristic system this knowledge is encoded directly as rules, usually with the help of a knowledge engineer who interviews domain experts and structures what they know. In a machine learning system the knowledge is partly in the data, but people still need to decide what the labels mean, which situations are typical or rare, and which domain constraints the model must respect. The process makes this explicit: identify sources of knowledge, collect it, refine and check it, and put it into a usable form. A practical artefact is a labelling guide written with domain experts, so that annotators label consistently.

AI data engineering. This is the largest AI-specific process and, for many projects, the largest share of the effort. It covers understanding data needs, finding and acquiring data, checking whether the organisation is allowed to use it for this purpose, exploring and cleaning it, labelling it, splitting it into training, validation and test sets, documenting its provenance and characteristics, and protecting it. It also covers data for operation: the input data the deployed system receives must be prepared in the same way as the training data, or the model will behave unpredictably. Typical artefacts are a data inventory, a data quality report, data sheets describing each data set and a record of where each item came from. Data quality itself is the subject of the ISO/IEC 5259 series, which can be used alongside this process.

Continuous validation. Traditional validation happens before release. For an AI system, the question "is this still fit for purpose?" must be asked again and again while it runs, because performance can drift. Continuous validation means defining what to watch (for example, input distributions, output distributions, error rates where ground truth becomes available, fairness indicators across groups), setting thresholds, monitoring, and triggering action when a threshold is crossed. It is especially important for systems that keep learning in operation, where the model changes without a formal release. Typical artefacts are a monitoring plan, dashboards, alert rules and periodic validation reports.

Figure 4 – Continuous validation is a loop in operation: monitored signals trigger analysis, a decision and controlled maintenance before monitoring resumes.

Modified processes: where AI changes everyday work

The twenty-three modified processes are where AI considerations quietly reshape familiar work. The following examples show the kind of changes the standard addresses; your tailoring decides how far to go.

Acquisition and supply – contracts for AI need to cover data (who provides it, who may reuse it), model performance criteria, how the model will be retrained, and what evidence the supplier must provide. A buyer who acquires a model without access to information about its training data will struggle to validate it.
Human resource management – AI projects need roles that may not exist yet, such as data scientists, data engineers, ML engineers and annotators, and the people around them need enough AI literacy to work with them.
Project planning and assessment – AI work is partly experimental. Nobody knows in advance whether the data will support the required accuracy. Plans therefore need explicit feasibility checkpoints and decision points instead of assuming a fixed path.
Risk management – new risk topics appear: unwanted bias, lack of transparency and explainability, use of data beyond the purpose it was collected for, robustness against unusual inputs and attacks on data or models. The detailed guidance for AI risk is in ISO/IEC 23894; ISO/IEC 5338 makes sure risk work is wired into the life cycle.
Configuration management – it is no longer enough to version source code. To reproduce or roll back a model you need versions of the training data, the data preparation code, the model, its hyperparameters and the training environment, and to know which combination is in production.
Quality assurance – quality includes model metrics such as accuracy, precision and recall, fairness indicators and robustness, not only defect counts.
Stakeholder and system requirements definition – requirements must state performance in statistical terms, describe the operating conditions in which the model is valid, set out the role of human oversight and include requirements for transparency and data.
Implementation – for AI elements this includes model engineering: choosing an approach, training, tuning and evaluating candidate models. Protecting training data is part of it, since real data is often sensitive in a way that synthetic test data for conventional software is not.
Verification and validation – tests must be statistical and use representative data the model has not seen; robustness, behaviour at the edges of the operating range and differences across groups need checking.
Operation and maintenance – operators need monitoring and a way to handle incidents caused by model behaviour; maintenance includes retraining, which is a planned, recurring activity rather than an exception.
Disposal – retiring an AI system includes deciding what happens to training data, models and logs, especially where personal data is involved, and to downstream processes that relied on the system's outputs.

Generic does not mean "irrelevant". Infrastructure management is generic, yet AI workloads may still need specialised compute, large storage and experiment-tracking tools; architecture definition is generic, yet a sensible AI architecture lets the model be monitored, replaced and rolled back without touching the rest of the system. The process itself is unchanged; the content you feed into it reflects the AI system.

Roles and artefacts

ISO/IEC 5338 does not prescribe job titles, but applying it usually involves an AI product owner (accountable for the use case and its value), a system or AI architect, data engineers and data scientists, software engineers, a quality or validation lead, risk and privacy specialists, operators and, for acquired systems, the supplier's corresponding roles. Typical artefacts include a business case with an AI suitability check, requirements with statistical acceptance criteria, a data plan and data sheets, a labelling guide, model documentation (sometimes called a model card), a risk register, configuration baselines linking data and model versions, verification and validation reports, a monitoring plan and a retirement plan.

Implementation steps for an organisation

Map your current engineering processes (often based on ISO/IEC/IEEE 15288 or 12207, or on an internal handbook) to the 33 processes of ISO/IEC 5338.
For each generic process, confirm that existing practice applies unchanged to AI projects.
For each modified process, review the AI considerations and update your procedures, templates and checklists.
Introduce the three AI-specific processes, assigning owners, tooling and artefacts.
Decide on tailoring rules: what a small internal pilot must do compared with a high-impact customer-facing system.
Train the people involved, pilot on one project, measure and improve.

Many practitioners also use the standard more lightly, as a checklist of AI attention points that their existing processes may have missed. That is a legitimate first step, as long as nobody mistakes it for full adoption.

Lesson 5 – Assessment, certification and compliance

There is no ISO/IEC 5338 certificate

ISO/IEC 5338 is not a management system standard and there is no accredited certification scheme for it. No certification body issues an "ISO/IEC 5338 certified" certificate under accreditation, and claims that suggest otherwise should be questioned. This is normal for life cycle process standards: ISO/IEC/IEEE 15288 and 12207 are also used mainly as references for internal process definition, contracts and process assessment, not for certificates.

What conformance means

Clause 5 of the standard explains how conformance can be claimed. In the style of its parent life cycle standards, an organisation states which processes it has adopted (possibly tailored) and demonstrates that it achieves their outcomes. Conformance is therefore about specific processes and evidence, not a single badge for the whole organisation. A claim such as "our ML platform team conforms to ISO/IEC 5338 for the AI data engineering, configuration management and continuous validation processes" is meaningful because it can be checked. A claim such as "we are 5338 compliant" without scope is not.

How adoption can be checked

Self-assessment and gap analysis – go through the 33 processes, compare current practice with the expected outcomes and AI considerations, and record gaps and actions.
Internal audit – sample real AI projects and check whether the evidence exists: is there a data plan, are data and model versions linked, is there a monitoring plan with thresholds, was there a re-evaluation decision?
Process assessment – organisations used to process capability assessment in the style of the ISO/IEC 33000 family can use life cycle processes as the reference and rate how well each process is performed and managed. This requires a suitable assessment model and trained assessors.
Second-party assessment – a buyer can ask a supplier to show how its AI life cycle covers the relevant processes, and can audit that as part of an acquisition.

Links to regulation and certifiable standards

Even without its own certificate, ISO/IEC 5338 is useful for compliance. ISO/IEC 42001, the AI management system standard, is certifiable and includes controls for the AI system life cycle; ISO/IEC 5338 provides the detailed process view that helps meet those expectations. Regulations such as the EU AI Act place obligations on providers of high-risk AI systems around data governance, technical documentation, record keeping, accuracy, robustness and post-market monitoring. A well-run AI data engineering process, configuration management of data and models and a continuous validation process produce much of the evidence such obligations call for. ISO/IEC 5338 is not, on its own, a legal compliance route: it is an engineering foundation that makes compliance work easier and more credible.

Evidence that convinces an assessor

Assessors look for outcomes backed by records. For AI work, the most persuasive evidence usually includes: a documented decision at inception that AI is suitable; requirements with measurable, statistical acceptance criteria; data sheets and provenance records; versioned links between data, code and models; verification and validation results on held-out representative data; a monitoring plan with owners and thresholds; logs of alerts and the decisions taken; and records of retraining and re-evaluation. Evidence produced as a by-product of daily work is more convincing than documents written just before an audit.

Lesson 6 – Worked example

Northfield Water is a mid-sized water utility that loses a significant share of its treated water through leaks and suffers several costly pipe bursts every winter. Its engineering department already follows a handbook based on ISO/IEC/IEEE 15288 for its control systems. The utility wants an AI system that predicts which pipe segments are most likely to burst in the next three months, so that crews can inspect and replace them first. It decides to use ISO/IEC 5338 to make the AI project part of its normal engineering system.

Step 1 – Inception: business analysis and stakeholder needs

The business or mission analysis process starts with the problem, not the technology. The team quantifies the cost of bursts, the current way of prioritising inspections (pipe age and a senior engineer's judgement) and the decision the AI output will support. They check suitability: is there enough historical data, and is a prediction actually actionable? Stakeholder needs come from crews, planners, the regulator, customers affected by water cuts and the data protection officer. Planners need a ranked list with reasons, not just a score; crews need a way to report back what they found. A decision is recorded to proceed to a feasibility phase with a clear stop condition: if a model cannot beat the current age-based ranking on historical data, the project stops.

Step 2 – Planning, people and infrastructure

Project planning is adapted for experimental work: the first eight weeks are a feasibility phase with a go or no-go decision. Human resource management identifies a gap: the utility has no data scientist. It hires one on contract and pairs them with an asset engineer. Infrastructure management sets up a separate analytics environment with experiment tracking, so that model runs are recorded from day one. Risk management opens an AI risk register, using ISO/IEC 23894 for guidance. Early risks include under-representation of old cast-iron pipes in the historical data, overreliance by planners on the ranking and use of customer complaint data, which contains personal information.

Step 3 – Knowledge acquisition

The data scientist runs workshops with senior network engineers. They capture which factors experts believe drive bursts (material, age, soil type, pressure changes, frost depth, previous repairs) and, crucially, what counts as a "burst" versus a minor leak. Different depots had recorded events differently. The output is a labelling guide and a short list of domain rules, for example that pipes already scheduled for replacement must still be ranked so planners can see the model agrees. The experts also explain known gaps: records before a system change ten years ago are unreliable.

Step 4 – AI data engineering

The team builds a data inventory: the pipe asset register, repair history, soil maps, pressure logger data, weather records and customer complaints. For each source they record ownership, permitted use and quality. The data protection officer agrees that complaint data can be used only after aggregation to pipe-segment level, with addresses removed. Cleaning reveals duplicate repair records and missing material codes for 8 % of pipes. Labels are applied consistently using the knowledge acquisition guide. The data is split by geography and time so that the test set contains districts and a winter the model has never seen, which gives a more honest estimate of real-world performance. Each data set gets a data sheet, and all versions are stored under configuration management.

Step 5 – Requirements, architecture and implementation

System requirements now state acceptance criteria in statistical terms: among the top 5 % of segments ranked by the model, the share that burst in the following quarter must be at least twice the share for the current age-based ranking, measured on the held-out winter. Further requirements cover explanations (the top three factors for each segment), human oversight (planners make the final decision and can override) and monitoring. The architecture separates the model service from the planning application so the model can be replaced or rolled back without touching the rest. Implementation includes model engineering: the team compares a simple baseline with two more complex models and chooses the one that meets the criteria with the most stable explanations.

Step 6 – Verification, validation and transition

Verification checks the system against its requirements: the ranking criterion on held-out data, explanation output for every segment, correct handling of missing inputs and behaviour across pipe materials, including the under-represented cast-iron group. Validation asks whether the system meets stakeholders' needs in real use: a two-month pilot in two depots runs the model alongside the existing process, and planners and crews give feedback. They report that explanations are useful but that the list needs to be filtered by depot. After the fix, the transition process moves the system into operation with training for planners, an operating manual and a rollback plan. Configuration management records exactly which data version, code version and model version went live.

Step 7 – Operation and continuous validation

The operation process runs the monthly ranking. Continuous validation tracks three signals: changes in the distribution of input features (for example, pressure patterns after a pumping station upgrade), the hit rate of inspections as crews report findings, and the share of planner overrides. Thresholds are agreed with the asset manager. In the second year, a district-metering programme changes how pressure is recorded and the input distribution shifts sharply. An alert fires; the analysis shows data drift, not a real change in risk. The maintenance process adapts the data preparation, retrains the model on recalibrated data, re-verifies it on the original criteria and transitions the new version through the normal release path.

Step 8 – Re-evaluation and, eventually, disposal

Each year a re-evaluation compares results with the original objectives: bursts and water losses on inspected segments, crew effort and any unfair concentration of service interruptions in particular neighbourhoods. The utility already knows that a future network-wide sensor system may make the current model obsolete. Its retirement plan states that the ranking service will be switched off only after planners have a replacement, that training data containing derived complaint information will be deleted according to the retention schedule, and that model versions and validation reports will be kept as engineering records for the regulator.

What the example shows

Northfield did not create a separate "AI method". It kept its 15288-based handbook, applied the AI considerations in the modified processes, and added the three AI-specific processes. The heaviest work was in data engineering and in setting up continuous validation, which matches the experience of most AI projects.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 5338 sits in a family of standards. It depends on some of them normatively and complements others. Understanding these relationships helps you avoid duplicated effort and gaps.

Standard / framework	What it covers	Relationship to ISO/IEC 5338
ISO/IEC/IEEE 15288	System life cycle processes for any engineered system	Parent standard: 5338 reuses its four process groups and process descriptions and extends them for AI
ISO/IEC/IEEE 12207	Software life cycle processes	Parent standard for software elements; conventional parts of an AI system can follow it directly
ISO/IEC 22989	AI concepts and terminology, including the AI system life cycle stages	Normative source of vocabulary and of the stage model used in 5338
ISO/IEC 23053	Framework for AI systems using machine learning (components and functions of an ML system)	Normative source for ML concepts such as data, model training and evaluation
ISO/IEC 23894	Guidance on AI risk management, built on ISO 31000	Provides the detail for the AI considerations in the risk management process
ISO/IEC 42001	AI management system requirements; certifiable	Sets organisation-level governance; 5338 gives the detailed life cycle processes that 42001 expects to be managed
ISO/IEC 5259 series	Data quality for analytics and machine learning	Supports the AI data engineering process with data quality models, measures and processes
NIST AI Risk Management Framework	Voluntary US framework for managing AI risk (Govern, Map, Measure, Manage)	Risk-focused; complements 5338, whose processes provide places in the life cycle to perform those risk functions

How the pieces fit together

A helpful way to picture the family is in layers. At the top, ISO/IEC 42001 sets up the organisation's governance of AI: policy, roles, objectives, risk and impact assessment, and continual improvement. In the middle, ISO/IEC 5338 describes the engineering processes through which each AI system is conceived, built, run and retired. Beside it, ISO/IEC 23894 deepens the risk process, and the ISO/IEC 5259 series deepens the data quality side of data engineering. Underneath, ISO/IEC 22989 and ISO/IEC 23053 provide shared concepts and vocabulary, while ISO/IEC/IEEE 15288 and 12207 provide the general process framework.

Figure 5 – ISO/IEC 5338 is the engineering layer: governance, risk and data guidance feed it, it builds on the life cycle and AI concept standards, and it shapes each AI system.

Relationship to MLOps practice

Many teams already practise MLOps: automated pipelines for data preparation, training, testing, deployment and monitoring of models. MLOps is a set of practices and tools, not a standard. ISO/IEC 5338 does not compete with it; it describes the outcomes that a mature MLOps setup should help achieve, and it adds the parts that pipelines alone do not cover, such as acquisition and supply, human resources, decision management, stakeholder needs, re-evaluation and disposal. A team can use ISO/IEC 5338 to check whether its MLOps platform covers the whole life cycle or only the technical middle of it.

Relationship to safety and sector standards

For safety-related uses, sector standards remain in force. A medical device with an ML component still follows the medical device software life cycle standard and risk management standard for that sector; an automotive function still follows the automotive functional safety and safety-of-the-intended-functionality standards. ISO/IEC 5338 can help those teams identify where AI changes their processes, and SC 42's technical report on functional safety and AI gives further guidance. It does not replace sector requirements.

Common pitfalls and best practices

Pitfalls

Treating AI work as research outside engineering. Models built in isolation and handed over informally miss requirements, configuration management and monitoring, and nobody owns them in operation.
Adding an "ML step" and changing nothing else. Twenty-three processes are modified; ignoring planning, risk, configuration, verification and maintenance changes leaves most AI considerations unaddressed.
Versioning code but not data and models. Without linked versions of data, code, model and settings, a team cannot reproduce a result, explain an incident or roll back safely.
Validating once and assuming the job is done. Performance at release says little about performance a year later; without continuous validation, drift goes unnoticed until users complain.
Testing on data that resembles the training data too closely. Random splits of data from the same period and places produce optimistic results that do not hold in new conditions.
Claiming "5338 certification". There is no accredited certification for this standard; vague compliance claims damage credibility with customers and auditors.
Forgetting disposal. Training data, models and logs may contain personal or sensitive data that must be handled when the system is retired.

Best practices

Start from your existing life cycle. Map current processes to the 33 processes, then adjust; this keeps one engineering system rather than two.
Write statistical acceptance criteria early. Agree how performance will be measured, on what data and against what baseline before building models.
Make data engineering a first-class process. Give it owners, plans, data sheets, provenance records and quality checks, and confirm the right to use each data source.
Plan for change. Design the architecture and release process so that retraining and rollback are routine, tested operations.
Define monitoring before go-live. Choose signals, thresholds and owners for continuous validation as part of the transition, not afterwards.
Tailor by impact. Apply more rigour to high-impact systems and record the reasons for lighter treatment of low-impact pilots.
Connect the family. Use ISO/IEC 23894 for risk detail, ISO/IEC 5259 for data quality and ISO/IEC 42001 for governance, so each standard does the job it is best at.

Summary and key takeaways

ISO/IEC 5338:2023 is the first and current edition of the international standard for AI system life cycle processes, published by ISO/IEC JTC 1/SC 42.
It extends ISO/IEC/IEEE 15288 and 12207 rather than replacing them, so AI work can live inside an organisation's existing engineering system.
It contains 33 processes in four groups: agreement, organizational project-enabling, technical management and technical processes.
Each process is typed as generic (7), modified (23) or AI-specific (3); most AI considerations are spread across the modified processes.
The three AI-specific processes are knowledge acquisition, AI data engineering and continuous validation.
The life cycle stage model comes from ISO/IEC 22989 and includes an explicit loop from operation and re-evaluation back to development, and a retirement stage.
There is no certification for ISO/IEC 5338; conformance is claimed for selected processes with evidence, and the standard supports certifiable schemes such as ISO/IEC 42001 and regulatory obligations.

Reflection questions

Think of an AI system in your organisation or one you use. Which of the three AI-specific processes is weakest for it today, and what would be the first improvement?
Pick two modified processes, such as configuration management and project planning. What would you change in your current procedure for each to handle AI elements?
How would you write a statistical acceptance criterion for an AI feature you know, and what baseline would you compare it with?
If a supplier offered you an AI component, which questions about data, retraining and monitoring would you put into the acquisition agreement?
A colleague says, "We passed validation last year, so the model is fine." How would you explain the role of continuous validation and re-evaluation to them?