The Algorithm in the Annex: A Practical Guide to AI Clauses in UK Commercial Contracts

Artificial intelligence is rarely the headline in a commercial contract. It tends to appear in the annexes: a reference to 'machine learning' in a statement of work, a licence to use 'models' in the definitions, or a promise of 'continuous improvement' in the service description. By the time the deal is signed, those few words can decide who may use data, who owns the output and who carries the risk when the system gets something wrong.

For UK businesses in 2026, the question is not whether AI terms belong in contracts. They usually do. The question is whether the terms are visible, proportionate and understood by the people signing. A supplier may describe its product as a standard software service while using customer data to refine a model. A customer may assume it owns every output, while the contract leaves the supplier with rights in 'derived data'. Neither outcome is necessarily unfair, but both should be deliberate.

Look at the schedule, not the sales deck

Start with the documents that carry the legal detail: the data processing schedule, the statement of work, the definitions and any security annex. Search for words such as 'model', 'training', 'machine learning', 'automated', 'output', 'prompt', 'usage data' and 'derived data'. Ask three questions. What data goes into the system? What does the supplier do with it? What comes out, and who may use it?

If the supplier will process personal data, the UK GDPR requires a clear allocation of controller and processor roles. A supplier that uses customer data for its own purposes - including training its own models - may be acting as a controller for that use, not simply as a processor. The contract should say so explicitly and should not leave the answer to inference.

Data use: permission needs boundaries

Broad wording is the main risk. A clause that allows the supplier to use 'anonymised' or 'aggregated' data 'to improve the services' can be read widely. It may permit model training, product development or benchmarking. That may be acceptable in some deals, but it should be a negotiated choice, not a side effect.

Consider a narrower formulation. The supplier may use technical logs and aggregated data that cannot identify the customer or any individual to maintain and improve the service. It may not use confidential information, personal data or customer content to train models available to other customers unless a separate written agreement says otherwise. If training is permitted, specify the data, the purpose, the retention period and whether the customer can opt out. Where personal data is involved, check the lawful basis and whether a data protection impact assessment is needed.

Intellectual property: inputs, outputs and models

AI contracts often blur three different assets. The first is the customer's input data. The second is the output - text, code, images, predictions or analysis. The third is the supplier's model, software and know-how. A good contract separates them.

The customer should normally retain ownership of its input data. The supplier should retain ownership of its pre-existing model and platform, subject to a licence for the customer to use the service. The output is less straightforward. The contract should state who owns it, or at least who may use it and for what purpose. If the supplier claims rights in 'derived data' or 'model improvements', check whether that includes anything generated from the customer's content.

Copyright in AI-assisted outputs is not always straightforward, and the contract should not pretend otherwise. If the customer needs to rely on the output commercially, it should seek an indemnity for third-party intellectual property claims and a warranty that the service does not knowingly reproduce protected material. Indemnities are not a substitute for due diligence, but they put the risk where the parties have agreed it should sit.

Confidentiality: what the model may remember

Confidentiality clauses written for ordinary software may not fit AI tools. Information entered as a prompt may be retained, reviewed or used to improve a model. The contract should say whether the supplier can retain prompts or outputs, for how long, and whether human reviewers may access them.

If the supplier uses third-party model providers, the obligations should flow down the chain. The customer should know which subprocessors are involved and whether data may leave the UK or the European Economic Area. Security annexes should cover access controls, encryption and incident notification. A general promise to keep information confidential is not enough if the architecture allows the model to learn from it.

Liability: the cap may not fit the risk

AI errors can be expensive: a wrong output, a biased decision, a data leak or a failure to meet a service level. The supplier's standard liability cap may be expressed as a multiple of fees, which may be small compared with the harm. The customer should check whether the cap applies to data protection breaches, confidentiality breaches and intellectual property infringement. Many suppliers exclude those risks or set sub-caps.

The right answer depends on the deal. A low-risk productivity tool may justify a standard cap. A system used in a regulated process may need higher limits, specific warranties and insurance. The contract should also deal with reliance. If the output is decision-support rather than advice, say so. If the customer must review outputs before use, put that in the operating model as well as the contract. For business-to-business terms, the reasonableness of exclusions and caps under the Unfair Contract Terms Act 1977 may still matter.

Change control and the meaning of 'continuous improvement'

AI services change. Models are updated, features are added and data uses evolve. A clause allowing 'continuous improvement' should not become a general permission to change the bargain. Require notice of material changes that affect data use, security, output quality or fees. Give the customer a right to object or terminate if a change is unacceptable. Keep a record of model versions where the output matters.

A proportionate negotiation checklist

Before signing, confirm that the contract answers these questions. Is customer data used for training, and on what terms? Who owns inputs, outputs and model improvements? What confidentiality obligations apply to prompts and outputs? Which liability caps and carve-outs apply to AI-related failures? Can the supplier change the model or data use without consent? What happens on exit?

Not every deal needs a bespoke AI schedule. But every deal needs the AI terms to be visible. If the supplier's template is silent or vague, a short side letter or schedule can fill the gap. The aim is not to overcomplicate the contract. It is to make sure the commercial bargain matches the technology being bought.