ISO/IEC 5338 vs ISO/IEC/IEEE 15288: What Changes for AI System Engineering?

5338 extends the 15288 structure rather than replacing it

ISO/IEC/IEEE 15288 establishes a common framework of process descriptions for the life cycle of human-created systems, defined from an engineering viewpoint. Its scope is broad: a system may include hardware, software, data, humans, processes, procedures, facilities and materials. The standard organizes its processes into four groups: agreement, organizational project-enabling, technical management, and technical processes. The 2015 edition also includes processes that support the definition, control and improvement of the life cycle processes used inside an organization or project. A 2023 edition of 15288 now supersedes the 2015 edition.

ISO/IEC 5338:2023 narrows the lens to AI. It defines a set of processes and associated concepts for describing the life cycle of AI systems based on machine learning and heuristic systems. It is based on 15288 and the software counterpart, 12207, with modifications and additions of AI-specific processes from ISO/IEC 22989 and ISO/IEC 23053. As of November 2026, the 2023 edition is the published version in the ISO/IEC JTC 1/SC 42 catalogue.

The practical consequence is a division of labor within one system. ISO states that when an element of an AI system is traditional software or a traditional system, the 12207 software processes and the 15288 system processes can be used to implement that element. The 5338 processes apply to the AI elements. An architect does not choose between the standards. The architect decides which elements of a given system fall on which side.

Side-by-side view

The table compares the two standards on the dimensions that matter when deciding how to organize an engineering process model.

• Scope: 15288: human-created systems of any kind. 5338: AI systems based on machine learning and heuristic approaches.
• Structure: 15288: a common framework of process descriptions. 5338: built on the 15288 and 12207 process structure, not a standalone framework.
• AI-specific content: 15288: none by design. 5338: modifications and additions drawn from ISO/IEC 22989 and ISO/IEC 23053.
• Traditional elements inside an AI system: 15288 and 12207 can be used to implement them. 5338 is applied to the AI elements.
• Documentation content: 15288: information items are addressed by the companion standard ISO/IEC/IEEE 15289. 5338: evidence artifacts need to be defined per process by the adopting organization.
• Edition to confirm: 15288: 2015 and 2023 editions exist, and the 2023 edition supersedes the 2015 edition. 5338: the 2023 edition is the published version.

Mapping AI characteristics onto the four 15288 process groups

A process-level comparison is easiest to run by asking where AI characteristics put pressure on each 15288 group. Three characteristics recur in AI engineering: dependence on data, behavior that can change through continuous learning or retraining, and probabilistic outputs that cannot be fully specified in advance. The exact additions and modifications are defined in the text of 5338, and the mapping exercise should be done against that text. The questions below give the exercise a structure.

In technical processes, the questions concern requirements, design, verification and validation. Data is already a possible system element under 15288, so data is not new to the scope. What changes is how much of system behavior is determined by data rather than by authored logic, which affects what verification can demonstrate and how often it must be repeated. In technical management processes, the questions concern configuration, quality assurance, risk and measurement when behavior may shift after release. In organizational project-enabling processes, the questions concern infrastructure, human resources and quality management, including who holds the competence to own AI-specific activities. In agreement processes, the questions concern acquisition and supply when models, data or components come from outside the organization.

The output of this exercise should be a table of AI-specific additions, each with a named owner and a defined evidence artifact. Activities without an owner are the main risk, because the existing 15288 process model will not surface them on its own.

Adopting the AI-specific processes in an existing 15288 practice

Adoption works best as an extension of the current process model, not a parallel framework. Duplicated frameworks create conflicting ownership and make it harder to show an auditor a single account of how a system was engineered. The steps below keep the work bounded.

• Confirm the 15288 edition in use: Establish whether the process model follows the 2015 or 2023 edition, and check 5338's basis in 15288 against that edition.
• Decompose each AI system: Separate AI elements, where 5338 applies, from traditional software or system elements, where 15288 and 12207 apply.
• Inventory current process ownership: Record who owns each 15288 and 12207 process today, then map each 5338 addition or modification to an owner.
• Define evidence per process: Specify the artifact that shows each process outcome was met. 15289 information-item guidance is a reasonable reference for documentation content.
• Relate to the NIST AI RMF as a mapping exercise: The AI RMF and 5338 were developed independently with some shared foundations in ISO/IEC 22989. The NIST-hosted crosswalk highlights common areas but is not a statement of equivalence.
• Add harm identification explicitly: Lifecycle tracking does not necessarily identify or manage harms, so harm identification and management may need to be written into lifecycle governance.

Operation and maintenance: where runtime evidence matters

Operation and maintenance are where the gap between a documented process and observed behavior is widest for AI systems. A life cycle process can specify that behavior is controlled, but an auditor will ask what the system was allowed to do and what it did. Design-time artifacts answer only part of that question, because probabilistic and data-dependent systems behave differently in production than in test.

This is where runtime policy enforcement can supply concrete, durable artifacts to operational-stage processes. Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with actions such as allow, redact, block, rate limit, and escalate for human approval. Enforcement applies to individual interactions and tool calls and is enforced at runtime, not reviewed after the fact. Each enforcement decision produces audit-ready evidence, which can be mapped to frameworks such as NIST and the EU AI Act. Teams can attach that evidence to the artifacts they define for their operation and maintenance processes.

This is a supporting capability, not a path to conformance. Neither 5338 nor 15288 is satisfied by a product, and Trussed makes no claim of certification or conformance with either standard. Runtime enforcement does not replace the engineering processes, ownership and documentation that the standards describe. It addresses one evidence gap within them. Teams should also be clear about scope: enforcement at the interaction and tool-call level does not by itself cover data management, validation or retraining activities earlier in the life cycle.