ISO/IEC 5338 for Acquirers vs Developers: Who Owns Which Lifecycle Processes?

Why a shared process vocabulary matters

ISO/IEC 5338:2023, "Information technology — Artificial intelligence — AI system life cycle processes", is published by ISO/IEC JTC 1/SC 42. Like the systems and software lifecycle standards that came before it, it is best read as a process vocabulary. Processes have a purpose, outcomes and activities, and they can be applied by different parties during acquisition, supply, development, operation and maintenance. The 15288 and 12207 standards state that their processes can be used when acquiring and supplying systems, and can be applied recursively and incrementally to system elements.

That last point matters for architects. A single AI-enabled product usually contains acquired components, such as a hosted model or a vendor application, alongside components your teams build. Treat each as a system element and record, per element, which party performs each process. The same vocabulary then covers a pure purchase, an in-house build and the common hybrid.

A caution on editions: as of November 2026, ISO/IEC/IEEE 15288:2015 and ISO/IEC/IEEE 12207:2017 are marked withdrawn, and a 12207:2026 edition is listed. If contracts or internal policy cite these standards alongside ISO/IEC 5338, confirm which edition each reference means.

A working ownership matrix by process area

The matrix below is a starting allocation for the processes most often negotiated, not a statement of what the standard requires. Adjust it per scenario. When you build in-house, one organization holds both columns, but the separation is still worth recording because it exposes review and independence gaps.

• Acquisition and supply: Acquirer defines need, selection criteria and acceptance terms. Developer states what it supplies, to which lifecycle processes, and with what evidence. Shared: the agreement itself.
• Requirements and design: Acquirer owns intended use, operating context and risk tolerance. Developer owns architecture, model choice and documented limitations. Shared: requirement traceability.
• Development and data preparation: Developer owns build, training data handling and configuration records. Acquirer owns data it supplies or fine-tunes with. Shared where data crosses the boundary.
• Verification and validation: Developer verifies against specification and supplies test evidence. Acquirer validates fitness in its own context before and after go-live. Shared: test scope and re-test triggers.
• Operation and monitoring: Acquirer owns runtime behavior, usage controls and operational accountability. Developer supplies operating guidance and known failure modes. Shared: incident feedback.
• Maintenance and retirement: Developer owns fixes, updates and change notices. Acquirer owns change acceptance, re-validation and decommissioning of its deployment. Shared: data disposition.

Where ownership is shared or contested

Three areas generate most of the disputes: validation, monitoring and maintenance. In each, one party holds the knowledge and the other holds the exposure.

Validation is contested because the developer can show that a system meets its specification, but only the acquirer knows the specific use, user population and data it will face. NIST AI RMF 1.0 makes the same point from a risk angle. A developer who makes AI software available can have a different risk perspective than the party deploying it for a particular use, and deployers may not recognize that their uses carry risks the developer did not foresee. The same framework notes that test, evaluation, verification and validation tasks occur throughout the lifecycle, so plan evidence at several handoff points instead of one acceptance gate.

Monitoring is contested because the developer holds design-time knowledge while the acquirer sees runtime behavior. Unless the agreement says otherwise, each side may assume the other is watching. Maintenance follows from monitoring: if use-specific issues found in operation have no defined route back to the developer, they stay unresolved or get patched locally without anyone updating the evidence.

Data preparation and retirement are less visible but behave the same way. Data and model artifacts can cross organizational boundaries in both directions, so name who is accountable for them at each end of the lifecycle.

Operation stage: runtime control and evidence belong to the acquirer

Design-time assurance does not describe what a system does with real inputs, real users and connected tools. The acquirer usually holds operational accountability, so it needs its own operation-stage controls and its own evidence, not only the developer's assessments. For auditors and regulators, that evidence must show what the system was allowed to do and what it did.

In practice this means defining runtime policy, enforcing it where interactions happen, and retaining records that map back to your risk framework. An INCITS crosswalk between the NIST AI RMF and ISO/IEC 5338 and 5339, dated April 2024, can serve as a starting reference for tying process outcomes to risk-management activities. Verify it against the current standard text and record the version you use.

Trussed addresses this stage as runtime control. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval, scoped to individual interactions and tool calls. Enforcement itself generates audit-ready evidence, mapped to frameworks including NIST and the EU AI Act. It is enforced at runtime, not reviewed after the fact, and it complements, rather than replaces, developer-side verification and validation.

Putting the split into practice

Start with one system. List its elements, mark each as acquired or in-house, and assign every process in the matrix to the acquirer, the developer or both. For each shared process, write down the artifact each party produces, the artifact each accepts and the trigger that causes it to be refreshed.

Then test the result with a few questions. Which processes does the vendor say it performs, and which does it expect you to perform? Who monitors behavior in operation, and what flows back? How are use-specific risks you identify fed to the developer for maintenance or redesign? Which edition of each standard does the agreement cite? Gaps in the answers are the unowned processes.

Re-confirm the status of referenced standards at each review cycle, and revisit the matrix whenever the system moves from acquired to modified or in-house, since ownership moves with it.