AI Vendor Due Diligence Questionnaire: 52 Questions Before You Sign
Many AI vendor evaluations get derailed in one of two ways: teams move too fast and skip the hard questions, or they get lost in a capabilities demo and forget to ask what happens when something goes wrong. The vendor's sales pitch tells you what the product does on its best day. Due diligence tells you what happens on a bad one: a data breach, a model failure, a price increase after you're locked in, or a compliance audit you didn't see coming. This questionnaire covers 52 questions organized across eight evaluation areas. Not every question applies to every vendor; use it as a checklist and adapt it to the specific AI product you're evaluating. The goal is a complete picture before you sign anything, not a confrontational interrogation.
Section 1: Company and Product Stability
1. How long has the company been operating, and how long has this specific AI product been in production?
2. Who are your largest customers in our industry, and can you provide two or three references we can contact?
3. What is your current funding stage and runway? (Relevant for startups, where a vendor going out of business mid-contract is a real risk.)
4. What is the product roadmap for the next 12 months, and how do you communicate changes to customers?
5. Have you had any significant data breaches, security incidents, or major service outages in the past 24 months? If so, describe them and what changed.
6. What is your customer churn rate, and what are the most common reasons customers leave?
What good answers look like: established production history, referenceable customers in your industry, transparent financials, a clear roadmap process, honest answers about past incidents with verifiable remediation. A vendor that deflects or refuses to answer questions 5 and 6 is telling you something.
Section 2: Data Handling and Privacy
7. What data do you collect from our use of the product, and where is it stored?
8. Is our data used to train your models? If yes, what is the opt-out process and what data is actually retained?
9. Where are your data centers located, and do you offer data residency options (e.g., US-only, EU-only)?
10. Who within your organization has access to our data, and under what circumstances?
11. Do you share our data with third-party subprocessors? List them.
12. What is your data retention policy, and what happens to our data when we terminate the contract?
13. Do you have a data processing agreement (DPA) we can review?
Why this matters: AI systems often process highly sensitive business data: customer interactions, financial records, employee communications, proprietary processes. Understanding where that data goes, who sees it, and what it's used for is not optional. A vendor that cannot clearly answer questions 8–11 may be using your data to improve models that also serve your competitors.
Section 3: Security and Compliance
14. What security certifications or audit reports do you hold? (Depending on your industry: SOC 2 Type II, ISO 27001, HIPAA BAA availability, FedRAMP, PCI DSS.)
15. How do you handle vulnerability disclosure and patch management?
16. What is your penetration testing cadence, and will you share the most recent report (under NDA)?
17. How is data encrypted in transit and at rest? What encryption standards do you use?
18. What are your access control and identity management practices? Do you support SSO and MFA?
19. How do you handle incidents, and what is your notification timeline to affected customers?
20. Are you compliant with GDPR, CCPA, and the AI-specific regulations that apply to our industry?
21. If we operate in a regulated industry (healthcare, finance, legal), do you have experience with our specific compliance framework?
Regulatory context: the EU AI Act sets documentation, transparency, and human oversight obligations for high-risk AI systems, with requirements phasing in over several years. In the US, the FTC has taken enforcement action against companies making unsubstantiated AI claims. Ask vendors to show you their compliance documentation, not describe it.
Section 4: Model Transparency and Reliability
22. What AI model(s) does your product use? Are they proprietary, fine-tuned from a foundation model, or off-the-shelf API calls?
23. If you use a foundation model provider (e.g., Anthropic, OpenAI, Google), what version are you on, and how do you handle model version updates?
24. How do you handle model errors, hallucinations, or outputs that are confidently wrong?
25. What is your published accuracy rate for our use case, and how was it measured? Can you reproduce that result with our data in a proof-of-concept?
26. How does the model handle edge cases, low-confidence situations, and inputs outside its training distribution?
27. What is your process for detecting model drift (performance that degrades after deployment)?
28. Do you offer explainability features? Can users understand why the model produced a specific output?
The foundational question: many enterprise AI failures are not caused by malicious attacks. They're caused by models producing confident wrong answers that nobody catches until something breaks downstream. Questions 24–28 probe whether the vendor has thought seriously about failure modes or is still in sell-mode.
Section 5: Integration and Technical Requirements
29. What APIs, webhooks, and integration methods do you support?
30. What are the system requirements? What does our team need to install, configure, or maintain on our side?
31. How do you handle API rate limits, and what happens when we exceed them?
32. Do you have native integrations with our existing tools? (List the specific tools you use: CRM, ERP, HRIS, communication platforms.)
33. What is the typical implementation timeline for a customer of our size and complexity?
34. Do you provide an implementation team, or is it self-service? What does onboarding support look like?
35. How do we migrate our data and configurations if we need to move to a different vendor?
Integration problems are a common cause of AI project delays. The vendor's demo environment almost always works; what matters is how their system connects to your actual tech stack under real conditions. Question 35 is particularly important, because many vendors make it easy to get in and very hard to get out.
Section 6: Performance, Uptime, and SLAs
36. What is your published uptime SLA, and what is your actual historical uptime over the last 12 months?
37. What is your defined response time for support tickets by severity tier?
38. What remedies are available if you miss your SLA? Are credits automatic or do we have to file a claim?
39. What is your planned maintenance schedule, and how much advance notice do you provide?
40. What are your stated latency benchmarks for our use case, and do they hold under peak load?
41. Do you have a published status page we can monitor?
42. What is your disaster recovery and business continuity plan?
The gap between contractual SLA and operational reality can be significant. Ask for the last 12 months of actual uptime data from their status page, not their aspirational SLA number. A 99.9% SLA sounds good, but it still allows roughly 8.8 hours of downtime per year. For a workflow-critical system, that may not be acceptable.
Section 7: Pricing and Contract Terms
43. What is the pricing model: per seat, per API call, per output token, per transaction, or flat fee?
44. How has your pricing changed over the past 24 months, and what triggers a price change?
45. Are there volume tiers, and how are they calculated: annually committed or actual monthly usage?
46. What happens if we exceed our contracted usage? Is the overage charged automatically, or does the service throttle?
47. What are the contract term options? Is there a minimum commitment period?
48. What does termination look like: notice period, data export process, and what data is deleted and when?
49. What IP rights do we retain over custom models, fine-tuning data, or outputs the system generates?
Pricing transparency is a leading indicator of vendor trust. A vendor that cannot clearly explain their pricing model in writing, or whose usage-based pricing is hard to predict, is creating a cost control problem for your finance team. Question 49 is increasingly important as businesses invest in fine-tuning and customization: make sure the IP you create stays with you.
Section 8: Vendor Lock-In and Exit Planning
50. In what format can we export our data, models, and configurations?
51. If you shut down or are acquired, what are our rights and the transition process?
52. What does a migration to a competing platform look like from a technical standpoint, and have you helped customers do it?
Lock-in is an AI procurement risk that teams often ignore until they're already locked in. The questions above should inform a specific section in your contract covering data portability, export formats, and transition assistance obligations. A vendor that refuses to specify export formats in the contract is building walls that serve them and not you.
Recommended next step: after completing this questionnaire with your shortlisted vendors, score each one by section (1–5 per question) and compare. The vendor with the highest capabilities score is not always the right choice if their data handling or exit terms score poorly, especially for systems that will process customer or employee data.
Frequently Asked Questions
Frequently Asked Questions
For a mid-market business evaluating a vendor for a core workflow, budget 3–4 weeks for due diligence after the initial demo: 1 week to send and receive answers to this questionnaire, 1 week to review documentation (SOC 2 report, DPA, sample contract), and 1–2 weeks for reference calls and a proof-of-concept with your own data. Rushing this process is how businesses end up locked into vendors that do not meet their actual requirements.
For any AI system that will process customer data, employee records, or business-critical workflows, yes. The IP clauses, data processing terms, and exit provisions in AI contracts are often less standardized than in traditional SaaS agreements. If a contract is worth, say, $50,000 a year, a few hours of attorney review is a small cost by comparison. Pay particular attention to: data ownership provisions, liability caps (especially for AI errors), and the conditions under which the vendor can change pricing or discontinue the product.
At minimum, look for a SOC 2 Type II report (not Type I: Type II tests how controls operated over a period of time, while Type I only looks at a single point in time). Healthcare organizations should require a signed HIPAA business associate agreement (BAA) if the vendor will handle protected health information. Financial services companies should ask about PCI DSS (if payment card data is involved) and SOC 1 Type II (for controls that affect financial reporting). Companies with EU operations or customers need to confirm GDPR compliance and review the DPA. The certifications are table stakes; what matters is reviewing the actual audit report, not just the certificate.
Vague or deflecting answers about data usage and model training. If a vendor cannot clearly state whether your data is used to train their models (or worse, it is, and opting out requires contacting support rather than a self-serve toggle), that vendor may have a business model that depends on your data, not just your fees. The second-biggest red flag is a contract with no specific exit and data portability provisions. Both situations are negotiable before signing; neither is after.