Eight items most AI vendor reviews miss, the contract terms that make them enforceable, and why we publish the list.

12 May 2026·7 min·Veetso engineering team, reviewed by Dr Reza Rezaey

Vendor due diligence for AI models, the way banks should do it.

Most AI vendor reviews we have seen are SaaS reviews with the word "AI" added at the top. They cover security and uptime, which matter, and ignore the things specific to AI, which matter more. This post lists what we actually check before a model provider gets to see one byte of bank data, and why each item is non-negotiable.

What standard SaaS due diligence covers

A standard vendor review will look at: encryption at rest and in transit, SSO support, data residency, retention, SOC 2 / ISO 27001 attestations, financial health, incident response, and the contract terms around uptime and breach notification. All of these still apply to an AI vendor and we run them in full.

The problem is that they are not enough. An AI vendor is not just a database vendor; the data they receive is processed in ways a database vendor's contract never had to address. The questions below are the ones the standard review does not ask.

What we add for AI vendors

01. No training on our data

The contract must state, in writing, that our data is never used to train any model, including future versions, including aggregated or anonymised forms. The default is on; we accept no opt-out language that places the burden on us to remember.

We have walked away from vendors who would not put this in the contract. We have walked away from vendors who put it in the contract but reserved the right to change the terms unilaterally. The default direction of travel is for vendors to soften this clause over time; ours has to harden.

02. Data residency we can name

The vendor tells us which jurisdictions our data is processed in, by name, for every stage of the pipeline including ephemeral inference. "We use a global infrastructure" is not an answer. If they cannot name the jurisdictions, our data does not go to them.

03. Retention measured in days, not years

How long does the vendor hold the prompt, the response, the logs, and any intermediate state? The answer should be measured in days for inference traffic, and the deletion has to be verifiable. If the answer is "we keep it for service-improvement purposes for 12 months", we use a different vendor.

04. Model versioning, public changelog

When the underlying model is updated, do we get notice? Can we pin a version? Is there a public changelog with the model identifier, the training cutoff, and any safety-relevant changes? A vendor that ships silent model changes is not usable for a regulated workflow, because we cannot reproduce the behaviour of a system whose components change underneath us.

05. Acceptable-use enforcement

What does the vendor do when their model is asked to do something it should not? Is the refusal documented? Is the boundary tunable? We need to know because the boundary affects what we can show the model, and because vendor refusals become our customer-facing problem if we are not ready for them.

06. Eval transparency

What evaluations does the vendor run on the model, and are the results public? "Trust us, it is safe" is not a security review. We expect to see at least the safety, refusal, and accuracy evals against published benchmarks. If the vendor does not publish them, we run our own against the model and compare.

07. Incident response specific to model behaviour

A model that hallucinates a false fact in a customer-facing answer is a different kind of incident than a database breach. The vendor's incident response plan has to cover behaviour incidents, not just security incidents. We want to see the playbook before we sign.

08. Sub-processor list

Every provider the vendor uses (cloud infrastructure, content moderation services, other model providers they route to) shows up on the vendor's sub-processor list. If we are not comfortable with one of those sub-processors, we say so before we sign.

The contract terms that go with the checklist

Three non-standard contract terms make the rest of the checklist enforceable:

Right to audit. We have the right, on reasonable notice, to inspect the vendor's controls relevant to our data. Most enterprise contracts include this; we make sure ours does.
Notification on material change. When the vendor changes the model, the retention, the residency, or the sub-processor list, we get notified before the change takes effect, with enough time to evaluate.
Exit terms. When we leave, our data is deleted within a defined window, with written confirmation. "On request" is not a window.

Why we publish this list

Two reasons. First, vendors who read it know what we are going to ask, and the ones who cannot answer self-select out of the conversation early, saving everyone time. Second, it is a useful template for other regulated organisations that are doing AI vendor review and might not yet have written one. Borrow what is useful.

Where this fits in our controls

Vendor due diligence is gate 06 in the six gates we apply to every AI workflow. It runs in parallel with the use-case registration so that by the time a workflow is approved for build, the vendor for it has already cleared the review.

Reviews are renewed annually or on any material change to vendor terms, whichever is sooner. The vendor list is itself an artefact in the audit log, with the version of the review each vendor passed.

FAQ

Questions readers ask

What is AI vendor due diligence?

AI vendor due diligence is the review a bank runs on a model provider or AI infrastructure supplier before any bank data flows to them. It extends standard SaaS vendor review with AI-specific checks: no-training contract terms, named data residency, retention measured in days rather than years, model version pinning, eval transparency, and behaviour-incident response.

What does a no-training contract clause look like?

It states explicitly, in writing, that the vendor will not use bank data to train any model, including future versions, including aggregated or anonymised forms. The default direction across the industry is for vendors to soften this clause; ours has to harden, with no unilateral right to change the terms.

What is the right-to-audit clause?

A contract term that gives the bank the right, on reasonable notice, to inspect the vendor's controls relevant to bank data. Most enterprise contracts include it; we make sure ours does. Without it, the vendor checklist is advisory rather than enforceable.

How often should AI vendor reviews be renewed?

Annually at minimum, or on any material change to vendor terms (whichever is sooner). The vendor due-diligence file is itself an artefact in the audit log, with the version each vendor passed at the time of review.

Why publish the vendor checklist publicly?

Two reasons. First, vendors who read it know what we will ask, and the ones who cannot answer self-select out of the conversation early. Second, it is a usable template for other regulated organisations doing AI vendor review and might not yet have written one.