AIG-009 AI System Deployment and Change Management
Description
A documented deployment plan exists for each production AI system and pre-dates its deployment record. The plan records the pre-deployment checks completed, the verification and validation sign-off, the impact assessment it relies on, the rollback procedure and the communication to affected users. The deployment policy defines what counts as a substantial modification and gives worked examples. The record for each substantial modification shows the same pre-deployment checks completed as for a first deployment.
Rationale
Ungated model changes are a leading cause of AI production incidents, because a retrained model can pass every infrastructure test and still behave differently on the traffic that matters. Teams most often disagree over what counts as a substantial modification. Without worked examples covering a training data source change, an architecture change and an inference threshold change, the same change is gated by one team and waved through by another. AIG-008 holds the verification and validation gate this plan cites. The conformity assessment that a regulated system repeats after a substantial modification is a separate obligation the library does not yet carry.
Applicability (9 profiles)
The deployment plan and the substantial-modification definition are the deployer's. The same definition is the Art.25 test: a substantial modification makes the deployer the provider.
Art.43(4) attaches an external consequence to the substantial-modification definition this control already carries: the conformity assessment is repeated whether or not the system is distributed further or continues in service. The definition and its worked examples are therefore the trigger for a procedure outside the organisation and not only for the internal pre-deployment checks. Changes predetermined and documented in the initial assessment for a continuously learning system are outside it, which is what makes writing them down at first assessment pay. AIG-037 holds the repeated assessment and the reissued declaration.
The deployment plan and the substantial-modification definition are the deployer's. The same definition is the Art.25 test: a substantial modification makes the deployer the provider.
Framework Mappings (15)
| MDS-05 | Model Documentation Validation | informative |
| EU-AI-Art.43.3 | Conformity Assessment — Reassessment After Substantial Modification | informative |
| A.6.2.5 | AI system deployment | full |
| GV-1.3-002 | Risk Management Activity Level Determination | GV-1.3-002 | informative |
| GV-1.3-007 | Risk Management Activity Level Determination | GV-1.3-007 | informative |
| MG-1.3-001 | High-Priority Risk Response Planning | MG-1.3-001 | informative |
| MG-3.1-001 | Third-Party AI Risk Monitoring and Controls | MG-3.1-001 | informative |
| MG-3.1-003 | Third-Party AI Risk Monitoring and Controls | MG-3.1-003 | full |
| MP-4.1-007 | AI Technology and Legal Risk Mapping | MP-4.1-007 | full |
| MS-2.3-003 | AI System Performance Measurement | MS-2.3-003 | full |
| MS-2.7-008 | AI System Security and Resilience Evaluation | MS-2.7-008 | full |
| MS-4.2-005 | Trustworthiness Measurement with Expert Input | MS-4.2-005 | informative |
| MANAGE 1.1 | AI System Purpose and Deployment Determination | informative |
| MANAGE 4.1 | Post-Deployment AI System Monitoring | partial |
| MANAGE 4.2 | Continual Improvement Integration | partial |
Evidence (2)
Completed pre-deployment checklist for each AI system deployment or substantial modification, documenting V&V sign-off, impact assessment completion, rollback procedure availability, and deployment approval.
Example: AI Deployment Checklist · Recommendation Engine v2.1 (Jira ticket AI-1203), showing all gates passed, rollback procedure linked, and sign-off by AI system owner on 2026-01-08
Test: Request pre-deployment checklists for a sample of recent AI system releases. Verify: (1) V&V sign-off is recorded, (2) impact assessment is referenced and completed, (3) rollback procedure is documented and linked, (4) operator runbook is available, (5) an authorised owner has approved the deployment, (6) the definition of 'substantial modification' is applied consistently.
AI deployment and change management policy defining the required gates, rollback requirements, and the definition of 'substantial modification' that triggers full pre-deployment controls.
Example: AI Change Management Policy v1.1 (Confluence), defining substantial modification examples (training data source change, model architecture change, inference threshold change), required checklist items, and approval authority per tier
Test: Request the AI deployment/change management policy. Verify: (1) 'substantial modification' is defined with concrete examples, (2) required pre-deployment artefacts are enumerated, (3) rollback procedure requirement is stated, (4) approval authority is defined per AI risk tier, (5) policy applies to third-party model updates where the organisation is deployer.
Questions (2)
Does a documented deployment plan exist for each production AI system, dated before its deployment?
The plan is the artefact, not the intention. An assessor compares the plan date against the deployment record date for a sample of releases; a plan written after go-live does not meet the control.
Which of the following does the deployment plan record for each production AI system?
Options run from the most commonly recorded to the least. Without a worked definition of a substantial modification, teams reach inconsistent judgements about when a change needs the full gate. Retraining on a new data source and a change to an inference threshold are the two cases worth naming.