Beyond the SaaS Template: Contractual Controls for AI Procurement

AI procurement has a familiar pattern. A business unit trials a tool, the supplier sends a standard SaaS agreement, and the renewal date arrives before anyone has tested the terms against the way the tool actually works. Generic SaaS contracts assume stable software, predictable outputs and customer data that stays within defined boundaries. AI tools do not fit that model. They learn, change and generate. As at November 2026, UK buyers need a clause audit before the next renewal cycle, not after an incident.

Why the SaaS template falls short

Standard SaaS terms are built around service availability, user access and data hosting. They rarely address model behaviour, output ownership or the supplier’s right to change the underlying engine. An AI tool may be trained on customer inputs, generate content that infringes third-party rights, or produce inconsistent results after a model update. A contract that treats the service as a static hosted application leaves those risks with the buyer.

The answer is not to reject supplier paper outright. It is to identify the clauses that must be added, amended or carved out. The following audit points are a practical starting list for UK procurement, legal and data protection teams.

1. IP ownership of inputs and outputs

• Confirm who owns the customer’s prompts, documents and other inputs.
• Confirm who owns the generated output and whether the customer receives an assignment or only a limited licence.
• Restrict the supplier’s right to use customer inputs to train models, improve services or create derived products without express consent.
• Require an IP infringement indemnity for outputs, with clear exclusions for customer-modified content and unlawful inputs.
• Check whether the supplier’s standard terms permit it to use anonymised or aggregated data indefinitely.

2. Data protection roles and lawful basis

AI procurement often blurs controller and processor roles. The buyer may be a controller, the supplier a processor, but the supplier may also determine how inputs are used for model training. The contract should map the roles clearly and include the UK GDPR Article 28 terms where required.

• Identify whether the supplier acts as processor, controller or joint controller for each processing activity.
• Require a data processing agreement that covers subprocessors, security measures and breach notification.
• Confirm the transfer mechanism for any international transfers, such as the IDTA or the UK Addendum.
• Address whether customer data is used for training, and if so, the lawful basis, retention period and deletion method.
• Require cooperation with data protection impact assessments and automated decision-making reviews under Article 22.
• Check the supplier’s record of training data provenance and any restrictions on sensitive data.

3. Liability caps and carve-outs

A generic cap tied to annual fees may be inadequate for AI risk. Output errors, biased results, data leakage or IP claims can cause losses far beyond the subscription value. The contract should distinguish between ordinary service failures and AI-specific risks.

• Set a separate, higher cap for data protection breaches, confidentiality breaches and IP indemnities.
• Carve out fraud, wilful misconduct and regulatory fines where legally permissible.
• Confirm that direct loss arising from defective outputs is recoverable and not excluded as indirect or consequential loss.
• Avoid broad exclusions for inaccurate output, model error or loss of business opportunity.
• Check whether the supplier’s insurance covers AI-related claims and whether the cover is maintained for the contract term.

4. Model-change rights and service stability

Suppliers often reserve the right to update, retrain or replace models at any time. That flexibility can undermine acceptance testing, regulatory approvals and business continuity. The buyer needs notice and control over material changes.

• Define what counts as a material model change, including accuracy, safety, bias or output-format changes.
• Require advance notice and a right to object before a material change takes effect.
• Provide for version pinning or a transition period where the buyer needs stability.
• Set acceptance criteria and re-testing rights after a model update.
• Require notice of model deprecation and a migration plan.
• Include service levels that reflect AI-specific performance, not only uptime.

5. Exit terms and data extraction

Exit is not simply termination. AI contracts need a practical route out, including the customer’s data, prompts, configurations and any customised outputs.

• Require export of customer data in a machine-readable format.
• Require deletion of customer data and training data derived from it, with written certification.
• Provide transition assistance for a defined period after termination.
• Address ownership and portability of fine-tuned models, embeddings and configurations.
• Consider escrow or source-code access where the service is business-critical.
• Confirm which clauses survive termination, including confidentiality, IP and liability.

6. Regulatory cooperation and audit rights

UK AI regulation remains a patchwork of sector rules, data protection law and emerging guidance. The contract should require the supplier to cooperate with regulatory enquiries and to provide evidence of compliance.

• Include audit and information rights, including access to relevant security certifications.
• Require incident notification within a defined period, not merely ‘without undue delay’.
• Require cooperation with regulators, courts and internal investigations.
• Confirm that the supplier will provide AI governance documentation, such as model cards or impact assessments where available.
• Address transparency obligations and any customer-facing disclosures.

7. Contract mechanics and order of precedence

• Define AI services, outputs and training data precisely in the order form or statement of work.
• Set a clear order of precedence between the master agreement, the data processing agreement and any online terms.
• Reject unilateral rights for the supplier to amend terms or suspend service without notice.
• Align renewal dates with a scheduled clause review, not automatic rollover.
• Record all deviations from supplier standard terms in a schedule.

A practical pre-renewal audit

Before the next renewal, procurement teams should obtain the full contract pack, including the order form, data processing agreement, security schedule and any online terms incorporated by reference. Legal and data protection teams should test the clauses above against the actual use case. Finance should confirm that the liability cap and insurance cover match the risk. The business owner should confirm that exit and model-change terms are workable in practice.

Conclusion

AI tools can deliver real value, but the contract must reflect how they behave. A generic SaaS template is not a neutral starting point; it allocates risk in ways that may not suit AI. For UK buyers, the clause audit is not a legal luxury. It is the difference between a controlled procurement and an open-ended exposure.