Assessing AI Vendors: The New Frontier of TPRM

You approved that vendor two years ago. Nothing about the contract has changed. But somewhere between then and now, they quietly bolted a generative AI feature onto their product, pointed it at a foundation model you've never vetted, and started running your customer data through it.

Nobody asked you. Nobody had to. Your vendor risk questionnaire never mentioned AI, so there was nothing to disclose.

This is the blind spot most Third-Party Risk Management (TPRM) programs have right now. We built our vendor assessments for a world of static software: hosting locations, encryption standards, SOC 2 reports, breach notification clauses. That world assumed a vendor's product behaved the same way on renewal day as it did on day one. AI breaks that assumption completely. Models get retrained. Features get "upgraded" overnight. A vendor you approved as a simple SaaS tool can become an AI processor of your sensitive data without a single line of the contract changing.

TPRM has to catch up. Here's what that actually looks like.

Why Your Existing Vendor Questionnaire Isn't Enough

Most vendor risk questionnaires were designed to answer one question: can this vendor keep our data safe and available? They're good at surfacing things like access controls, uptime guarantees, and where data is physically stored.

They were never designed to answer questions like:

• Is a machine making decisions with our data, and can anyone explain how?
• Is our data being fed into a model that a different company entirely trained, hosts, and controls?
• Will that model behave differently next month than it does today, without our vendor telling us?

That last point is the real shift. A traditional software vendor is relatively static. An AI-powered vendor is a moving target, because the underlying model is often owned by someone else, updated on someone else's schedule, and improved in ways your vendor may not fully control or even fully understand.

If your questionnaire doesn't ask about AI specifically, you're assessing yesterday's risk profile on a tool that's already changed.

The Questions You Need to Start Asking

Think of this as a new layer bolted onto your existing vendor assessment, not a replacement for it.

1. Does the product use AI or ML at all, including features you didn't explicitly buy? Vendors often roll out AI features as "enhancements" to existing tools, sometimes enabled by default. Ask specifically, not just "have you told us about AI," but "what AI capabilities exist in this product today, including ones added since our last review."
2. Whose model is it? There's a meaningful difference between a vendor that built and trained its own proprietary model, and one that's essentially a wrapper around OpenAI, Anthropic, Google, or another provider's API. If it's the latter, your real risk exposure runs two layers deep: you're inheriting risk from your vendor and from whoever they're relying on.
3. Is our data used to train anything? This is the single most important question and the one vendors most often bury in dense terms-of-service language. You want an explicit, contractual answer, not a vague assurance, about whether your inputs, outputs, or customer data become training data for the vendor's model or anyone else's.
4. What happens when the model changes? Ask whether you'll be notified when the vendor updates or swaps the underlying model. A model update can change accuracy, introduce new biases, or alter behavior in ways that affect your risk exposure, and most vendors currently have zero obligation to tell you when it happens.
5. Can they explain a decision the AI makes? If the tool is doing anything beyond low-stakes content generation, such as flagging fraud, scoring candidates, or prioritizing support tickets, ask how the vendor would explain a specific output if you or a regulator asked. "The model decided" is not an answer.
6. Do they test for bias and accuracy, and how often? Ask for evidence, not a policy statement. A one-time bias audit from launch day tells you nothing about a model that's been retrained six times since.

Evaluating the Vendor's Own AI Governance Maturity

Beyond the product itself, look at how seriously the vendor governs AI internally. This tells you a lot about how they'll behave under pressure.

• Do they have a published responsible AI policy? Not marketing copy, an actual internal governance framework.
• Do they have model documentation? Sometimes called a "model card," a plain description of what the model does, its known limitations, and what it wasn't designed for.
• Do they have a named owner for AI risk internally? If nobody can tell you who owns this, it likely means nobody does.
• Have they mapped themselves to a recognized framework like NIST's AI Risk Management Framework or ISO/IEC 42001? This doesn't guarantee competence, but its absence is a signal worth noting.

A vendor that can answer these clearly, with documentation, is operating differently than one that responds with reassurances and nothing else.

Getting the Contract to Actually Protect You

Questions are only useful if the answers get written down somewhere binding. A few contractual protections worth pushing for:

• Data usage restrictions: explicit language that your data will not be used to train the vendor's model, or any third-party model, without your separate written consent.
• Model change notification clauses: a requirement that you're told before a material change to the underlying model, not after.
• Audit rights: the ability to request evidence of testing, bias audits, or model documentation on a recurring basis, not just at onboarding.
• Liability allocation for AI errors: clarity on who's accountable when the model gets it wrong, especially for anything customer-facing or decision-making.
• Subprocessor disclosure for AI providers: the same way you'd want to know about a cloud subprocessor, you want to know if your vendor is quietly routing your data through a third-party model provider.

None of this is exotic. It's the same instinct that already drives your standard data processing addendums, just extended to cover a category of risk most contracts haven't caught up to yet.

Tiering AI Vendors by Actual Risk

Not every AI vendor deserves the same scrutiny. Applying your highest bar to every tool that touches AI will bury your team and slow the business down for no real safety gain. A simple tiering approach:

• Low risk: AI used for internal, low-stakes tasks such as drafting internal copy, summarizing meeting notes, or generating first-pass content that a human fully reviews before it goes anywhere.
• Medium risk: AI that touches customer data or influences internal decisions, but with a human firmly in the loop before anything is finalized. Think: support ticket triage or internal analytics.
• High risk: AI making or materially influencing decisions about people, such as credit, hiring, eligibility, pricing, or anything customer facing without meaningful human review.

High-risk vendors earn the full weight of the questions above, deep contractual protections, and recurring reassessment. Low-risk vendors get a lighter touch. The goal is proportionate rigor, not a blanket process that treats a note-summarizing tool the same as a lending decision engine.

This Isn't a One-Time Assessment

Here's the uncomfortable part: even a perfect assessment today has a shelf life. Traditional vendor risk assumes that once you've reviewed a vendor, their risk profile holds reasonably steady until the next scheduled review, usually annually. AI vendors don't play by that rule. The model underneath them can change on a schedule you don't control and often won't even know about unless you've built the right clauses into the contract and the right cadence into your monitoring.

That means:

• Building AI-specific questions into ongoing reassessments, not just initial onboarding
• Tracking public information about your vendors' underlying model providers, since a major incident or policy shift at an OpenAI- or Anthropic-level provider can matter to you even if your direct vendor never mentions it
• Treating "our vendor added an AI feature" as a trigger for a fresh risk review, the same way you'd treat a new subprocessor or a change in data hosting location

Key Takeaways

• Your existing vendor questionnaire likely doesn't cover AI at all. It was built to assess static software, not tools whose underlying model can change without notice.
• AI-powered vendors carry a hidden second layer of risk. Many vendors are really just wrappers around someone else's model (OpenAI, Anthropic, Google, etc.), so you're inheriting risk from both the vendor and whoever they rely on.
• The most important question is whether your data trains the model. Get an explicit, contractual answer, not a vague assurance buried in a terms-of-service page.
• A vendor's own AI governance maturity matters as much as their product. Look for a real responsible AI policy, model documentation, and a named owner, not just reassurances.
• Contracts need to catch up too. Push for data usage restrictions, model change notifications, audit rights, and clear liability for AI errors.
• Not every AI vendor needs the same scrutiny. Tier by actual risk (low, medium, high) so oversight is proportionate instead of a blanket process that slows everything down.
• This is not a one-time check. Models change on their own schedule. AI-specific reassessment needs to be built into ongoing monitoring, not just initial onboarding.

The Bottom Line

AI-powered vendors aren't fundamentally a new category of third party. They're your existing vendors, plus a layer of risk your current process wasn't built to see. The fix isn't to rebuild TPRM from scratch. It's to extend what you already do well, questionnaires — tiering, contractual protections, ongoing monitoring — to actually account for how AI behaves differently from static software.

The organizations that get this right won't be the ones that ban AI vendors outright, or the ones that wave every AI feature through unchecked. They'll be the ones that asked the right questions early, got the answers in writing, and kept asking as the models, and the risk, kept changing underneath them.

A version of this article was originally published on Sarika Bhatta's blog.