ISO/IEC 5338 configuration management for AI systems

What ISO/IEC 5338 is and where configuration management fits

ISO/IEC 5338:2023, "Information technology, Artificial intelligence, AI system life cycle processes", is published by ISO/IEC JTC 1/SC 42, the same subcommittee that publishes ISO/IEC 42001:2023. It is a process standard. It describes processes an organization performs across the life of an AI system, rather than a management system to be certified or a set of technical controls.

For architects, the useful reference point is ISO/IEC/IEEE 12207, the software life cycle process standard, which defines configuration management as a process in its own right. Reading the 5338 configuration management process alongside the 12207 process is a sensible way to separate what is generic to any software system from what AI changes. The generic parts are familiar: identify items, establish baselines, control changes, record status, and verify that what is deployed matches what was approved.

This guide does not reproduce clause wording. Where it describes which AI elements to bring under control and what a defensible record contains, that is interpretation for enterprise implementation, and it is labelled as such.

Which AI elements to treat as configuration items

In a conventional application, behavior is determined mostly by code and a small set of environment settings. In an AI system, behavior also depends on artifacts that are not code and often change outside a release pipeline. A practical rule of interpretation: if changing an element can change what the system does, and you would need to explain that change later, treat it as a configuration item.

Applying that rule, the following groups are strong candidates. Treating an item as a configuration item means giving it a unique identifier, a version and an owner. It does not mean the standard names each one.

• Models, datasets and training parameters: Model versions and the datasets and hyperparameters used to produce or evaluate them, identified by version so a deployed model can be tied to an approved release.
• Prompts and system instructions: Prompt templates, system messages and any retrieval or formatting instructions that shape model output.
• Policies and rules: Access, content and data-handling policies applied to interactions, including their version and effective dates.
• Tool and MCP server connections: Which tools and MCP servers an agent can reach, with their endpoints, scopes and credentials references.
• Application code and pipelines: Orchestration code, build and deployment definitions, and infrastructure configuration.
• Runtime settings: Inference parameters, routing rules, model selection logic and feature flags that alter behavior without a code release.

Baselines and change control for non-code items

A baseline is an approved, identifiable state that later changes are measured against. For AI systems the difficulty is rarely the concept. It is that prompts, policies and tool connections are frequently edited in consoles, configuration files or shared documents, where no baseline exists and no approval is recorded.

A workable approach is to store every configuration item in a versioned repository, or reference it from one by immutable identifier, and to define a release baseline as a set of item versions that were approved together. Change control then applies the same questions to a prompt edit as to a code change: who requested it, what changed, what was assessed, who approved it, and when it took effect. Risk-based tiers help. A wording change to an internal drafting prompt does not need the review that adding a new MCP server connection to a production agent does.

The tradeoff is friction. Heavy approval for every prompt edit pushes teams to work around the process, which recreates the problem. Define tiers by consequence, automate the record-keeping, and reserve manual approval for changes that alter what the system can access or decide.

What a defensible configuration record looks like

Configuration management is an evidence problem as well as a process problem. A configuration that cannot be shown to have been in force at a given time has little audit value, however well it is documented in a wiki.

A defensible record has four properties. It is identifiable: each item and version has a unique reference. It is time-bound: it states when a version was approved, deployed and retired, so any interaction can be placed against the configuration then in force. It is attributable: it names who requested, approved and made each change. And it is tamper-evident or at least access-controlled, so the record could not have been quietly rewritten after an incident.

The test an architect can run is the first buyer question auditors tend to ask in some form: for a specific interaction on a specific date, can you show which model, prompt, policy and tool connection versions applied? If answering requires reconstructing history from chat messages and memory, the record is not yet audit-grade. Also decide who owns each record. Items with no named owner are the ones that change without approval.

Related standards, regulation and the role of runtime enforcement

ISO/IEC 42001:2023 is a separate standard in the SC 42 catalogue, titled as an AI management system standard. A reasonable reading is that 42001 sets the organizational management framework, while 5338 describes life cycle processes such as configuration management that operate beneath it. Evidence from configuration records can serve both, but any formal mapping to 42001 or to the NIST AI RMF should be done by your compliance team against the texts.

On regulation, timing has moved. As of November 2026, the European Commission states that the Digital Omnibus on AI entered into force on 27 July 2026. It sets 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products, replacing the earlier 2 August 2026 date. The Commission attributes the extension to the delayed availability of standards. Regulated enterprises should confirm scope against the final legal text.

Runtime enforcement can support part of this picture, but only a part. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate decisions to individual interactions and tool calls. Because enforcement happens at runtime, not after the fact, it produces audit-ready evidence of what was allowed, redacted or blocked. That evidence can show which policy governed a given interaction or tool call. It does not replace configuration records for models, datasets, prompts or code, and it does not address model provenance, lineage or end-to-end workflow tracing.