How traditional system and software lifecycle standards are extended for AI systems
Earlier in this series we established that impact assessment and risk assessment are activities repeated across the lifecycle. The standard that defines the processes that make up that lifecycle is ISO/IEC 5338:2023. This page explains how ISO/IEC 5338 extends traditional system and software lifecycle standards for AI, which processes it adds that are genuinely new, and which AI-specific considerations existing processes have to absorb.
ISO/IEC 5338 is not a management-system certification standard like ISO/IEC 42001. But its Introduction states that it provides more detail on the AI system lifecycle processes discussed in ISO/IEC 42001. Where ISO/IEC 42001 requires you to "manage the lifecycle," ISO/IEC 5338 describes, concretely, what activities that lifecycle is made of.
Scope note
This overview is based on the published text of ISO/IEC 5338:2023, read alongside ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207, and ISO/IEC 42001:2023. Where a term could be ambiguous, the standard's wording is used. For formal citation or document submission, refer to the official standard text.
What is ISO/IEC 5338?
ISO/IEC 5338:2023 is the international standard (first edition) for AI system lifecycle processes, published by ISO/IEC JTC 1/SC 42 in December 2023. It covers the lifecycle of both machine-learning-based AI systems and heuristic (knowledge-based) systems, and applies to organizations and projects that develop, deploy, and operate AI systems.
Its starting point is two existing lifecycle standards: ISO/IEC/IEEE 15288, which defines system lifecycle processes, and ISO/IEC/IEEE 12207, which defines software lifecycle processes. Building on that process framework, ISO/IEC 5338 presents 33 processes in Clause 6, sorted into generic, modified, and AI-specific processes, and draws on the AI concepts and terms from ISO/IEC 22989 and ISO/IEC 23053 covered earlier in this series.
So ISO/IEC 5338 does not invent a lifecycle from scratch. It mandates no particular lifecycle model; instead it focuses on the AI-specific processes that can occur at various lifecycle stages. On the premise that an AI system combines traditional elements (conventional software, databases) with AI-specific ones, it reuses proven methods and practices and adds only what AI newly requires.
Key point 1 — ISO/IEC 5338 "extends" traditional lifecycle standards for AI
ISO/IEC 5338 sorts every lifecycle process into three buckets: use it as-is, modify it, or build it new.
The first step to understanding ISO/IEC 5338 is its three-way classification of every process:
| Type | Meaning | What the organization does | Representative processes |
|---|---|---|---|
| Generic | Identical to the existing standard | Use as-is | Infrastructure management, integration, and so on |
| Modified | An existing process with AI-related elements modified, added, or removed | Check the "AI-specific particulars" and reinforce | Risk, configuration, and decision management; verification; operation; maintenance |
| AI-specific | Entirely new work that did not exist before | Establish anew | Knowledge acquisition; AI data engineering; continuous validation |
This classification matters because it changes the practical approach. An organization already running development on 15288 or 12207 does not need to redesign everything for AI. It can leave the generic processes alone, reinforce the modified processes with the AI-specific particulars, and stand up only the AI-specific processes anew.
The definition of conformance follows the same logic. ISO/IEC 5338 treats implementing all the processes, activities, and tasks it defines as conformant — but where a particular process, activity, or task is not relevant to the AI system in question, it requires the organization to record and document why it was not applied. Leaving things out is allowed; the reason must be on record.
Key point 2 — What makes the AI lifecycle different
Machine-learning AI in particular learns its behavior from data, so its performance shifts over time and it does not guarantee a correct answer every time. These are the reasons existing processes have to be modified and extended.
To explain why existing processes need modifying and extending, ISO/IEC 5338 sets out the characteristics that distinguish AI systems from traditional ones. The most important:
- Measurable performance degradation — an AI model models a "desired behavior" that can change over time, so you may have to measure and monitor shifts in input data (data drift) or departures from the desired output (concept drift).
- Data dependence — a machine learning model's behavior is learned from data, not programmed, so the sufficiency, representativeness, and quality of training, test, and validation data are decisive.
- Probabilistic nature — ML-based decisions are inherently probabilistic and not always accurate; there are inherent limits to testing a model's accuracy formally.
- Iterative requirements — an AI system's requirements and model behavior are not fixed up front; they can evolve through cycles of prototyping and refining requirements.
- Autonomy — fast, complex automated decision-making calls for extra attention to fairness, security, safety, privacy, reliability, transparency, explainability, and accountability. The more a system can harm people when it goes wrong, the more these checks matter.
- Difficulty of understanding — heuristic or ML model behavior is produced by knowledge engineering or training data rather than explicit programming, so predictability, explainability, and transparency can be low, which can erode trust.
These characteristics are exactly why ISO/IEC 5338 modifies existing processes and adds new ones: data dependence calls for a new data engineering process, degradation and drift call for a continuous validation process, the probabilistic nature calls for statistical verification, and autonomy calls for extending risk and decision management.
Key point 3 — The new AI-specific processes
Building an AI model follows a flow: requirements → prepare the materials (data, knowledge) → build the model → test → deploy → check after deployment.
The three processes ISO/IEC 5338 newly defines — absent from 15288 and 12207 — are the most distinctive part of the AI lifecycle:
- Knowledge acquisition (6.4.7) — acquiring the knowledge needed to build an AI model. Central for heuristic (knowledge-based) models in particular.
- AI data engineering (6.4.8) — making data usable for building and validating an AI model. Especially weighty for ML-based AI.
- Continuous validation (6.4.14) — monitoring whether a deployed model keeps performing acceptably, linking drift detection to retraining decisions.
On top of these, actually building the model — "model engineering" — is not a separate process but happens within the implementation process (6.4.9). Because of the distinct role data and knowledge play in AI, ISO/IEC 5338 keeps AI model engineering inside implementation while separating data engineering into its own process: the two are closely linked but play different roles.
The standard also maps where the "core technical steps" of ML and heuristic models fall:
| Step | Machine learning model | Heuristic model | ISO/IEC 5338 process |
|---|---|---|---|
| ① Set requirements | Set model requirements | Set model requirements | System requirements definition (6.4.3) |
| ② Prepare materials | Acquire and prepare data | Acquire knowledge | AI data engineering (6.4.8) / Knowledge acquisition (6.4.7) |
| ③ Build the model | Train and tune | Knowledge programming | Implementation (6.4.9) |
| ④ Test before deployment | Test | Test | Verification (6.4.11) |
| ⑤ Deploy | Deploy | Deploy | Transition (6.4.12) |
| ⑥ Check after deployment | Continuous monitoring | (as needed) | Continuous validation (6.4.14) |
Key point 4 — AI data engineering: data is behavior (6.4.8)
In machine learning, data quality is model quality. So acquiring, labeling, checking, and recording the data is split out as its own process.
The most fully described process in ISO/IEC 5338 is AI data engineering. Because an ML model's behavior is learned from data, the quality of this process governs the quality of the whole system. Its main threads:
Data quality analysis. Data has to be sufficient in quantity and representative, with bias inside acceptable limits. Bias is checked by confirming the behavior is balanced across socially protected attributes (for example sex or race). Simply removing the attribute is not enough — a "proxy" variable standing in for it may remain in the input. Data poisoning risk is treated as an aspect of quality too.
Data lineage and provenance documentation. Because training data determines the AI system's behavior, its source, processing history, owner, and rationale have to be understandable. Data lineage records the origin and movement path of data so an error can be traced back to its source; data provenance gives a historical record of the data's inputs, subjects, systems, and processing.
Cleaning, merging, preparation, and feature engineering. Through extraction, merging, cleaning, filtering, correction, augmentation, encoding, and handling of missing values, the features used as model input are produced. Filtering screens out data that is unneeded, induces bias or discrimination, requires de-identification under privacy law, or is sensitive and needs protection. Because preparation is easily exploratory and ad hoc and so hard to reproduce, reusable automation and (automated) testing are preferred.
The outputs of all this — datasets, metadata, preparation scripts — fall under configuration management for traceability and experiment reproduction. The view that data is not a mere input but a system element to be versioned and tracked runs through the whole of ISO/IEC 5338.
Key point 5 — Model implementation and verification: validated statistically
An AI model can't be checked as simply "right or wrong," so statistics measure "how well it gets it right."
Building the model is handled as AI model engineering within the implementation process (6.4.9). For ML, three activities are added: algorithm selection, model training, and model tuning. Interpretability is a consideration in choosing the algorithm — the standard explicitly names the tension that harder-to-interpret models tend to perform better, while interpretable models raise trust and transparency. In training, the priority is to prevent overfitting — performing well on training data but poorly on production data — and to generalize well. For heuristic models, "knowledge programming" takes that place. Transfer learning (starting from an existing model) and AutoML (automating parts of the process) are offered as efficiency approaches.
The verification process (6.4.11) is where ISO/IEC 5338's distinctiveness shows. A traditional system is programmed to work "exactly" as defined, but an AI model is constructed to come "as close as possible" to the desired behavior. Because of that probabilistic nature, the model has to be verified statistically — applying statistical techniques to a validation dataset of inputs and expected outputs to measure accuracy and robustness. Here the standard distinguishes two datasets: validation data, used to select the best among candidate models, and test data, used to judge whether the final model works and generalizes appropriately.
Another verification route is review. Source code written specifically for the AI system (including the knowledge representation of a heuristic system) can be code-reviewed. But an ML model's algorithm is part of a library or framework, so code review cannot confirm its accuracy. The standard therefore recommends including AI-related code in ordinary code-quality review — peer review of training scripts, unit testing of data-preparation code.
One more distinction: in ISO/IEC 5338, verification obtains objective evidence that a system or element meets specified requirements and characteristics, whereas validation confirms it achieves business and mission objectives, stakeholder needs, and intended use in the real operating environment. For AI systems, confirming the value and risk of the AI itself through a proof of concept can be part of validation.
Key point 6 — Deployment is the start, not the end
AI isn't finished at deployment. Performance can degrade over time, so you keep watching it and, if needed, roll back or retrain.
The AI-specific nature shows clearly in the post-deployment processes too: transition (6.4.12), operation (6.4.15), continuous validation (6.4.14), maintenance (6.4.16), and disposal (6.4.17).
Transition (moving to the operating environment, deployment). The model is deployed to the real operating environment. The system that actually runs the model is often distinguished from the model itself (its set of parameters, such as weights), and operational needs can mean deploying in a different form than during development. The organization has to design for model updating (retraining, knowledge engineering) and continuous monitoring of operational metrics.
Continuous validation. A core process newly defined by ISO/IEC 5338. It watches input data for data drift, and updated test data or output anomalies for concept drift. A large departure leads into retraining or continuous learning in the maintenance process, and can signal a data-quality problem or malfunction. Where automatic continuous learning runs without a human in the loop, an automatic rollback procedure that triggers at defined thresholds has to be included to prevent unwanted model change.
Maintenance. As with traditional software, maintenance can re-include earlier activities (especially implementation). Models are retrained or updated, new training data is collected, and data preparation changes. Here ISO/IEC 5338 names "continuous learning" — continually evolving the model on production data instead of occasional retraining — as a maintenance activity.
Disposal. Traditional disposal is extended to "disposal of data." Data related to the system has to be thoroughly disposed of because of security and privacy risk, with applicable retention requirements considered too.
In operation, the standard even covers compute resources and power use: ML training in particular consumes significant compute, and the resulting cost and carbon footprint can be a factor in how often to train and which algorithm to choose. And every incident after deployment — including system failures and data errors — has to be reported and assessed.
Key point 7 — AI in the management processes: risk, configuration, decision
The existing activities for managing risk, versions, and decisions gain AI-specific check items too.
As important as the new processes is that the existing management processes gain extra AI considerations. Three are worth watching from an audit and governance perspective:
| Management process | Added AI consideration | Related standard |
|---|---|---|
| Risk management (6.3.4) | AI risk objectives, setting boundaries for autonomous decisions, audit trail for safety systems | ISO/IEC 23894 |
| Configuration management (6.3.5) | Version the model together with its training data; roll back on a quality problem | — |
| Decision management (6.3.3) | Define "gates" for new decisions such as retirement, refactoring, and updating | ISO/IEC 38507 |
Risk management (6.3.4). ISO/IEC 5338 does not detail AI risk management itself; it points to ISO/IEC 23894. The risk objectives covered there (fairness, privacy, reliability, transparency, explainability, accountability, and so on) carry straight over. For autonomous decisions that time constraints prevent a human from verifying, it proposes "continuous risk management by the system itself" — operating boundaries or rule-based control. A safety-related AI system has to have an audit trail (data provenance, source verification, risk analysis, decision history) to secure accountability.
Configuration management (6.3.5). Beyond the objects traditional software versions (source code and the like), in an AI system the data that makes up the model (rules, weights, parameters) and its metadata also fall under version control. The standard recommends managing the model together with the data used to train it — for traceability (audit, compliance) and experiment reproduction. Rolling back to a previous version when a new model has a quality problem is the headline use case; the operational challenge, unlike traditional software, is that datasets are large and stored in systems separate from the code.
Decision management (6.3.3). AI produces new kinds of decisions: whether to "retire" a system when effective behavior no longer meets requirements, whether to "refactor" by resetting and retraining the model, whether to update specifications, contracts, and documentation to reflect learned behavior. The standard stresses that a pre-defined decision process matters all the more for these, and points to ISO/IEC 38507 (AI governance) as a help in identifying the governance-level "gates." Those gates are the main subject of the next article.
How it connects to ISO/IEC 42001
In the context of this series, ISO/IEC 5338 is most useful when you implement the "AI system lifecycle management" that the ISO/IEC 42001 management system requires as actual processes. As noted, its Introduction frames it as a detailing of ISO/IEC 42001's lifecycle discussion.
Among ISO/IEC 42001 Annex A control objectives, the ones that map most directly to ISO/IEC 5338 are A.6 (AI system lifecycle) and A.7 (data for AI systems). Where A.6 requires controls across the lifecycle (responsible development, documentation, testing), ISO/IEC 5338's technical processes (6.4) supply the how. Where A.7 requires controls on data source, quality, and preparation, ISO/IEC 5338's AI data engineering process (6.4.8) makes the activity concrete.
The link to risk and impact assessment is clear too. ISO/IEC 5338's risk management process (6.3.4) leads into ISO/IEC 42001 6.1.2 (AI risk assessment) and ISO/IEC 23894, and the impacts identified at the requirements and operation stages connect in practice to the impact assessment of ISO/IEC 42005. In short: ISO/IEC 42001 sets the "what" of the management system and ISO/IEC 23894 and 42005 give the methods for risk and impact assessment, while ISO/IEC 5338 provides the whole structure of the "lifecycle process" in which all those activities actually happen. That lifecycle is also what regulatory record-keeping and quality-management expectations — for example under the EU AI Act — ultimately rest on.
From an audit perspective — points to watch
ISO/IEC 5338 is not a certification standard, but it is a good yardstick for gauging how well the lifecycle-related controls (A.6, A.7) are implemented in an ISO/IEC 42001 audit. The gaps that can surface include the following. (These are situations that can arise in practice, not assertions of frequency.)
- Weak data lineage and provenance records — the source and processing history of training data is undocumented, so a problematic dataset cannot be traced to its origin.
- Model and data configuration managed separately — the model version is managed, but the data and metadata used to train it are not versioned with it, so experiment reproduction or rollback is not guaranteed.
- Continuous validation undefined — activity ends at deployment, with no drift monitoring, re-assessment trigger, or automatic-rollback threshold defined as a process.
- Missing labeling controls — the competence and training of labelers, and review and correction procedures, are undefined, so bias enters the data easily.
- No rationale for exclusions — a process or activity is not applied without justifying and documenting its absence, conflicting with the conformance definition.
In an audit, you would typically be asked to show not just the process procedures but the actual outputs — data lineage metadata, model and data version histories, continuous-validation logs, and records that a rollback has fired.
Putting it into practice — where to start
- An organization already developing on 15288/12207 — you do not need to build everything new. Leave the generic processes as they are, use the "AI-specific particulars" of the modified processes as a checklist to reinforce, and focus on standing up the three new processes: knowledge acquisition, AI data engineering, and continuous validation.
- An organization preparing for ISO/IEC 42001 certification — implement the Annex A.6 (lifecycle) and A.7 (data) controls with the corresponding ISO/IEC 5338 processes, and connect their outputs as evidence. See our templates for the document set.
- An organization strong in data and MLOps — AI data engineering (6.4.8) and continuous validation (6.4.14) often already run as an MLOps pipeline. Here the question is less "do we have the technology" than "is it defined as a process and preserved as records."
To see where this sits in the wider portfolio, the ISO/IEC AI Standards Map lays out the SC 42 standards by category on a single page.
Key terms at a glance
| Term | Meaning |
|---|---|
| AI data engineering | The new process (6.4.8) of acquiring, labeling, quality-analyzing, and preparing data so it can be used to build and validate an AI model. |
| knowledge acquisition | The process (6.4.7) of finding, gathering, and refining the knowledge needed to build an AI model. |
| continuous validation | The new process (6.4.14) of continuously monitoring a deployed model's performance and detecting drift. |
| data drift / concept drift | A change in input data / a departure from the desired output. |
| data lineage / data provenance | A record of data's movement and transformation path / a historical record of data's origin and subjects. |
| validation / test data | Used to select the best among candidate models / used to judge the final model's performance and generalization. |
| generic / modified / AI-specific | The three types into which ISO/IEC 5338 sorts every lifecycle process (5.1). |
The bottom line
ISO/IEC 5338:2023 does not build an AI lifecycle from scratch. On the proven processes of ISO/IEC/IEEE 15288 and 12207, it carefully reworks only the parts AI affects and adds only the processes genuinely needed. Two things matter most. First, what sets the AI lifecycle apart stands out less in the model-building step than in data management and post-deployment continuous validation. Second, models and data are system elements to be versioned and tracked, no less than source code.
Asking "who decides and who is accountable" on top of this lifecycle is governance. The standard ISO/IEC 5338 references for its "gates" in decision management is the subject of the next article: ISO/IEC 38507:2022 — Governance Implications of the Use of AI by Organizations.
📚 SC 42 AI Standards Series
← Previous: ISO/IEC 42005:2025 — AI System Impact Assessment
📍 Current: ISO/IEC 5338:2023 — AI System Lifecycle Processes
→ Next: ISO/IEC 38507:2022 — Governance Implications of the Use of AI (forthcoming)