Skip to content
AI Compliance Tool
Check my AI risk
PlatformSolutionsPricingRegulationsFree toolsGuides Partners Sign in

AI Vendor Due Diligence Checklist

Twelve question areas for assessing AI vendors, from training data and retention to model changes, with how to verify claims and the red flags that should stop a deal.

By AI Compliance Tool editorial team · Published 2026-10-14 · Reviewed 2026-10-14 · Reviewer: Pending independent review · 10 min read

Key takeaways

  • You stay accountable for personal information your vendors process; due diligence is how you evidence that accountability, not a way to transfer it.
  • Ask twelve question areas in writing and attach the answers to the inventory entry. Unanswered questions are scored as risk, not as neutral.
  • A claim of certification is not evidence. Ask for the certificate, the issuing body, the scope and the date, or the audit report and its bridge letter.
  • Model changes are the vendor risk most businesses miss: ask how you will be told when the model, its guardrails or its data practices change.
  • Walk away from vendors that will not answer in writing, train on your data with no opt-out, or cannot say where your data is.

Most small businesses do not build AI; they buy it. That means most AI risk arrives through vendors, and most of the evidence you will ever need lives in what you asked them and what they answered.

Due diligence does not move accountability. Under PIPEDA Principle 4.1.3 an organisation remains responsible for personal information transferred to a third party for processing; Alberta PIPA s. 5 and BC PIPA say the equivalent; Quebec Law 25 s. 17 requires an assessment and a written agreement before communicating personal information outside Quebec. The EU AI Act puts deployer duties on you even when the provider built the system. Due diligence is how you show you took that responsibility seriously.

How to run it

  1. Send the twelve question areas below in writing before any personal or confidential data flows.
  2. Ask for documents, not assurances: policies, reports, certificates, contract clauses.
  3. Score each area: answered with evidence, answered without evidence, not answered. Treat “not answered” as a risk in your assessment, not as neutral.
  4. Attach the answers and your decision to the inventory entry, and set a review date.

For a low-stakes tool (drafting from public inputs), a short version of areas 1, 2, 3 and 12 may be enough. For anything touching personal data, decisions about people or agent actions, run all twelve.

The twelve question areas

1. Training data

  • Are our inputs, uploads, outputs or metadata used to train, fine-tune or improve your models or anyone else’s? Is that off by default on our tier? Where is this stated in the contract?
  • What data was the underlying model trained on, at the level of categories and sources? Was personal data scraped from the web? (Canada’s privacy regulators’ generative AI principles flag web-scraped personal data as needing a lawful basis.)

2. Retention

  • How long are prompts, files, outputs and logs retained, by default and at minimum? Can we set a shorter period?
  • Are there separate retention periods for abuse-monitoring copies, backups and support access?

3. Security

  • Which recognised security framework does your program follow, and can you share the most recent independent report (not a summary page)?
  • How are our data and other customers’ data separated? Who at the vendor can see our content, and under what controls?
  • What protections exist against prompt injection and data exfiltration through the model? This matters for any tool that reads documents, email or web pages on your behalf.

4. Incident notification

  • What is your commitment, in hours, to notify us of a security incident or confidentiality incident affecting our data?
  • Who is notified, how, and what information is included? Quebec requires enterprises to handle confidentiality incidents with a real risk of serious injury, and Alberta PIPA s. 34.1 requires Commissioner notification where there is a real risk of significant harm; your vendor’s clock has to be fast enough for yours.

5. Model evaluations

  • What testing has been done on the model and on the product as configured for us: accuracy, robustness, bias, harmful output? Can we see the results, not just the claim?
  • For tools that rank, score or screen people: what adverse-impact or discriminatory-effect testing exists, by which groups, and when was it last done? This is directly relevant to Title VII disparate-impact exposure for US employers, Illinois HB 3773, NYC Local Law 144 bias audits, and, from 2 December 2027, EU high-risk provider duties (Arts. 9, 10 and 15).

6. Transparency and documentation

  • Is there a model or system card, instructions for use, and a statement of known limitations?
  • For EU Annex III uses, will you provide the documentation the AI Act requires providers to give deployers? For Colorado, will you provide the technical documentation SB 26-189 requires developers to give deployers from 1 January 2027 (intended uses, training-data categories, known limitations, instructions for human review)?

7. Subprocessors

  • List every subprocessor that touches our data, including the upstream model providers, hosting and support tools.
  • How will we be notified of changes, and can we object?

8. Deletion

  • How do we delete a user’s data, a conversation, or everything on termination? How long does deletion take, and does it reach backups and the upstream model provider?
  • Will you certify deletion in writing?

9. Geography

  • Where is our data stored and where is it processed, including by subprocessors? Can we restrict to a region?
  • Does any processing happen outside Canada, the EU or the country we operate in? Quebec s. 17 and GDPR transfer rules turn this into a contractual requirement, not a preference.

10. Access controls

  • Can we manage users, roles and leavers centrally? Is single sign-on supported?
  • What can the tool itself access in our environment (email, files, CRM, calendars), and can we scope that per user?

11. Human review

  • Does the product allow a human to review, override and stop outputs or actions before they take effect? Is that the default?
  • For tools that affect decisions about people, can we route cases to a human reviewer and record it? Quebec s. 12.1, GDPR Art. 22 and Colorado SB 26-189 all expect a human-review route.

12. Model changes

  • How and when will you tell us the underlying model, its guardrails, its system instructions or its data practices change? Can we pin a version or test before a change goes live?
  • Colorado SB 26-189 requires developers of covered ADMT to notify deployers of material updates from 1 January 2027; ask for that commitment everywhere.

How to verify claims

Vendors say things on websites that their contracts do not say. Use this hierarchy, from weakest to strongest:

What the vendor offersWhat it provesWhat to ask for
Marketing statement (“enterprise-grade”, “we never train on your data”)Nothing enforceableThe contract clause that says it
Trust-centre summary pageIntentThe underlying documents
Claim of certification (“ISO 27001 certified”, “ISO 42001 certified”)That a certificate may existThe certificate itself: certification body, accreditation, scope, expiry
Certificate from an accredited bodyThat a management system was audited for the stated scopeConfirm the scope covers the service you are buying
Independent audit report with findings and periodWhat controls were tested and whether exceptions existThe full report under NDA, plus a bridge letter if the period has lapsed
Contract and data-processing termsWhat you can enforceEverything above reflected in writing

Two points often misunderstood. First, ISO/IEC 42001:2023 is a voluntary management-system standard; a certificate is issued by an accredited certification body, not by ISO, and tells you the vendor’s AI management system was audited against the standard for a defined scope. It does not tell you how your data is handled under your contract. Second, “aligned with the NIST AI RMF” is a self-description of a voluntary framework. It is useful context, not a certification, and does not establish legal compliance for you or them.

For evaluation claims, ask who ran the test, on which model version, on what dataset, and when. A claim such as “95% accurate” with no answer to those four questions is also a consumer-protection exposure for the vendor: the FTC has acted against unsubstantiated AI accuracy claims (Workado final order, August 2025), and a careful buyer does not repeat such claims in its own marketing.

Red flags

Stop or escalate when you see any of these:

  • Refusal to answer in writing, or answers that only reference a web page that can change.
  • Training on your inputs by default with no opt-out on your tier.
  • Inability to say where your data is stored or which subprocessors see it.
  • No incident-notification commitment, or one measured in “promptly” rather than hours.
  • “Certified” with no certificate, or a certificate whose scope does not cover the product you are buying.
  • Accuracy or bias claims with no test details.
  • No way to turn off actions (sending, posting, updating records) or to route to a human.
  • No model-change notice process; you learn about changes from behaviour.
  • Pressure to sign before the questionnaire is answered.
  • A reseller that cannot name its upstream model providers.

Worked example

Larkspur Home Services, a 40-person HVAC company in Edmonton, evaluated a call-handling AI that would answer the phone, book jobs and record customer details. Nine of twelve areas were answered with documents. Three were not: the vendor could not confirm whether call audio was used to improve its upstream speech model, named “a major cloud provider” as the only subprocessor, and had no model-change notice process.

Larkspur scored the three gaps as risks (likelihood “unknown”, scored high), negotiated a contract clause excluding training on its data, obtained the actual subprocessor list, and accepted a 30-day change-notice commitment with a right to test. The inventory entry records all three documents and a review date of one year. Without the written questions, Larkspur would have bought a tool that stored Alberta customers’ call recordings in an unknown place under unknown terms, in tension with its PIPA s. 34 reasonable-security duty.

Sources

Frequently asked

Is a security questionnaire enough for an AI vendor?
No. Standard security questionnaires rarely cover training-data use, model evaluations, human review or model-change notice. Add the AI-specific areas in this checklist to whatever security review you already do.
Our vendor says they are 'ISO 42001 certified'. Does that settle it?
Ask for the certificate. Verify the accredited certification body, the scope (which services and sites), and the expiry date. A certificate shows a management system was audited; it does not tell you how your data is handled under your contract.
What if the vendor is a reseller of a larger model provider?
Then you need answers for both layers. Ask the reseller which upstream providers process your data, under what terms, and whether the upstream provider trains on inputs sent through the reseller.
How often should we repeat due diligence?
Annually, and on any trigger: a model change notice, a new feature with write or send capability, a security incident, a change of subprocessors or a change in where data is processed.

This guide is general information, not legal advice. Laws and dates are drawn from our verified regulatory dataset and link to official sources; check them for changes after the review date.