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

# 07 AIGO AI Change Management Procedure v0.1

# AIGO — AI Governance Operating Framework

## AI Change Management Procedure

**Version:** 0.1\
**Status:** Draft\
**Working Name:** AIGO\
**Full Name:** AI Governance Operating Framework\
**Document Identifier:** AIGO-PROC-007

***

### 1. Purpose

This procedure defines the process for identifying, assessing, approving, implementing, documenting, monitoring, and closing changes to AI systems throughout their lifecycle.

The procedure ensures that changes to AI systems are governed according to their potential impact on risk, controls, compliance, security, privacy, performance, safety, and operational behavior.

***

### 2. Scope

This procedure applies to changes affecting AI systems within the organization's AIGO governance scope.

It applies to:

* AI models;
* AI applications;
* AI agents;
* generative AI systems;
* data and datasets;
* prompts and system instructions;
* AI configurations;
* integrations;
* infrastructure;
* third-party AI services;
* monitoring mechanisms;
* governance controls; and
* operational processes supporting AI systems.

***

### 3. Objectives

The objectives of AI change management are to:

* ensure changes are identified and documented;
* assess the potential impact of changes;
* determine whether reassessment is required;
* maintain appropriate governance controls;
* obtain required approvals;
* prevent unauthorized changes;
* maintain traceability;
* manage implementation risks;
* verify successful implementation; and
* ensure changes do not introduce unacceptable risk.

***

### 4. Change Management Principles

AI changes should be managed according to the following principles:

* risk-based;
* proportionate;
* controlled;
* documented;
* traceable;
* authorized;
* testable;
* reversible where possible; and
* subject to post-change review.

Changes should not be implemented solely because they are technically possible.

***

### 5. Change Ownership

Each material change should have an accountable change owner.

The change owner is responsible for:

* defining the change;
* assessing its impact;
* coordinating required reviews;
* obtaining approval;
* coordinating implementation;
* maintaining evidence; and
* confirming completion.

***

### 6. Change Triggers

A change management process should be initiated when a proposed modification may affect the AI system's:

* intended purpose;
* functionality;
* model;
* data;
* performance;
* security;
* privacy;
* autonomy;
* users;
* integrations;
* controls;
* risk profile; or
* governance classification.

***

### 7. Change Categories

Changes may be categorized according to their potential impact.

A representative classification is:

1. Minor change.
2. Standard change.
3. Material change.
4. Major change.
5. Emergency change.

The organization should define criteria for each category.

***

### 8. Minor Change

A minor change is a change expected to have negligible impact on the AI system's:

* risk;
* intended purpose;
* security;
* privacy;
* performance;
* controls; or
* governance classification.

Minor changes may follow an expedited process where appropriate.

***

### 9. Standard Change

A standard change is a planned change that follows an established and repeatable process.

Examples may include:

* routine configuration updates;
* approved maintenance;
* standard dependency updates;
* routine monitoring changes; and
* predefined operational changes.

Standard changes should remain subject to appropriate authorization and evidence requirements.

***

### 10. Material Change

A material change is a change that may significantly affect the AI system's governance, risk, controls, or intended operation.

Examples may include:

* model replacement;
* significant model update;
* new data sources;
* new intended purpose;
* increased autonomy;
* new user groups;
* new geographic deployment;
* new external integrations;
* major changes to controls; and
* significant changes to system architecture.

Material changes should normally trigger formal impact assessment.

***

### 11. Major Change

A major change is a change with significant potential consequences for:

* safety;
* security;
* privacy;
* compliance;
* business continuity;
* affected individuals;
* financial impact;
* organizational reputation; or
* governance classification.

Major changes should require enhanced governance review and approval.

***

### 12. Emergency Change

An emergency change may be required to:

* address a security incident;
* contain an AI incident;
* prevent significant harm;
* restore critical service;
* address an urgent vulnerability; or
* prevent continued unsafe operation.

Emergency changes should be documented and reviewed retrospectively.

***

### 13. Change Request

Each material change should be documented through a change request.

The change request should identify:

* change description;
* reason;
* affected AI system;
* change owner;
* expected impact;
* dependencies;
* proposed implementation date;
* testing requirements;
* rollback approach; and
* required approvals.

***

### 14. Change Description

The proposed change should be described sufficiently for an informed review.

The description should identify:

* current state;
* proposed state;
* reason for change;
* affected components;
* expected benefits;
* expected risks; and
* known limitations.

***

### 15. Change Impact Assessment

The change owner should assess potential impacts.

The assessment should consider:

* risk;
* classification;
* controls;
* security;
* privacy;
* compliance;
* performance;
* safety;
* human oversight;
* monitoring;
* business continuity; and
* third-party dependencies.

***

### 16. Risk Reassessment

A change should trigger risk reassessment when it may materially alter the AI system's risk profile.

Risk reassessment may be required when:

* likelihood changes;
* impact changes;
* new risks emerge;
* existing controls become ineffective;
* autonomy increases;
* new stakeholders are affected; or
* the operating context changes.

***

### 17. Classification Reassessment

The AI system's classification should be reviewed when a change may affect governance significance.

Triggers may include:

* increased autonomy;
* increased impact;
* new affected populations;
* new decision authority;
* increased scale;
* new regulatory exposure; or
* significant changes in business criticality.

***

### 18. Control Impact Assessment

The change owner should determine whether existing controls remain appropriate.

The assessment should identify:

* affected controls;
* controls requiring modification;
* new controls;
* controls becoming unnecessary;
* control testing requirements; and
* evidence requirements.

***

### 19. Security Impact Assessment

Changes should be reviewed for security impact where appropriate.

The assessment may consider:

* new interfaces;
* new permissions;
* new credentials;
* attack surface;
* model security;
* data exposure;
* third-party dependencies; and
* security monitoring.

***

### 20. Privacy Impact Assessment

Where personal or sensitive data is affected, the change should be reviewed for privacy impact.

The assessment may consider:

* new data;
* new processing purposes;
* data sharing;
* retention;
* access;
* profiling;
* affected individuals; and
* privacy controls.

***

### 21. Compliance Impact Assessment

The change should be assessed for changes to applicable:

* laws;
* regulations;
* contractual requirements;
* internal policies;
* industry requirements; and
* governance obligations.

***

### 22. Human Oversight Impact

Changes should be assessed for their effect on human oversight.

The assessment should consider whether the change affects:

* reviewer responsibilities;
* intervention;
* override capability;
* workload;
* competence;
* escalation; or
* decision authority.

***

### 23. Data Changes

Changes to data should be governed appropriately.

Data changes may include:

* new datasets;
* new data sources;
* changed data distributions;
* changed data quality;
* changed retention;
* changed access;
* new personal data; and
* new sensitive data.

***

### 24. Model Changes

Model changes should be documented and assessed.

Model changes may include:

* model replacement;
* model version update;
* retraining;
* fine-tuning;
* parameter changes;
* architecture changes;
* provider changes; and
* changes in model configuration.

***

### 25. Prompt and Instruction Changes

Changes to prompts, system instructions, policies, or agent instructions should be assessed where they may affect AI behavior.

The assessment should consider:

* changed outputs;
* changed permissions;
* changed decision behavior;
* safety implications;
* security implications; and
* new unintended behavior.

***

### 26. Integration Changes

Changes to external systems and interfaces should be assessed.

Integration changes may affect:

* data flow;
* permissions;
* authentication;
* dependencies;
* availability;
* security;
* privacy; and
* operational resilience.

***

### 27. Autonomy Changes

Any increase in AI autonomy should receive enhanced review.

The assessment should consider:

* new actions;
* new tools;
* expanded permissions;
* reduced human intervention;
* transaction authority;
* action reversibility; and
* monitoring.

***

### 28. Third-Party Changes

Changes made by third-party AI providers should be monitored and assessed.

Examples include:

* model updates;
* service changes;
* data processing changes;
* terms changes;
* infrastructure changes;
* security changes; and
* service retirement.

The organization should determine whether provider changes require reassessment or approval.

***

### 29. Change Dependencies

Material dependencies should be identified before implementation.

Dependencies may include:

* other AI systems;
* applications;
* infrastructure;
* datasets;
* APIs;
* suppliers;
* human processes; and
* governance controls.

***

### 30. Change Testing

Material changes should be tested before production implementation where appropriate.

Testing may include:

* functional testing;
* performance testing;
* security testing;
* privacy testing;
* fairness testing;
* robustness testing;
* safety testing;
* integration testing; and
* regression testing.

***

### 31. Change Validation

Testing should determine whether the changed system continues to meet defined requirements.

Validation should consider:

* intended purpose;
* expected performance;
* control requirements;
* risk tolerance;
* approval conditions; and
* applicable governance requirements.

***

### 32. Regression Testing

Where a change may affect existing functionality, regression testing should be performed.

Regression testing should confirm that previously acceptable functionality has not been materially degraded.

***

### 33. Rollback Planning

Material changes should have a rollback or recovery strategy where technically feasible.

The rollback plan should identify:

* rollback trigger;
* rollback method;
* responsible owner;
* expected recovery time;
* dependencies; and
* validation after rollback.

***

### 34. Change Approval

Changes should receive approval appropriate to their category and risk.

Approval may require review by:

* AI system owner;
* risk owner;
* AI governance;
* security;
* privacy;
* legal;
* compliance;
* technical authority; or
* executive authority.

***

### 35. Change Approval Conditions

Approval may include conditions.

Conditions should specify:

* required action;
* responsible owner;
* deadline;
* evidence;
* verification; and
* consequences of non-compliance.

***

### 36. Change Implementation

Approved changes should be implemented according to an authorized implementation plan.

The plan should identify:

* implementation steps;
* responsible personnel;
* dependencies;
* timing;
* testing;
* monitoring;
* rollback; and
* communication.

***

### 37. Change Documentation

Implementation evidence should be maintained.

Evidence may include:

* change request;
* approval;
* test results;
* configuration records;
* deployment records;
* validation results;
* monitoring results; and
* closure evidence.

***

### 38. Change Monitoring

The changed AI system should be monitored after implementation.

Monitoring should consider:

* performance;
* errors;
* incidents;
* security;
* privacy;
* control effectiveness;
* user feedback; and
* unexpected behavior.

***

### 39. Post-Implementation Review

Material changes should receive a post-implementation review where appropriate.

The review should determine whether:

* the change achieved its objective;
* unexpected impacts occurred;
* controls remain effective;
* risks remain acceptable;
* monitoring is adequate; and
* further action is required.

***

### 40. Change Closure

A change should be formally closed when:

* implementation is complete;
* testing is complete;
* required validation is complete;
* monitoring is operational;
* documentation is updated;
* conditions are satisfied; and
* required approvals are confirmed.

***

### 41. Failed Changes

A failed change should be documented and investigated according to its significance.

The organization should determine:

* cause;
* impact;
* rollback;
* incident implications;
* risk implications;
* control implications; and
* corrective actions.

***

### 42. Unauthorized Changes

Unauthorized changes should be identified and investigated.

Actions may include:

* containment;
* rollback;
* incident management;
* risk assessment;
* corrective action; and
* escalation.

***

### 43. Emergency Change Review

Emergency changes should receive retrospective review.

The review should confirm:

* reason for emergency;
* authorization;
* implementation;
* impact;
* testing;
* monitoring;
* rollback; and
* required follow-up actions.

***

### 44. Change Records

The organization should maintain a change record for material changes.

The record should contain:

* change identifier;
* AI system;
* description;
* category;
* owner;
* assessment;
* approvals;
* implementation;
* testing;
* monitoring;
* outcome; and
* closure date.

***

### 45. Change Traceability

Change records should maintain traceability to relevant governance artifacts.

The organization should be able to demonstrate:

**Change → Impact Assessment → Risk → Controls → Testing → Approval → Implementation → Monitoring → Closure**

***

### 46. Change Reporting

The AI governance function should report material changes as appropriate.

Reporting may include:

* changes by category;
* material changes;
* emergency changes;
* failed changes;
* unauthorized changes;
* overdue changes; and
* changes requiring reassessment.

***

### 47. Change Metrics

Organizations may establish change management metrics.

Examples include:

* change success rate;
* failed changes;
* emergency changes;
* unauthorized changes;
* rollback events;
* overdue changes;
* change approval time; and
* post-implementation findings.

***

### 48. Change Freeze

The organization may establish change-freeze periods for critical systems or sensitive operational periods.

During a change freeze:

* only approved exceptions should proceed;
* emergency changes should follow emergency procedures; and
* required authorization should be documented.

***

### 49. Change Communication

Material changes should be communicated to relevant stakeholders.

Communication may include:

* change scope;
* implementation date;
* expected impact;
* operational instructions;
* known limitations;
* monitoring requirements; and
* escalation contacts.

***

### 50. Change Training

Where a change affects users or operators, appropriate training should be completed before or during implementation.

Training may address:

* changed functionality;
* changed responsibilities;
* changed risks;
* new controls;
* new procedures; and
* escalation requirements.

***

### 51. Change and Approval Lifecycle

Change management should remain connected to the AI governance lifecycle.

Material changes may require updates to:

* AI System Profile;
* classification;
* risk assessment;
* control assessment;
* approval;
* monitoring;
* assurance; and
* documentation.

***

### 52. Responsibilities

**Change Owner**

* define the change;
* conduct or coordinate impact assessment;
* obtain approval;
* coordinate implementation;
* maintain evidence; and
* confirm closure.

**AI System Owner**

* assess operational impact;
* ensure governance requirements remain satisfied;
* approve changes within authority;
* monitor outcomes; and
* initiate reassessment where required.

**AI Governance Function**

* maintain change governance;
* review material changes;
* determine escalation requirements;
* monitor change compliance; and
* maintain governance records.

**Specialist Functions**

* provide security, privacy, legal, compliance, risk, technical, safety, or other specialist review where required.

***

### 53. Change Management Workflow

The standard workflow should be:

1. Identify proposed change.
2. Register change request.
3. Categorize change.
4. Assess impact.
5. Determine whether risk reassessment is required.
6. Determine whether classification reassessment is required.
7. Assess control impact.
8. Conduct specialist assessments where required.
9. Define testing requirements.
10. Define rollback strategy.
11. Obtain required approval.
12. Implement change.
13. Monitor implementation.
14. Validate results.
15. Conduct post-implementation review where required.
16. Update governance records.
17. Close change.

***

### 54. Continuous Improvement

The change management process should be improved based on:

* failed changes;
* incidents;
* rollback events;
* assurance findings;
* audit findings;
* user feedback;
* operational experience;
* regulatory developments; and
* changes in AI technology.

***

### 55. Procedure Review

This procedure should be reviewed periodically and when material changes occur.

Review triggers may include:

* changes to AIGO requirements;
* significant incidents;
* major technology changes;
* regulatory developments;
* assurance findings;
* recurring change failures; and
* implementation experience.

Material changes should be versioned and approved according to applicable document governance requirements.

***

### 56. Procedure Status

**Document:** AIGO AI Change Management Procedure

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-PROC-007`

**Document Type:** Operational Procedure

This procedure establishes the operational process for governing changes to AI systems throughout their lifecycle under the AIGO framework.

***