ISO/IEC 5338 and AI Systems That Continue Learning After Deployment

Continuous learning is a change-control problem

A system that retrains, adapts or updates after release behaves differently from the version that was reviewed. That is the core enterprise problem. The approval given at release describes a point in time, while the system in production keeps moving.

ISO/IEC 5338:2023, "Information technology, Artificial intelligence, AI system life cycle processes", is a voluntary standard in the ISO/IEC JTC 1/SC 42 catalogue. As of November 2026 it carries no stated compliance date, and nothing in it makes it a legal obligation on its own. Because it is organized around life cycle processes, the useful question for an architect is not whether a continuously learning system is permitted. It is which processes govern the system once it is in operation, and who owns each one.

This framing matches how NIST describes the issue. The AI RMF Playbook notes that AI systems are dynamic and may perform in unexpected ways after deployment, and it treats continuous monitoring as the risk management process for tracking those issues. Drift is handled as a general property of dynamic systems, not as its own category.

The post-deployment processes to cover

Four process areas matter once a system is live: operation and monitoring, maintenance, re-validation and change management. The standard's own text is the authority for how each process is defined and what outcomes it expects, and any mapping to owners should be made against that text. What follows is the practical shape of each area, informed by NIST guidance on the same period of the life cycle.

Operation and monitoring covers how the system is run and how its behavior is observed. NIST says AI systems should be tested before deployment and regularly while in operation, and the Playbook calls for documented plans for continuous monitoring and feedback.

Maintenance and change management cover how updates are proposed, approved and released. For self-updating systems, including adaptive, online and reinforcement learning, the Playbook says resource allocation approaches should be identified in advance.

Re-validation answers a different question: when does a change in behavior require the system to be assessed again? NIST SP 1270 notes that impact assessments are point-in-time, so they must be applied at a reasonable cadence for iterative and evolving systems. Triggers and cadence are decisions your organization makes. They are not something a standard can set for you.

How NIST and ISO/IEC 42001 materials fit around 5338

NIST describes the AI RMF as a voluntary resource, and its Roadmap names production of crosswalks to related standards, including ISO/IEC 5338. NIST's AIRC crosswalk page lists a crosswalk between the AI RMF and ISO/IEC 5338 and 5339, dated April 2024. Teams that report against more than one framework can use these mappings to avoid building separate post-deployment control sets.

The NIST crosswalk to ISO/IEC 42001, the AI management system standard, adds operational detail. It includes planned ongoing monitoring and periodic review, with roles defined and review frequency determined. It also covers mechanisms and assigned responsibilities to supersede, disengage or deactivate systems that show problematic performance.

The practical division is this. A management system standard asks that monitoring, review and deactivation authority exist and are assigned. A life cycle standard places those activities within the processes that run from operation through retirement. Keep a record of which obligation you derive from which document, so that interpretation is not mistaken for requirement.

What runtime enforcement and evidence contribute

Runtime enforcement acts on observed behavior at execution time. It sits in the execution path, so a policy decision is made on each interaction and each tool call before the action completes. This is enforced at runtime, not reviewed after the fact. For a system that has changed since its last review, that matters because the policy still applies whatever the model has learned.

The evidence it produces supports operation-phase controls. A reviewer assessing whether a system stayed within approved policy needs records of decisions, not only outputs. For self-updating systems, those records are most useful when they identify the model or version in service, so behavior before and after a change can be compared. How to attach that identifier is an architecture decision for your team.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence from that enforcement. Its scope is individual interactions and tool calls. It does not provide model lineage, dataset provenance or pre-deployment validation, so those controls need to be covered elsewhere in the pipeline.

There is one further tradeoff. Runtime controls can constrain a system whose behavior has drifted, but they do not explain why it drifted. Cause analysis depends on the lineage and change records held in the build and release pipeline.