Skip to main content

​
AIGO — AI Change Management Example

​
AIGO — AI Governance Operating Framework

Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-EXAMPLE-008 Document Type: Implementation Example Example Type: AI Change Management

​
1. Purpose

This document provides an illustrative example of how an organization can identify, assess, approve, implement, verify, and close changes to an AI system using the AIGO AI Governance Operating Framework. The example demonstrates how AI change management connects:
  • change identification;
  • AI system registration;
  • lifecycle management;
  • risk assessment;
  • control assessment;
  • evidence;
  • testing;
  • approval;
  • deployment;
  • monitoring;
  • incident management;
  • continual improvement.
This document is an implementation example and does not constitute legal, regulatory, audit, certification, or legal-compliance advice.

​
2. Example Organization

For this example, the organization is ExampleCorp, a fictional organization implementing AIGO. The organization operates an AI-enabled recruitment-support system.

​
3. AI System

System Name: Candidate Assessment Assistant AI System ID: AI-HR-001 Business Function: Human Resources Classification: Class 3 — Enhanced Governance Lifecycle Stage: Operate System Owner: HR AI System Owner Model Owner: AI/ML Engineering Lead Risk Owner: Enterprise Risk Manager

​
4. Change Scenario

ExampleCorp plans to introduce a new model version for the Candidate Assessment Assistant. The new version is expected to:
  • improve candidate-summary accuracy;
  • improve processing speed;
  • update the underlying language model;
  • modify one preprocessing component;
  • change the model’s inference configuration.
Because the change may affect AI behavior, risk, controls, performance, and affected stakeholders, the change is submitted to the AIGO change-management process.

​
5. Change Objective

The objective is to ensure that the proposed change:
  1. is identified;
  2. is properly classified;
  3. is assessed for impact;
  4. is risk assessed;
  5. is tested;
  6. has appropriate controls;
  7. receives required approval;
  8. is implemented in a controlled manner;
  9. is monitored after deployment;
  10. can be rolled back when necessary.

​
6. Change Management Principle

AI changes should not be treated solely as technical changes. A change may affect:
  • AI behavior;
  • model performance;
  • fairness;
  • privacy;
  • security;
  • explainability;
  • human oversight;
  • risk;
  • controls;
  • regulatory obligations;
  • system classification.

​
7. Change Lifecycle

​
8. Change Record

Change ID: CHG-AI-001 AI System: AI-HR-001 Change Type: Model Update Change Classification: Material AI Change Requested By: Model Owner Change Owner: AI/ML Engineering Lead Status: Assessment

​
9. Change Description

The proposed change includes:
  • replacing the current language model with a newer model version;
  • updating preprocessing logic;
  • modifying inference parameters;
  • updating model configuration;
  • retraining selected supporting components.
The change is expected to improve performance but may also change system behavior.

​
10. Why the Change Requires Governance

The change could affect:
  • recommendation quality;
  • fairness;
  • candidate treatment;
  • system outputs;
  • latency;
  • security;
  • privacy;
  • explainability;
  • monitoring indicators;
  • previously established risk assumptions.
Therefore, the change cannot be treated as an ordinary software update.

​
11. Change Classification

AIGO classifies changes according to their potential impact. This example is classified as: Material AI Change

​
12. Change Classification Criteria

The organization considers whether the change affects:
  • intended purpose;
  • model architecture;
  • model version;
  • training data;
  • inference data;
  • data pipeline;
  • feature engineering;
  • model parameters;
  • system interfaces;
  • human oversight;
  • risk;
  • control requirements;
  • system classification.

​
13. Change Impact Assessment

The change is assessed across:

​
14. Impact Assessment Conclusion

The proposed change may materially alter AI outputs. The organization therefore requires:
  • formal risk reassessment;
  • control reassessment;
  • testing;
  • governance approval;
  • post-deployment monitoring.

​
15. Change and Intended Purpose

The intended purpose remains unchanged. The system continues to provide recruitment-support recommendations. The system must not be expanded to make autonomous final hiring decisions as part of this change.

​
16. Change and System Classification

The organization reassesses classification. Previous Classification: Class 3 Post-Change Classification: Class 3 The classification remains unchanged because the intended purpose and impact category remain the same.

​
17. Change Risk Assessment

The organization identifies:

​
18. Risk Treatment

Treatment measures include:
  • benchmark testing;
  • fairness testing;
  • regression testing;
  • human review;
  • shadow deployment;
  • enhanced monitoring;
  • rollback capability;
  • approval controls.

​
19. Control Assessment

Relevant controls are reassessed.

​
20. Monitoring Gap

The existing monitoring process does not fully account for a new model-specific performance indicator. The organization therefore requires a monitoring update before production deployment.

​
21. Change Testing Strategy

The change is tested through:
  1. functional testing;
  2. regression testing;
  3. performance testing;
  4. fairness testing;
  5. security testing;
  6. privacy testing where applicable;
  7. explainability testing;
  8. human-oversight testing;
  9. operational testing.

​
22. Test Environment

Testing is performed in an environment separated from production. The test environment uses:
  • controlled datasets;
  • documented model version;
  • controlled configuration;
  • repeatable test procedures;
  • captured test evidence.

​
23. Functional Testing

Functional testing verifies that:
  • inputs are processed correctly;
  • outputs are generated correctly;
  • interfaces remain functional;
  • expected workflows continue to operate;
  • errors are handled appropriately.
Result: Passed.

​
24. Regression Testing

Regression testing compares the new model against the current production version. The comparison evaluates:
  • accuracy;
  • output consistency;
  • error rates;
  • edge cases;
  • known failure modes.
Result: Passed with minor documented differences.

​
25. Fairness Testing

Fairness testing compares relevant performance indicators across defined groups. The organization evaluates:
  • recommendation differences;
  • error-rate differences;
  • false-positive differences;
  • false-negative differences;
  • distribution changes.
Result: Within approved thresholds.

​
26. Performance Testing

The new model demonstrates:
  • improved response time;
  • improved candidate-summary accuracy;
  • acceptable resource consumption.
Result: Passed.

​
27. Security Testing

Testing evaluates:
  • access control;
  • authentication;
  • authorization;
  • API exposure;
  • logging;
  • model endpoint security;
  • dependency vulnerabilities.
Result: Passed.

​
28. Privacy Testing

Where applicable, testing verifies:
  • approved data use;
  • data minimization;
  • access restrictions;
  • retention behavior;
  • handling of sensitive information.
Result: Passed.

​
29. Explainability Testing

The organization verifies that users continue to receive sufficient information to understand the basis and limitations of AI-generated recommendations. Result: Acceptable.

​
30. Human Oversight Testing

Human reviewers test whether they can:
  • review outputs;
  • challenge recommendations;
  • override recommendations;
  • identify uncertainty;
  • access relevant supporting information.
Result: Passed.

​
31. Rollback Testing

The organization verifies that the previous production model can be restored. Rollback testing confirms:
  • previous version remains available;
  • configuration is preserved;
  • deployment procedure works;
  • data compatibility exists;
  • rollback authorization is defined.
Result: Passed.

​
32. Testing Evidence

The evidence package contains:
  • test plans;
  • test results;
  • test datasets;
  • model version identifiers;
  • configuration records;
  • fairness results;
  • security results;
  • privacy results;
  • rollback results;
  • approval recommendation.

​
33. Change Evidence Chain

​
34. Change Approval Package

The approval package contains:

​
35. Residual Risk

Following testing and treatment:

​
36. Change Approval Decision

Decision: Approved for Controlled Deployment Conditions:
  1. deploy through controlled release;
  2. activate enhanced monitoring;
  3. retain rollback capability;
  4. conduct post-deployment validation;
  5. complete formal change closure.

​
37. Deployment Strategy

ExampleCorp uses a controlled deployment approach. The new model is initially released to a limited operational population. Monitoring is increased during the initial deployment period.

​
38. Controlled Deployment Model

​
39. Deployment Record

Deployment ID: DEP-AI-001 Change ID: CHG-AI-001 Model Version: MODEL-V2 Deployment Date: TBD Deployment Owner: AI/ML Engineering Lead Approval Authority: AI Governance Committee

​
40. Post-Deployment Validation

The organization verifies:
  • model performance;
  • fairness;
  • error rates;
  • user feedback;
  • system stability;
  • monitoring indicators;
  • incident indicators.

​
41. Post-Deployment Monitoring

For the first 30 days:
  • performance is monitored daily;
  • fairness indicators are reviewed daily;
  • incidents are escalated immediately;
  • model drift is monitored continuously where technically feasible;
  • governance reporting occurs weekly.

​
42. Monitoring Results

After deployment: Performance: Improved Fairness: Within approved thresholds Security: No material issues Privacy: No material issues User Feedback: Positive Incidents: None Rollback: Not required

​
43. Change Closure Criteria

The change may be closed when:
  • deployment is successful;
  • monitoring results are acceptable;
  • no unresolved critical issue remains;
  • required evidence is complete;
  • residual risk is acceptable;
  • documentation is updated;
  • ownership is confirmed;
  • approval conditions are satisfied.

​
44. Change Closure Decision

Change ID: CHG-AI-001 Status: Closed Closure Basis:
  • testing completed;
  • deployment completed;
  • monitoring completed;
  • no material incidents detected;
  • residual risk accepted;
  • documentation updated.

​
45. Change Record

​
46. Emergency Change Scenario

AIGO also supports emergency changes. An emergency change may be required where:
  • a critical security vulnerability exists;
  • a severe AI incident occurs;
  • continued operation creates unacceptable risk;
  • a critical operational failure occurs.
Emergency changes should still be:
  • authorized;
  • documented;
  • risk assessed as far as practicable;
  • monitored;
  • reviewed retrospectively.

​
47. Emergency Change Model

​
48. Change Rejection

A change should be rejected or deferred where:
  • risk becomes unacceptable;
  • testing fails;
  • critical controls fail;
  • evidence is insufficient;
  • rollback is unavailable where required;
  • intended purpose becomes unclear;
  • governance approval cannot be obtained.

​
49. Change Suspension

An approved change may be suspended if:
  • deployment causes unexpected behavior;
  • monitoring detects material deterioration;
  • incidents occur;
  • residual risk increases;
  • approval conditions are violated.

​
50. Rollback

Rollback should restore the system to the last approved state where technically feasible. Rollback may be initiated when:
  • critical performance degradation occurs;
  • unacceptable fairness deterioration occurs;
  • security issues are discovered;
  • operational instability occurs;
  • material unexpected behavior is detected.

​
51. Rollback Decision Model

​
52. Change and Approval

A material AI change should normally require approval before production implementation unless an authorized emergency process applies. Approval should consider:
  • change impact;
  • risk;
  • controls;
  • testing;
  • evidence;
  • residual risk;
  • rollback capability.

​
53. Change and Risk Management

Every material change should be evaluated for its potential effect on existing risks. A change can:
  • reduce risk;
  • increase risk;
  • create new risk;
  • eliminate risk;
  • change risk ownership;
  • change control requirements.

​
54. Change and Controls

A change may require:
  • new controls;
  • modified controls;
  • retired controls;
  • additional monitoring;
  • additional evidence;
  • changed approval thresholds.

​
55. Change and Evidence

Evidence should demonstrate:
  • what changed;
  • why it changed;
  • who authorized it;
  • what was tested;
  • what risks were assessed;
  • what controls were evaluated;
  • what results were obtained;
  • what was deployed;
  • what happened afterward.

​
56. Change and Lifecycle

Change management operates throughout the AI lifecycle.

​
57. Change Traceability

A complete change should be traceable to:

​
58. Change Roles

​
59. Segregation of Duties

Where practical:
  • change requester proposes the change;
  • technical owner implements the change;
  • risk owner evaluates risk;
  • control owners assess controls;
  • testing personnel validate results;
  • approval authority authorizes deployment.
The person implementing a material change should not unilaterally approve it.

​
60. Change Management Checklist

  • Change identified
  • Change registered
  • Change classification completed
  • Impact assessment completed
  • Intended purpose reviewed
  • Classification reassessed
  • Risk assessment completed
  • Controls reassessed
  • Test plan approved
  • Functional testing completed
  • Regression testing completed
  • Fairness testing completed
  • Security testing completed
  • Privacy testing completed where applicable
  • Human oversight tested
  • Rollback tested
  • Evidence package completed
  • Residual risk assessed
  • Change approved
  • Deployment completed
  • Post-deployment monitoring completed
  • Change closed

​
61. Lessons Learned

The example demonstrates that:
  1. AI changes can alter risk even when intended purpose remains unchanged;
  2. model updates require structured assessment;
  3. testing must include governance-relevant characteristics;
  4. rollback capability is important;
  5. post-deployment monitoring is part of change management;
  6. change records must remain traceable;
  7. material changes may require renewed approval.

​
62. Continual Improvement

Change management results should feed continual improvement. Lessons may lead to:
  • new controls;
  • updated procedures;
  • revised risk criteria;
  • improved testing;
  • improved monitoring;
  • revised approval thresholds;
  • updated training.

​
63. Relationship to AIGO Procedures

This example should be implemented through the applicable AIGO procedures, particularly:
  • AI Change Management Procedure;
  • AI System Registration Procedure;
  • AI Classification Procedure;
  • AI Risk Assessment Procedure;
  • AI Control Assessment Procedure;
  • AI Approval Procedure;
  • AI Monitoring Procedure;
  • AI Incident Management Procedure;
  • AI Assurance Procedure;
  • Continuous Improvement Procedure.

​
64. Relationship to AIGO Controls

The change-management example demonstrates interaction between:
  • governance controls;
  • risk controls;
  • model controls;
  • human oversight controls;
  • testing controls;
  • monitoring controls;
  • approval controls;
  • incident controls.

​
65. Relationship to ISO/IEC 42001

AI change management can support an AI management system by maintaining controlled operational changes, risk consideration, documented information, monitoring, evaluation, corrective action, and continual improvement. Applicable ISO/IEC 42001 requirements should be evaluated separately by the implementing organization.

​
66. Relationship to NIST AI RMF

The change-management process can support activities associated with:

​
67. Complete Change Management Model

​
68. Key Governance Principles

​
68.1 No Uncontrolled Material Changes

Material AI changes should be governed before implementation.

​
68.2 Change Impact Must Be Assessed

Technical changes may have governance consequences.

​
68.3 Risk Must Be Reassessed

Existing risk assumptions may no longer be valid after a material change.

​
68.4 Controls Must Be Reassessed

A change may affect control effectiveness.

​
68.5 Testing Must Be Evidence-Based

Testing results should be retained as controlled evidence.

​
68.6 Deployment Must Be Controlled

Production implementation should follow an authorized deployment process.

​
68.7 Monitoring Continues After Deployment

Change completion does not mean governance completion.

​
68.8 Rollback Must Be Considered

Where practical, the organization should retain the ability to return to an approved state.

​
69. Final Example Decision

ExampleCorp determines that CHG-AI-001 is a material AI change and authorizes controlled deployment after completion of the required assessment, testing, evidence review, and approval activities. The change is subsequently monitored and formally closed after successful validation.

​
70. Document Status

Document: AIGO — AI Change Management Example Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-EXAMPLE-008 Document Type: Implementation Example Example Type: AI Change Management This document provides an illustrative example of how an AI system change can be governed from initial identification through assessment, approval, controlled deployment, monitoring, validation, closure, and continual improvement.

​
71. End of Example Document

AIGO — AI Change Management Example Document ID: AIGO-EXAMPLE-008 Version: 0.1 Status: Draft End of Document