AI Vendor Risk Management: Questions to Ask Before You Buy

In April 2026, Vercel disclosed that "the incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee." An attacker used that tool to take over the employee's Google Workspace account, and from there reached some customers' non-sensitive environment variables. Nobody had reviewed Context.ai like a vendor, because it looked like a productivity app.

That gap is what AI vendor risk management closes. It is the process of reviewing a third-party AI tool before you adopt it and while you use it: what data it sees, which models and sub-processors sit behind it, what it can do with the access you give it, what evidence the vendor can show, and what happens when it changes or fails.

The numbers explain why it is urgent. According to IBM's 2026 Cost of a Data Breach Report, as summarized by the law firm Baker Donelson, AI-related breaches represented 21% of all breaches, up from 13% a year earlier. Incidents involving shadow AI, meaning employees using AI tools nobody approved, more than doubled from 20% to 43%.

Quick take One standard review is a questionnaire, a request for evidence, a contract check and a score. My estimate is an afternoon for one person per vendor, and about an hour for a low-risk tool. Most of the value comes from asking seven groups of questions and grading the answers.

Note This guide covers reviewing someone else's AI. For the general vendor program, see our guides to the TPRM lifecycle, the third-party risk management policy and the vendor management policy template. For reading a vendor's SOC 2 report, see how to review a SOC 2 report. For assessing an AI system you build or run, see the AI risk assessment guide.

By the end, you will have a checklist you can send to a vendor today, a way to grade what comes back, and a scoring method that ends in a clear approve, approve with conditions or reject.

Here's what I'll cover:

How AI vendor risk differs from ordinary SaaS vendor risk
How to triage which tools need a full review
Seven groups of due diligence questions, each with a good answer and a red flag
What a SOC 2 report or ISO certificate does not tell you about an AI vendor
The contract clauses worth negotiating
A worked scoring example, then monitoring and offboarding after approval

What AI Vendor Risk Management Is and Why It Differs From Ordinary Vendor Risk

AI vendor risk management is a vendor review extended to cover the things an AI product does that other software does not: learn from your data, rely on a model someone else runs, change behavior without a release, and act on your behalf.

The vendor may be an AI-first company, or an established tool that added an AI feature last quarter. Both need the review, because the exposure you take on, third party AI risk, comes from what the vendor does with your data and access, not from the logo on the invoice.

A normal vendor review asks whether the vendor protects your data. An AI vendor review asks that, then five more things.

What changes	Ordinary SaaS vendor	AI vendor
Use of your data	Stored and processed to deliver the service	May also be used to train or improve a model, unless the contract says otherwise
Behavior over time	Changes with a release you can read about	The underlying model can change without a release note
Who is in the chain	Hosting provider and a few sub-processors	Often a model provider and its own infrastructure as well, so a fourth party sees your data
Output	Deterministic, testable	Probabilistic, so wrong or harmful answers are a normal failure mode
Access	Permissions you configure	Permissions you grant to an assistant that then acts on them

The third row is the one buyers miss. Many AI tools are an interface on top of a model from another company, which means your prompt may pass through two or three parties before an answer comes back.

A chain showing company data flowing into an AI vendor, then to a model provider and its sub-processors, with the ordinary vendor review covering only the first link and the AI vendor review covering the whole chain.

Where AI Vendor Risk Management Overlaps With Your Existing Vendor Program

You do not need a second program. Keep your vendor inventory, your tiers, your onboarding steps and your annual reassessment, and add the AI questions in this guide to the same workflow. If you have no vendor process yet, the vendor management policy template is the place to start, and the TPRM lifecycle guide explains the stages.

What changes is where you spend your time. A routine SaaS tool may need a certificate check. An AI tool that reads customer data needs the full set below.

ISO 42001

ISO 42001 expects you to manage your AI suppliers

ISO 42001's control on suppliers (A.10.3) asks for due diligence and ongoing evaluation of the AI you buy. ComplyJet's ISO 42001 workspace includes a structured AI risk assessment workflow, plus templates and workflows for AI impact assessments.

See ISO 42001 support

Why AI Vendor Risk Management Matters Before the Contract Is Signed

The cheapest moment to review an AI vendor is before anyone has connected it to anything. After that, you are unwinding access and guessing what the tool has already seen.

Go back to the Vercel incident. According to Wiz's analysis, at least one Vercel employee had authorized the affected app with "Allow All" permissions, which gave the attacker broad access once the tool's vendor was compromised. Vercel's own bulletin says a limited subset of customers whose non-sensitive environment variables were stored on the platform were affected.

The lesson is not that AI tools are uniquely dangerous. It is that a tool one employee signs up for can hold more access than a vendor your security team approved.

A Hacker News commenter who describes themselves as a head of security, replying to a thread about the breach, called for a "strictly enforceable AI install allowlist" in April 2026. That is the control this guide is built to support: a short list of reviewed tools, and a clear route for adding one.

Three more pressures make the review worth doing early:

Customer diligence runs both ways. Enterprise buyers now ask which AI tools you use and where their data goes, in the same questionnaire as your SOC 2 answers.
Embedded AI arrives uninvited. A vendor you approved two years ago may have switched on an AI assistant since. The old review did not cover it.
The audit trail starts at approval. If an incident happens, you will be asked who approved the tool, on what evidence, and when it was last reviewed.

Watch out Approving a tool is not approving every feature a vendor later enables. Tie your approval to a named use case and a set of permissions, and treat a new AI feature or a wider permission as a trigger for a fresh review.

Triage First: How Much AI Vendor Risk Management Each Tool Needs

Not every AI tool deserves an afternoon. Sort by two things: how sensitive the data is, and what the tool can do with the access it gets.

Depth	When it fits	What you collect	Time (my estimate)
Light	No company or customer data, nothing connected, pasted public text only, such as a grammar checker	A one-line approval, the use case and an owner in your inventory	About 15 to 30 minutes
Standard	Internal or confidential business data, or connected accounts with read access, such as a meeting-notes assistant	The full question set below, a DPA, the sub-processor list and a scored review	About half a day
Deep	Customer or personal data, source code or credentials, or any ability to send, edit, delete or deploy	Standard, plus evidence review, negotiated contract terms, a named risk owner and sign-off from leadership	One to three days, spread over a week or two

The time column is my own estimate for a team of 50 or fewer, not a benchmark. It excludes waiting for the vendor to reply, which is often the slowest part.

Two rules keep the sorting honest. Anything that touches customer data starts at Deep. And a tool that looks Light moves up the moment someone connects it to a drive, a mailbox or a repository.

Pro tip Start with the AI tools that can read customer data or act on your accounts. Reviewing three Deep tools well teaches your team more than a plan to review every browser extension.

The AI Vendor Questionnaire: Questions to Ask AI Vendors Before You Buy

These are the questions to ask AI vendors, grouped into seven areas. Each table pairs the question with what a good answer sounds like and what should make you pause.

Think of it as your AI vendor questionnaire, and treat it as a conversation, not a form. A vendor that answers precisely and shows documents is telling you something. A vendor that answers with marketing language is telling you something too. Use the whole set for Deep tools, and the first four groups for Standard ones.

AI Vendor Risk Management Starts With Data Use and Training

Data use is where AI vendors differ most from other software, and where one contract sentence changes everything.

Question	A good answer	A red flag
Is our data (prompts, files, outputs) used to train or improve your models, or anyone else's?	No, stated in the contract, and the default for our plan	An opt-out buried in settings, or "to improve our services" with no limit
Does the answer differ by plan, product or free tier?	Written down per plan	"It depends", or an answer that changes after you ask twice
Who at the vendor can read our prompts and outputs, and when?	Named conditions, such as a support ticket or abuse review, with access logged	Open access, or no answer
Is any of our data reviewed by humans for evaluation?	Only with opt-in, or for documented abuse monitoring	Routine human review with no notice
If we fine-tune or ground the tool on our documents, is that kept separate from other customers?	Per-customer storage and separation described	A shared index or "we handle that"

Verdict: if the vendor cannot say in writing that your data does not train a model, treat it as if it does.

Retention, Location and Deletion in AI Vendor Risk Management

You are asking how long your data lives and where, because that sets how much of it is exposed if the vendor is breached.

Question	A good answer	A red flag
How long are prompts, outputs, uploaded files and logs kept?	A stated period for each, ideally configurable	"As long as necessary"
Where is data processed and stored, and can we choose a region?	Named regions and a way to pin one	No region stated, or it changes without notice
What happens when we send a deletion request or end the contract?	Deletion within a stated window, with written confirmation	No process, or backups kept indefinitely
Are data encrypted in transit and at rest?	Described in the security documentation or audit report	Cannot describe it
Do transcripts, embeddings or summaries survive after we delete the source?	Derived data is deleted with the source	Derived data stays

Verdict: a tool with no deletion answer is a tool you can never fully leave.

Third Party AI Risk: Model Providers and Sub-Processors Behind the Tool

This is the group most buyers skip, and it is where third party AI risk becomes fourth-party risk. The vendor you sign with may not be the company that runs the model.

Question	A good answer	A red flag
Which models power the feature, and who hosts them?	A named provider and hosting arrangement	"Proprietary AI" with no detail
Does the model provider receive our data, and under what terms?	Terms that match ours, with no training on our data	The vendor cannot say what the provider's terms are
Is there a current sub-processor list, and how are changes announced?	A public list, advance notice and a right to object	A stale list, or no notice
What happens if the vendor switches model providers or one fails?	A documented fallback and notice before a switch	Silent switching
Which of the tool's components are open source, and who maintains them?	An inventory and a patching process	Nobody knows

Verdict: you are approving the whole chain, so ask for the whole chain.

Quick take If the answer to "which model is this?" is vague, the answer to "who else sees our data?" will be vague as well. Ask both in the same email.

AI Vendor Risk Management for Security, Access and Permissions

This group is the Vercel lesson in question form. The risk is often not the model but the access you hand the assistant.

Question	A good answer	A red flag
Which independent attestations do you hold, and does the scope cover the product we will use?	A current SOC 2 Type II report or ISO 27001 certificate covering the product that touches our data	A report covering only corporate IT, a lapsed report, or none
What access does the tool request (OAuth scopes, API keys, browser permissions), and can we narrow it?	Least-privilege scopes that an admin can limit	An "all access" grant is required to work at all
How do you defend against untrusted content that tries to steer the model (prompt injection)?	A described mitigation, testing and restricted actions	"That is not a concern"
Do you support SSO, role-based access and audit logs on our plan?	Yes, and the plan is stated	Shared logins, or logs only on a higher tier
How are customers separated from each other?	A described architecture	Cannot explain

Verdict: the narrower the permission, the smaller the incident.

Try this yourself Open the third-party app grants page in your Google Workspace or Microsoft 365 admin console and sort by access level. Any AI assistant holding broad read or write access to mail, drive or calendar that your security team never reviewed belongs in your inventory today.

Model Changes and Output Quality: What Happens When the Model Moves

A vendor can improve a model and break your workflow on the same day. You are asking how they manage that, and how they know the outputs are any good.

Question	A good answer	A red flag
How are models versioned, and are we told before one changes?	Pinned versions or advance notice	Silent updates
How do you test accuracy and harmful output, and can we see a summary?	Documented evaluations with results shared	"We test internally" with nothing to show
Where are the known limitations and unsafe uses written down?	System or model documentation with intended-use limits	Marketing claims only
Can we require confirmation before the tool acts (approve, undo)?	Built in and configurable by an admin	It acts automatically, with no switch
How do we report a bad output, and what response do we get?	A defined channel and a response commitment	A general support inbox

Verdict: an AI vendor that cannot describe how its model changes cannot promise that what you approved today is what you run next month.

Compliance Evidence and Governance: What the Vendor Can Prove

Here you are checking that the vendor treats AI as a managed risk, not a feature. Small vendors may not hold every certificate, so look for a documented program, not a logo.

Question	A good answer	A red flag
Will you sign a data processing agreement, and are you our processor for personal data?	A standard DPA, offered without a fight	Refuses a DPA
How do you classify the system under the EU AI Act, and what documentation can you supply?	A stated role and category, with documents on request	"Not applicable" with no reasoning
Do you hold ISO 42001 or run a documented AI governance program?	A certificate with its scope, or a written program	Neither, and no plan
Who at the vendor is accountable for AI risk?	A named function or role	Nobody
If the tool makes content or talks to our users, how is AI use disclosed?	A described disclosure approach	Never considered

Verdict: a documented answer, even from a small vendor, beats a certificate nobody can scope.

Incidents, Logs and Exit: When Something Goes Wrong or You Leave

Ask these questions before you need them. They decide how bad a bad day gets, and how hard it is to walk away.

Question	A good answer	A red flag
How quickly will you tell us about an incident, including AI-specific ones such as a data leak through the model?	A stated window in the contract	"Promptly", undefined
Can we see logs of our own use (prompts, outputs, actions) and for how long?	Exportable logs under our control	No logs, or vendor-only access
What is your record on past incidents?	Public post-incident write-ups	Silence
What can we export if we leave, and in what format?	Documented export of data and configuration	No export path
Can an admin switch the AI features off?	A tenant-level toggle	The AI is forced on

Verdict: if you cannot get your data and your logs back, the vendor owns your exit.

Reading the Evidence: What SOC 2 and ISO Reports Miss in AI Vendor Risk Management

Answers are claims. Evidence is what lets you check them. The mistake is treating a familiar document as covering more than it does.

Evidence	What it shows	What it does not show
SOC 2 Type II report	Security and related controls operated over a period, for the scope the report defines	Model behavior, bias, safety or whether your data trains a model. SOC 2 was not designed to test those
ISO 27001 certificate	An information security management system exists, for a stated scope	Anything about the AI system, unless it is in scope
ISO 42001 certificate	A management system for AI exists, for a stated scope	That a specific model is accurate or safe for your use
DPA and sub-processor list	Who processes your data, and under what terms	Whether the model provider's terms match
Penetration test summary	That someone tested the product recently	Whether prompt injection and agent permissions were in scope
System or model documentation	Intended use, limits and known failure modes	Whether the vendor follows its own document
Incident history	How the vendor behaves under pressure	Incidents that were never disclosed

For the SOC 2 mechanics, such as scope, auditor, exceptions and bridge letters, our guide to how to review a SOC 2 report covers each step. The AI-specific addition is one question: does the report's scope include the product I am about to connect?

Try this yourself Send the vendor three lines: "Please send your current SOC 2 report or ISO certificate and its scope statement. Please send your sub-processor list and the name of the model provider. Please confirm in writing whether our data is used to train any model." The speed and precision of the reply is itself data.

An AI company has the same questions coming back at it from its own customers. That is the other side of the table, and it is where a quick, clean answer wins deals.

ComplyJet customers

Being the AI vendor your customers approve

Nitin Pande, CTO at Vink AI, an AI go-to-market platform, says "as a small team, we needed a partner who could move quickly and handle the heavy lifting." Read how they earned SOC 2 Type 1 in under a month.

Read the Vink AI story

AI Vendor Contract Clauses Worth Negotiating

A good answer in an email is not a commitment. The terms that matter should be in the contract or the DPA, where you can point to them later.

Look for these AI vendor contract clauses, in rough order of importance:

No training on your data. A clear statement that prompts, files and outputs are not used to train or improve models, for your plan.
Retention and deletion. Stated periods, and deletion on request and at exit, confirmed in writing.
Sub-processor and model-provider notice. Advance notice of changes, and a right to object or terminate.
Incident notification window. A defined time to tell you, covering AI-specific incidents as well as classic breaches.
Evidence and audit rights. The right to receive current reports and, for Deep tools, to ask reasonable follow-up questions.
Output and IP terms. Who owns outputs, and what the vendor says about infringement claims. This one needs a lawyer.
Exit and data return. A defined export format and a date by which your data is returned and deleted.

If you provide a high-risk AI system in the EU, the law pushes in the same direction. Under Article 25(4) of the EU AI Act, providers of high-risk systems and the third parties that supply them components, tools or services must set the necessary information, technical access and other assistance out in a written agreement.

Note This is a practical guide, not legal advice. Have counsel review indemnity, liability caps and output ownership before you sign anything for a Deep-tier tool.

AI Vendor Risk Assessment: Scoring Two Tools End to End

A questionnaire gives you answers. A score gives you a decision you can defend. This AI vendor risk assessment method is deliberately small: four dimensions, three levels each.

A Simple Scoring Scale for AI Vendor Risk Management

Score each dimension from 1 (low) to 3 (high), then add them up for a total from 4 to 12.

Dimension	1	2	3
Data sensitivity	No company or customer data	Internal or confidential business data	Customer or personal data, source code or credentials
Permissions	Works only on what a person pastes in	Reads connected accounts such as a drive, calendar or tickets	Can act: send, edit, delete or deploy, or holds broad OAuth scopes
Vendor transparency	Documented no-training terms, named model provider and sub-processors, change notice	Partial: some answers missing	Opaque: cannot or will not answer
Regulatory exposure	No regulated data, no decisions about people	Personal data under GDPR or similar	Decisions about people, or an EU high-risk category

Then read the total against three bands:

Total	Decision	What it means
4 to 6	Approve	Standard monitoring
7 to 9	Approve with conditions	Written conditions, a named owner and an earlier review date
10 to 12	Reject, or redesign	Do not adopt until the high scores come down

One override: any vendor scoring 3 on both data sensitivity and transparency is not approved until the open questions are answered in writing. These bands are one workable setup, not a standard. Write yours down before you start scoring, so the numbers cannot be bent to fit a decision already made.

Two Worked Examples: A Meeting-Notes Assistant and a Code Assistant

These are illustrations, not real vendors. The company is a made-up 25-person SaaS business, and every score is a judgment under the scale above, not a benchmark.

	Meeting-notes assistant	Code assistant	Free AI browser summarizer
Use	Joins customer calls, transcribes and summarizes, connects to calendar and drive	Suggests code in the IDE on private repositories, suggestions only	Reads any page the user opens, free tier
Data sensitivity	3: customer calls contain customer data	3: private source code may contain secrets	3: users open customer dashboards
Permissions	2: reads calendar, writes to drive	1: suggestions only, nothing executed	3: reads every page, broad browser permission
Vendor transparency	2: sub-processor list published, model provider not named, training answer vague	1: business-tier terms rule out training, providers named, change notice offered	3: no terms on training, no provider named
Regulatory exposure	2: personal data and call-recording consent	1: no personal data expected	2: personal data on pages viewed
Total and decision	9: approve with conditions	6: approve	11: reject

The meeting-notes assistant lands in the middle, which is where most real tools land. The conditions I would write for it: a written no-training term, a retention period you choose, use limited to internal calls until consent wording is fixed, narrower calendar and drive scopes, and the CTO as risk owner.

The code assistant passes cleanly, with one trap. If someone later turns on an agent mode that can run commands, Permissions moves from 1 to 3 and the total from 6 to 8. That is a re-score, not a footnote.

From Score to Decision: Approve, Approve With Conditions or Reject

Whoever owns the tool proposes the decision, and someone independent of that owner signs it. For a Deep tool that is typically the head of security or the CTO. Record the score, the conditions, the evidence you saw and the date, because that record is what you hand a customer or an auditor.

A flow showing triage, questionnaire, evidence, score and then three outcomes: approve, approve with conditions and reject, with approved tools entering monitoring.

Conditions only count if someone checks them. Put each one in the register with an owner and a date, and treat a missed condition as a reason to reopen the decision.

AI Vendor Monitoring: Ongoing AI Vendor Risk Management After Approval

Approval is a snapshot. AI vendor monitoring is what keeps it true. Two clocks run together: a calendar floor and event triggers that override it. I suggest at least an annual review for Standard tools and a more frequent one for Deep tools, with these events forcing a review sooner:

The vendor changes its model or its model provider
The sub-processor list changes
The vendor ships a new AI feature, or you switch one on
The tool asks for wider permissions, or someone widens them
The vendor reports an incident, or one is reported about it
Your use changes: new data, a new team or a new customer segment
A relevant rule changes or comes into force

A loop showing an annual review as the calendar floor, with seven event triggers such as a model change, a sub-processor change, a new feature and an incident each sending the vendor back to review.

Between reviews, keep a few signals going: watch the vendor's change notes, re-check third-party app grants, and sample outputs where the tool writes to customers. Vendor risk management metrics covers which KPIs and KRIs to report.

Offboarding belongs here too. When you retire a tool, revoke its grants and keys, export what you need, request deletion in writing, and record the date. Unused AI tools with live permissions are the quietest exposure on this list.

For the general vendor workflow, ComplyJet's vendor risk management product builds a vendor inventory from your connected tools, risk-tiers each vendor by what it can access, sends questionnaire templates, tracks sub-processors and sets annual reassessment reminders for high-risk vendors. The AI questions in this guide work in any tool, including a spreadsheet.

Mapping AI Vendor Risk Management to ISO 42001 and the EU AI Act

You can run the review without choosing a framework. The framework you are asked about decides where you file the output.

Source	Control or article	What it asks for
ISO 42001 Annex A	A.10.2 Allocating responsibilities	A clear split of responsibilities between you, your suppliers and your customers
ISO 42001 Annex A	A.10.3 Suppliers	Supplier services and products that match your responsible AI commitments, through due diligence, monitoring and evaluation
ISO 42001 Annex A	A.10.4 Customers	Responsibilities toward your own customers, relevant when you resell or embed the vendor's AI
EU AI Act Article 25(4)	Written agreement along the value chain	For providers of high-risk systems and their suppliers: the necessary information, technical access and assistance set out in writing
EU AI Act Article 26	Deployer obligations for high-risk systems	Use per the provider's instructions, human oversight by competent people, monitoring, informing the provider of serious incidents, and keeping logs you control for at least six months unless other law says otherwise

What is ISO 42001 and the ISO 42001 checklist explain the standard and its controls, and our EU AI Act compliance guide covers the dates and roles.

Here is how to choose where to start:

Choose ISO 42001 alignment if a customer or investor will ask for a certificate.
Read Articles 25 and 26 if you provide or deploy a high-risk AI system in the EU.
Otherwise, run the questionnaire and score now, and relabel the output when someone asks for a framework.

Mistakes That Undermine AI Vendor Risk Management

Each of these shows up as a weak answer to a customer or an auditor. All are cheap to fix early.

Reviewing the company, not the feature. A clean SOC 2 report for a vendor does not cover a new AI assistant inside its product.
Skipping the model provider. The question "who else sees our data?" has more than one answer in most AI tools.
Accepting a certificate without reading its scope. A report that covers corporate IT says nothing about the product you connect.
Approving the tool, not the permissions. The Vercel incident involved an AI app authorized with broad access.
Treating the questionnaire as the decision. A filled-in form with no score and no named owner is a record that nobody decided anything.
Letting free tiers slip through. Free plans often differ from paid ones on training and retention, and they are where shadow AI starts.
Reviewing once. A model change or a new feature can undo the result within weeks.

Quick take The test of a good AI vendor review is not its length. It is whether a new colleague could open your register, find which AI tools hold customer data, see who approved each one and on what evidence, and know when each is next due.

AI Vendor Due Diligence Checklist: The Final Gate

Use this AI vendor due diligence checklist as a last check before approving a tool. A "no" on any line means the review is not finished.

Is the use case named, with an owner and the data it will touch?
Did you triage the tool as Light, Standard or Deep?
Do you have written confirmation of whether your data trains any model?
Do you know which model provider and sub-processors sit behind the tool?
Did you check that the SOC 2 or ISO scope covers the product you will use?
Do you know exactly which permissions the tool holds, and are they the narrowest that work?
Is there a DPA, and are the key terms (training, retention, incident window, exit) in the contract?
Is there a score, a decision and a named signer, recorded with the date?
Are the conditions assigned to owners with due dates?
Is there a next review date, and a list of events that would bring it forward?

FAQs

What Is AI Vendor Risk Management?

It is the process of reviewing a third-party AI tool before you adopt it and while you use it. It covers what data the tool sees, which models and sub-processors sit behind it, what access it holds, what evidence the vendor provides and how changes and incidents are handled. It extends your normal vendor review rather than replacing it.

How Do You Assess an AI Vendor?

Triage the tool by data sensitivity and permissions, send the seven groups of questions, request evidence such as the SOC 2 report scope, DPA and sub-processor list, check the contract terms, then score the vendor and record an approve, approve with conditions or reject decision. Set a review date and the events that would bring it forward.

What Questions to Ask AI Vendors Before Adopting a Tool?

Start with four: does our data train any model, which model provider and sub-processors see it, what access does the tool need, and what does the SOC 2 or ISO scope actually cover. Then add retention and deletion, model change notice, incident notification and exit. The tables above give a good answer and a red flag for each.

Is a SOC 2 Report Enough to Approve an AI Vendor?

No. A SOC 2 report shows that security controls operated for the scope it defines. It does not test model behavior, bias or whether your data trains a model, and its scope may not include the AI product at all. Treat it as one input, and read the scope first.

Should an AI Vendor Be Allowed to Train on Your Data?

For most business data, no. Customer data, personal data, source code and credentials should not train a vendor's model, and the contract should say so for your plan. If the vendor offers training only as an opt-in, record that you declined. If it cannot say either way, treat that as a red flag.

Do AI Features Inside Tools You Already Buy Need a Vendor Review?

Yes. An AI feature a vendor switched on can read the same data as a tool you chose on purpose, and your last review did not cover it. Re-triage the vendor when a new AI feature appears, and check the sub-processors and training terms again.

What Contract Clauses Should an AI Vendor Agreement Include?

At minimum: no training on your data, stated retention and deletion, notice of sub-processor and model-provider changes, an incident notification window, evidence or audit rights, clear output and IP terms, and an exit and data-return process. Have counsel review indemnity and liability before signing for a high-risk tool.

How Often Should You Reassess an AI Vendor?

At a calendar floor and whenever something significant changes. I suggest at least annually for Standard tools and more often for Deep ones, plus event triggers: a model or sub-processor change, a new AI feature, wider permissions, or an incident.

Who Should Approve a New AI Tool?

The person who owns the use case proposes it, and someone independent signs it. At a small company that is often the CTO or head of security, with legal or privacy input for tools touching personal data. Avoid letting the requester be the only approver.

Book a demo

Turn your vendor reviews into a living register

Talk through your vendors and AI tools, how they would be tiered, reviewed and tracked, and what an auditor or customer would expect to see for a team your size.