Boards commonly approve an AI use case as though the decision attaches permanently to the application. In practice, an approval is a judgment about a particular system, a specific configuration of model, data, workflow, permissions, and users, operating under particular conditions, supported by evidence gathered at a particular point in time. Any of those components can change without the application ever returning to the board or receiving a new name.
I wrote recently about a parallel problem in AI-assisted research: a claim can be correct, well-sourced, and no longer true, because citation validity and temporal validity are separate properties. The same distinction holds for governance. An approval record proves that a particular system was judged acceptable under particular conditions. It does not prove that the system currently in production still matches either of them.
Conventional change control is not the wrong tool here. It is an incomplete one. Traditional change management already addresses impact, risk, testing, approval, scheduling, dependencies, and rollback. Its blind spot is that AI-system behaviour can also change through vendor-controlled model updates, retrieval changes, prompt and tool configurations, inference settings, and user context, including changes outside the components the organisation versions itself. These changes can bypass ordinary change control precisely because they occur inside a vendor service or through configuration rather than code.
The object being governed is the whole system, not the model name
Organisations often use "the model," "the application," and "the AI system" interchangeably, and that habit hides where change actually enters. The object being governed is the complete deployed system: the model itself, the instructions and policy layer wrapped around it, the sources it retrieves from, the tools it can call, the permissions it operates under, and the humans positioned to catch its mistakes. A change to any one of these can move the system outside the boundary the original approval assumed, even while the application keeps the same name on the same dashboard.
| Component | Example of change | Possible governance consequence |
|---|---|---|
| Model | Vendor upgrades the underlying foundation model | Capability or failure pattern shifts |
| Instructions | System prompt or policy wording changes | Different decisions or boundaries |
| Retrieval | New sources added, or ranking changes | Different evidence reaches the model |
| Tools | Agent gains access to email, payments, or code execution | Consequence of an error increases |
| Permissions | Agent can act without confirmation | Human control is reduced |
| Users | Internal pilot expands to customers | New populations, new obligations |
| Environment | Regulation or threat landscape shifts | Previously accepted risk may no longer be acceptable |
The board doesn't need the technical detail behind each row. It needs confidence that management is governing the complete system rather than tracking a model name on a vendor contract.
Three tests for whether an approval still applies
Test 1: Is the operating system still materially equivalent to the one that was approved?
Something almost always changes. The question isn't whether change happened, it's whether the change altered a capability, failure mode, affected population, decision boundary, or potential consequence that mattered to the original approval. The UK AI Security Institute has identified significant post-deployment system changes as points at which renewed evaluation may be warranted, including the addition of tools, domain-specific fine-tuning, and longer context windows, part of an evolving, still-tentative approach to lifecycle testing rather than settled practice, but a useful list to borrow regardless: a model upgrade that enables longer autonomous workflows, a new data source that introduces personal or regulated information, a shift from recommendation to execution, a workflow that expands into a new jurisdiction, a human approval step that gets removed or delayed.
The board should require: a management-defined standard for what counts as material equivalence for each system.
The CIO should implement: a system inventory and version record that covers more than the model identifier, since the model is only one of the components in the table above.
Test 2: Does the earlier evidence still apply?
An evaluation result applies most directly to the system and conditions it actually tested. After a change, management has to establish which findings remain transferable and which require revalidation, not assume either that nothing has changed or that everything has. Reusing an old evaluation after a material change without checking which findings still hold is the operational equivalent of citing a well-sourced claim whose validity window has already closed. Where the change is vendor-controlled, contracts and operating procedures should provide enough notice, version information, and rollback capability for the organisation to determine whether earlier evidence remains applicable. A vendor's assurance describes the system it tested. It does not establish that the same system, configuration, and safeguards are operating in the customer's environment today.
The board should require: evidence that material changes trigger risk-appropriate revalidation.
The CIO should implement: traceability between deployed versions, evaluation results, and the approvals that relied on them.
Test 3: Can the organisation detect when the system leaves its approved boundary?
Pre-deployment testing cannot establish every production behaviour. A March 2026 NIST report, based on three practitioner workshops and a review of 87 studies, identifies non-standardised metrics and difficulties establishing baselines and deviation thresholds as recurring barriers to monitoring deployed AI systems. Better tools may help, but they cannot determine which baseline matters, what degree of deviation is acceptable, or who has authority to act. Those are governance decisions. The organisation needs signals showing whether error rates changed, escalation patterns shifted materially, tool use expanded beyond what was approved, or the system began operating on cases outside its intended scope.
The board should require: reporting on material deviations from approved assumptions, not routine operational metrics repackaged as assurance.
The CIO should implement: monitoring tied specifically to the assumptions and limits documented at the time of approval, not a generic dashboard.
Not every change is a board matter
A framework that treats every prompt edit as a governance event will get ignored, which defeats the purpose. The right classification depends on effect, not on the technical form the change takes. A model replacement or a prompt change should each trigger an impact assessment; which tier it lands in depends on what the change actually does to the deployed system, not on which layer of the stack it touched. A small wording change to a system prompt or safety policy can produce a material behavioural shift, since the instructions are as much a part of the governed system as the model itself; a model swap might, after testing, turn out to change nothing that mattered for a narrowly constrained use case.
| Change tier | Governance test | Required response |
|---|---|---|
| Routine | Demonstrated not to affect behaviour, risk, controls, or approved scope | Logged and locally tested |
| Significant | Behaviour changes within the existing purpose and risk boundary | Targeted revalidation |
| Material | An assumption, capability, population, permission, control, or consequence relied on in the approval may no longer hold | Formal risk reassessment |
| Fundamental | Intended purpose, legal classification, or overall risk profile changes | Treated as a new deployment |
Materiality should also be assessed cumulatively, not only per release. Five changes individually classified as routine can move a system further from its approved baseline than one change formally logged as significant, and a framework that only ever looks at the most recent release will miss that drift entirely.
The EU AI Act offers one regulatory analogue. It defines a "substantial modification" as an unforeseen or unplanned post-market change that affects compliance with the high-risk requirements or changes the assessed intended purpose. Its logging requirements also recognise that organisations need records capable of helping identify changes that may require reassessment, without the system itself being expected to make that determination; a person still has to interpret the record. The practical boundary remains imperfectly specified externally, which is a reason to establish an internal classification now rather than wait for regulation to resolve every case.
The board's role in this classification isn't to review each technical change. It's to approve the escalation rule itself, and to decide which tier of change management can handle without coming back for renewed sign-off.
What to bring to the next governance review
Ask which deployed AI systems have changed materially since their last approval, and whether anyone could answer that with evidence rather than an impression. Ask what the organisation classifies as a material change for each system, and who owns that classification. Ask whether management evaluates cumulative change over time, or only the most recent release. Ask whether each system's current version can be linked to the evaluation evidence used to approve it, or whether that thread has gone cold. Ask which vendor-controlled changes can happen without prior notice, and what the plan is when one does. And ask what specific production signal would cause management to suspend, restrict, or revalidate a system, rather than assuming someone would notice in time.
A board does not need to approve every model update, prompt revision, or new data source. It needs confidence that management can tell the difference between routine change and a change that invalidates the assumptions behind an earlier decision. Where that distinction can't be made, the organisation doesn't have continuing assurance. It has an approval record for a system that may no longer exist.