AI Vendor Risk Assessment: What It Should Actually Check in 2026
Regulators are moving fast on AI accountability, and the real exposure is contractual, not technical. Here are the three things a proper AI vendor risk assessment checks before you ship.
You ran a security check on your AI vendor. Did anyone check the liability? Most teams treat an AI vendor as an IT decision, so the review covers data protection, uptime and infrastructure. The exposure that actually bites sits somewhere else: in the contract. When the model gets something wrong, the question is not whether the firewall held. It is who owns the output, who indemnifies whom, and where the liability lands.
Last time we looked at the clauses enterprise buyers redline first in SaaS contracts. This week we turn to the other side of the table, the AI tools you rely on, and what a proper AI vendor risk assessment should check in 2026. These are the three areas that decide whether the risk is priced or simply inherited.
Who owns the output, and who is liable when it is wrong
The first thing a real assessment checks is output ownership and accountability. AI vendor terms are often vague on who owns generated output and silent on what happens when that output is wrong, biased or infringing. To your customer, it is your product, so accountability for an AI decision usually lands on whoever put the feature in front of the user, unless the contract says otherwise.
Confirm in writing that you own or are clearly licensed to use the output, and look at what the vendor disclaims. Most AI terms disclaim accuracy entirely. If the vendor takes no responsibility for a wrong output and your customer contract makes no allowance for it, you are carrying that gap alone. The point of the assessment is to find that gap before a customer does.
The indemnity and liability cap, read together
The second area is where the money sits. AI vendor agreements frequently cap liability low, often at fees paid, and offer little or no indemnity for intellectual property infringement or for harm caused by the model. That matters because your own customers will increasingly ask you to indemnify them for exactly those risks. If you indemnify downstream but have no protection upstream, the exposure stacks on you.
Read the vendor indemnity and the liability cap together, not as separate clauses, and map them against what you promise your own customers. Look for an intellectual property indemnity on the AI output and check whether breaches of confidentiality or data sit inside or outside the cap. Where the upstream protection is thin, that is a commercial decision to make on purpose, not a clause to skim past.
Data processing, sub-processors and derived data
The third area is data, and AI changes the picture. If your product sends customer data to an AI vendor, that vendor is usually a sub-processor and your data processing agreement needs to name it. The harder question is what the vendor does with the data after it arrives: whether inputs are used for training, who holds the derived data, and what is actually deleted when the contract ends.
Derived data is the part most assessments miss. The patterns and model improvements built from how your customers used the tool rarely fall under a deletion clause written for raw data, because the learning is not the data. A proper assessment checks that training use is addressed explicitly, that sub-processors are named, and that the deletion terms reach the derived data, not only the inputs. This is also what sharp enterprise buyers now look for in your contracts, so closing it upstream protects you downstream too.
The real exposure is contractual, not technical
A security review checks whether the vendor can protect data. An AI vendor risk assessment checks where the loss lands when the model is wrong. Both matter, but only one of them is usually missing. Output ownership, the indemnity and cap read together, and data processing including derived data are the three that decide whether you have priced the risk or simply inherited it. That sits in the agreement, not the firewall.
Frequently asked questions
What is an AI vendor risk assessment?
An AI vendor risk assessment reviews the contractual exposure created when you build on or resell a third party AI tool. It checks who owns the output, who indemnifies whom when the model is wrong, how liability is capped, and whether the AI vendor is named as a sub-processor with clear terms on derived data. It is a legal and commercial review, not only a security or IT check.
Is an AI vendor risk assessment the same as a security review?
No. A security review checks how a vendor protects data and infrastructure. An AI vendor risk assessment checks where the legal risk sits when the AI gets something wrong: output ownership, indemnities, liability caps and data processing terms. The real exposure is usually contractual, and it lives in the agreement, not the firewall.
How does a fractional general counsel help with AI vendor contracts?
A fractional general counsel is senior, embedded commercial counsel for the contracts, deals and risks that actually come up, at a fraction of the cost of a full time hire and without a firm relearning your business every time. For UK technology and SaaS companies shipping AI features, it means your AI vendor agreements, your DPAs and your customer terms are reviewed together by someone who already knows your model and your risk appetite.