An AI assistant is approved to summarise a controlled set of internal documents. A month later, the team adds another data source, changes the model and connects a tool that can update business records. The product name is unchanged. The conditions behind its approval have moved.
My recommendation for AI change control is to reopen an approval when a change could invalidate an operating assumption, weaken a control or move the system beyond its agreed scope. Leaders should know which changes fit within that boundary, which require a focused reassessment and which require a new deployment decision. Otherwise, a sequence of small releases can turn a limited pilot into a materially different system without anyone explicitly accepting the new risks.
What did the original approval actually cover?
An approval needs a baseline that people can compare with the proposed change. Record the intended task, users and affected parties; permitted data sources; model and important configuration versions; connected tools and access rights; and the actions the system may take.
Include the operating assumptions too. These might cover expected volume, required review capacity, performance limits, escalation arrangements and an available fallback. A system approved for a small specialist team may behave differently when adopted by a larger audience with different knowledge and expectations.
The baseline should point to the relevant tests and the decision-maker who accepted the remaining risk. It can be concise. Its value is that a change request can answer a specific question: which part of the approved operating situation will be different?
Six changes that should trigger a review
A release label is a poor guide to governance significance. A minor configuration change can alter what the system is allowed to do. I would screen changes against six questions:
- Purpose: is the system supporting a new task or influencing a different decision? Moving from summarising documents to recommending a course of action changes what users may rely on.
- People and context: will different users or affected groups encounter it? A new language, location or customer-facing channel can expose gaps that the original evaluation did not cover.
- Data: will it receive a new source, a more sensitive category of information or different retention arrangements? More data can also mean different access and disclosure risks.
- Behaviour: has the model, prompt, retrieval process or configuration changed in a way that could alter output? Supplier changes belong in this assessment even when the interface stays the same.
- Authority: can it now send, edit, approve or execute something that it previously only described? New tool permissions can change the consequences and reversibility of an error.
- Operating conditions: have volume, staffing, failure patterns or control performance moved outside the approved assumptions? Review can be necessary even when no software release has occurred.
These are screening questions, not a claim that every change needs the same approval process. Their purpose is to identify which earlier conclusions may no longer hold.
Match the review to the consequence
A useful change process distinguishes three routes. The organization should define the routes in advance, with authority levels that fit its risk tolerance.
Routine change within an agreed boundary. A designated owner checks that the change remains within a pre-approved class, completes the required regression checks and records the release. For example, correcting a non-functional display label may qualify if it cannot affect interpretation or user decisions.
Focused reassessment. A change could affect a known risk or control, but the intended purpose and authority remain bounded. The owner identifies the affected assumptions, obtains the relevant specialist review and reruns the tests needed to assess those effects. For example, changing retrieval ranking within the same approved document collection may call for renewed answer-quality and source-citation tests without expanding the system’s authority. Unaffected evidence can be reused when its continuing relevance is explained.
New deployment decision. An expanded purpose, new consequential action, substantially different audience or unresolved risk may take the system beyond its previous approval. Hold that expanded use until the appropriate decision-maker has evaluated it. The original use may continue only if its controls and dependencies remain valid.
A business sponsor can explain the expected benefit. A technical owner can explain the change and test results. Neither role automatically has authority to accept every resulting risk. Where privacy, security or another specialist concern is affected, involve that function under the organization’s existing decision rights.
A practical example: expanding a procurement assistant
Consider a hypothetical assistant that helps purchasing staff summarise approved supplier documentation. It does not select suppliers, send messages or update records. Users open the source documents before relying on the summary.
The team proposes adding a mailbox connection and a tool that writes extracted details into the supplier register. Calling this an “integration improvement” hides two important changes: a broader information source and permission to alter a business record.
The change review should establish which messages are in scope, who is entitled to access them, which fields can be updated and how an incorrect update will be detected and corrected. Tests should include conflicting supplier details, an outdated attachment and a message that contains instructions the assistant should treat as untrusted content.
The decision might allow a limited evaluation that produces proposed updates for comparison, while keeping production writes disabled. The owner would then compare those proposals with verified records, investigate errors and return for a decision on the write capability. Passing the earlier summarisation tests would not, by itself, answer these new questions.
Make the change record useful at decision time
For a material change, ask for a short record that includes:
- The approved baseline and the proposed difference, including the reason for changing it.
- The assumptions, risks, affected people and controls that need reassessment.
- The evaluation results, their limitations and any unresolved questions.
- The decision, accountable approver, conditions and permitted rollout scope.
- The monitoring owner, review point and conditions for pausing, restricting or reversing the change.
Keep the record connected to the release identifier and the governance evidence chain. Link to controlled evidence rather than duplicating sensitive inputs across tickets and reports.
Where people review outputs, confirm that the changed workflow still gives them the information and authority to intervene. An approval process becomes fragile when it quietly assumes the same team can absorb more work or make a more complex judgment.
Plan for supplier updates and emergency changes
Some changes arrive through a supplier rather than an internal release. Establish what notification, version information, evaluation access and rollback options the service actually provides. If a previous model version cannot be retained, the fallback may need to be a restricted workflow or an established manual process.
An urgent fix also needs a defined decision path. Name who can authorize a limited emergency change, what checks must precede it and when the fuller review must occur. Record any temporary conditions and their expiry. Urgency should not quietly create permanent permission.
Connect change control with monitoring
The NIST AI Risk Management Framework 1.0 Core provides a useful foundation: GOVERN 1.5 addresses ongoing monitoring and periodic review of the risk management process and its outcomes, while MANAGE 4.1 includes change management in post-deployment monitoring plans. These outcomes support a continuous governance process; they do not prescribe the three review routes proposed here or certify a particular implementation.
NIST’s 2026 report on monitoring deployed AI systems also distinguishes controlled pre-deployment evaluation from observing systems in real settings, and identifies open challenges in monitoring practice. That is a reason to keep testing assumptions after release and to be candid about what the monitoring can detect.
This connects with the Adoption Roadmap phase of VORTA, the structured AI adoption framework: test criteria, decision records, change control and operational runbooks should remain connected as deployment develops. The practical leadership task is to ensure that a detected change reaches someone who can decide what happens next.
Use the next release to test your approval boundary
Choose one AI system and compare its current operation with its last approval. What has changed in purpose, people, data, behaviour, authority or operating conditions? Can the owner show how those differences were assessed?
Resolve one unreviewed difference before expanding the system further. Then make the review triggers visible to the people who change, purchase and operate it. An approval remains useful only while its conditions still describe the system people are actually using.