AI Procurement: Contracts, Data Rights and Exit Clauses

Standard SaaS terms were not written for this

Most AI tools arrive with the same click-through terms as any other subscription software. Those terms were designed for products whose behaviour is fixed between releases, whose outputs are deterministic, and where customer data is simply stored and returned.

AI products break all three assumptions. Behaviour changes when the underlying model changes. Outputs vary and are sometimes wrong. And data may be processed, retained or learned from in ways a storage product never would.

This post is written from the perspective of engineers who have had to live with the consequences of AI contracts, not as legal advice. Use it to prepare for the conversation with your lawyer and your vendor. Smaller purchases on standard terms may leave little room to negotiate, but knowing where the gaps are still tells you how much to depend on the product.

Data use and training rights

This is the clause to read first, and the one most often vague.

• An explicit statement that your inputs, outputs and uploaded documents will not be used to train or improve any model, including the vendor's and any sub-processor's
• If some use is permitted, such as aggregated usage statistics, a precise definition of what that means
• Retention periods for prompts, outputs and logs, including backups and sub-processors
• A list of sub-processors, including underlying model providers, with notice of changes and a right to object
• Confirmation of processing locations if data residency matters to you

Watch for training permissions hidden in an 'improving our services' clause or in a privacy policy the contract incorporates by reference. A settings toggle is not a contractual commitment.

Who owns outputs and what was built for you

For custom development, where a firm like SpiderHunts builds a system for you, the norm should be that you own the code, prompts, evaluation sets and any models trained on your data. If a development partner wants to retain those, ask exactly why.

Model changes and performance commitments

An AI product can get worse overnight without a single line of the vendor's own code changing, because an upstream model was updated. Contracts should acknowledge that.

• Notice of material model changes, with a reasonable period before they reach your account, where the vendor can control that
• Access to an evaluation or the ability to run your own test set before and after a change
• A defined performance measure for anything critical: what is measured, on which data, how often, and what happens if it drops
• Service levels covering availability and response time, since AI features often depend on third-party APIs with their own outages

Be realistic here. Few vendors will contractually guarantee accuracy, and for good reason, since accuracy depends on your data. What you can often get is a commitment to a measurement process and a remedy, such as a right to terminate without penalty, if an agreed benchmark on your test set drops materially.

Liability when the AI gets it wrong

Vendors' standard terms usually disclaim responsibility for the accuracy of outputs and cap liability at a year of fees or less. For a writing assistant that is reasonable. For a system that makes or shapes decisions affecting customers, it may leave you carrying all the risk.

Points worth discussing include whether data protection and confidentiality breaches sit outside the general cap, whether IP indemnity covers outputs as well as the software, and whether the vendor warrants that it will operate the system in line with its documentation. We cover the wider question of who bears the loss, including insurance, in our post on AI liability and insurance.

If the contract says the vendor is responsible for nothing the AI does, plan your controls as if that is true. It is.

Exit clauses that actually work

Exit terms are drafted at the moment of maximum goodwill and read at the moment of least. Make them specific.

1. A right to export all your data, configuration, prompts, feedback and labelled examples in a documented, machine-readable format
2. A transition period after termination during which the service continues and export remains available
3. Reasonable assistance with migration, at stated rates if not included
4. Certified deletion of your data, including from sub-processors and backups within a stated period
5. No termination penalties triggered by the vendor's own material changes to price, model or terms

Then test the export before you rely on it. Our experience of AI vendor lock-in is that the contract usually promised an export, and the export was the problem. The pre-signature checks that should come before this negotiation are in our AI vendor due diligence checklist.

When to negotiate, and when to walk away

For a low-cost tool used by a handful of staff on non-sensitive work, accept the standard terms and manage the risk through how you use it. For anything handling personal data at volume, touching customers, or becoming central to operations, the clauses above are worth negotiating, and a vendor's willingness to engage tells you a lot about the relationship ahead.

If a vendor will not commit in writing that your data will not train its models, and the data is sensitive, walk away. If the exit route cannot be demonstrated, price that lock-in into the decision. Sometimes the conclusion is that owning the system through a custom build is less risky than renting one on terms you cannot change.

Frequently asked questions