Category: Model Lifecycle & MLOps

Change Management

Also known as: Organizational Change Management, Change Control

Simply put

Change management is a structured approach an organization uses to move from its current way of working to a desired future state, with particular attention to guiding the people affected through the transition. It typically involves preparing the organization for change, planning it, putting it into practice, and reviewing the results. In the context of AI systems, it commonly refers to how modifications to models, data, or processes are proposed, reviewed, and implemented in a controlled way.

Formal definition

As commonly defined in the general management literature, change management is the coordinated, structured set of methods and practices an organization uses to transition from a current to a desired future state, emphasizing the human element as well as changes to internal and external processes. Commonly described process steps include preparing the organization, planning, implementation, embedding, and review. Note that the evidence provided describes change management as a general organizational discipline and does not address the narrower, technical sense of 'change control' as applied to AI or model risk management; in model governance contexts change management is often operationalized as controls over version changes, retraining, recalibration, and configuration modifications, with associated approval, documentation, and revalidation requirements. This distinction between organizational change management and technical change control should not be conflated, and the specific control expectations vary by framework and sector and are out of scope for this evidence packet.

Why it matters

Change management matters because organizational transitions frequently fail not on technical grounds but on the human element—how people affected by a change are prepared, guided, and supported through it. As the evidence describes, change management is fundamentally the art and science of navigating organizational transitions with attention to that human dimension, alongside changes to internal and external processes. Without a coordinated, structured approach to moving from a current to a desired future state, organizations risk poorly adopted changes, inconsistent implementation, and outcomes that are not embedded or reviewed.

In AI governance contexts, the concept is especially salient because modifications to models, data, or processes can carry consequences that are difficult to reverse once deployed at scale. A structured approach to how changes are proposed, reviewed, and implemented supports controlled transitions rather than ad hoc ones. It is important to note, however, that the general organizational discipline of change management should not be conflated with the narrower technical sense of 'change control' as applied to model risk management. The evidence packet here addresses change management as a general organizational discipline; it does not establish specific technical control expectations for AI systems, which vary by framework and sector.

Because the distinction between organizational change management and technical change control is one that practitioners frequently blur, treating them as interchangeable can lead to gaps—either overlooking the human transition needs when focusing only on version controls, or assuming a governance policy addresses model-level controls when it addresses only organizational adoption. Managing this distinction carefully helps organizations reduce, though not eliminate, the risks associated with change.

Who it's relevant to

AI Governance and Policy Specialists

Professionals establishing organizational structures and oversight for AI systems use change management as a discipline for guiding transitions in how AI is developed, deployed, and used. They are typically responsible for the coordinated, structured approach to moving the organization from current to future states, with attention to how affected people are prepared and supported.

Model Risk Managers

Those managing model risk should understand where organizational change management overlaps with, but remains distinct from, technical change control over model versions, retraining, recalibration, and configuration modifications. The specific control expectations—including approval, documentation, and revalidation requirements—vary by framework and sector and are not defined by the general management evidence underlying this entry.

Compliance Officers and Auditors

Compliance and audit professionals evaluate whether changes are proposed, reviewed, and implemented in a controlled way. They benefit from distinguishing the organizational discipline of change management from the narrower technical sense of change control, so that assessments do not assume one addresses the other.

Data Scientists and Model Developers

Practitioners who modify models, data, or processes are directly affected by change management practices, which govern how modifications move through preparation, planning, implementation, embedding, and review. The precise technical requirements they must follow depend on the applicable framework and sector.

Inside Change Management

Change Identification and Documentation

The process of recording proposed modifications to an AI system or model, including changes to input data, features, model architecture, hyperparameters, thresholds, deployment environment, or intended use. In many model risk frameworks, documentation of what changed and why is a prerequisite for downstream review.

Change Classification / Materiality Assessment

An evaluation that categorizes a change by its potential impact, often distinguishing material changes (which may trigger revalidation or governance sign-off) from minor or routine changes. The specific thresholds and categories vary by organization and are typically defined in internal policy rather than by a single external standard.

Review and Approval Workflow

The defined path through which a change moves for evaluation and authorization, commonly involving roles across governance and risk functions. This connects to accountability structures (an AI governance concern) and to the assessment of risk introduced by the change (a model risk management concern), which overlap here without being identical.

Testing and Revalidation Considerations

The determination of whether a change requires re-testing, verification (confirming the system was built correctly per specification), or validation (confirming the model is suitable for its intended purpose). In many frameworks a material change to a model can prompt some level of revalidation before deployment.

Versioning and Change History

The maintenance of a record of successive versions and the changes between them, supporting traceability, rollback, and audit. This is frequently relied upon by third-line functions such as internal audit and by external reviewers.

Post-Change Monitoring

Ongoing observation after a change is deployed to detect unexpected effects, including performance shifts. Note that monitoring for performance degradation is distinct from monitoring model risk more broadly, though a change management process may address both.

Common questions

Answers to the questions practitioners most commonly ask about Change Management.

Is change management for AI models the same as ongoing monitoring?

No, though they are related and often confused. Change management, as commonly defined, is the set of controls governing how modifications to a model, its inputs, its code, or its operating environment are proposed, reviewed, approved, documented, and implemented. Ongoing monitoring tracks whether a deployed model continues to perform as expected over time. Monitoring may detect conditions that trigger a change (for example, performance degradation), but the act of managing that change—authorization, revalidation where warranted, and documentation—is a distinct control. Treating them as interchangeable can leave changes undocumented or unapproved even when monitoring is robust.

Does having a change management process mean every model change eliminates the associated risk?

No. Change management is a control that helps reduce and manage the risk introduced by modifications; it does not eliminate risk. A well-run process improves the likelihood that changes are appropriately reviewed and that residual risk is understood, but it cannot guarantee that no error or unintended consequence remains. Professionals should describe change management as a mechanism for controlling and documenting change-related risk rather than as a means of removing it.

What kinds of changes typically fall within the scope of a model change management process?

In many frameworks, scope includes changes to model methodology or algorithms, changes to input data sources or feature definitions, code or implementation changes, recalibration or retraining, and changes to the operating environment or intended use. Some frameworks also treat changes in the assumptions or limitations documented for a model as in-scope. Organizations often define materiality thresholds to distinguish changes that require full review and revalidation from minor changes handled through lighter-touch procedures. The precise scope varies by organization and sector, so what is treated as material in banking model risk contexts may differ from general enterprise AI settings.

How is change management typically documented?

Documentation commonly includes a description of the proposed change, its rationale, an assessment of its potential impact, the approvals obtained, any testing or validation performed, and the date and responsible parties for implementation. Version control of models, code, and data definitions supports traceability. The level of detail expected typically scales with the assessed materiality and inherent risk of the change. Specific documentation requirements depend on an organization's internal policies and any applicable supervisory expectations.

How do the lines of defense typically interact in change management?

In a common three-lines model, the first line (model owners, developers, and users) proposes and implements changes and produces supporting documentation. The second line (for example, independent model risk or validation functions) reviews changes, assesses whether revalidation is warranted, and challenges assumptions. The third line (internal audit) provides periodic independent assurance that the change management process is designed and operating as intended. Roles and their exact boundaries vary by organization, and this description should not be read as a universal requirement.

When does a model change warrant revalidation rather than a lighter review?

Practice varies, but many frameworks tie the extent of review to the materiality and risk of the change. Material changes—such as a new algorithm, a substantially different data source, or a change in intended use—often warrant revalidation of affected components, whereas minor or routine changes may be handled through streamlined procedures. Organizations typically define these thresholds in policy so that decisions are consistent and documented. Because thresholds and expectations differ across sectors and institutions, there is no single universally applicable rule for when full revalidation is required.

Common misconceptions

Change management and model validation are the same activity.

They are related but distinct. Change management is the process of controlling and authorizing modifications, while validation assesses whether a model remains fit for its intended purpose. A change management process may trigger revalidation, but it does not replace it, and validation is itself distinct from verification.

A change management process eliminates the risk introduced by modifying a model.

Change controls are measures that reduce and help manage risk; they do not eliminate it. Even a well-documented and approved change can introduce residual risk, which is distinct from the inherent risk of the change before controls are applied.

Any change requiring the same treatment, or all changes being 'material,' is universal across frameworks.

Materiality thresholds and the categorization of changes are typically defined by internal policy and vary by organization and sector. What counts as a material change in a banking model risk context may differ from a general enterprise AI context, and no single external definition governs all cases.

Best practices

Define and document clear materiality criteria that determine which changes trigger governance sign-off, revalidation, or lighter-touch review, and revisit these criteria periodically.

Maintain complete versioning and change history so that each modification is traceable, attributable, and can be reviewed by second- and third-line functions or external auditors.

Distinguish explicitly in your workflow between verification and validation activities, and specify when a change requires each rather than treating them as interchangeable.

Assign clear ownership and approval accountability for changes across the relevant lines of defense, keeping governance oversight distinct from the operational teams making the change.

Establish post-change monitoring that separates detection of performance degradation from broader model risk indicators, and define rollback or remediation paths if a change produces unexpected effects.

Describe controls as risk-reducing measures rather than risk-eliminating, and record residual risk after a change is deployed to support ongoing oversight.