The SaaS Vendor AI Due Diligence Checklist: 13 Questions To Ask Before You Sign

A practical AI due diligence checklist for SaaS buyers. Thirteen questions you can realistically get answered, with the reasoning behind each one.

Michael Mullins

Michael Mullins

— 8 min read
Share
The SaaS Vendor AI Due Diligence Checklist: 13 Questions To Ask Before You Sign

If you buy SaaS, you already buy AI. It arrived in your stack through product updates, not through procurement.

Most AI due diligence checklists in circulation run to thirty or forty items and assume you can compel a vendor to hand over regression benchmarks and model architecture diagrams. If you are a 40 person company buying a scheduling tool, you cannot. The vendor will ignore the questionnaire, or send you a link to a trust page.

This checklist has thirteen items. Every one of them is a question a small team can get answered, either from the vendor's documentation, from the contract, or from a short email that a mid-sized supplier will actually reply to. Each item includes why it matters, because a checklist you follow without understanding is just a box-ticking exercise with extra steps.

Before you start: decide how much diligence this deal deserves

Not every purchase needs the full list. Before you send anything to a vendor, answer one question: what happens if the AI gets it wrong?

If the AI drafts meeting summaries that a human reads and edits, a wrong output is an annoyance. If it screens job applicants, scores credit risk, flags fraud, or triages anything safety related, a wrong output is a legal and human problem, and it may put you in scope for obligations under the EU AI Act.

For low impact tools, items 1 to 7, plus 10 are enough. For anything that touches personal data at scale, or that influences a decision about a person, work the full list and do not sign until the gaps are closed.

What you are actually buying

1. Which parts of the product depend on AI?

Ask for a list of features, modules and workflows that use AI, and whether each is on by default.

Why this matters: You cannot assess something you have not located. Vendors describe AI at the marketing layer ("AI-powered insights") and buyers assume it is one contained feature. It is often several, spread across search, summarisation, routing, ranking and support tooling, some of which process data you never intended to expose to a model. This list is also what you will re-check in twelve months when the product has changed.

2. Which models are used, and via which providers?

Ask for the specific models and the providers behind them. Anthropic, OpenAI, Google, Mistral, AWS Bedrock, Azure OpenAI, or self-hosted open weights.

Why this matters: The vendor's security posture is not the whole picture. Their model provider's is now part of yours, and the provider's terms may differ substantially from the vendor's own. A vendor with excellent controls calling an API on default consumer terms has undone its own work. You also need this to answer the residency question in item 6, and to know who to look at when a provider has an incident.

3. Will you be told when the model or provider changes?

Ask for a contractual commitment to notify you before the underlying model or provider changes, with a defined notice period.

Why this matters: This is the item almost every checklist misses, and it quietly invalidates all the others. Everything you verify at signing is a snapshot. Vendors switch models for cost or performance reasons and announce it in a release note, if at all. A change of provider can move your data to a different jurisdiction, under different terms, with different training defaults, without a single line of your contract changing. Without notification, your assessment has a shelf life you cannot see.

What happens to your data

4. Is prompt data used for training or fine tuning?

Get a written answer covering prompts, uploads, outputs and support tickets, at both the vendor layer and the model provider layer. Ask whether the setting is contractual or a toggle in an admin console.

Why this matters: "We do not train on customer data" is frequently true of the vendor and false of the provider they call, or true of the default configuration and false of the plan you are on. If it is a toggle rather than a contract term, it can be reset by a migration or a support engineer. Get it in the DPA.

5. Is prompt data retained, and can it be deleted?

Ask for specific retention periods, and for what deletion actually covers. Prompts, outputs, logs, cached embeddings and vector indexes.

Why this matters: Retention is where "we do not train on your data" and "your data is in our systems for 30 days" both turn out to be true at the same time. Abuse-monitoring retention at the model provider is a common blind spot, and it is often separate from anything the vendor controls. Derived data is the second blind spot. Deleting a document does not necessarily delete the embedding generated from it.

6. Where is the data processed and stored, at both layers?

Ask separately about the SaaS platform and the model inference. Get the regions for each.

Why this matters: These two answers diverge more often than not. A Swiss-hosted, Swiss-registered SaaS calling a US model API is doing US processing, whatever the residency page says. For Swiss buyers this is a revFADP transfer question and, for many, a FINMA or professional secrecy question as well. For EU buyers it is a Chapter V question. The vendor's own hosting location tells you very little on its own.

7. Which third parties have access to the AI data?

Ask for the subprocessor list covering the AI features specifically, and for how you are notified when it changes.

Why this matters: Beyond the model provider there is usually an observability platform, an evaluation tool, sometimes a human review vendor. Each one is another place your prompts exist. Standard subprocessor lists were written before AI features arrived and frequently have not been updated to include them, so ask explicitly rather than accepting the general list.

What the vendor can prove

8. What AI-specific certifications or assurance does the vendor hold, and what is in scope?

Ask for ISO 42001 certification, an AI-specific assurance report, or a documented AI governance framework. Then ask for the scope statement.

Why this matters: The scope statement is the whole point, and almost nobody reads it. A certificate can legitimately cover an organisation's management system while excluding the AI feature you are buying, or cover a subsidiary that is not the entity on your contract. If the vendor holds nothing at all, that is not automatically disqualifying for a low impact tool, but it tells you the governance is informal and the answers to items 3 through 7 are less likely to survive a change of staff.

9. What security certifications does the vendor hold, and do they cover the AI components?

Same question, same follow-up. ISO 27001, SOC 2 Type II, and the scope.

Why this matters: AI features are frequently built by a newer team, on newer infrastructure, outside the boundary that was audited two years ago. The certificate is real and the AI feature is outside it. Ask whether the AI components sit inside the certified scope, and if the vendor cannot answer that quickly, you have learned something useful about how well they know their own boundary.

What you control

10. Can you turn it off, and can a human stay in the loop?

Ask whether AI features can be disabled per tenant, per workspace and per user, and what oversight controls exist over outputs.

Why this matters: For most SMEs this is the only mitigation you actually own. Everything else depends on the vendor keeping its word. An off switch at workspace level lets you run the AI where it is useful and exclude it from the HR system or the client files. It is also the practical answer if a later review goes badly, because it lets you reduce exposure without terminating a contract you depend on.

What the contract gives you

11. Do you have a right to audit?

Check whether the contract gives you audit rights, and what form they take: on-site, questionnaire, or reliance on third-party reports.

Why this matters: In practice you will rarely exercise it, and that is fine. The value is that it makes every answer above enforceable rather than decorative. Without it, the questionnaire the vendor signed is a statement of intent. Note that most SaaS contracts satisfy this with "we will provide our SOC 2 report", which is acceptable only if item 9 confirmed the AI is in scope.

12. Is there an incident response SLA covering AI-specific failures?

Check notification timelines, and check that the definition of an incident is broad enough.

Why this matters: Standard SaaS incident clauses were written for breaches and outages. An AI incident may be neither. A prompt injection that causes data leakage between tenants, a model update that starts producing systematically wrong outputs, or a provider-side exposure are all events you need to hear about, and none of them look like a classic breach. If the clause only triggers on unauthorised access to personal data, half of what can go wrong here will never be reported to you.

13. What happens to your data when you leave?

Check what is deleted on termination, on what timeline, and what evidence you get.

Why this matters: Exit is where the retention answers get tested. Prompts, outputs, logs and derived indexes should all be named. So should the model provider's copies, which the vendor may not control and should be honest about. Ask what you receive as proof: a deletion certificate, an attestation, or nothing at all.

One thing this checklist will not tell you

Everything above assesses the vendor. It does not assess you.

If you deploy an AI system in the EU, you are a deployer under the EU AI Act, with your own obligations. Depending on the risk classification, those can include human oversight, using the system in line with the provider's instructions, keeping logs, informing affected workers, and ensuring the people using it are competent to do so. None of that transfers to the vendor because you bought their product. Being outside the EU does not settle it either: the Act reaches Swiss companies whose AI systems, or the outputs of those systems, are used in the EU.

This catches people out. The diligence gets done, the contract gets signed, and nobody notices that the organisation has taken on duties of its own. If the tool influences decisions about people, this is worth ten minutes with someone who knows the classification rules before you deploy.

Scoring it

Once you have answers, score the vendor rather than counting failures.

I treat items 4, 5 and 6 as critical. If prompt data is trained on, retained indefinitely, or processed somewhere you cannot justify, that is a stop rather than a finding, regardless of how good the rest looks.

Item 3 is the one I would fight for in negotiation. It costs the vendor almost nothing and it is what keeps the rest of your assessment alive.

Items 8, 9 and 11 are where a small vendor will legitimately be weak. A twelve person company will not have ISO 42001. Judge that against the impact of the use case rather than against a fixed bar, and consider a time-limited pilot with restricted data instead of a straight refusal.

If the vendor has no ISO 42001

If a small vendor has no ISO 42001, ask them to complete CSA's AI-CAIQ and submit it to the STAR Registry as a STAR for AI Level 1 self-assessment. Certification costs money that a small SaaS provider does not have. This does not. The questionnaire looks intimidating at over 300 questions, but it carries a shared responsibility ownership column, so most of the infrastructure, datacentre and endpoint controls are marked as inherited from their cloud provider rather than written up.

The real work lands in a handful of domains: model security, data security and privacy lifecycle, supply chain. Those are the ones you care about anyway. Public entries from larger vendors give them a reference for the rest. Be clear about what Level 1 is: a self-declaration published in public, with no audit behind it. Level 2 is the audited tier, requiring ISO 42001 certification plus a Valid-AI-ted questionnaire. The value of Level 1 is that a team has to sit down and answer honestly in a standard format, and what they cannot answer tells you more than what they can.

Keep the record

Whatever you decide, record the answers somewhere central, with the date and the named owner. Not for the audit. For the day in eighteen months when the vendor changes something and you need to know what you agreed to in the first place.

Sources and further reading

Read more