The AI vendor market is producing extraordinary sales talent. Demos are polished. Benchmark comparisons are strategically curated. Customer references are hand-selected. And enterprise procurement processes that were not designed for AI products are being overwhelmed by claims that are difficult to verify without specific domain knowledge.
The result is that enterprises are signing multi-year, multi-million dollar AI vendor contracts based on information that is incomplete at best and deliberately misleading at worst. The vendor lock-in, data dependency risks, and support failures that follow are predictable. We see them repeatedly. And in almost every case, a proper due diligence process would have either prevented the decision or negotiated materially better contract terms.
This framework covers the six due diligence categories that enterprise buyers consistently underweight. It is not a procurement checklist. It is a practitioner's guide to asking the questions that reveal vendor risk before you are contractually obligated to live with the consequences.
Category 1: Data Privacy and Ownership
Data rights are the most consequential and most frequently misunderstood dimension of AI vendor contracts. The questions below are not legal formalism. They are the specific issues that have caused the most expensive post-signature surprises across enterprise AI deployments we have advised on.
- Does your contract explicitly state that you own all data submitted to the system and all outputs generated? Or does the vendor claim any license to use that data?
- Is the vendor's model trained or fine-tuned using customer data by default? What is the opt-out mechanism and what data has already been used before opt-out?
- Where is data processed and stored? Does data ever leave a specific geographic region? Are there documented data residency commitments with SLA consequences?
- What happens to your data if you terminate the contract? What is the deletion timeline and how is deletion verified?
- Does the vendor use subprocessors who have access to your data? Who are they and what are their contractual obligations?
- Are there any circumstances under which your data could be exposed to other customers or used to improve shared model capabilities?
- What is the vendor's breach notification obligation and timeline? How does this interact with your own regulatory reporting requirements?
Category 2: Model Performance and Reliability
Benchmark performance and production performance are entirely different things. The due diligence questions in this category are designed to reveal the gap between what the vendor's marketing materials claim and what you should actually expect in your specific deployment context.
- What are the published benchmarks based on, and are those benchmarks representative of your specific use case domain and data distribution?
- What is the vendor's stated accuracy or quality metric for your specific use case? Is this metric contractually committed or aspirational?
- How does model performance degrade on out-of-distribution inputs? What is the failure mode when inputs are outside the training distribution?
- What is the vendor's API uptime SLA? What are the contractual remedies when SLA is missed? Are there exclusions that effectively void the SLA commitment?
- What are the rate limiting policies at different usage levels? How does the vendor manage peak demand and what are your protections during high-traffic periods?
- How does the vendor handle model updates and version changes? Can you pin to a specific model version? What is the notice period before breaking changes?
- What is the latency SLA at your expected traffic volume? Have you tested performance under realistic load conditions, not just demo conditions?
Category 3: Security and Compliance Architecture
Security certifications are not the same as security. A vendor with SOC 2 Type II certification has demonstrated they have security controls in place. It does not mean those controls are sufficient for your specific regulatory environment or data sensitivity requirements.
- What certifications does the vendor hold and for which specific services? Note that certifications often cover a subset of a vendor's infrastructure.
- How does the vendor handle prompt injection attacks? What testing has been conducted on adversarial inputs and what controls are in place?
- What is the vendor's vulnerability disclosure policy and historical response time to critical vulnerabilities?
- Is there a dedicated enterprise security review process? Will the vendor provide architecture documentation sufficient for your internal security team to assess?
- Does the vendor's infrastructure meet your specific regulatory requirements: HIPAA, FedRAMP, PCI DSS, GDPR, or sector-specific regulations?
- What are the vendor's access controls for their own employees? Who can access customer data and under what circumstances?
Independent AI Vendor Evaluation
Our vendor selection practice conducts structured due diligence across all six categories on your behalf. We have no vendor relationships and no referral fees. Ever.
Request Vendor Evaluation Download Vendor GuideCategory 4: Commercial Terms and Lock-in Risk
The commercial terms that matter most are rarely the ones in the initial proposal. Pricing models for AI products are structurally designed to obscure the real cost of scale, and the terms that govern your exit are as important as the terms that govern your entry.
- What is the fully loaded cost at 3x your current usage estimate? Most AI deployments scale significantly faster than anticipated and initial pricing rarely reflects that reality.
- Are there minimum spend commitments? What are the consequences of not meeting them and how was the minimum calculated relative to your actual usage projections?
- What are the price increase provisions at renewal? Is there a cap? What notice is required? Can the vendor change pricing during the contract term?
- What proprietary elements of your deployment are stored in vendor-specific formats that would need to be rebuilt on migration? Fine-tuned models, embedded data, custom connectors?
- What is the data export process if you terminate? Is it self-service or does it require vendor assistance? Is there a cost? What format is the export in?
- What is the vendor's financial stability? For AI startups specifically: what is the runway, who are the investors, and what happens to your deployment if the vendor is acquired or shuts down?
Category 5: Support and Operational Commitments
Support commitments are where the gap between what is in the contract and what happens in practice is largest. The specific questions below reflect the most common support failures we have observed in enterprise AI deployments.
- What is the named support contact structure at enterprise tier? Is there a dedicated technical account manager with AI domain expertise, or a shared support queue?
- What is the contractual response time for critical production incidents? How is "critical" defined and who has authority to escalate?
- What is the vendor's documented process for handling model quality degradation? Who detects it, who is notified, and what remediation timeline is committed?
- What onboarding support is included? Is there a structured technical onboarding program or is documentation the primary resource?
- How does the vendor handle customer feedback on model quality? Is there a structured mechanism for reporting systematic errors and a committed response process?
Category 6: AI Ethics, Bias, and Responsible Use
Ethics and bias questions are increasingly moving from "nice to have" to legal and regulatory requirements in many jurisdictions. The EU AI Act, sector-specific guidance from financial regulators, and US executive orders on AI all create obligations that flow through to vendor contracts.
- What bias testing has been conducted on the model? Across which demographic groups and in which use case contexts? Are the results available for review?
- How does the vendor support explainability requirements? Can the model provide explanations for individual decisions in a format that satisfies your regulatory obligations?
- What are the vendor's published acceptable use policies and how are they enforced? What are the consequences if a customer violates these policies?
- Does the vendor provide audit logs sufficient to satisfy your AI governance and regulatory reporting requirements?
- How is the vendor preparing for the EU AI Act high-risk AI system requirements if your use case falls in a regulated category?
Red Flags That Should Stop or Restructure a Deal
Beyond the structured due diligence categories, certain vendor behaviors during the sales process are reliable predictors of post-signature problems. These are the red flags that should either stop a deal or require material contract restructuring before signing.
Resistance to Data Ownership Language
Any vendor who resists explicit contractual language stating that you own your data and outputs has a reason for that resistance. That reason is not in your interest.
No Model Version Control
Vendors who cannot commit to model version stability or offer no mechanism to pin to a specific version will introduce production instability every time they update their model.
References Only From Early Adopters
A vendor who can only provide references from customers who signed in the first year of the product's existence has not demonstrated sustained enterprise delivery. Ask for references from mature, complex deployments.
Vague Data Residency Commitments
Statements like "data is primarily processed in the US" are not commitments. If data residency matters for your regulatory environment, you need specific contractual commitments, not marketing language.
No Published Incident History
Vendors with no public incident history either have not had any incidents or are not being transparent about the ones they have had. Ask directly for their incident history and evaluate the response.
Sales Cycle Pressure Without Substance
Artificial urgency around pricing or deadlines is a negotiating tactic, not a business reality. Vendors who create pressure to sign before due diligence is complete are managing your discovery process.
Weighted Scoring for Comparative Evaluation
When evaluating multiple AI vendors simultaneously, a weighted scoring model prevents the common failure mode of selecting the vendor with the best demo rather than the best fit for production requirements. The weights below reflect the relative importance of each category based on post-deployment failure analysis across enterprise AI programs.
For regulated industries, the ethics weight should be increased to 15 to 20 percent and the scoring criteria should explicitly include regulatory compliance requirements. For a detailed guide on applying these criteria to specific vendor categories including LLM providers, AI application platforms, and MLOps infrastructure, see our AI vendor selection service and our full enterprise AI vendor selection framework.
AI Vendor Selection Due Diligence Toolkit
Our complete vendor evaluation toolkit includes the full question set, scoring templates, contract redline guidance, and reference check scripts for each vendor category.
Download the AI Vendor Selection Guide →The most important principle in AI vendor due diligence is independence. Procurement advisors who are compensated through vendor referral fees have an inherent conflict of interest that no disclosure fully resolves. The questions in this framework are designed to be conducted by your own team or an advisor with a strict no-vendor-relationship policy. For a detailed discussion of how to structure independent vendor evaluation, see our guide on independent AI vendor evaluation.
Independent AI Vendor Evaluation
Our vendor selection practice conducts structured due diligence with no vendor relationships and no referral fees. We have evaluated 150+ AI vendors across every category.
Request Vendor EvaluationAI Strategy Before Vendor Selection
Vendor selection without a clear AI strategy leads to the wrong vendor for the right problem. We help you clarify requirements before you talk to vendors.
Start with AI Strategy