← All resources
For software and technology companies · AI vendor diligence

AI vendor due diligence: 12 questions before you sign.

Buying or embedding a third-party AI tool creates obligations that flow to you — under the AI Act and under GDPR.

Xprofesso · Resources~6 min readCurrent as of 21 July 2026Cited to source

General information for software and technology companies, not legal advice for your specific facts or jurisdiction — no lawyer-client relationship. See full terms.

TL;DR

Twelve questions, in three clusters, surface the risk in any AI vendor contract before signature: rights and ownership (who owns outputs, can they train on your data, can you leave), compliance and risk (who holds the AI Act "deployer" obligations, is there a DPA, has security been checked), and operations (uptime, silent model changes, real exit cost, liability cap). Most of this needs to be settled in the contract, not discovered after an incident.

Twelve questions

What to ask before you sign.

Grouped into three clusters — rights, compliance, and operations.

Work through these systematically before signature — a written checklist beats relying on memory during a sales call, and it gives you something concrete to hold the vendor to later.

Rights & ownership
Q1

Who owns the output?

Do the vendor's terms grant you a usable licence to what the tool generates, or just a revocable right to view results?

Q2

Can they train on your data?

Does the vendor claim any right to use your inputs — prompts, documents, customer data — to train or improve their models, and can you opt out contractually, not just via a settings toggle?

Q3

Who carries provenance risk?

If the vendor's model was trained on data with disputed provenance, does their contract offer any indemnity — or does that risk sit entirely with you?

Q4

Can you actually leave?

Can you export your data and stop using the vendor without losing access to the historical outputs your business depends on?

Compliance & risk
Q5

Who's the AI Act "provider" here?

Under the EU AI Act, the vendor is usually the "provider" of the underlying model — which often leaves you holding the "deployer" obligations, including the Article 50 disclosure duties, as the integrator.

Q6

Is there a model card?

Does the vendor publish, or contractually commit to provide, a model card, GPAI documentation, or equivalent transparency information you'll need for your own AI Act compliance file?

Q7

Where's the data processed?

If personal data passes through the tool, is there a GDPR-compliant DPA in place, and where — geographically — is the data actually processed and retained?

Q8

Has security been independently checked?

Has the vendor been assessed against SOC 2, ISO 27001 or equivalent, and will they contractually commit to a defined breach-notification window?

Operations
Q9

What's the uptime commitment?

What SLA does the vendor offer, and what happens contractually if their outage breaks your own customer-facing commitments?

Q10

How are model changes communicated?

Could a silent model-version update change your product's behaviour without notice?

Q11

What's the real exit cost?

If this vendor doubles pricing or gets acquired, is there a realistic migration path — or is this a single point of failure for your product?

Q12

Does the liability cap match the risk?

Does the vendor's liability cap realistically cover the scale of harm a failure on their end could cause your business?

Specialist note

The question vendors dodge most is Q1 — who owns the output. Most will answer confidently on uptime and security, then get vague fast on IP in generated content. That vagueness is itself the answer; price the risk accordingly.

In practice

A worked example.

SILENT
MODEL SWAP

A support-automation vendor pushed a model upgrade mid-quarter with no changelog. Response tone and accuracy shifted enough that a customer escalated — and the buyer had no contractual notice right that would have caught it earlier, only a support ticket after the fact. The fix sits in Q10 above, agreed before signature, not requested after an incident.

Sources & dating

Cited, not guessed.

Cross-references the EU AI Act deadlines and GDPR security review resources above for the underlying statutory citations. Current as of 21 July 2026.

Want AI configured to check a vendor contract against this list?

Questions

Before you act on this.

Does this apply if we're just calling an API, not reselling a product?

Yes. API-level integration still makes you a "deployer" under the AI Act for whatever the API does inside your product, and still creates a data-processing relationship under GDPR if any personal data passes through the call.

We reviewed this vendor a year ago — do we need to redo it?

AI vendor terms, model versions and sub-processor lists change more often than typical SaaS vendor contracts. A light annual refresh, not a full redo, is the pragmatic cadence most companies settle on.

What if the vendor refuses to answer some of these?

That's itself a useful diligence signal — weigh it against how deeply the tool will be embedded in customer-facing workflows. A vendor unwilling to commit to basics for a peripheral internal tool is a different risk than the same refusal for a customer-facing, core-workflow dependency.

Want a founder-level read on your own setup?

30 minutes, fixed fee, with the person who does the work — not a sales call.