AI Approval Must Follow the Use, Not the Purchase

The purchase is not the unit of risk

A team receives approval to use an AI service to summarize internal product documentation. Six months later, employees use the same service to draft customer commitments, interpret exceptions and recommend how to resolve disputes. The subscription has not changed. The business exposure has.

The original review may have been sound. The failure is allowing that review to cover work it never examined.

This is a governance problem with a human cause. Teams adapt useful tools to adjacent work. Managers reward speed. Vendors add capabilities. Responsibility becomes unclear when a local experiment becomes a standard practice without an explicit decision.

As 2027 budgets and supplier renewals come into focus, executives should distinguish two questions: Is this supplier acceptable? Is this particular use acceptable under these conditions? Procurement approval answers only part of the second question.

The NIST AI Risk Management Framework treats risk management as work across the AI lifecycle, not a one-time gate. Its emphasis on context, defined responsibilities and ongoing monitoring supports a practical conclusion: approval should attach to a defined business use and remain valid only while its material conditions hold.^[1]

Define what the approval actually covers

Every consequential AI use should have a short approval record that a business leader can read without technical translation. It should state:

• Purpose: The task the system supports and the uses explicitly excluded.
• Information: What data it may access, receive and retain.
• Influence: How its output may affect a business decision or external communication.
• Responsibility: Who owns the outcome, who reviews the output and who can restrict the use.
• Conditions: The evidence, safeguards and review date on which approval depends.

Consider a customer service team using AI to summarize warranty policies. Approval might allow staff to retrieve relevant policy passages, while requiring them to verify the source before responding. It would not automatically permit the tool to interpret ambiguous contract language or determine exceptions.

That distinction matters commercially. An inaccurate summary creates rework. An unsupported customer commitment may create a financial obligation. The same product can produce very different exposure depending on where people place it in the workflow.

Human accountability must also be operational. The reviewer needs access to the underlying evidence, authority to reject the output and enough subject knowledge to recognize a problem. Naming a reviewer without those conditions transfers responsibility without giving the person control.

The OECD AI Principles place accountability on organizations and people according to their roles and the context of use. That supports assigning responsibility to an actual business owner rather than an abstract governance committee.^[3]

Reopen approval when the consequences change

Not every software update warrants an executive review. A process that treats cosmetic changes like material risks will become a queue that teams learn to bypass.

Instead, define changes that reopen the relevant part of the approval. These should include access to more sensitive information, use by a different population, greater influence over consequential decisions, expanded external distribution or removal of an existing safeguard.

Supplier changes also matter when they alter approved conditions. A new feature that connects to business records is not equivalent to a revised interface. A change in data handling deserves attention even if employees experience no visible difference.

NIST’s Generative AI Profile addresses risks across the lifecycle, including risks associated with components and third parties. It reinforces the need to examine how a system is deployed and maintained, not just how it performed during an initial demonstration.^[2]

Give each trigger a route and an owner. The business owner should identify the changed use. The appropriate technical, security, legal or risk specialists should assess the changed condition. A named business authority should decide whether the use can continue, needs restrictions or requires fresh evidence.

Where practical, restrict the expanded use rather than stopping an unchanged, approved activity. Governance should contain the exposure without creating unnecessary disruption.

Make continued approval visible to leadership

The board does not need a catalogue of every feature release. It needs assurance that management can recognize when an approved use has become a different business activity.

For the next operating review, ask each function to identify its consequential AI uses and compare current practice with the original approval. Start with uses that affect external commitments, sensitive information or material business decisions.

Ask for exceptions, not a reassuring average. Which uses lack an accountable owner? Which have expanded beyond their approved purpose? Which safeguards exist on paper but no longer operate in practice?

Then connect the answers to renewal and funding decisions. Expanding a service should require evidence that its current use is understood and governed. Renewing a contract should not silently renew every activity employees have built around it.

The executive test is simple: can management explain what changed, who assessed it and who accepted the resulting exposure? If not, the organization has a purchase approval—not continued control over the business use.