AI Procurement: The Questions Your Board Should Ask Before Signing Any AI Contract

The most critical AI contract question is what the vendor does with your data. There is a substantial difference between vendors who use customer data to improve their models and those who do not. Consumer AI products, including the free tiers of ChatGPT and some AI writing tools, may use user inputs to train or fine-tune models. Enterprise AI products typically have explicit contractual protections that prohibit this.

Boards should insist on seeing explicit contractual language confirming that the vendor will not use your organisation's data to train, fine-tune, or improve their AI models, that your data will not be used to generate outputs for other customers, and that upon contract termination, all your data will be deleted from vendor systems within a specified period. For UK organisations, these protections need to be consistent with UK GDPR obligations, which means they also need legal basis confirmation for any data processing the vendor does perform.

AI models are not static software. Vendors update their models regularly, and updates can change model behaviour in ways that affect your business. An AI that your compliance team has validated and approved may behave differently after a model update, which creates re-validation requirements that are time-consuming and expensive.

Contracts should specify the notice period for material model changes, the organisation's right to continue using a previous model version for a transition period, and the vendor's obligations regarding documentation of what has changed. Enterprise AI agreements from Microsoft Azure, Google Cloud, and Anthropic all include provisions in this area, but the specific terms vary and should be reviewed explicitly.

UK and EU data protection law imposes constraints on where personal data can be processed and who can access it. AI vendor contracts need to specify the geographic locations where your data will be processed, including any locations where it may be transmitted during model inference, the vendor's security certifications and compliance with relevant standards (ISO 27001, SOC 2, Cyber Essentials Plus), and access controls that prevent vendor employees from viewing customer data unless specifically authorised.

For regulated organisations, these requirements may be more specific. FCA-regulated firms typically require that AI vendors can demonstrate compliance with FCA operational resilience requirements. NHS organisations have specific data security and protection obligations that AI vendors must meet.

AI system failures can have significant business consequences. A Copilot system outage during a critical board meeting or deal process is a business problem. An AI system that produces systematically incorrect outputs over a period of weeks before the error is identified is a potentially serious liability issue.

Contracts should specify availability SLAs with financial consequences for breach, response time commitments for different categories of incident, the process for reporting and investigating AI errors (including errors that are caused by model behaviour rather than infrastructure failure), and liability provisions that are proportionate to the business impact of failure. The indemnity caps in standard AI vendor contracts are often much lower than the potential business impact of serious AI failures and should be negotiated accordingly.

Organisations that cannot exit their AI vendor relationships without prohibitive cost or data loss are in a weak negotiating position at every contract renewal. AI vendor lock-in is real and growing as workflows, data, and integrations become dependent on specific platforms.

Boards should insist on exit provisions that specify data export formats and timelines, transition assistance obligations from the vendor, and the prohibition of data practices that would make migration prohibitively expensive (such as storing data in proprietary formats that cannot be exported). Where significant AI customisation has been built on a vendor platform, the contract should specify who owns the customisation and what rights the organisation has to take it to an alternative provider.