How ISO/IEC 5338 Applies When You Consume Third-Party LLM APIs and Foundation Models

What ISO/IEC 5338 covers, and what changes for consumed models

ISO/IEC 5338:2023, "Information technology — Artificial intelligence — AI system life cycle processes", defines a set of processes and associated concepts for describing the life cycle of AI systems based on machine learning and heuristic systems. As of November 2026, the 2023 edition is the one listed in the ISO/IEC JTC 1/SC 42 catalogue. It is best used as a process framework for describing how an AI system is acquired, built, run and retired, not as a checklist of technical controls.

The standard describes the life cycle of an AI system. That framing matters for consumed models. An enterprise that calls a hosted LLM API is building a system around a component it did not train, cannot inspect and does not release. The system is still the enterprise's, so most life cycle processes still apply. What changes is where the evidence for each process comes from.

The mapping in the next section is the author's analysis. It uses common life cycle stages and should be checked against the licensed text of the standard before it is adopted as an internal control mapping.

Who owns each life cycle stage when the model is third-party

Read the table as a starting position. Ownership is rarely absolute. Most stages combine an enterprise decision with an input from the provider.

• Acquisition and supply: Enterprise decides whether and how to acquire the model or API, with accountable owners in legal, procurement and policy roles. Terms, rights and service commitments depend on the supplier.
• Design and integration: Enterprise owns the architecture: what data reaches the model, which tools it can call, and which controls sit in the path. Model behavior documentation comes from the supplier.
• Operation: Enterprise owns what each interaction and tool call is allowed to do. This can be enforced and evidenced in the enterprise's own execution path.
• Monitoring: Enterprise monitors its own traffic and control decisions. Provider incident and change notices supplement this.
• Maintenance: Provider controls model and API versions. Enterprise controls testing, change approval and policy updates in response.
• Retirement: Provider sets deprecation timing. Enterprise plans migration, data handling and decommissioning of its own integration.

What stays supplier-dependent

Model provenance, lineage and dataset provenance are supplier-side matters. For a hosted API, the enterprise typically has no model file to hash or sign, so integrity checks that apply to downloaded model artifacts do not carry over directly. OWASP's LLM03:2025 guidance on supply chain risk describes weak model provenance as a problem to compensate for, and recommends relying on maintained versions of APIs and the underlying model. For a hosted API, compensation means asking the provider for documentation and assurances, and designing your own controls so they do not depend on those assurances being perfect.

The NIST AI RMF makes a related point. Risk measurement and management can be complicated by how customers use or integrate third-party data or systems, particularly without sufficient internal governance structures and technical safeguards. Safeguards the enterprise owns should therefore be designed explicitly around the integration, not assumed to come with the model.

A runtime enforcement layer cannot supply provenance or lineage for a model it does not control. Treat those as supplier documentation requests, and treat the enterprise-side controls below as a separate body of evidence.

Runtime controls and evidence for the enterprise-owned processes

Three NIST AI RMF subcategories give a practical anchor for the enterprise side. MAP 4.2 calls for internal risk controls for AI system components, including third-party AI technologies, to be identified and documented. MANAGE 3.1 calls for regular monitoring of risks and benefits from third-party resources, with risk controls applied and documented. GOVERN 6.2 calls for contingency processes for failures or incidents in high-risk third-party data or AI systems. An INCITS crosswalk between the AI RMF and ISO/IEC 5338 and 5339 is listed by NIST, and it is a reasonable starting point for evidence mapping once reviewed directly.

In practice, this suggests four artifacts. First, a component inventory with one record per consumed API or model, including version, owner, approved use cases and the controls applied. Second, a policy definition for each component that states what data may be sent, what responses may be returned and which tool calls are permitted. Third, a decision record for each enforced interaction showing the policy version applied and the outcome: allow, redact or block. Fourth, a contingency procedure for provider failure or incident, tested against the integration rather than only written down.

The timing of enforcement matters. A control that is enforced at runtime, not reviewed after the fact, changes what the system does. A review of stored traffic only describes what already happened. For operation, the first is the process control and the second is supporting evidence.

Maintenance and retirement need inputs from the provider but outputs from the enterprise. Track provider version and deprecation information, retest policies when versions change, and keep a migration plan for each component.

Evaluating runtime enforcement tooling

Whatever tool is selected, test it against criteria that map to the enterprise-owned processes. Does it enforce policy in the execution path, or only observe traffic? Does it cover individual interactions and tool calls? Can it allow, redact and block, and can those decisions be tied to a policy version? Does it produce durable, audit-ready evidence that can be retained under your own retention and data residency rules? Can it document the controls applied to each third-party component so they map to MAP 4.2 and MANAGE 3.1? Can it be deployed in your own cloud?

Trussed is runtime control infrastructure for regulated enterprises. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-human-approval decisions on individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to frameworks including NIST, and it can be deployed self-managed in the customer cloud with configurable retention and data residency. Trussed does not provide model provenance, model lineage or dataset provenance. Those remain questions for the model provider.