What lifecycle management model is required for Artificial Intelligence (AI)…

Research Question

What comprehensive lifecycle management model is required for AI models, prompts, and low-code applications, covering versioning strategies, deployment controls, rollback mechanisms, ownership tracking, change management, documentation standards, and processes for decommissioning or retiring unused or unsafe artefacts?

Findings

Executive Summary

• Enterprises need a single registered-artefact lifecycle for AI models, prompts, and low-code applications that runs from registration through development, validation, controlled promotion, production monitoring, controlled change, rollback readiness, and formal retirement, because the governing standards all require operation and disposal controls and the tooling evidence shows each artefact class already exposes versionable operational state.
• A separate lifecycle model for each artefact class would add taxonomy complexity without changing the required control phases, because the shared duties, registration, validation, approval, monitoring, rollback readiness, and retirement, stay constant while only the pinned reproducibility fields differ.
• The common lifecycle must keep one enterprise state model but different reproducibility tuples, because a model version, a prompt version, and a low-code version are not pinned by the same fields.
• Promotion and rollback should be governed through risk-based change classes and immutable release paths rather than through direct production editing, because otherwise version history and approval evidence lose authority.
• The lifecycle therefore ends only when the artefact is retired through a documented shutdown, archive, credential, and data action plan.

Key Findings

1. High confidence: The required enterprise lifecycle is a common state machine of registration, build, validation, approved deployment, monitored operation, controlled change, rollback readiness, and retirement, because ISO, NIST, model-risk guidance, and current tooling all keep the control phases constant across artefact classes even when the operational artefacts themselves differ.
2. High confidence: A separate lifecycle model for each artefact class is less defensible than a shared state model with artefact-specific tuples, because reliable reproduction of a model requires lineage and deployment alias context, reliable reproduction of a prompt requires prompt text plus model and parameter context, and reliable reproduction of a low-code application requires managed package and dependency context.
3. High confidence: Production promotion should be mapped to standard, normal, and emergency change classes, because repeatable low-risk releases can be preapproved, materially new behavior or dependency changes need explicit review, and restoration after incidents must be fast but still documented and reviewed afterward.
4. High confidence: Rollback is only dependable when the prior approved artefact, its dependency tuple, and its deployment target remain preserved, because tools across models, prompts, and low-code all bind usable restoration to stored versions plus surrounding runtime metadata rather than to labels alone.
5. High confidence: Ownership must persist as a live operational record, including owner of record, technical operator, monitoring cadence, and exceptions history, because inventory and continuity obligations fail as soon as an artefact loses a steward or an accountable deployment identity.
6. High confidence: Monitoring must be wired into change control, because performance deterioration, changing conditions, dependency shifts, or platform retirement notices are not merely telemetry events, they are lifecycle events that should trigger revalidation, rollback, migration, suspension, or retirement decisions.
7. High confidence: Decommissioning has to be a first-class lifecycle phase with explicit triggers, because NIST requires safe phasing out, the Federal Reserve guidance ties documentation to continuity and remediation, and Microsoft already shows that platform retirement can force planned migration or shutdown.
8. Medium confidence: Low-code and prompt lifecycle governance needs compensating controls against mutable direct-publish behavior, because native tooling can expose direct publication paths that bypass the enterprise artefact record unless production environments are locked to governed promotion channels.

Assumptions

• Assumption: Prompt-governance requirements below extend beyond any one vendor page. Justification: the prompt-tooling sources expose versioning and deployment mechanics, but enterprise approval, retention, and retirement duties are synthesized from lifecycle and change-control standards rather than stated verbatim by one prompt platform.

Analysis

• The lifecycle-state conclusion was weighted most heavily toward ISO and NIST because they are the clearest normative sources on continuous lifecycle governance, inventory, and retirement.
• The main alternative hypothesis, separate lifecycle models for models, prompts, and low-code artefacts, was rejected because the evidence differentiates reproducibility fields and deployment mechanics much more strongly than it differentiates the required governance phases.
• The ownership, validation, monitoring, and documentation requirements were strengthened by SR 26-2 and MLflow because those sources make the operational record concrete instead of abstract.
• The change-class mapping was resolved in favor of standard, normal, and emergency categories because they scale better than one committee pattern and fit how low-risk recurring promotions differ from materially new or emergency recoveries.
• The most important practical trade-off is between lifecycle discipline and bypass risk, because a detailed lifecycle model adds little control if teams can still edit or publish directly into production.

Risks, Gaps, and Uncertainties

• SR 26-2 is a model-risk precedent rather than a direct generative-AI rule, so enterprises should use it as a control-design analogue and not as definitive legal guidance for foundation-model governance.
• Public prompt-tooling pages are stronger on versioning mechanics than on retirement and exception handling, so prompt-specific archival and post-incident practice still requires enterprise policy design.
• Azure Prompt Flow is itself on a retirement path, which means some prompt-lifecycle mechanics in current tooling are unstable and should not be treated as permanent architectural anchors.
• Power Platform rollback and promotion controls are reliable only if the institution actually enables the relevant settings, blocks unmanaged production changes, and preserves prior artefacts.

Open Questions

• How should Q5 risk tiers translate into exact thresholds for standard versus normal AI or prompt changes, especially when the artefact uses the same business purpose but a different underlying model deployment?
• What minimum evaluation bundle should accompany a prompt version so that approval and rollback decisions stay comparable across teams and vendors?
• Which governance system should serve as the system of record for lifecycle inventory, the control plane, the deployment platform, or a separate configuration database?

sources

• [x] ISO/IEC/IEEE 12207:2017 - Systems and software engineering - Software life cycle processes — - current ISO lifecycle standard listing for the common framework and process-control baseline
• [x] PeopleCert - ITIL 4 Practitioner: Change Enablement — - official purpose and scope statement for change enablement
• [x] Atlassian IT service management change management guide — - accessible summary of standard, normal, and emergency change classes and modern risk-based approvals
• [x] ManageEngine - Types of IT changes — - accessible summary of standard, normal, and emergency changes
• [x] MLflow Model Registry — - model registry source for model versions, aliases, lineage, and tags
• [x] Power Platform application lifecycle management (ALM) — - Microsoft overview for low-code lifecycle management
• [x] Pipelines in Power Platform — - Microsoft source for pipeline stages, backups, approvals, and redeploying prior versions
• [x] Solution concepts with Power Platform — - Microsoft source for managed and unmanaged solutions, updates, upgrades, patches, and dependencies
• [x] Delegated deployments in Power Platform pipelines — - Microsoft source for delegated promotion identity, approvals, and ownership of deployed objects
• [x] Block unmanaged customizations — - Microsoft source for production lock-down and preventing direct unmanaged changes
• [x] Copilot Studio security and governance — - Microsoft source for channel publication controls, data policies, audit, and publication disablement
• [x] Publish and deploy your agent in Copilot Studio — - Microsoft source for direct publish behavior and channel-wide update behavior
• [x] Deploy a prompt flow for real-time inference — - Microsoft source for prompt flow deployment, endpoint identity, overwrite behavior, telemetry collection, and retirement notice
• [x] LangSmith prompt engineering — - official prompt-tooling source for built-in prompt versioning and deployment workflow
• [x] Weights & Biases Weave tutorial: app versioning — - official prompt and application versioning source for tracked parameters and reusable versioned objects
• [x] Federal Reserve SR 26-2 revised guidance on model risk management — - official notice superseding SR 11-7
• [x] Federal Reserve SR 26-2 attachment Portable Document Format (PDF) — - detailed guidance for model inventory, validation, monitoring, effective challenge, and documentation
• [x] NIST Artificial Intelligence Risk Management Framework (AI RMF) 1.0 — - foundational AI governance framework
• [x] NIST AI RMF Core — - current subcategories for inventory, monitoring, accountability, and decommissioning
• [x] Deployment pipeline as the only enforceable control gate for citizen-developed agents — - related repository work on release-time enforcement
• [x] Where should governance enforcement points be implemented within enterprise architecture — - related repository work on layered enforcement
• [x] What identity and access management model is required for AI agents and low-code artefacts — - related repository work on machine identity and attribution