Your AI Approval Should Not Survive Every System Change

Approval covers a specific operating setup

As leadership teams finalize 2027 budgets, AI proposals should distinguish expansion from continued permission to operate. A successful pilot supports a particular use under particular conditions. It does not establish that every later version, integration or application is fit for business use.

The system approved in June may not be the system employees use in October. A supplier may update its underlying technology. An internal team may connect a new document repository. A business unit may apply an existing tool to a more consequential decision. Each change can alter performance without changing the product name.

Consider an assistant approved to summarize supplier contracts. Connecting it to live procurement records changes its information access. Asking it to interpret disputed terms changes its purpose. Letting those interpretations flow directly into supplier communications changes the consequences of an error.

These are different business uses, not minor feature additions.

NIST’s AI Risk Management Framework treats risk management as a continuing activity across the system lifecycle, including monitoring deployed systems. The executive implication is straightforward: approval should describe the permitted use, information access and human decision rights—not simply identify an approved vendor.^[1]

Define what makes the original evidence insufficient

Do not send every software update to the board. Set a material-change threshold that management can apply consistently.

Require reassessment when a change affects any of four conditions:

• Purpose: The system is being used for a different task or a decision with greater consequences.
• Information: It receives new categories of internal, customer or third-party information, or different access permissions.
• Behavior: A supplier update or internal configuration change materially affects outputs, reliability or safeguards.
• Workflow: Outputs reach more people, move into external communications or receive less human review.

For each trigger, specify the evidence needed before use continues or expands. That might include retesting representative business cases, checking access controls, validating source references or restoring an explicit human approval step.

NIST’s Generative AI Profile identifies risks including confabulation, information integrity and problematic human-AI configurations. Its suggested actions include pre-deployment testing and ongoing monitoring.^[2] Those risks explain why a prior demonstration is not enough: evidence collected for one operating setup may not support the next.

Keep the test tied to the business consequence. A fluent contract summary is not evidence that a disputed obligation has been interpreted correctly.

Buy change visibility, not just access

Procurement discussions often emphasize price, security and available features. Executives should also ask whether the organization can detect and manage changes after purchase.

Seek clear terms covering notice of material changes, version identification where available, changes to data handling and incident escalation. Establish whether the business can test a changed service before wider use and whether it can revert to an earlier configuration or suspend the affected workflow.

Not every supplier will offer every control. Treat that limitation as a business constraint, not an administrative detail. A service without meaningful change visibility may be unsuitable for work where errors are difficult to detect or costly to reverse.

The OECD AI Principles call for traceability and systematic risk management throughout the AI system lifecycle.^[3] In practice, your organization needs enough records to reconstruct what changed, what was tested and why continued use was accepted.

For a material change, keep a short decision record: the affected use, the evidence reviewed, the unresolved limitations and the person authorized to accept the residual business risk. Committees can advise. A named executive should make the decision.

Budget for reassessment before funding expansion

Reassessment consumes operating capacity. Someone must maintain test cases, inspect failures, resolve supplier questions and verify that employees still follow the required review steps.

If the 2027 business case includes licenses and implementation but excludes this work, it is incomplete. Ask business sponsors to identify who will perform reassessment and what existing work will move. Do not assume that legal, technology or operational teams can absorb it indefinitely.

This week, select one consequential AI use already in production. Compare its current purpose, information access, supplier version and review process with the conditions under which it was approved. If those conditions were never recorded, establish the baseline now.

Then test the response to a material change. Who notices? Who evaluates it? Who can pause use? What manual process keeps the business moving?

Humans must retain decision authority, including the authority to stop using the system. An approval process that cannot respond to change offers little protection once the original conditions disappear.