What should we ask an AI vendor in a security review?

Where our data resides and whether it trains models; what access the vendor holds and when it ends; who owns the code, prompts, infrastructure, and evals; what happens if the vendor disappears; and which subprocessors touch our data. The answers that reduce risk all point the same way: the system runs in your cloud and you own it.

What is a red flag in an AI vendor security review?

The vendor holds your data on their platform, keeps standing access after go-live, cannot say who their subprocessors are, or cannot commit that your data will not train a model. Each one is a surface you then have to review and monitor indefinitely.

How do you shorten an AI vendor security review?

Reduce what there is to review. A vendor who builds in your cloud, keeps no copy of your data after handover, and hands over ownership leaves almost nothing on the third-party risk register, which is usually the fastest path through procurement.

When should security terms be agreed?

Before the build, in writing. Data handling, access scope, subprocessors, and the handover belong in the MSA and SOW, not discovered at go-live. A vendor who resists specifying them early is telling you how the engagement ends.

The AI vendor security review, answered

The short answer

An AI vendor security review comes down to five questions: where your data lives and whether it trains models, what access the vendor keeps and when it ends, who owns what is built, what happens if the vendor vanishes, and who else touches your data. The answers that lower risk all reduce to one thing: the system runs in your cloud and you own it, so there is little left to review.

By the time an AI engagement reaches security review, the buyer usually wants it to work. The review is not there to say no. It is there to answer one question honestly: what could go wrong because we let this vendor in? The vendor's answers to a handful of questions decide how long that takes, and whether it ends in a yes.

Why the review got harder

Third-party involvement in breaches doubled to 30% in 2025, according to Verizon's Data Breach Investigations Report. Every vendor is part of your attack surface, and AI vendors tend to ask for more of it than most: your data to process, a platform to run on, and standing access to keep it working. The review is harder because the default arrangement gives a security team more to worry about, not less.

The questions that matter

Strip the questionnaire to what actually moves risk, and the difference between a safe vendor and a costly one shows up in the answers.

The question	A risky answer	A safe answer
Where does our data live?	On the vendor platform, or "our cloud".	In your own cloud accounts. It never has to leave.
Is our data used to train models?	Vague, or "anonymized".	No. Not for us, not for anyone.
What access does the vendor keep?	Standing admin, indefinitely.	Least-privilege during the build, revoked at handover.
Who owns the code, prompts, infra, evals?	The vendor, licensed to you.	You do: built in your accounts from the first commit, yours as each phase is paid.
What if the vendor disappears?	The system stops or gets stranded.	Nothing operational. You already run it.
Which subprocessors touch our data?	Unclear or unlisted.	A short, named list, or none beyond your own stack.

The pattern in the safe answers

The safe answers are all the same answer: you own it, and it runs in your cloud.

Read the right-hand column top to bottom and it collapses into a single posture. Data that never leaves cannot be mishandled by a vendor. A system that runs on your infrastructure cannot strand you. Access that ends at handover cannot be abused later. That is the argument for ownership as the security posture: it does not manage the vendor-risk surface, it removes most of it. There is less to review because there is less to trust the vendor with.

Ownership only counts if you can operate what you own, which is why the handover has to include prompts, evals, credentials, and runbooks, not just the code. A repository you cannot safely run is not an answer to a security question.

Ask before you sign

The questions above belong in the contract, not the retrospective. Data handling, access scope, subprocessors, and the handover standard go in the MSA and SOW before the build starts. A vendor who can put them in writing early is showing you the engagement ends in your hands. One that resists is showing you the opposite. The rest of that judgment call is in how to choose an AI development partner, and the enterprise version of this posture is on the enterprise page.