Buying an AI tool: the contract questions that actually matter

The demo answers what the tool does. The contract answers what happens to your data, who owns the output, and who carries the cost when the model is confidently wrong.

The demo is not the deal

An AI vendor demonstrates the tool. It reads your documents, drafts your replies, sorts your tickets, scores your leads. The demo answers the only question the room is asking, which is whether it works.

The contract answers the questions nobody asked in the room. Whether the data you feed it trains a model other customers benefit from. Whether you own what comes out. Who carries the cost when the output is confidently wrong and somebody acts on it. What you get back, and in what format, on the day you leave.

Those questions are settled in a document that arrives as a standard form and is usually signed without amendment, because the tool costs less per month than the meeting to review it. The price is not the measure of the risk. A cheap tool sitting on your customer data, your pricing, or your product roadmap carries the same exposure as an expensive one.

Does your data train the model?

This is the first question, and the answer has to be in the contract rather than in a blog post or a sales call.

Vendors sit in three broad positions. Some do not train on customer data at all, and will say so in the agreement. Some train by default and offer an opt-out that must be actively exercised, sometimes on a per-workspace basis. Some train on customer data as a condition of the service, and price accordingly.

All three can be acceptable. What is not acceptable is not knowing. If the tool will see anything a customer told you in confidence, anything covered by a confidentiality obligation in another contract, or anything that identifies a person, the position on training has to be explicit and it has to be contractual.

Watch for the gap between "we do not train our foundation models on your data" and "we do not use your data to improve the service". The second is much broader than the first, and it is the second you want.

Ask the same question of the sub-processors. A vendor sitting on top of a third-party model has passed your data along, and the terms that matter may be the ones further down the chain. The list of sub-processors should be in or referenced by the contract, with notice of changes.

Who owns the output?

The vendor's terms will usually assign output to the customer, or say the customer may use it freely. Read whether that assignment is unconditional, or whether it is a licence dressed as ownership — a right to use output "in connection with the services", which ends when the subscription does.

That distinction matters most where the output becomes part of your product or your asset base: generated code, generated designs, generated marketing copy that carries your brand. If it is going into something you will one day sell or license, the ownership position needs to survive termination.

The harder question sits underneath: whether the output is capable of being owned at all, and whether it infringes something. A vendor confident in its training data will often offer an indemnity covering third-party intellectual property claims arising from output. The scope of that indemnity, its cap, and its conditions — usually including that you used the tool as instructed and did not disable its filters — are worth reading closely. An indemnity capped at twelve months' fees on a £400-a-month tool is a gesture.

Who is liable when it is wrong?

AI vendor terms disclaim accuracy heavily, and it is not unreasonable that they do. The output is probabilistic. The vendor cannot promise it is right.

That means the risk lands with you, and the contract should say what you are expected to do about it. If the tool is making or materially influencing decisions about people — hiring, credit, pricing, service refusal — the design of human oversight is not a compliance nicety. It is the thing that determines whether a decision is defensible.

Two practical positions to settle in the paper. First, whether the vendor may unilaterally change the underlying model. Most reserve the right to, and a model change can alter behaviour without any change to the interface. Notice of material changes, and a right to terminate if the service materially degrades, are reasonable asks and often conceded.

Second, what the service level actually covers. Uptime commitments are common; output quality commitments are rare. Where a tool is doing something operationally critical, the absence of any quality commitment is a decision the business is making, and it should make it knowingly.

Data protection, said plainly

If personal data goes into the tool, the vendor is processing it on your behalf and the arrangement needs the written terms that the Data Protection Act 2018 and the UK GDPR require of a controller and its processor. That is a defined list — purpose, duration, security, sub-processing, assistance, deletion or return at the end — and a good vendor will have a data processing addendum ready.

Two things to check beyond the standard form. Where is the data processed, and does the answer include jurisdictions that require a transfer mechanism? And what happens to it at the end: deletion within a stated period, confirmed in writing, including from backups on a stated cycle.

Exit

Assume you will leave. Every AI purchase should be tested against the day it is replaced.

What comes out, in what format, and over what period? A tool that has ingested three years of your documents and will return them only through a manual export limited to a hundred files at a time has effectively locked you in. The right to export in a usable, machine-readable format, on request and at termination, belongs in the contract.

What happens to anything the tool built that sits inside it — prompt libraries, fine-tuned configurations, workflows your team spent months refining? Ownership and portability of that layer is regularly overlooked and regularly expensive.

What this looks like in practice

Dinmore Bell runs the client side of a software or AI purchase. That means writing down what the business actually needs before looking at vendors, running the selection against that specification rather than against a demo, negotiating the agreement and the data terms, and then holding the vendor to what was agreed for as long as the contract runs — with the renewal and notice dates on the same register as every other contract in the business.

The aim is not to make the purchase harder. Most of these points are conceded when asked and never offered when not.

Where a specialist is needed

Where an AI system sits inside a regulated activity — lending decisions, insurance pricing, clinical or diagnostic support, anything a regulator supervises — the regulatory position is confirmed with a specialist in that regime before the tool is deployed, and Dinmore Bell instructs and manages that advice.

Where a deployment reaches users or a market outside the UK, the position in that jurisdiction is assessed with specialist advice rather than assumed from the UK position.

Where a dispute with a vendor becomes contentious, litigation is conducted by instructed specialists under Dinmore Bell's management, with the budget and the outcome held in one place.

Tax treatment of software and AI spend, including any relief claimed on development work, stays with the business's accountants.

Dinmore Bell provides an outsourced General Counsel function for founder-led businesses, owning work of this kind end to end rather than advising on it and handing it back.