ISO/IEC 23894 and ISO/IEC 5338 Lifecycle Mapping: Where Risk Activities Sit and What Operation Requires

Two standards, read together

ISO/IEC 5338:2023 defines a set of processes and associated concepts for describing the life cycle of AI systems based on machine learning and heuristic systems. ISO/IEC 23894:2023 provides guidance on risk management and describes processes for the effective implementation and integration of AI risk management. As of November 2026, both are published standards.

Many regulated enterprises adopt them as separate programs. The lifecycle belongs to engineering, and the risk process belongs to a risk or compliance function. The result is predictable. Nobody can say which risk activity is performed at which stage, who owns it, or what record it leaves behind. Operation is usually the weakest point, because a treatment agreed during design has no defined owner once the system is live.

The NIST AI RMF points the same way. It states that risk management should be continuous, timely and performed throughout the AI system lifecycle. The mapping below is practitioner interpretation, not quoted standard text. Validate it against the licensed standards and tailor it to your own lifecycle definitions.

Design-time artifacts versus operational controls

Context establishment, identification, analysis and evaluation mostly produce documents and decisions: criteria, registers, assessments. They are revisited at later stages but are fundamentally design-time artifacts. An auditor reads them to understand what the organization intended.

Treatment is split. The decision about how to treat a risk is a design-time artifact. The implementation of that decision is an operational control, and it needs its own ongoing evidence. Monitoring and review, and recording and reporting, are operational by nature. They have no meaning unless the system is running. Communication and consultation run through every stage.

This split is where programs fail. A risk register can state that sensitive data must not leave a defined boundary. If nothing in operation enforces that statement, the register is a record of intent, not evidence of control. A practical rule is to keep three linked records for every treatment: the decision, the control that implements it, and the operational evidence that the control acted. Traceability between the three is what lets you answer how an identified risk was controlled.

Operational monitoring also needs defined thresholds. The NIST AI RMF Manage guidance refers to detected risks that exceed tolerance thresholds. Set those thresholds at inception, confirm them at deployment, and state what response each breach triggers and who owns it.

Operation phase: runtime enforcement and evidence

NIST AI RMF MEASURE 2.4 states that the functionality and behavior of the AI system and its components are monitored when in production. That is monitoring at system or component level. It does not by itself say what happened in a given interaction or tool call, and an auditor may ask exactly that.

Runtime policy enforcement addresses this narrower scope. A policy is applied to each interaction or tool call in the execution path, and the outcome is one of a small set of actions: allow, redact, block, rate limit, or escalate to a person. Several common treatments translate directly into these actions. Preventing disclosure of sensitive fields becomes redact. Prohibiting a tool or action becomes block. Limiting exposure to abuse or runaway usage becomes rate limit. Risks that need human judgment become escalate. Because the decision is made at runtime rather than reviewed after the fact, the treatment is enforced, and each decision can be recorded.

The limits matter. Enforcement can only implement treatments that can be expressed as a rule on an individual interaction or tool call. It does not replace validation of model behavior, assessment of data quality, or the re-evaluation step. Treatments for those risks stay with the other lifecycle stages.

Trussed operates in this part of the lifecycle. It enforces policy in the execution path across models, agents, tools and MCP servers, scoped to individual interactions and tool calls. The enforcement generates audit-ready evidence of what policy applied and what action was taken. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. It does not address model or dataset provenance, or end-to-end tracing of agentic workflows. Those concerns sit with other stages and tools.

For each treatment, an auditor will typically want to see the policy in force at the time, the action taken on a specific interaction, who approved any escalated action, and how threshold breaches were handled. This is practitioner interpretation of audit expectations, and the evidence should be mapped to your own treatment records.