AI vendor contracts, what businesses actually need
Standard software contracts are not designed for AI. They miss the risks that matter most: what happens to your data, how the model behaves, what changes when the vendor updates, and who is liable when the AI gets it wrong. This article covers the specific contract provisions businesses need when procuring AI tools and services.
The provisions that actually matter
Data use restriction. The most consequential single clause. Does the vendor use your data to train or improve their models? For consumer-tier AI tools, the default is often yes. Enterprise contracts should include an explicit, contractually binding commitment that your data will not be used for model training. Verify this in the Data Processing Agreement, not in marketing materials.
Data Processing Agreement (DPA). Required under GDPR, UK GDPR, and increasingly under PDPA, DPDP Act, and other privacy frameworks. The DPA should cover: data processing purposes; sub-processor disclosure and approval rights; data location and transfer; retention and deletion; breach notification timelines; audit rights.
Sub-processor transparency. Most AI vendors use sub-processors, foundation model providers (OpenAI, Anthropic, Google), cloud infrastructure (AWS, Azure, GCP), and others. You should know who they are. Contract should include: list of current sub-processors; notification before material changes; approval rights for changes affecting your data; flow-down of obligations to sub-processors.
Model change notification. AI vendors update their models, sometimes with material effects on your use case. Contract should require: advance notification of material model updates; version control where possible; ability to test updates before deployment; rollback rights if updates materially affect your operations.
Performance benchmarks. Define measurable performance expectations. Accuracy, response time, availability, false positive/negative rates where applicable. Generic vendor claims ("99% accurate") rarely reflect real-world performance for your specific use case.
Liability and indemnification. Standard liability caps often don't address AI-specific risks. Consider: IP infringement indemnification (training data litigation creates downstream exposure); liability for AI errors affecting your customers or business; regulatory fine allocation; uncapped liability for data breaches.
Exit provisions. What happens when the relationship ends? Data return and verified deletion. Transition period. Migration support. Continued access during transition. Format of returned data.
Regulatory-specific provisions
EU AI Act compliance. For AI that may fall within high-risk categories: vendor warranty regarding risk classification; technical documentation availability; conformity assessment evidence; cooperation with deployer obligations.
APRA (Australian Prudential Regulation Authority) CPS 230 (Australian financial services). Material service provider contracts must include: defined service descriptions; locations; security obligations; audit rights; sub-outsourcing rules; exit provisions. AI vendors are not in the limited NTSP exempt categories.
DORA (EU financial services). ICT third-party contracts must address: service descriptions; data locations; audit rights; sub-outsourcing rules; exit and termination provisions; incident notification. AI vendors qualifying as ICT providers fall within scope.
Red flags in vendor contracts
Vendor refuses to provide a DPA. Training opt-out is not contractually binding (only in a FAQ or policy page). No sub-processor disclosure. Unlimited right to change the model without notice. Standard liability cap that doesn't reflect AI-specific risk. No exit provisions or data return commitment. "As-is" warranty disclaimer that removes all performance expectations.
Primary sources: IAPP, EU Model AI Contractual Clauses · EU AI Act
