Control · C-044 · Model & System Lifecycle
AI change management
Changes to models, prompts, data sources, tools and configuration are assessed, tested, approved and versioned before they reach production.
- Control type
- Preventive
- Family
- Risks addressed
- 7
- Audience
- Heads-of · Practitioner
- Frameworks
- Principle 11 · Article 43 · Annex A.6 · Clause 8
- Responsible AI domain
- Lifecycle stage
- Reviewed
- 2026-11-11
What it does
It ensures that the system in production is the one that was approved. In an AI system far more than code can change behaviour: a new model version, an edited prompt, a refreshed dataset, a different retrieval source, a changed setting. Each is treated as a change. The system owner is accountable; the control applies to every change, with the level of scrutiny set by its potential effect.
How to implement it
- Define what counts as a change, including prompts, data and supplier model versions.
- Classify changes by impact, and set the testing and approval each class needs.
- Version every component so that any past state can be identified and restored.
- Require regression results before approval.
- Reassess risk tier, validation and regulatory classification on material change.
- Keep a record of what changed, why, who approved it and when.
Evidence it operates
Design: a change standard listing change types, classes and required approvals. Operation: a change log reconciled to the production configuration; test evidence attached to each change; a sample of production components that match approved versions.
Where it fits
Governs every transition after first release. It is the primary control for uncontrolled AI change and for safeguard erosion through fine-tuning, and it relies on the evaluation suite for evidence.
Limits
It governs changes the organisation makes. A supplier's change to a hosted model arrives from outside and needs version pinning and monitoring to be seen at all. Prompt edits made directly in a production console bypass the process unless the console is locked down.
Risks this mitigates
Primary mappings
- AI system lifecycle controls gap Medium
- Applies assessment, testing and approval at each lifecycle transition. The organisation has no defined lifecycle for AI systems, so there is no consistent checkpoint at which a system is assessed, validated, approved, monitored or retired.
- Safeguard erosion through fine-tuning Medium
- Treats fine-tuning as a change requiring assessment and approval. Fine-tuning or other adaptation weakens a base model's safety behaviour, and the change goes untested because the base model had already been assessed.
- Uncontrolled AI change High
- Requires assessment, testing, approval and versioning before any change reaches production. Models, prompts, data sources and configuration change in production without assessment, testing, approval or a record.
Supporting mappings
- Inability to stop or roll back AI High
- Versioning preserves the state to return to. A misbehaving system cannot be disabled, reverted to a known good version, or have its actions reversed quickly enough to limit harm.
- Model interdependency and aggregation Medium
- Assesses downstream effects before an upstream model changes. Models feed other models, so an error or change in one propagates, and the combined uncertainty across the chain is never assessed.
- Output inconsistency and non-reproducibility Medium
- Fixes model version and settings so behaviour is repeatable. The same input produces materially different outputs on different occasions, so decisions cannot be reproduced, audited or relied on to treat like cases alike.
- Unrecognised provider obligations Medium
- Flags substantial modifications for that test. An organisation rebrands, substantially modifies or repurposes an AI system and takes on a provider's legal duties without realising it.
Framework and clause references
| Framework | Clause | Title |
|---|---|---|
| Code of Practice for the Cyber Security of AI | Principle 11 | Maintain regular security updates, patches and mitigations Updates. |
| EU AI Act | Article 43 | Conformity assessment Substantial modification. |
| ISO/IEC 42001:2023 | Annex A.6 | AI system life cycle Lifecycle and change. |
| ISO/IEC 42001:2023 | Clause 8 | Operation Operational planning and control of change. |
| SS1/23: Model Risk Management Principles for Banks | Principle 3 | Model development, implementation and use Controlled implementation. |
Related terms
How to cite
Axiom Verity (2026). AI change management. Reference Library, C-044. https://axiom-verity.com/controls/ai-change-management. Reviewed 2026-11-11.
Found an error or a better source? Report a correction.