Most vendor risk questionnaires were written before any of your suppliers ran your data through a model. They ask about encryption, access control, and incident response—all of which still matter, and none of which tell you whether a vendor is training on your customer records, routing your data through a model provider you have never heard of, or letting an autonomous agent take actions on your behalf.
AI vendor risk is the set of exposures that open up when the third parties you depend on start using artificial intelligence, and it sits in the blind spot of the assessment process most organizations still run. This is a practical guide to what that risk actually is, why standard vendor reviews miss it, how to assess a vendor that uses AI, and which frameworks are emerging to give the work structure.
What is AI vendor risk?
AI vendor risk is the risk your organization inherits when an external party uses AI to process your data, make decisions that affect you or your customers, or operate inside your systems. It is a subset of third-party risk, but it introduces failure modes the older discipline was not built to catch.
Two things make it different from ordinary vendor risk. The first is opacity: with a traditional vendor you can reason about controls, but with an AI system the behavior emerges from training data and model weights you cannot inspect, and even the vendor may not be able to fully explain a given output. The second is that the thing you assessed can change underneath you. A vendor can swap the model behind their product, retrain it, or update a system prompt—and the system you approved in March can behave differently in June with no contract change and no notification.
The risk surfaces an AI vendor opens up
Data use & training
If your inputs are used for training or fine-tuning, they can influence outputs to other customers—and become very hard to delete once baked into model weights. Get the opt-out commitment in writing and verify it.
Model provenance & subprocessors
You need to know which underlying models a vendor uses and who provides them. That provider is now effectively a subprocessor for your data, with their own data-handling terms your vendor inherits.
Automated decisions
If a vendor's system decides something about a person—a credit limit, a fraud flag, a job application—you have inherited accountability for that decision, including its bias and explainability problems. 'The vendor's algorithm did it' is not a regulatory defense.
Accuracy & fabrication
Generative systems produce confident output that can be wrong. A vendor that uses a model to summarize, classify, or generate content can surface fabricated information into your workflow, and the risk scales with how much your team trusts the output without checking it.
Model-layer security
AI systems have attack surfaces that standard vendor reviews do not cover: prompt injection, training-data poisoning, model extraction, and sensitive data leakage through outputs. Excellent traditional security posture and model-layer exposure can coexist.
Shadow AI
Employees paste sensitive data into consumer AI tools that were never assessed, never contracted, and never approved. The tool is a third party, the data is exposed the moment it is submitted, and no one in the program knew the relationship existed.
Why traditional vendor assessments miss AI risk
A standard questionnaire is organized around a fixed picture of what a vendor does with your data: where it is stored, who can see it, how it is protected. AI breaks that picture in three specific ways. It asks the wrong questions. There is usually no line for 'do you use our data to train or fine-tune models,' 'which model providers sit behind your product,' or 'does your system make automated decisions about our customers.' If the form does not ask, the vendor does not answer, and the risk goes unrecorded. It assumes a static system. The whole assessment model rests on the idea that you evaluate a thing once and it stays roughly that thing. Models get updated continuously, and a vendor's AI capabilities often ship faster than your annual review cycle can track. It stops at the vendor's edge. An AI feature is frequently a thin wrapper over a foundation model from a separate provider—which means your data may travel one more hop to a party you never assessed and have no contract with.
Extending your existing program for AI
You do not need a separate program for AI vendors. You need to extend the one you have with AI-specific questions, gather evidence rather than accept claims, and re-check the vendors whose AI does something consequential. Tier the depth to what the AI does. A vendor using a model to draft marketing copy is a different risk than one using a model to approve loans or make decisions about your customers. For the consequential cases, build in a trigger for model or behavior changes rather than relying only on an annual date. Then ask for evidence behind the answers: a data-processing addendum that names AI subprocessors, an ISO 42001 certification or NIST AI RMF self-assessment, model cards or documentation, and the results of any red-teaming the vendor has done.
Agentic AI is a sharper version of the same problem
The fastest-moving corner of this is agentic AI—systems that take actions rather than only answering: they browse, send messages, move data, execute transactions, and call other tools. When a vendor's product includes an agent, or when you grant an AI agent credentials into your own environment, the risk changes in kind.
An agent with permissions can do whatever those permissions allow, including things you did not anticipate when you granted them. The questions stop being only about data and start being about authority: what can this agent do, what credentials does it hold, what stops it from acting on a malicious instruction hidden in a web page or a document, and is there a human in the loop for consequential actions. Treat agent permissions the way you would treat a new employee's access—with least privilege and an audit trail—because functionally that is closer to what you are granting.
The fourth-party model problem
Articles on third-party risk talk about fourth parties—the vendors your vendors use. AI adds a particularly important one: the foundation model provider. When you adopt a SaaS tool that added an AI feature, you have often added a dependency on a model provider you did not choose and cannot see in your contract with the vendor.
This matters for concentration risk too. A large share of AI features across the entire software market run on a small number of foundation models. You can carefully diversify your vendors and still find that most of them route to the same two or three model providers—which means a single provider's outage, policy change, or incident can ripple across your whole vendor base at once. Mapping which of your vendors depend on which model providers is becoming part of a serious program.
How to assess a vendor that uses AI
A working set of questions to add at intake and assessment. Ask for evidence behind the answers—the same way you would for any other control.
Does your product use AI, and for what functions specifically. Scope the AI use before everything else—you need to know what you are assessing before you can assess it well.
Do you use our data to train, fine-tune, or improve any model? If so, can we opt out, and is that commitment contractual. Confirm it covers any downstream model providers, not just the vendor's own systems.
Which model providers and AI subprocessors are involved, and where is our data processed. The underlying provider is a subprocessor you now depend on. Get them named in the data-processing addendum.
Does the system make or materially influence automated decisions about individuals? If so, how is it tested for bias and how is a decision explained to the person it affects. Regulators treat this as a high-risk activity.
What controls protect the model layer against prompt injection, data leakage through outputs, and misuse. Ask for red-team results or third-party model-security testing, not just a policy.
How will you notify us when the underlying model or its behavior changes. Absence of a change-notification commitment is itself a risk—a vendor can retrain and redeploy with no obligation to tell you.
For any agentic features: what actions can the agent take, what credentials does it use, and where is the human checkpoint. Treat agent permissions the way you would treat a new employee's access. Least privilege applies.
The frameworks giving this structure
The governance scaffolding for AI risk is young but real. These three frameworks give a program something to map AI questions against, which beats inventing criteria from scratch.
AI governance frameworks and their relevance to TPRM
| Framework | Origin & type | Key relevance for TPRM |
|---|---|---|
| ISO/IEC 42001 | International; published late 2023; certifiable management-system standard | The first certifiable AI governance standard—roughly what ISO 27001 is for information security. A vendor certified to it has committed to a structured AI management system. Ask for it as you would a SOC 2. |
| NIST AI Risk Management Framework (AI RMF) | US; published 2023 with a generative AI profile added 2024; voluntary framework | A widely used shared vocabulary for governing, mapping, measuring, and managing AI risk. Not certifiable, but a common baseline for internal AI risk practice and vendor conversations in the US market. |
| EU AI Act | EU; first broad horizontal AI law; phasing in over several years | Risk-tiered obligations: bans certain practices outright, imposes heavy requirements on high-risk uses (credit, employment, essential services), lighter transparency duties on lower-risk systems. If you or your vendors operate in the EU, this shapes what AI uses are permitted and what documentation is required. |
What good looks like
A program that has caught up to AI risk can answer a few questions without scrambling. Most programs cannot answer any of these today—which is the gap worth closing first.
It knows which of its vendors use AI and for what. Not a guess or a policy—an active inventory, updated when vendors change their products.
It knows which foundation model providers it depends on through those vendors, and where data is processed. The concentration picture includes the model layer, not just direct vendor relationships.
It has contractual positions on training and data use for its sensitive vendors. The commitment is in the data-processing addendum, covers downstream subprocessors, and has been verified—not just accepted on a sales call.
It re-checks vendors whose AI makes consequential decisions rather than filing them once. High-risk AI use triggers reassessment on model changes, not only on an annual date.
It has at least started on shadow AI by giving employees an approved path. Prohibition alone pushes the behavior further underground. An approved alternative plus clear policy is what actually reduces the exposure.
Using AI to run the program
There is a second meaning of 'AI in TPRM' worth separating out, because the two get conflated. The first—the subject of this article—is assessing vendors that use AI. The second is using AI yourself to run the program: parsing a vendor's SOC 2 to extract control evidence, drafting first-pass assessments, summarizing findings, and flagging changes across a large vendor base.
That second use is genuinely helpful for the volume problem that buries most teams, and it is showing up across the tooling market. The honest caveat is that AI used to assess risk has the same accuracy and oversight requirements you would demand of any vendor's AI—so a finding it produces still wants a human check before it drives a decision. The tool that helps you manage AI risk is itself an AI system you are now relying on.
Frequently asked questions
What is the difference between AI risk and AI vendor risk?
AI risk is the broad set of harms an AI system can cause, including bias, inaccuracy, and misuse. AI vendor risk is the portion of that you inherit from third parties: vendors using AI on your data, in their products, or inside your systems. AI vendor risk is AI risk arriving through your supply chain.
Can a standard security questionnaire cover AI vendors?
Not on its own. Standard questionnaires were written around static systems and data-at-rest controls, and they rarely ask about training data, model providers, automated decisions, or agent permissions. You can extend an existing questionnaire with AI-specific sections rather than building a separate process.
Is it safe if a vendor says they do not train on our data?
It is the right commitment to get, but get it in the contract rather than a sales call, confirm it covers any downstream model providers they use, and treat it as a control to verify rather than a fact to assume. The vendor's own subprocessors may have different defaults.
What is shadow AI?
Shadow AI is employees using unapproved AI tools—often consumer chatbots—with company or customer data. It is a third-party relationship no one assessed, and the data is exposed the moment it is submitted. The practical fix is usually an approved alternative plus clear policy, since prohibition alone tends to push the behavior further underground.
Which AI framework should we map our vendor questions to?
If you want a certifiable signal from vendors, ISO 42001 is the one to ask about. If you want an internal organizing framework, the NIST AI RMF is widely used. If you operate in the EU, the AI Act sets obligations you do not get to opt out of. Many programs reference more than one.
How often should AI vendors be reassessed?
More often than traditional vendors at the same tier, because the underlying models change between your review cycles. For vendors whose AI makes consequential decisions, build in a trigger for model or behavior changes rather than relying only on an annual date.
