The Enterprise AI Procurement Checklist: 40 Questions Before You Sign

Most enterprise AI contracts are signed before the hard questions are asked. The vendor demonstration is compelling. The pilot results are positive. The procurement process moves forward with the same framework used for SaaS subscriptions. Three years later, the organization discovers that its most sensitive customer data has been used to train the vendor's general model, that the model version the pilot was built on was deprecated without the contractually required notice period, and that the IP generated through fine-tuning on the organization's proprietary data belongs to the vendor. These outcomes are not hypothetical. They are recurring patterns in enterprise AI contracts signed between 2022 and 2025.

AI procurement requires a fundamentally different approach from software procurement because the risks are fundamentally different. Traditional software has defined functionality, documented APIs, and deterministic behavior. AI systems have probabilistic outputs, undefined performance boundaries, evolving underlying models, and complex data relationships that create legal and regulatory exposure that most procurement frameworks were not designed to address.

This post presents the 40 questions every enterprise should require answers to before signing an AI vendor contract. They are organized into seven categories: data governance, model transparency, performance standards, security and compliance, IP and licensing, exit and portability, and vendor stability. A vendor that cannot or will not answer these questions is communicating something important about what the relationship will look like when it matters.

Category 1: Data Governance (Questions 1–8)

Data governance questions are the highest-risk category in AI procurement. The way an AI vendor handles customer data determines both the organization's regulatory exposure and the competitive sensitivity of the insights the AI system generates from that data.

Q1: Where is our data stored, and what jurisdictions govern that storage? Data residency requirements are non-negotiable in regulated industries and increasingly relevant in any industry with European customer data. The contract must specify the geographic location of data storage, the regulatory regime governing that storage, and the vendor's obligations if that regime changes.

Q2: Can our data be used to train, fine-tune, or improve the vendor's general models? This question must be answered in writing, explicitly and unambiguously. Many AI vendor agreements contain default terms that permit training data use unless the customer affirmatively opts out. Opt-out provisions buried in enterprise agreements are not appropriate for sensitive data. The requirement should be explicit prohibition, not opt-out.

Q3: Who has access to our data within the vendor organization? The answer should specify the categories of personnel who can access customer data, the purpose limitations on that access, and the technical and contractual controls governing it.

Q4: What happens to our data at contract termination? The contract should specify the timeline and format for data return, the confirmation procedure for data deletion, and the certification the vendor will provide confirming that deletion has been completed including all backup and training copies.

Q5: How is our data isolated from other customers' data in multi-tenant environments? The answer should describe the technical isolation architecture and the vendor's process for detecting and remediating cross-tenant data exposure incidents.

Q6: What data processing agreements govern the relationship under GDPR, CCPA, and other applicable privacy regulations? These agreements must be in place before any personal data is processed, not as an afterthought.

Q7: What is the vendor's data breach notification timeline and process? The contract should specify the notification period, the information to be provided in the initial notification, and the remediation timeline.

Q8: Does the vendor have the right to share anonymized or aggregated insights derived from our data with other parties? Anonymization claims by vendors should be reviewed carefully. True anonymization of behavioral data is technically difficult, and many "anonymized" data products can be re-identified with sufficient auxiliary data.

"A vendor that resists answering data governance questions before contract signing will not become more transparent after the contract is signed. The negotiation posture reveals the operational culture."

Category 2: Model Transparency (Questions 9–15)

Q9: What model or models power the system, and are they proprietary or third-party? Many enterprise AI vendors build on top of third-party foundation model APIs. This creates a dependency chain: the vendor's capabilities are constrained by the third-party provider's decisions about model updates, pricing, and availability.

Q10: What is the deprecation policy for model versions? This question is critical. A model version the organization's workflows depend on may be deprecated by the vendor without advance notice unless the contract specifies a minimum notice period. The minimum acceptable notice period for a production system is typically 90 days.

Q11: How are model updates tested before deployment to production customers? The vendor should describe the evaluation methodology, the test sets used, and the criteria for determining that a model update is safe to deploy. The organization should understand whether it will be notified of model updates and whether it has the ability to delay updates while validating the new model version against its own use cases.

Q12: What is the vendor's process for evaluating model fairness and bias across different demographic groups? This question is particularly important for AI systems that influence decisions affecting individuals. The vendor should be able to provide documented fairness evaluation results, not just principles.

Q13: Can the vendor provide a model card or equivalent documentation describing training data, known limitations, and evaluation results?

Q14: What audit log capability exists to reconstruct what input produced what output at a specific point in time? Audit capability is both a governance requirement and a practical operational need. Without it, the organization cannot investigate anomalous outputs, respond to regulatory inquiries, or learn from system failures.

Q15: Does the system use our data at inference time in ways that could expose it to other customers or to the vendor's personnel? The architecture of retrieval-augmented generation systems in particular creates potential for cross-customer data exposure that must be explicitly addressed in the contract.

Category 3: Performance Standards (Questions 16–22)

Q16: How is uptime defined for an AI system, and what constitutes an outage? Traditional software SLAs define uptime as the percentage of time the system is accessible. AI system SLAs must additionally address the scenario where the system is accessible but producing significantly degraded outputs. A system that is technically available but hallucinating at high rates is functionally an outage for the business processes that depend on it.

Q17: What are the response time SLAs at the 50th, 95th, and 99th percentiles? Average response times are not adequate for production planning. Tail latency at the 99th percentile is the relevant metric for user experience and downstream system reliability.

Q18: How is model accuracy defined, measured, and guaranteed? The vendor should specify the evaluation methodology, the data set on which the accuracy figure was measured, and the mechanism for contractual remedies if accuracy falls below the specified threshold in production.

Q19: What is the escalation process when AI outputs cause harm to the organization or its customers? Vendors should have a defined escalation path that goes beyond the standard support ticket process. When an AI system causes a material business or reputational incident, you need a named contact, a response commitment in hours not days, and a documented root cause process. If this process is undefined, you will be navigating it for the first time during a crisis.

Q20: What are the remedies for SLA violations? Service credits that represent a small fraction of contract value are not meaningful remedies for production AI system failures. The contract should specify remedies that are proportionate to the business impact of the failure.

Q21: How does the vendor handle degraded performance during model updates or infrastructure changes? AI system performance can degrade without triggering a formal outage. Model updates that shift output distributions, infrastructure migrations that introduce latency, or backend changes that affect context handling can all reduce quality without crossing an SLA threshold. The contract should require advance notice of model updates and define acceptable performance variance during transition periods.

Q22: What is the vendor's incident communication protocol, including timeline and format? "We will notify you of incidents" is not a protocol. A real protocol specifies: how quickly initial notification occurs after incident detection (measured in minutes, not days), what information the initial notification contains, how frequently updates are provided during an active incident, and what format the post-incident report takes. Vendors who cannot describe this in writing do not have a functioning incident communication process.

Category 4: Security and Compliance (Questions 23–28)

Q23: What security certifications does the vendor hold (SOC 2 Type II, ISO 27001, FedRAMP, HITRUST)? The relevant certification depends on the industry and regulatory context. The certification should be current, not expired or in renewal.

Q24: Has the vendor completed a penetration test on the AI system infrastructure within the last 12 months, and will they share the results summary? A penetration test completed more than 12 months ago is effectively out of date for AI infrastructure, which changes rapidly. Vendors who cannot share at minimum an executive summary of test findings are either hiding material weaknesses or have not conducted a meaningful test. For high-sensitivity deployments, require sharing of the full report under NDA, not just an attestation that testing was done.

Q25: What are the vendor's subprocessor relationships, and how are subprocessors governed? AI systems frequently rely on a chain of subprocessors: cloud infrastructure providers, data pipeline vendors, model providers. Each link in that chain is a potential exposure point.

Q26: Does the vendor's AI system comply with the EU AI Act requirements applicable to high-risk AI systems? Organizations deploying AI systems in the European Union must understand whether the system falls under high-risk categories and what compliance obligations that creates.

Q27: What audit rights does the organization have regarding the vendor's security practices and data handling? The right to audit is meaningless without specifics: what can be audited, by whom, with how much notice, and at whose cost. Many enterprise AI contracts include nominal audit rights that are practically unexercisable because they require 90 days notice, prohibit third-party auditors, and place the full cost on the customer. Negotiate for annual audit rights with a qualified third party, reasonable notice periods, and cost-sharing for standard audit scopes.

Q28: What is the vendor's process for responding to government or law enforcement requests for customer data? Vendors operating in multiple jurisdictions may receive legal demands to produce customer data from governments or law enforcement agencies. Your contract should require the vendor to notify you promptly when such a request is received, to the extent legally permitted, and to exhaust legal remedies to limit disclosure before complying. Vendors who cannot commit to a notification process are accepting that they may hand over your data with no warning.

Category 5: IP and Licensing (Questions 29–33)

Q29: Who owns the IP in models fine-tuned on our proprietary data? This is one of the most commercially significant questions in AI procurement. The default in many vendor agreements is that the vendor owns the fine-tuned model, even though the fine-tuning data came entirely from the customer. This is a direct transfer of competitive value to the vendor.

Q30: Does our use of the AI system create any copyright or IP exposure for outputs used in our business? This question is relevant for AI systems that generate content used in commercial contexts. The legal status of AI-generated content and the indemnification obligations of vendors for IP claims related to training data are active areas of litigation.

Q31: What indemnification does the vendor provide for IP claims arising from training data used to build the model?

Q32: Are there restrictions on how AI-generated outputs can be used, attributed, or commercialized?

Q33: If we develop workflows, integrations, or configurations that create value on top of the vendor platform, who owns that value?

Category 6: Exit and Portability (Questions 34–37)

Q34: What does a contract exit actually look like, step by step? Exit provisions in AI contracts deserve the same attention as entry terms. The practical question is not whether the organization can cancel the contract, but whether it can actually extract its data, models, and configurations in a format that enables migration to an alternative.

Q35: In what format will our data be returned at exit, and is that format importable into alternative systems?

Q36: What is the timeline for data return at exit, and what penalties apply for delays?

Q37: Are there portability provisions for custom models, fine-tuned weights, or proprietary configurations we have created on the platform?

Category 7: Vendor Stability (Questions 38–40)

Q38: What is the vendor's financial position, and what happens to the contractual obligations in the event of acquisition, insolvency, or significant strategic change? The AI vendor market is consolidating rapidly. An organization that has built production workflows on a vendor that is acquired by a competitor faces a materially different situation than the one anticipated at contract signing.

Q39: What contractual protections exist if the vendor is acquired and the acquirer wishes to change the pricing, terms, or availability of the service?

Q40: What is the vendor's roadmap for the specific capabilities the organization depends on, and what happens to existing contracts if those capabilities are deprecated or significantly changed?

The Post-Signature Governance Framework

Procurement questions answered before signing create the contractual foundation for a healthy vendor relationship. But the relationship itself requires ongoing governance to remain functional. Most enterprises invest in pre-signature diligence and then operate the relationship informally until a problem forces a formal conversation. By then, the problem is usually larger than it needed to be.

An effective AI vendor governance framework includes quarterly business reviews with standardized agendas, defined escalation paths for technical and commercial issues, regular audits of data handling practices, and annual contract reviews that address performance against original commitments. The governance framework should be documented in the contract itself, not left to informal agreement.

Questions About Incident Response

Forty-one: What is the vendor's incident response commitment when their AI system produces a materially incorrect output that causes business harm? How quickly will they acknowledge, investigate, and respond? What remedies are available? Forty-two: Does the contract include a root cause analysis requirement for significant incidents, or only an acknowledgment? Forty-three: What is the vendor's communication protocol for AI safety incidents affecting multiple customers? Are you notified proactively or only upon inquiry?

Forty-four: How does the vendor define a material incident versus a normal operational variance? Who makes that determination, and is it subject to dispute? Forty-five: What limitations of liability apply to AI-caused business losses, and are those limitations proportionate to the contract value and potential business impact? These questions are uncomfortable to raise with vendors during negotiations, but they are the questions that matter most when something goes wrong, which it eventually will.

Contract Review Cadence

Even a well-negotiated AI vendor contract requires active management. Markets shift, models are deprecated, vendor priorities change, and your own strategic requirements evolve. Build a formal contract review cadence into the governance framework: quarterly performance reviews against SLA commitments, annual strategic reviews that assess whether the vendor relationship remains aligned with your direction, and a biennial formal renegotiation cycle that reassesses pricing, terms, and scope in light of market changes.

The vendors that perform best over multi-year relationships are those whose contracts include mutual obligations and regular touchpoints, not just service levels enforced by penalties. Build the relationship you want, not just the protections you need.

The enterprises that build the strongest AI vendor relationships are those that approach vendor management as a strategic discipline rather than a contractual obligation. They invest in regular engagement with vendor product and engineering teams, participate in beta programs for new capabilities that align with their strategic direction, and provide structured feedback that helps vendors prioritize the capabilities that matter most for enterprise use cases. This engagement pays dividends in better service, earlier access to new capabilities, and stronger contractual leverage at renewal time.