Applying ISO/IEC 5338 AI System Life Cycle Processes in Healthcare

What ISO/IEC 5338 covers and how it fits with adjacent standards

ISO/IEC 5338, published as ISO/IEC 5338:2023 under the title "Information technology, Artificial intelligence, AI system life cycle processes", is maintained by ISO/IEC JTC 1/SC 42. It is a process standard. It organizes the work of building, running, and retiring an AI system into defined life cycle processes, which gives an enterprise a common vocabulary for what has to happen at each stage.

It is rarely used alone. ISO/IEC 42001 is a management system standard and addresses the organization-level system that governs AI activity. ISO/IEC 23894:2023 provides guidance on AI risk management, including the effective implementation and integration of risk management processes. NIST AI RMF 1.0 is described as showing test, evaluation, verification, and validation processes occurring throughout an AI life cycle, assessment and audit included. A workable way to combine them is to let the management system set accountability, let the risk process decide what matters, and let the life cycle processes define where in a system's life each control lives.

The formal mappings between these documents are for your control inventory to settle. The practical point for architects is that each standard answers a different question, and none of them by itself shows what a deployed system did on a given day.

Pre-deployment process versus runtime control

Most organizations implementing life cycle standards start with the stages that produce documents: acquisition decisions, design records, verification results, and approvals. These are necessary, and they describe intended behavior. They show that a system was reviewed and that a policy exists.

The operation, monitoring, and maintenance stages are different in kind. A system in production receives inputs that nobody reviewed in advance, calls tools nobody tested in that exact combination, and may handle protected health information. A regulator or auditor reviewing that period asks what the system was actually allowed to do and what it did. A design document cannot answer that.

This is an implementation choice, not a text requirement. ISO/IEC 5338 does not need to prescribe runtime enforcement for you to conclude that operation-stage processes are only credible when policy is applied to individual interactions and tool calls and the outcome is recorded. Enforcement at the point of execution turns a stated rule into something you can evidence. Review after the fact can only tell you what happened, not what was permitted.

Operation-stage processes that call for enforcement and evidence

The mapping below is an editorial reading for implementation planning, not a restatement of clauses. For each operation, monitoring, or maintenance concern, it shows the runtime control and the evidence artifact an auditor would reasonably expect to see.

• PHI handling in prompts and responses: Control: redact or block PHI according to policy before it reaches a model or leaves the boundary. Evidence: per-interaction record of the policy applied, the action taken, and a timestamp.
• Tool and system access: Control: allow or block each tool call against an explicit policy for that agent and purpose. Evidence: the call, the policy version, and the decision.
• High-impact actions: Control: escalate for human approval before execution. Evidence: the request, the approver, the decision, and when it was made.
• Usage limits: Control: rate limit by user, application, or tool. Evidence: limit definitions and the interactions that were throttled.
• Monitoring and review: Control: review blocks, redactions, and escalations for patterns. Evidence: review records tied to the underlying enforcement events.
• Maintenance and policy change: Control: version every policy change with an effective date. Evidence: change history that lets you reconstruct which policy governed any past interaction.

Where insurers, banks, and health systems place the emphasis

All three institution types go through the same life cycle stages, but the stage that carries the most exposure differs in practice.

Health systems and other HIPAA-covered organizations concentrate on operation, because PHI moves through AI interactions continuously. The HIPAA Security Rule technical safeguards at 45 CFR 164.312 include audit controls at paragraph (b), so the retention and reviewability of production activity records is a central design question. Redaction and access decisions on each interaction are the natural enforcement points.

Insurers that use AI in underwriting, claims, or customer communication tend to put weight on the link between a consequential output and the policy and human oversight around it. Escalation for human approval and the ability to reconstruct decisions are the relevant controls. Insurers should map these to the NAIC and NYDFS expectations that apply to them.

Banks tend to emphasize maintenance and change control, since models and prompts change frequently and each change alters risk. Versioned policy and evidence tied to the policy in force at the time matter most. Organizations that span more than one of these categories, such as an insurer with a provider arm, will need all three emphases.

Implementing enforcement and evidence in the execution path

Any architecture that applies policy per interaction and tool call and records the outcome can satisfy the pattern above. Trussed is one way to do it. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants, with actions that include allow, redact, block, rate limit, and escalate for human approval. Enforcement generates audit-ready evidence continuously, mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency.

Its scope is individual interactions and tool calls. It does not replace the pre-deployment processes in a life cycle standard, and it does not address model provenance or lineage. Trussed has run continuously in production in a regulated enterprise for more than 18 months and operates with healthcare and insurance organizations.

The tradeoff to weigh is placement. Enforcement in the path adds a dependency to every interaction, so availability, latency, and failure behavior need explicit design decisions, whichever approach you choose.