Lifecycle control points for enterprise AI agents
Effective 5338 alignment for agents depends on control points that remain visible from design through retirement. The stages below are the practical anchors most teams need before deeper process mapping.
Design-time gates
Intended use, risk tiering, permission matrix, and evaluation evidence before build promotion.
Runtime enforcement
Agent identity, scoped tool access, policy decisions, and action authorization in production.
Operate and change
Monitoring, drift triggers, versioned modifications, rollback, and forced re-validation.
Retire with evidence
Credential revocation, tool access removal, retained audit trails, and accountable closure.
What ISO/IEC 5338 requires in practice
ISO/IEC 5338:2023, Information technology — Artificial intelligence — AI system life cycle processes, specifies process requirements for AI systems across the life cycle. It is intended to be used with systems and software life cycle process standards and adapts those concepts to AI-specific concerns such as data, models, and continuous change.
In related ISO AI guidance, life cycle management commonly spans conception and requirements, design and development, verification and validation, deployment, operation and monitoring, and retirement or decommissioning. ISO/IEC 5338 therefore frames AI work as managed processes rather than a one-time model build. For enterprise AI agents, that framing matters because agents introduce non-deterministic planning, tool calling, memory, and external integrations. Approvals at design time do not remain credible unless the same constraints are visible and enforceable while the agent runs.
ISO/IEC 5338 should be implemented together with an AI management system such as ISO/IEC 42001, which addresses policies, roles, risk treatment, and continual improvement. NIST AI RMF functions (Govern, Map, Measure, Manage) and generative AI profile guidance on intended use, human oversight, monitoring, and post-deployment risk measurement are complementary. They help structure controls, but they do not replace explicit life cycle process ownership for each production agent.
Bind lifecycle approvals to runtime control planes
ISO/IEC 5338 does not prescribe a single reference architecture for tool-using agents. Implementation therefore depends on mapping life cycle stages to concrete control planes that already exist in enterprise platforms: design-time registries, promotion gates, runtime policy engines, observability stacks, and decommissioning hooks.
The architectural priority for agents is attribution. Separate agent workload identity from initiating user identity and from tool or connector identities so permissions, credentials, and accountability remain clear. Enforce tool-call governance with allowlists or denylists, argument validation, rate limits, egress controls, and approval breakpoints for sensitive actions such as payments, privileged administration, or data exfiltration-prone connectors.
Preserve lineage among dataset or feature versions, model versions, prompt and policy packs, agent configuration, and deployment environment. After an incident or audit request, teams should be able to reconstruct which approved version acted, under which policy, with which tools, and with what human intervention. Change management must create new immutable versions for prompt, tool, model, or permission updates, with rollback and re-validation paths.
Runtime governance evidence typically comes from policy decision and enforcement logs, identity bindings, permission scopes, and trace spans for model invocations and tool calls. Cloud AI operational guidance consistently treats monitoring, tracing, evaluation, access control, and change management as core production responsibilities. Those mechanisms are how lifecycle governance remains demonstrable after deployment, not only documented before it.
Practical rule
Prefer enforceable controls over document-only controls. Design-time policies matter, but production evidence from identity, permission scope, tool-call policy, and monitoring is what keeps autonomous action paths auditable.
Map lifecycle stages to security and governance controls
Use the stage-to-control mapping below as a working checklist when adapting existing SDLC and MLOps gates for agents.
| Lifecycle stage | Primary controls | Evidence to retain |
|---|---|---|
| Requirements and design | Intended use, risk tier, permission matrix, tool inventory | Approved scope, owners, acceptance criteria |
| Validation and admission | Evaluation reports, promotion gates, policy pack binding | Test results, version stamp, residual risk sign-off |
| Deployment and operation | Agent identity, least-privilege access, tool-call policy, monitoring | Decision logs, traces, incident records |
| Modification | Immutable versioning, rollback, forced re-validation | Change ticket, diff of prompts/tools/models/permissions |
| Retirement | Credential revocation, access removal, archive process | Closure checklist, retained audit trail |
Implementation priorities and practical tradeoffs
- Reuse existing gates, add agent-specific evidence: Map 5338-aligned activities onto current intake, security review, CI/CD promotion, and change boards. Add only agent-specific artifacts such as tool inventories, permission matrices, and runtime policy packs.
- Prefer enforceable controls over document-only controls: Design-time policies matter, but auditors increasingly expect production evidence from identity, permission scope, tool-call policy, and monitoring. Documents without enforcement create false assurance for autonomous action paths.
- Tier controls by action risk, not model novelty: An ordinary model with privileged tools can be higher risk than a complex model confined to read-only retrieval. Concentrate dual control and stricter evaluation where blast radius is largest.
- Make change visible and expensive in the right places: Allow rapid iteration in lower environments, but require immutable versioning and re-validation before production admission when tools, permissions, prompts, or models change materially.
- Plan retirement with the same rigor as deployment: Orphaned agents retain credentials, connectors, and residual access. Decommissioning should be a controlled process with access removal and archive of audit trails, not an informal shutdown.
- Know the standard’s limits: ISO/IEC 5338 provides general AI process requirements. Exact tool-call control catalogs are implementation-specific, and legal conformity may require additional jurisdiction or use-case obligations beyond 5338 alignment alone.
Minimum artifacts, ownership, and audit records
Before production admission, most enterprise programs should be able to produce the following baseline set.
- Approved intended use statement and risk tier
- Evaluation report tied to the candidate agent version
- Permission matrix covering tools, data paths, and identities
- Monitoring and incident response plans with named owners
- Versioned configuration for prompts, models, policies, and tools
- Runtime policy enforcement enabled for declared tools and data access
- Lineage sufficient to reconstruct what ran after an incident or audit request
- Retirement checklist covering credential revocation and record retention
Common implementation questions
How do we map ISO/IEC 5338 to existing SDLC and MLOps processes?
Treat 5338 as the AI-specific process overlay. Reuse intake, build, test, promote, operate, and retire gates. Add agent artifacts for intended use, tool permissions, evaluation evidence, runtime policy binding, monitoring ownership, and decommission checks.
Which runtime controls count as lifecycle governance evidence?
Strong evidence includes agent identity bindings, least-privilege permission scopes, tool-call allow or deny decisions, policy evaluation logs, model and configuration versions, human override records, incident handling, and retained lineage across environments.
What is the minimum bar before production admission?
At minimum: approved intended use and risk tier, evaluation report, permission matrix, monitoring and incident plans, named owners, versioned configuration, and runtime policy enforcement enabled for declared tools and data access paths.
Who owns re-validation when agent behavior changes?
Technical and operations owners detect drift and control failures. Risk or compliance owners set thresholds that force re-entry into modification and validation. Business owners accept residual risk before re-admission to production.
What must retirement include for AI agents?
Disable the agent version, revoke credentials, remove tool and data access, confirm retention or deletion obligations, archive approval and runtime audit records, and record formal owner closure of the retirement checklist.