The Board's AI Question: Who Controls the Next Vendor Change?

By Mark Bold | leadership | 8 min read

Approving an AI supplier is not the same as approving every future change to its service. Leaders need to distinguish routine maintenance from changes that alter business commitments, permissions or dependence.

A company approves an AI service for a limited purpose. The business case is sensible, the pilot is useful and the contract is signed. Months later, the supplier changes the underlying model, adds an integration or introduces an action the original tool could not take. Management describes the change as an upgrade. The more important question is whether the company is still using the service it actually approved.

This is a governance problem at the boundary between a vendor relationship and the company's own authority. It does not require directors to review every software release. It requires leaders to distinguish routine maintenance from changes that alter the business decision, and to decide who has permission to accept those changes.

Scope

This article offers a practical approach to supplier change, not a claim that AI creates one new legal duty for every board. Board and management authority depends on applicable law, governing documents, delegations and the circumstances. Delaware's corporate statute, for example, places management of a covered corporation's affairs with or under the direction of its board, subject to stated exceptions. That is a jurisdictional example, not the governance rule for every entity. NIST's framework is voluntary guidance, not a substitute for that legal analysis. [1] [2]

Identify what the company approved

A vendor name is not a complete description of an approved use. The approval may depend on a particular data arrangement, limited permissions, a human review step or a business process that the vendor does not control.

Consider a hypothetical customer support assistant. Management approves it to draft responses for employees to review. The supplier later offers an integration that sends responses directly and updates customer records. Using the same supplier does not make the second arrangement equivalent to the first.

The company should be able to reconstruct the original decision. What work was approved? What information was allowed? Which actions remained with staff? Which commitments did the business make to customers or counterparties on that basis?

NIST includes documenting intended scope, human oversight and risks from system components and outside providers. A company can use those concepts to describe its approval as an operating arrangement rather than a product subscription. [2]

Decide which changes matter

Not every vendor change needs a board discussion. Treating all changes as equally consequential can consume attention without improving judgment. The useful distinction is whether a change affects the reasons, limits or risk assumptions behind the original authorization.

Possible triggers include a new ability to take action, broader access to information, removal of a review step, different data handling or a material change in the company's ability to stop or replace the service. These are suggested review questions, not universal legal thresholds.

In the support example, a correction to interface wording might be ordinary maintenance. Giving the assistant permission to send binding communications requires a different examination. Whether board approval is necessary is a separate question under the company's actual authority arrangements.

Management can establish an escalation rule that identifies who decides when a proposed change stays within existing authority and who resolves uncertainty. The rule should work when a release is inconveniently timed, not only when everyone has advance notice.

Separate vendor permission from company permission

A supplier may make a feature available without deciding whether the customer's personnel are authorized to enable it. A platform setting can permit an employee to activate an integration even when the business has not approved the resulting workflow.

Leaders should examine those two layers separately. Technical access concerns what the user can configure. Organizational authority concerns what the person may approve on the company's behalf. Neither should silently stand in for the other.

This distinction also matters when the supplier changes a feature by default. The company needs to understand which changes it can defer, reject or reverse, rather than assume that every update requires affirmative acceptance.

NIST's Govern function addresses responsibilities, communication and risk decisions. Its Manage function calls for monitoring risks from outside resources, including pretrained models. Those recommendations support continued examination of the relationship rather than treating initial procurement as the end of governance. [2]

Read the agreement for the operating question

The relevant contract review is more specific than asking whether the agreement is generally acceptable. It should examine the capabilities and changes on which the business depends.

Questions may concern notice of material changes, permitted data uses, access to records, service discontinuation, suspension rights and practical transition assistance. A supplier may not offer all the protections a customer would prefer. The decision then becomes whether the remaining limitations fit the proposed use.

Contract language alone cannot establish that an export works, that an older version remains available or that the company's integration can be disabled safely. Those are facts to verify with the technical and operating teams.

Counsel should understand the intended workflow and the consequences of interruption before recommending terms. A negotiated right is useful only if the business understands what it protects and how it would use it. The objective is informed acceptance of the relationship, not an assumption that a signed agreement removes dependence.

Keep a usable alternative

Dependence changes the cost of saying no. If staff cannot perform an essential task without the supplier, management may accept a change it would otherwise reject. That is a reason to examine alternatives before a disagreement or outage.

An alternative need not duplicate the entire service. It may preserve a critical task through a reduced process while the company investigates or changes providers. The question is what the business must still be able to do.

NIST addresses contingency arrangements involving outside providers and the ability to disengage or deactivate systems whose outcomes are inconsistent with intended use. Those are framework recommendations; the feasibility of a particular alternative remains a company specific question. [2]

In the support example, staff might retain access to the underlying customer records and a route for responding without the assistant. The company would need to confirm that this route still works when the AI integration is unavailable, rather than relying on a document that assumes normal operation.

Give directors a decision, not another inventory

The board's useful contribution is not to approve every configuration change. It is to examine material choices within its role and make sure management's authority and resources fit the approved strategy.

Where a supplier change raises an issue for directors, management should describe the difference from the approved arrangement, the commercial reason to accept it, the available alternatives and the obligations or constraints that affect the choice. Technical uncertainty should be identified rather than hidden behind a vendor assurance.

This is different from presenting a list of AI tools or reporting that a pilot remains popular. A choice about broader permissions, increased dependence or a changed customer promise calls for a business judgment about that change.

The proper decision maker may be management, a committee or the board, depending on the facts. Counsel can help identify the relevant authority and obligations without substituting a generic claim that all AI decisions belong at one level.

Make the decision survive the next update

Once a change is accepted, the record should explain the approved scope, who decided and what would trigger reconsideration. The people operating the service need access to those limits. A board resolution or procurement record that never reaches the administrator cannot guide the next configuration choice.

This need not become a separate bureaucracy for every release. A proportionate process can route routine changes through ordinary operating controls while directing genuinely different uses to the appropriate decision maker.

The leadership discipline is to recognize when a technical update changes the deal the business is making. Keeping that distinction visible helps the company benefit from improvement without giving its supplier, or an unnoticed setting, the final word on its own commitments.

Executive Imperatives

Describe the approved use. Record the permissions, data arrangement and human decisions that supported the original choice.

Set change triggers. Identify which differences require reconsideration and who resolves uncertain cases.

Verify the exit. Test the practical alternative instead of relying only on an export promise or contractual right.

Revisit authority with counsel. Examine the actual business change and governing arrangements before accepting a broader commitment.

Sources

1. [Delaware General Corporation Law section 141(a), board authority and statutory exceptions](https://delcode.delaware.gov/title8/c001/sc04/index.html)

2. [NIST AI 100-1, AI Risk Management Framework 1.0, especially Govern 1, 2 and 6, Map 3 and 4, and Manage 2 and 3](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf)