AAIA lesson 7: AI change and supervision

An AI system can behave differently tomorrow without anyone deploying anything. A retrained model, a new prompt template, a refreshed data feed or a silent provider update each shifts outputs, and drift shifts them with no event at all. Change management for AI therefore has to cover at least four artefacts (model, data, prompt, provider), and supervision has to cover what the system actually produces, not just how it was built. These are subtopics 2C (Change Management specific to AI) and 2D (Supervision of AI Solutions, covering outputs, impacts and decisions); supporting tasks add configuration management and the role of AI decision-making systems.

Four things that change behaviour

Classic change management tracks code and configuration. For AI, the unit of change is wider:

Each needs an identifier (a version), an owner, an assessment of impact, an approval and a revalidation step proportionate to risk. The audit question is simple: can the organisation say which version of each artefact produced a given output last March?

Configuration management answers that question. It keeps the approved baseline: which model version, prompt, parameters, data snapshot and integration settings make up the production system, recorded in a registry or repository. Change management is the controlled move from one baseline to the next. The audit test is to compare the live configuration with the recorded baseline; a difference with no matching change record is an unauthorised change, and a baseline nobody keeps makes every later question about the past unanswerable.

Drift is not a change

Drift is gradual divergence between the world the model learned and the world it now meets. Customer behaviour shifts, fraud patterns evolve, language moves on. Nothing is deployed, so no change record can ever exist. Two flavours matter:

• Data drift: the inputs look different from the training data.
• Concept drift: the relationship between inputs and the right answer has moved.

The control is therefore detective: monitoring of input distributions and of outcome quality against thresholds, with a defined trigger for investigation, retraining or withdrawal. A model with no monitoring and no revalidation date has an unknown level of accuracy, not a known one.

Worked example

The insurer from lesson 1 uses a hosted language model to summarise claims notes for adjusters. In one quarter the provider retires the model version in use, a team member shortens the system prompt to cut cost, and the claims system begins sending notes in a new template. The change log shows nothing for the quarter.

An auditor would reason in order. First, establish the artefact list: model version, prompt, input format, retrieval content. Second, ask for version history and dated revalidation for each. Third, look at how the organisation learned of the provider’s retirement and whether a contract clause obliges notice. Fourth, check that monitoring would have flagged a drop in summary quality. The finding is a gap in change coverage, with a root cause (no one owns prompts) rather than a complaint about the vendor.

Supervision: oversight that operates

Supervision (2D) asks whether people watch outputs, impacts and decisions. Policies saying “a human reviews decisions” show intent. The auditor wants evidence of operation:

• Defined roles: who reviews, with what training, how much time per case.
• Criteria: what the reviewer checks against, and what triggers escalation.
• Authority: can the reviewer reject or override, without penalty?
• Records: review logs, override counts, escalated cases, outcomes.
• Metrics: KPIs and KRIs (error, complaint and override rates, drift indicators) with thresholds and named recipients.

An override rate of exactly zero is a warning sign, not a success. It may mean rubber-stamping (automation bias), a reviewer queue too long to read, or a review button that does nothing. Impact monitoring also reaches beyond the system: complaints, appeals and outcome differences between groups are evidence about real-world effects. Where a system makes or heavily shapes decisions, the auditor also asks what role it has: advising a person, deciding with a person able to intervene, or deciding alone. The greater its role, the stronger the oversight, appeal route and monitoring should be, and the more the effects on customers, staff and downstream systems matter. See AI governance and risk for the wider ownership picture and MLOps basics for how versioning is done in practice.

Easy to confuse

• Change vs drift: a change is an event someone makes; drift happens to the model. Change management covers the first, monitoring the second.
• Human in the loop vs on the loop: in the loop means a person approves each decision; on the loop means a person watches and can intervene. The auditor tests whichever the design claims.

Key points

• Behaviour changes through model, data, prompt and provider changes, all of which need versioning and approval.
• Drift cannot appear in a change record, so only monitoring and scheduled revalidation address it.
• Contracts with providers should oblige advance notice of model changes.
• Policy shows intent; review logs and override records show oversight operating.
• A zero override rate or an unread review queue suggests nominal oversight.

Check yourself

The domain recap is on the AI operations page.