When the AI Risk Isn't Yours, But You Own It Anyway 

This series has delineated two conversations that often get collapsed into one: governance OF AI (overseeing how a company uses AI) and governance WITH AI (using AI to improve a board's own work). We then looked at five core categories of AI risk. This article looks closer at vendor risk, where exposure arrives through an external provider rather than through something an organization has built.

Most Organizations Don't Build Their Own AI. 

Few organizations train their own models. Instead, they use software that has AI quietly built into it (HR platforms that add resume screening, customer service tools that add a chatbot layer, finance systems that add anomaly detection). This shows up as a routine software renewal rather than explicit AI adoption. 

But risk exposure doesn't wait for a deliberate AI decision. If a vendor changes what its product does, the organization has changed what it does too, whether or not anyone approved that shift internally.

Why This Risk Is Different

The risks covered in the second article, bias, privacy, regulatory exposure, overreliance, and reputational fallout, don't disappear when AI arrives by vendor. Instead, they become more difficult to see and control.

When an organization builds a tool internally, it has direct visibility into the data that trains it, how it makes decisions, and when it changes. When an organization purchases that capability, most of that visibility is gone by default. The vendor controls the training data, the model updates, and the release schedule. The organization controls only the contract.

Vendor AI risk is not a technical risk so much as a contractual and oversight one.

Four Questions That Cover Most of the Exposure

A board needs to know whether management can answer a few specific questions about any vendor with embedded AI. 

1. What changed, and when did we find out? 

Vendors update their AI features continuously, often without a formal release note a customer would notice. If management cannot say how the organization would learn about a material change before customers or regulators do, the organization is operating blind.

2. Where does our data go? 

Contracts should plainly state whether organization or customer data is used to train the vendor's models, how long the data is kept beyond the service period, and if data is shared with the vendor's own subprocessors. Legal counsel should be able to point to contract language, not assumptions, when answering. 

3. What happens when the vendor is wrong?

Every AI vendor will eventually produce a bad output: a wrongful denial, a biased ranking, an inaccurate summary treated as fact. Oversight should confirm that liability, audit rights, and remediation obligations are defined in the contract up front. Waiting until after an incident means negotiating under pressure, with real uncertainty about how the contract will be interpreted.

4. Can we explain this to a regulator? 

If a regulator asks why a hiring or lending decision came out the way it did, can the organization answer, or will it need to ask the vendor and hope for a response? Organizations remain accountable for outcomes even when a vendor's model produces them.

Whose Responsibility Is This Anyway

Vendor AI risk tends to fall between departments in a way that lets it go unowned. Procurement negotiates the contract. IT security reviews data handling. Legal reviews liability language. A vendor contract can clear every existing checkpoint without anyone having evaluated it as an AI risk at all. 

The Risk or Audit Committee, consistent with the ownership laid out in the first article, should  be explicitly responsible for asking whether the AI-specific version of these four questions has been answered. 

The practical fix is adding AI-specific questions to procurement and vendor-renewal processes that already exist, so the review happens at the point where it's cheap, before signature, rather than after something has gone wrong.

Takeaway Questions

Ask when a new vendor tool has embedded AI, or an existing vendor adds it:

• Do we know which of our vendors currently use AI in the product we're paying for?
• Does our contract give us visibility into material model changes, not just uptime and support terms?
• Does the contract specify how our data is used, retained, and whether it trains the vendor's models?
• If this tool produced a harmful or inaccurate output, do we know who is liable and what the remediation path is?
• Could management explain an AI-driven decision from this vendor to a regulator or customer without going back to the vendor first?