The Three Questions Every Board Should Ask About Third-Party AI Risk

There’s a conversation happening in a lot of boardrooms right now, and it usually starts with a director asking some version of: “Are we using AI, and if so, is it safe?” It’s a reasonable question. It’s also the wrong one.

The sharper question—the one that keeps experienced CISOs up at night—isn’t whether your organization is using AI. It’s whether your vendors are. Because they almost certainly are, and in most cases they haven’t told you, and in a surprising number of cases they don’t fully know themselves.

Over the past couple of years, AI features have spread across nearly every category of enterprise software. Your CRM added a “smart summary” button. Your HR platform now screens resumes with a model. Your help-desk tool routes tickets through a large language model. Your legal review software drafts first-pass contract language. Each of these features touches your data, and each of them represents a vendor making decisions about AI on your behalf—often without a formal disclosure, and almost never with your sign-off.

This is the new shape of third-party risk, and most governance frameworks haven’t caught up. The exposure isn’t theoretical, either. In its most recent breach-cost research, IBM reported that 13% of organizations had suffered breaches of AI models or applications, and that 97% of those breached organizations lacked proper AI access controls —a gap that widens considerably once you factor in the AI your vendors run on your behalf.

So rather than hand boards a 40-page framework, here are three questions that actually cut to the heart of the matter.

Question One: Where Does Our Data Go When a Vendor’s AI Touches It?

This sounds simple. It almost never is.

When a vendor embeds an AI feature, they frequently don’t build the underlying model themselves. They call an API from a foundation-model provider, or they route your data through a third model layer you’ve never heard of. So your data doesn’t just go to your vendor—it may travel to their vendor, and possibly to a fourth party beyond that. This is fourth- and fifth-party risk, and it’s largely invisible in standard vendor questionnaires.

The questions a board should expect management to answer include:

• Is our data used to train models? Many AI providers retain input data to improve their models unless a customer explicitly opts out through an enterprise agreement. If your vendor is on a consumer or standard tier, your sensitive data may be contributing to a model that competitors could later query.
• Where is the data processed and stored? AI inference often happens in cloud regions that may sit outside the jurisdictions your compliance obligations require. For regulated industries, data crossing a border inside an AI pipeline can be a reportable event.
• How long is the data retained, and who can see it? Prompt logs, caches, and debugging records often persist far longer than anyone expects, and they frequently contain exactly the sensitive data you’re trying to protect.

If management can’t trace the path your data takes once a vendor’s AI feature touches it, that’s not a minor gap. It’s a sign that the organization doesn’t actually know its own attack surface.

Question Two: What Happens When the AI Is Wrong—or Manipulated?

Traditional software is deterministic. Give it the same input, and you get the same output. AI systems don’t work that way, and this breaks a lot of assumptions baked into existing risk controls.

Two distinct failure modes matter here, and boards should understand both.

The first is ordinary error. A model embedded in a vendor’s product can produce a confident, fluent, completely wrong answer—a “hallucination.” If that output feeds an automated decision — say, flagging a transaction, screening a candidate, or summarizing a contract clause — the error propagates with the appearance of authority. The question for the board isn’t whether this will happen. It’s whether a human reviews consequential AI outputs before they cause harm, and whether the vendor’s contract makes clear who’s liable when the model gets it wrong.

The second failure mode is adversarial, and it’s less familiar to most directors. Attackers have learned to manipulate AI systems through prompt injection, hiding instructions inside documents, emails, or web pages that a vendor’s AI then reads and obeys. A malicious instruction tucked into a PDF that your vendor’s AI assistant processes can, in the wrong architecture, cause that assistant to leak data or take unauthorized actions. This isn’t hypothetical. Prompt injection sits at the top of the OWASP Top 10 for Large Language Model Applications as LLM01,  a widely referenced industry list of the most serious AI-specific vulnerabilities.

The uncomfortable reality is that your vendor’s AI feature can become an entry point into your environment, even when your own systems are locked down tight. A board should ask whether the organization has tested how vendor AI integrations behave under adversarial conditions—not just whether they work under normal ones.

Question Three: How Will We Know If a Vendor’s AI Changes?

This is the question almost nobody asks, and it may be the most important of the three.

Traditional software changes on a release schedule. You get a version number, release notes, and usually a chance to test before you adopt. AI-powered features don’t play by those rules. A vendor can swap the underlying model, retrain it, adjust its behavior, or change its data-handling practices—often silently, often overnight, and often without anything you’d recognize as a software update.

That means the vendor you assessed and approved six months ago may not be the vendor you’re actually running today. The risk profile you signed off on can shift under your feet. A model that was conservative about what it would output last quarter might be far more permissive this quarter, and you’d have no automatic way to know.

So the board should press on continuous oversight:

• Does our contract require notification of material AI changes? Most vendor agreements written before 2024 say nothing about this. They should be renegotiated to require disclosure when a vendor changes models, training practices, or data handling.
• Do we reassess AI vendors on a schedule, not just at onboarding? A one-time assessment at procurement is close to meaningless for a capability that evolves continuously. AI vendors need periodic re-evaluation built into the governance calendar.
• Can we actually detect unexpected behavior? Monitoring vendor AI outputs for drift, anomalies, or policy violations is hard, but it’s the only way to catch a silent change before it causes a problem.

Why This Matters More Than the Usual Checklist

None of these questions require a board to become AI experts. They require directors to recognize that AI has changed the nature of third-party risk in ways that older oversight habits simply don’t capture. The data moves further, the failures look different, and the whole thing can change without warning.

This is precisely the kind of problem where an outside perspective earns its keep. At Plurilock, our Governance, Risk, and Compliance work and our AI security testing are built around exactly these gaps—tracing where data actually flows, probing vendor AI integrations for prompt injection and other adversarial weaknesses, and helping organizations build third-party risk programs that account for systems that don’t hold still. We find the exposure that standard questionnaires miss, because we test the way real attackers do.

Boards don’t need to fear AI. But they do need to ask better questions about it—and then make sure someone can actually answer them. ■