> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 08 AIGO AI Change Management Example v0.1

# 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

```text id="9r9z0j" theme={null}
Change Identified
   ↓
Register Change
   ↓
Classify Change
   ↓
Impact Assessment
   ↓
Risk Assessment
   ↓
Control Assessment
   ↓
Testing
   ↓
Evidence Review
   ↓
Approval
   ↓
Implementation
   ↓
Validation
   ↓
Monitoring
   ↓
Close
   ↓
Learn / Improve
```

***

# 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.

| Change Class | Description                                                             |
| ------------ | ----------------------------------------------------------------------- |
| Minor        | Limited impact with no material change to AI behavior                   |
| Significant  | Potential material impact requiring formal review                       |
| Material     | Significant change to model, purpose, data, risk, controls, or behavior |
| Emergency    | Urgent change required to address immediate risk or operational threat  |

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:

| Area                | Impact |
| ------------------- | ------ |
| AI behavior         | High   |
| Performance         | High   |
| Fairness            | High   |
| Privacy             | Medium |
| Security            | Medium |
| Human oversight     | Medium |
| Explainability      | Medium |
| Operational process | Medium |
| Risk profile        | High   |

***

# 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:

| Risk ID | Risk                       | Change Impact |
| ------- | -------------------------- | ------------- |
| R-001   | Biased recommendations     | High          |
| R-005   | Inaccurate recommendations | High          |
| R-006   | Model drift                | High          |
| R-007   | Uncontrolled change        | High          |
| R-009   | Reduced explainability     | Medium        |

***

# 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.

| Control             | Status              |
| ------------------- | ------------------- |
| Change Management   | Effective           |
| Risk Assessment     | Effective           |
| Model Validation    | Effective           |
| Fairness Testing    | Effective           |
| Human Oversight     | Effective           |
| Monitoring          | Partially Effective |
| Rollback            | Effective           |
| Incident Management | Effective           |

***

# 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

```text id="o8g0h6" theme={null}
Change Request
   ↓
Impact Assessment
   ↓
Risk Assessment
   ↓
Control Assessment
   ↓
Test Plan
   ↓
Test Results
   ↓
Evidence
   ↓
Approval
   ↓
Deployment
   ↓
Monitoring
```

***

# 34. Change Approval Package

The approval package contains:

| Item                    | Status   |
| ----------------------- | -------- |
| Change request          | Complete |
| Impact assessment       | Complete |
| Risk assessment         | Complete |
| Control assessment      | Complete |
| Testing                 | Complete |
| Monitoring update       | Complete |
| Rollback plan           | Complete |
| Residual risk           | Complete |
| Approval recommendation | Complete |

***

# 35. Residual Risk

Following testing and treatment:

| Risk                       | Residual Level |
| -------------------------- | -------------- |
| Biased recommendations     | Medium         |
| Inaccurate recommendations | Low            |
| Model drift                | Medium         |
| Uncontrolled change        | Low            |
| Reduced explainability     | Low            |

***

# 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

```text id="l8f1es" theme={null}
Approved Change
      ↓
Controlled Release
      ↓
Limited Operation
      ↓
Enhanced Monitoring
      ↓
Validation
      ↓
Expand / Roll Back
```

***

# 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

| Field              | Value        |
| ------------------ | ------------ |
| Change ID          | CHG-AI-001   |
| AI System          | AI-HR-001    |
| Change Type        | Model Update |
| Classification     | Material     |
| Risk Assessment    | Complete     |
| Control Assessment | Complete     |
| Testing            | Passed       |
| Approval           | Approved     |
| Deployment         | Completed    |
| Monitoring         | Completed    |
| Rollback           | Not Required |
| Status             | Closed       |

***

# 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

```text id="6b42at" theme={null}
Emergency Detected
       ↓
Immediate Risk Assessment
       ↓
Emergency Authorization
       ↓
Controlled Change
       ↓
Validation
       ↓
Enhanced Monitoring
       ↓
Retrospective Review
```

***

# 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

```text id="l4g6b2" theme={null}
Post-Deployment Monitoring
          ↓
Unexpected Behavior
          ↓
Risk Assessment
       /       \
Acceptable    Unacceptable
   ↓              ↓
Continue        Rollback
                   ↓
              Investigation
                   ↓
              Corrective Action
```

***

# 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.

```text id="ydj3nt" theme={null}
Identify
   ↓
Classify
   ↓
Assess
   ↓
Approve
   ↓
Deploy
   ↓
Operate
   ↓
Monitor
   ↓
Change
   ↓
Reassess
   ↓
Approve
   ↓
Continue / Roll Back / Retire
```

***

# 57. Change Traceability

A complete change should be traceable to:

| Element      | Identifier                    |
| ------------ | ----------------------------- |
| AI System    | AI-HR-001                     |
| Change       | CHG-AI-001                    |
| Risk         | R-001 / R-005 / R-006 / R-007 |
| Controls     | Applicable AIGO controls      |
| Model        | MODEL-V2                      |
| Test Package | TEST-AI-001                   |
| Deployment   | DEP-AI-001                    |
| Approval     | APR-AI-001                    |
| Monitoring   | MON-AI-001                    |

***

# 58. Change Roles

| Role               | Responsibility                    |
| ------------------ | --------------------------------- |
| Change Owner       | Coordinates change                |
| System Owner       | System accountability             |
| Model Owner        | Technical change                  |
| Risk Owner         | Risk assessment                   |
| Control Owners     | Control evaluation                |
| Testing Lead       | Testing and evidence              |
| Governance Lead    | Governance review                 |
| Approval Authority | Approval decision                 |
| Operations         | Deployment                        |
| Assurance          | Independent review where required |

***

# 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:

| Function | Change Contribution                     |
| -------- | --------------------------------------- |
| GOVERN   | Change accountability and approval      |
| MAP      | Change context and impact               |
| MEASURE  | Testing and evaluation                  |
| MANAGE   | Risk treatment and deployment decisions |

***

# 67. Complete Change Management Model

```text id="l6v0si" theme={null}
Change Identified
   ↓
Register
   ↓
Classify
   ↓
Impact Assessment
   ↓
Risk Assessment
   ↓
Control Assessment
   ↓
Testing
   ↓
Evidence Review
   ↓
Approval
   ↓
Controlled Deployment
   ↓
Validation
   ↓
Enhanced Monitoring
   ↓
Continue / Roll Back
   ↓
Close
   ↓
Learn
   ↓
Improve
```

***

# 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**