What is AI change control?

How it works

It starts with deciding whether a change is material

A useful change control process does not treat every edit the same way. The first question is whether the proposed change is routine, material, or emergency. That judgement usually turns on whether the change could affect intended purpose, legal classification, risk level, affected people, data provenance, security posture, or system behaviour in a meaningful way. Mature programmes also ask whether the change sits inside an envelope that was already bounded and assessed in advance, or whether it falls outside that envelope and therefore needs fuller review.

That distinction matters because some frameworks explicitly recognise pre-bounded change. The FDA's Predetermined Change Control Plan model is built around that idea. The EU AI Act does something similar for high-risk AI systems that continue to learn after release: if post-release changes were predefined by the provider and assessed at the initial conformity stage, they may stay within the original assessment rather than automatically counting as a "substantial modification". If the change was not foreseen, or if it alters compliance or intended purpose, it becomes a much more serious governance event.

In practice, many organisations create at least three routes. A standard route covers low-risk edits that still need recording. A material route requires fuller testing, wider approval and often independent review. An emergency route allows speed, but still requires minimum evidence, logging and retrospective scrutiny.

It covers the whole AI system, not just the model

AI change control should be applied to the full socio-technical system. For traditional machine learning, that often includes the model artefact, feature logic, training data, labels, thresholds, business rules, interfaces, human review points and deployment environment. For generative AI, the perimeter is often wider still: base model version, fine-tunes or adapters, system prompts, retrieval sources, content filters, tool use, external APIs, guardrails, user permissions, and fallback modes can all alter behaviour in practice.

This wider perimeter is why ordinary software release notes are not enough. A base model may stay the same while a prompt pack, retrieval corpus, threshold, or external tool changes the system's behaviour in practice. Official frameworks now recognise this system view. NIST's generative AI profile treats third-party models, embedded tools, fine-tuning, retrieval-augmented generation, content moderation, human-AI configuration, and deployment context as governance and monitoring issues, not just engineering choices.

A practical rule is simple: if the change could alter what the system does, how reliably it does it, who is affected, or what legal and governance evidence supports it, it belongs inside AI change control.

Testing and approval come before release

Once a change has been classified, the organisation needs a documented path to release. A sensible change record usually captures the rationale for the change, the versions affected, the data or prompt provenance, the expected effect on performance or risk, the test plan, the go or no-go criteria, the approvers, and the rollback conditions. For higher-risk systems, the people approving release should not rely on informal verbal assurance. They should see evidence that the changed system was tested in conditions close to actual use.

The exact test set depends on context, but the pattern is consistent. Compare the changed system to a baseline. Re-run relevant AI evals. Stress the changed system with red-teaming or adversarial tests where appropriate. Check accuracy, bias, privacy, security, resilience, and failure behaviour against documented tolerances. If the change affects personal data, thresholds, or automated decision making, human review and legal checks may also be needed. NIST and the ICO both emphasise pre-deployment testing, defined criteria for release, and formal release authority.

For generative AI, a robust test set often includes more than benchmark scores. It may include structured prompt testing, refusal testing, retrieval integrity checks, policy compliance checks, citation or source verification, and review of how the system behaves when tools, filters or reference sources fail. The key point is not any one method. It is that the changed system must earn release by evidence, not by assumption.

Logging, inventories and retention make the process auditable

A change control process is only credible if it leaves a trail. That trail usually includes a current inventory of AI systems, model versions, prompts or policy packs, data sources, third-party components, access modes, oversight roles, known issues, incident references, approvals, deployment timestamps and rollback history. Technical logs should support monitoring. Governance records should support assurance, investigation and audit.

This is where AI change control becomes more than a release checklist. NIST recommends defined periodic review responsibilities, document retention for test and verification history, and inventories that record versioning, provenance and underlying models. The EU AI Act also treats logging and technical documentation as core compliance evidence for high-risk systems. If a team cannot reconstruct what was changed and what was tested, it will struggle to defend the release later.

Good records also prevent a common failure in vendor-hosted AI. If the organisation cannot tell which model, prompt layer, retrieval corpus or API behaviour was live on a given date, it cannot confidently investigate incidents, answer complaints or verify whether a supplier changed something upstream.

Regulation can turn a technical update into a legal event

The clearest current legal example is the EU AI Act. For high-risk AI systems, providers must operate a quality management system that includes procedures for managing modifications, maintain technical documentation and logs, and run post-market monitoring. A "substantial modification" can make the system subject to a new conformity assessment. The party that makes such a modification can also become the provider for that changed system, which is a major governance consequence. In practice, this means change classification is not only an internal control matter. It can affect regulatory duties.

Sector regulators sometimes make the same point in a more structured way. The FDA now gives detailed recommendations for a Predetermined Change Control Plan for AI-enabled device software functions. Instead of treating every later model adjustment as an informal patch, the guidance expects the manufacturer to define the planned modifications, the validation and implementation protocol, and the impact assessment in advance. That is a formal version of the same basic idea: some future changes can be approved only if the future change space has been described, bounded and tested up front.

Other regulators do not always use the phrase "change control", but they still expect its components. The UK ICO's AI audit guidance expects testing and documentation before go-live for changes to existing AI systems, regular monitoring for drift, retraining where needed, complaint logging, senior sign-off, and the ability to revert to a previous model version. In other words, the control logic often appears through data protection, fairness, safety or product governance duties even where no single AI-specific statute uses the label.

Monitoring, rollback and emergency change paths close the loop

Release is not the end of the process. After deployment, change control should connect to ongoing monitoring. Teams should watch for drift, complaint trends, override rates, security events, near misses, unexplained performance drops, and shifts in the operating environment. Thresholds for escalation should be defined in advance. When those thresholds are crossed, the organisation should know whether to pause the system, limit use, revert to a prior version, or open an incident process.

Rollback is especially important in AI because many harmful changes do not look dramatic at first. A small threshold adjustment may quietly increase false positives. A prompt change may weaken refusal behaviour. A vendor model refresh may alter behaviour across many tasks at once. Good change control therefore includes not only a forward release plan, but also a realistic fallback plan, preserved prior versions, and a record of what must be undone if the release is withdrawn.

Emergency fixes may need a faster route, especially for security or safety issues, but they should not escape governance. A lean emergency lane should still identify who can authorise the change, what minimum tests must happen, how long the emergency release may remain in place before fuller review, and how lessons learned flow back into policy.