Change management

Change management is how a firm keeps control of an AI system as it is retrained, reconfigured, or swapped underneath. It is one of the seventeen areas in the MindForge AI Risk Management Toolkit, the Singapore industry's practices for the AIRG. This guide sets out the MindForge practice, the AIRG expectation it meets, and the evidence it produces. I wrote the AIRG, and this is the area firms fall into most, because a system passes a rigorous review, then changes, and the review no longer describes what is running.

What the AIRG expects

The AIRG expects controls for managing changes to AI, with a clear line between a material change that needs full review and a minor one that does not, and enhanced controls for AI that updates itself. The expectation is an outcome: a changed system has been reviewed in proportion to how much the change moves the risk. For how change control sits with the other lifecycle controls, see the AIRG in practice and the AIRG itself.

What MindForge says to do

The Toolkit extends the IT change-management process a firm already runs to cover AI, rather than inventing a parallel one.

Define, track, and gate changes

Set change types, approval workflows and escalation thresholds, so that changes to model architecture, training technique or system configuration are logged and reviewed before they go live. Use version control over the AI components - models and their weights, training data, and hyperparameters - so every change is traceable, reviewable and auditable. Above all, define consistently what counts as a material change.

Match the review to the change

A less-significant change, such as retraining on more recent data, is unlikely to move risk materiality and may need only a light performance check - but track it anyway, and count it when you decide how often to re-review. A material change, such as a new architecture or training technique, goes through the full review and approval, with the AI risk assessment and AI-specific review repeated alongside the usual development steps.

Dynamic and third-party changes

Some use cases, such as fraud detection or anti-money laundering, retrain on recent data very frequently. These dynamic systems need enhanced controls: a clear justification for allowing automatic updates, stronger data-quality checks, drift detection, and tighter monitoring thresholds. For third-party AI, where the firm may not see a change coming, negotiate or contractually require a change-notification process, assess the impact of any change, test it where it is material, and fall back on heavier review or monitoring where notification cannot be assured.

How banks do it

The MindForge Implementation Examples show the pattern: a bank tests changes in a dedicated environment before production, documents and approves them with the product team and senior stakeholders, and puts major changes through a peer review so the use case stays fit and its key risks are not overlooked.

My take

Covering every stage sounds thorough, until you ask: to what standard? A retrain is a small new model, not a refresh.

The trap is treating a retrain as routine maintenance. If a changed model never goes back through review, the validation you are relying on describes a system that no longer exists. (From my book, AI Risk Management for Directors.)

Work with me

I train and advise financial institutions on AI change control and the rest of the AIRG programme. See the courses and workshops, read more on AI risk management, or get in touch.