AI vendor due diligence: the questions to ask
By Sam Rivera, Founder, SentinelPanda · June 2, 2026 · 3 min read · AI Governance
A standard vendor questionnaire was built for SaaS that does not change underneath you. AI vendors do. Here is what to add.
Why AI vendors need extra diligence
Vendor due diligence was designed for SaaS that runs the same code today as yesterday and changes only on a published roadmap. AI vendors deviate in three ways. First, the model underneath the API can be updated silently — same endpoint, different behaviour. Second, the training data and post-training (RLHF, fine-tuning, distillation) determine what the model can do, but providers rarely disclose either in detail. Third, the supply chain is layered — your direct vendor may host their own model, fine-tune someone else's, or proxy to a third party, with each layer adding its own data-handling rules.
These differences invalidate parts of a normal vendor questionnaire. A vendor that "does not store customer data" may still see your prompts flow through a hosted GPU provider that retains them for 30 days. A vendor that "has not changed their service" may be silently routing your traffic to a new model release with different safety properties.
The questions that actually matter
- What model versions are you currently using to serve my requests, and how am I notified when that changes?
- Where is the model hosted, and who else has access to the inference logs?
- Are my prompts, outputs, or fine-tuning data used to train or improve any models — yours or anyone else's?
- What is the data retention for inference inputs and outputs, and can I opt out?
- What sub-processors are involved in serving my requests, and what are their respective data-handling commitments?
- How do you handle model output errors (hallucinations, harmful content, leaked training data) — incident response, remediation, customer notification?
- Where is the training data documented, and what intellectual-property and personal-data provenance can you attest to?
- What is your evaluation and red-teaming programme, and can I see the results for the model versions I rely on?
Contract clauses you actually need
Standard data processing agreements were not written with AI in mind. Add specific clauses: (1) right to be notified of model version changes that materially affect output behaviour; (2) prohibition on using customer data for model training without explicit opt-in; (3) sub-processor list with notification on additions; (4) right to audit retention policies; (5) explicit allocation of liability for harmful model outputs, including IP infringement from training-data exposure.
A common pitfall is accepting the vendor's "we may use anonymised aggregate data to improve our services" clause without scrutiny. For language models, prompts and outputs are rarely meaningfully anonymous — they carry context that can re-identify the source. Either negotiate this clause out or limit it tightly.
Ongoing monitoring (not a one-time review)
A vendor due diligence done at procurement time and never revisited is useless against a vendor whose model can change next week. Build a monitoring cadence: review the vendor's model release notes quarterly, re-test your critical use cases against the current model, watch for sub-processor changes, watch for changes to the privacy notice or data-use terms. Treat material model behaviour changes the same way you treat a security incident — incident response process, impact analysis, customer notification if needed.
A short checklist
- Model version and change notification clause in the contract.
- Written confirmation that customer data is not used to train models (or explicit opt-in toggle).
- Sub-processor list, including upstream model providers.
- Inference data retention policy and opt-out mechanism.
- Documented evaluation programme and access to results.
- Quarterly review cadence for model behaviour drift.
- Incident-response process specific to AI failures (hallucination, harmful output, training-data leakage).