Eight clauses matter: whether your inputs train the supplier's models, where processing happens, who owns outputs, who carries liability for wrong ones, security and sub-processor control, audit and evidence rights, change notification, and exit with data return. Where software runs on hardware you own, the deployment settles location and exit rather than the drafting.
What AI clauses should be in a supplier contract?
Eight clauses carry the weight: training use of your inputs, processing location, output ownership, liability for wrong outputs, security and sub-processor control, audit and evidence rights, notice of material change, and exit with data return. Everything else is ordinary commercial drafting your legal team already handles.
The pattern is consistent in the contracts I have read. The security schedule runs to pages; those eight clauses get a couple of paragraphs. The schedule describes controls the supplier already has. The clauses describe the control the buyer wants to take.
One framing helps. Under Article 28 of the UK GDPR, a processor contract must already specify the nature, purpose and duration of processing, the types of personal data, sub-processor authorisation, assistance with data subject rights, deletion or return of data at the end, and the information and access needed to demonstrate compliance, including audits and inspections (legislation.gov.uk). Most of what follows is that list made concrete for a system that generates outputs, not only records. If a supplier resists a clause, ask which part of Article 28 they intend to satisfy instead.
Can the supplier train models on our inputs?
Ask for a flat prohibition, then define the words. "We do not train on your data" is a sentence with several doors in it. Training, fine-tuning, retrieval indexing, evaluation, abuse monitoring, human review of flagged content and retention of prompts for debugging are different activities, and a supplier can honour that sentence while doing five of them.
Write it as a closed list of permitted purposes with everything else excluded. Name the artefacts as well as the activity: prompts, attachments, outputs, embeddings, logs, and any derived index or model weights. Say what happens to an existing derivative if the contract ends. Then get the retention period in days, in the contract, not in a policy the supplier can revise alone.
Two practical notes. A supplier right to change that policy on notice is not protection: the notice lands precisely when switching is expensive. And if a zero-retention tier exists, get it named in the order form: a capability that sits in the platform but not in your paperwork is not yours.
Where is our data processed and stored?
Name countries, not regions, and cover the whole path rather than the storage bucket. Inference, caching, logging, telemetry, backups, disaster recovery and the support desk all touch your data, and they often sit somewhere other than the database. "UK hosted" means little if the model runs elsewhere, or an engineer connects from a third country at three in the morning.
Then get three answers in writing. Which country each processing activity happens in. Who can access the data for support, from where, under whose approval. What happens if a government or law enforcement body in any of those countries demands access, and whether you will be told. The third question changes architecture decisions, and it is the one least often answered on paper.
The ICO's AI and data protection guidance covers the data protection half of this. Accountability stays with you as controller, whatever the supplier's terms say about their own compliance.
Who owns the outputs and who carries liability?
Two questions, and conflating them costs buyers money. On ownership, ask for assignment of outputs, or failing that a broad, irrevocable, royalty-free licence to use them for any purpose, with an express statement that the supplier asserts no interest in them. Add a term for what happens if an output reproduces third-party material, because that risk sits with whoever published it: you.
On liability, expect a cap, an exclusion of indirect loss and a disclaimer of accuracy. Fighting the cap rarely works. Making the decision architecture explicit in the contract does. Set out which classes of action the system may take on its own and which require a named person to approve, then tie the accuracy disclaimer to that boundary. Where a person approved, liability sensibly follows the person and their organisation. Where the system acted alone, the disclaimer becomes a live commercial question. Have that argument before signature, not after an incident.
One more term: require the supplier to distinguish model-generated output from retrieved or deterministic output. You cannot allocate responsibility for a decision if you cannot tell which part of the system produced it.
What security and sub-processor terms are needed?
Your usual security schedule, plus three AI-specific additions and a change-notification clause. The NCSC's Guidelines for Secure AI System Development are the reference I point buyers at: they treat the AI supply chain as part of the attack surface rather than a procurement formality.
The additions. An approved sub-processor list, prior written consent for changes, and a right to object without penalty. Named controls for prompt injection and for content entering the system from untrusted sources, since in an AI system your inputs are also an instruction channel. And an incident definition covering model behaviour, not only confidentiality: a system that starts issuing wrong instructions is an incident even though nothing leaked.
Change notification is the clause buyers skip and later regret. These products move underneath you: a new model version, a changed default, an added sub-processor, a new region, a withdrawn capability. Require advance written notice of material change to the model, its hosting, its sub-processors or its behaviour, with a defined notice period and a right to exit without penalty if the change is unacceptable. Otherwise the system you validated in procurement is not the system you are running two quarters later.
What audit and evidence rights should you reserve?
Reserve a right to evidence, not merely a right to ask. An annual questionnaire tells you what the supplier believes. What a regulated buyer needs is a record it can check: what the system did, on whose authority, against which data, at what time, and whether the record has been altered since it was written.
Specify three properties. The format, so the record exports and reads without the supplier's tooling. The retention period, long enough for your regulatory window rather than their default. And the verification method, so an auditor can confirm the record is intact.
That last one gets blurred in sales talk. Tamper-evident is not the same as tamper-proof. Nothing stops a sufficiently privileged party altering bytes on a disk. What a sound cryptographic scheme gives you is that altering them breaks verification, so the change is detectable by anyone holding the public key. Ask which signature scheme is used, who holds the signing key, and whether verification needs the supplier to be cooperative, or even still trading. If they receive your request and send you a report, you have a reporting right, not an audit right.
What does a clean exit clause look like?
Four things, each with a date attached. Return of your data in a documented, non-proprietary format. Deletion everywhere, including backups and derived artefacts, with written certification by a stated deadline. Continuity of the audit record after termination, because your retention duty outlives the supplier relationship. And a transition period at known terms, so you are not negotiating while the service is being switched off.
Add the clause most buyers leave out: what happens if the supplier fails as a business. Escrow of source code is the traditional answer and it is weak for a hosted service: code without the hosting, the weights and the operational knowledge is not a running system. Where continuity genuinely matters, the answer is architectural rather than contractual. Software you run on your own estate keeps running when the supplier stops.
Which clauses does the deployment answer for you?
The Mickai Sovereign Intelligence Operating System installs on hardware the customer owns. It is offline capable, there is no data egress, and licensing is bound to that hardware. The Open Audit Record seals every consequential action under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024, and an exported record verifies offline against a public key using tools that are not ours. Consequential actions wait for a named person to approve them.
Set that against the checklist. Processing location is settled by where the machine sits. Training use of inputs is settled by the fact that inputs do not leave the estate. Sub-processor risk reduces to whatever you add yourself. Audit evidence is verifiable without our cooperation, or our continued existence. Exit is largely answered, because the system and the data are already yours.
Four clauses still need drafting properly: output ownership, liability, security obligations for the software itself, and change notification for updates you choose to accept. Deployment changes where the risk sits. It does not delete the contract, and anyone saying that software on your own hardware lets you skip the paperwork is selling rather than engineering.
We are in closed beta, with one regulated company onboarding as a design partner. If you are drafting a clause set this quarter, those eight headings are the ones I would put in the first draft, in that order.
Frequently asked questions
What is the single most important AI clause to get right?
Training use of your inputs. It is the clause suppliers word most loosely and the one you can least unwind later, because a model or index built from your data cannot be cleanly separated afterwards. Define the prohibited activities by name, list the artefacts covered, and state what happens to any existing derivative when the contract ends.
Delete this entire FAQ entry (question and answer) so the FAQ contains exactly five items. It duplicates FAQ 1, which already covers training use of inputs as the clause to get right.
Yes, if you write it as a closed list rather than a slogan. Name training, fine-tuning, retrieval indexing, evaluation and human review of flagged content separately, cover prompts, attachments, outputs, embeddings and logs, and fix the retention period in days inside the contract. Get any zero-retention tier named in the order form, not just the sales deck.
What audit rights should we ask an AI supplier for?
A right to evidence rather than a right to ask. Specify an exportable record of what the system did, on whose authority and when; a retention period matching your own regulatory window; and a verification method an auditor can run independently. Add inspection rights and a defined route for your regulator to obtain information directly.
How do we write an exit clause for an AI contract?
Attach dates to four things: return of your data in a documented, non-proprietary format, deletion everywhere including backups and derived artefacts with written certification, continuity of the audit record after termination, and a transition period at known terms. Then add what happens if the supplier fails as a business, because escrow alone rarely restores a running service.
Does an on-premises deployment remove the need for these clauses?
No. It answers several clauses in the architecture rather than the drafting: processing location, training use of inputs, sub-processor exposure and most of exit. Output ownership, liability allocation, security obligations for the software itself and change notification for updates still need proper terms. Anyone saying otherwise is selling rather than engineering.
Who is liable if the AI gives a wrong answer?
It depends on who authorised the action, which is why the contract should say. Suppliers disclaim accuracy and cap liability, so the workable approach is to define which actions the system may take alone and which wait for a named person to approve. Where a person approved, responsibility follows them; where the system acted alone, argue it before signing.
Related briefings
Procurement and defence
- Buy AI Through G-Cloud and Government Frameworks: Guide
- AI Disclosure in Public Sector Tenders: What's Required?
- AI Bid Evaluation in Public Procurement: Is It Lawful?
- AI for Procurement Contract Review: Is It Allowed?
- JSP 936 for AI Suppliers: What the MOD Now Requires
UK AI regulation
- Is There a UK AI Act? How the UK Regulates AI Today
- AI Cyber Security Code of Practice: Who It Applies To
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)