Skip to main content
Bureau of AI
Category: Model Lifecycle & MLOps

AI Lifecycle Processes (ISO/IEC 5338)

Also known as: ISO/IEC 5338, ISO/IEC 5338:2023, AI system life cycle processes
Simply put

ISO/IEC 5338 is an international standard, published in 2023, that describes the processes and concepts involved in the life cycle of AI systems built on machine learning and heuristic approaches. It provides a structured way to think about how AI systems are developed, engineered, and managed over time. It is a voluntary standard rather than a law, and it is commonly used to organize and improve engineering and management practices for AI systems.

Formal definition

ISO/IEC 5338:2023 is a standard issued by ISO and IEC that defines a set of processes and associated concepts for describing the life cycle of AI systems based on machine learning and heuristic systems. Per the available evidence, it is primarily used to structure and improve how AI systems are engineered and managed across their life cycle. It has been mapped against the NIST AI Risk Management Framework 1.0 through a published crosswalk, indicating areas of overlap; however, the specific process definitions, their scope boundaries, and their relationship to other lifecycle standards are not detailed in this evidence and should be confirmed against the standard text. As a voluntary international standard, it is distinct from binding law and from supervisory model risk management guidance, and it does not by itself establish regulatory obligations.

Why it matters

AI systems differ from traditional software in ways that complicate governance: they are trained on data that shifts over time, their behavior can degrade after deployment, and responsibility for them is often distributed across data science, engineering, and business functions. ISO/IEC 5338 matters because it offers a shared, structured vocabulary for describing what happens across an AI system's life cycle, from development through ongoing management. For organizations trying to move from ad hoc practices to repeatable, auditable processes, a recognized international standard can serve as a common reference point that engineering, risk, and compliance teams can align around.

Because ISO/IEC 5338 is a voluntary international standard rather than binding law or supervisory guidance, its significance is practical rather than regulatory. It does not by itself create legal obligations, and adopting it does not demonstrate compliance with any specific regulation. Its value lies in helping teams organize and improve how AI systems are engineered and managed, which can in turn support broader governance and risk objectives. Where the standard's process definitions overlap with other instruments, it can be used alongside them; the published crosswalk mapping it against the NIST AI Risk Management Framework 1.0 is one example of how organizations connect it to related, non-binding frameworks.

Professionals should be careful not to overstate what the standard delivers. The evidence available here confirms that ISO/IEC 5338 defines processes and concepts for the AI life cycle, but it does not detail the specific process boundaries, their exact scope, or how they interact with other lifecycle standards. Those details should be confirmed against the standard text itself before relying on them for design, audit, or assurance decisions.

Who it's relevant to

AI and ML engineering teams
Teams that build and maintain AI systems can use ISO/IEC 5338 as a reference for structuring and improving their engineering and management practices across the life cycle, helping move from informal workflows toward more repeatable processes. The standard's specific process definitions should be read directly, as they are not detailed in the evidence summarized here.
AI governance and policy specialists
Those responsible for organizational structures and oversight of AI systems may reference the standard as a voluntary common vocabulary for the AI life cycle. It is important to communicate internally that adopting it does not create regulatory obligations and does not substitute for compliance with applicable law or supervisory guidance.
Auditors and assurance professionals
Auditors evaluating AI development and management practices may find the standard useful as a structured baseline against which to assess process maturity. Because the evidence here does not spell out scope boundaries or individual process requirements, assurance conclusions should be grounded in the standard text rather than summaries.
Risk and compliance teams working across frameworks
Teams reconciling multiple AI governance references may benefit from the published crosswalk between ISO/IEC 5338 and the NIST AI Risk Management Framework 1.0, which identifies areas of overlap. This supports mapping efforts but does not make the two instruments interchangeable, and neither is binding law on its own.

Inside AI Lifecycle Processes (ISO/IEC 5338)

AI system lifecycle stages
ISO/IEC 5338 is commonly understood to describe processes spanning the AI system lifecycle, from inception and design through development, deployment, operation, and eventual retirement. The exact stage boundaries can vary in how organizations map them to their own practices.
Extension of established software lifecycle processes
The standard is generally positioned as building upon and adapting existing software and systems engineering lifecycle process frameworks, adding processes specific to the characteristics of AI systems (such as data-centric development and continuous learning behaviors) rather than defining lifecycle processes from scratch.
AI-specific process considerations
It typically addresses considerations that distinguish AI systems from conventional software, such as reliance on data, model training and evaluation, and behavior that may change over time. The intent, as commonly framed, is to help organizations structure activities around these characteristics.
Process-oriented rather than control-prescriptive framing
The standard is oriented toward describing lifecycle processes and activities. It is distinct from management-system requirements (such as those associated with ISO/IEC 42001) and from risk-management-specific frameworks; readers should confirm the precise scope against the published text.
Positioning within AI governance and model risk management
Lifecycle process definitions can support both AI governance (by clarifying organizational activities and accountability across stages) and model risk management (by providing structure for development, validation, monitoring, and decommissioning activities), though the standard itself is not a governance framework or a model risk management guidance instrument, and these functions should not be conflated.

Common questions

Answers to the questions practitioners most commonly ask about AI Lifecycle Processes (ISO/IEC 5338).

Does ISO/IEC 5338 replace or supersede existing model risk management frameworks like SR 11-7?
No. ISO/IEC 5338 is a voluntary international standard describing AI system lifecycle processes, whereas SR 11-7 is supervisory guidance issued for a specific regulatory and jurisdictional context (U.S. banking model risk management). They operate at different levels and are not interchangeable. An organization may reference lifecycle process concepts from ISO/IEC 5338 while still being obligated to meet the expectations set out in applicable model risk guidance. Treat them as potentially complementary rather than substitutes, and confirm which instruments actually bind your organization before relying on one to satisfy the other.
Is following ISO/IEC 5338 the same thing as having AI governance in place?
Not exactly. Lifecycle processes describe how AI systems are developed, deployed, operated, and retired, which is closer to the process and engineering dimension. AI governance typically concerns the organizational structures, roles, accountability, and oversight that sit above and around those processes. There is overlap, since defined lifecycle processes can support governance objectives, but implementing lifecycle process activities does not by itself establish the accountability and oversight arrangements that governance normally entails. The two should be aligned rather than conflated.
How does ISO/IEC 5338 relate to more general system and software lifecycle standards our organization may already use?
ISO/IEC 5338 is commonly positioned as addressing AI-specific lifecycle considerations that extend or adapt broader system and software lifecycle process concepts. In practice, organizations that already apply general lifecycle process frameworks may find it useful to map their existing process definitions against the AI-specific activities the standard describes, identifying where AI characteristics (such as data dependence and ongoing behavioral change) warrant additional or modified process steps. Verify the precise relationship in the current text of the standard rather than assuming a fixed mapping.
Where in the AI lifecycle should we place validation and monitoring activities?
Lifecycle process frameworks generally distinguish activities occurring before deployment from those occurring during operation. Validation-type activities are typically associated with development and pre-deployment stages, while monitoring is generally an ongoing operational activity that continues after a system is in use. Keep these conceptually distinct: pre-deployment assessment does not eliminate the need for post-deployment monitoring, particularly given that AI system behavior can change over time. How you assign these to specific process stages should follow the definitions in the standard and any applicable regulatory expectations.
How do we assign responsibility for lifecycle process activities across teams?
Lifecycle process descriptions define what activities occur, but they do not by themselves determine who is accountable. Organizations typically layer governance roles and defined lines of responsibility on top of lifecycle activities to establish ownership. Be careful not to assume that describing a process step also assigns accountability for it; that assignment is usually a governance decision. Where a first, second, and third line of defense structure is used, map each lifecycle activity to the appropriate line rather than collapsing the roles together.
Can we treat lifecycle processes as one-time, sequential steps that end at deployment?
That is a common pitfall. AI lifecycle process frameworks generally recognize that activities can be iterative and that operation, monitoring, maintenance, and eventual retirement continue after deployment. Treating the lifecycle as a linear path that concludes at go-live can leave post-deployment activities under-resourced. Plan for ongoing process activities across the operational life of the system, and define how and when systems are reassessed, updated, or retired, consistent with the process definitions in the standard.

Common misconceptions

ISO/IEC 5338 is a legally binding requirement that organizations must comply with.
As an ISO/IEC standard, it is generally a voluntary standard rather than binding law. It does not carry the force of regulation such as jurisdiction-specific legislation, and adopting it does not by itself establish legal compliance. Organizations should verify obligations against the laws and supervisory guidance applicable to their sector and jurisdiction.
ISO/IEC 5338 is interchangeable with ISO/IEC 42001, the NIST AI Risk Management Framework, or model risk management guidance such as SR 11-7.
These instruments differ in purpose, issuing body, and status. ISO/IEC 5338 is commonly framed as a lifecycle process standard; ISO/IEC 42001 is associated with AI management system requirements; the NIST AI RMF is a voluntary framework issued by a U.S. body; and SR 11-7 is supervisory guidance historically framed for banking model risk management. They may complement one another but are not substitutes, and their scopes should be kept distinct.
Following the lifecycle processes described in ISO/IEC 5338 eliminates AI or model risk.
Structured lifecycle processes are measures that can help identify, organize, and reduce risk, but they do not eliminate it. Residual risk typically remains after controls are applied, and lifecycle process adoption does not substitute for ongoing validation, monitoring, and independent oversight.

Best practices

Map the lifecycle stages described in the standard to your organization's actual AI development and operational practices, documenting where stage boundaries and responsibilities fall rather than assuming a single fixed structure.
Use the standard alongside, not in place of, complementary instruments (for example a management-system standard, a risk-management framework, or applicable supervisory guidance), keeping the distinct purpose and status of each clear.
Confirm the precise scope, definitions, and processes against the published text of ISO/IEC 5338 before relying on it for internal policy, since summaries may not capture all stage boundaries or process details.
Integrate lifecycle process activities with model risk management practices such as validation, ongoing monitoring, and decommissioning, while maintaining the distinction between governance activities and model risk controls.
Verify applicable legal and regulatory obligations for your sector and jurisdiction separately, treating adoption of the standard as a voluntary practice that supports but does not establish compliance.
Document residual risk and the limits of lifecycle process controls, ensuring stakeholders understand that structured processes reduce and manage risk rather than remove it.