The Clauses Behind the Copilot: A One-Week Data Terms Audit for UK Buyers

UK organisations have become comfortable asking an AI vendor what the model can do. Far fewer ask what the contract permits the vendor to do with what the model sees. The gap is not negligence so much as tempo: pilots are approved at director level, terms are accepted at click-through speed, and the data governance function meets the arrangement for the first time when a subject access request or an audit committee question lands.

A useful corrective is to stop treating the vendor agreement as a legal formality and start treating it as a data source. It has provenance, lineage, quality problems and an owner. It can be catalogued, tested and scored. What follows is a five-day sprint, sized for a mid-market UK firm or a single business unit of a larger one, that produces a defensible position rather than a legal opinion.

Why the contract belongs in the data catalogue

Most governance teams already hold processor terms under UK GDPR Article 28. AI arrangements stretch that template in ways the template was not drafted for. Training-data clauses sit outside the usual categories of controller and processor. Output ownership is rarely stated in language a data steward would recognise. Subprocessor lists change without the change-control discipline applied to any other dependency.

The sprint's premise is simple: if the arrangement cannot be described in the same register as the systems it touches, it cannot be governed. The output is a one-page scorecard, an evidence file, and a short list of clauses to renegotiate at renewal.

Day one: establish what was actually signed

Start with the documents, not the relationship. Assemble the master agreement, the data processing addendum, the acceptable use policy, the subprocessor list, the service level schedule and any security annex. Record each document's version, date and the route by which it was accepted. Click-through acceptance is common and legitimate, but it should be evidenced, not assumed.

Then test the join. Does the data processing addendum reference the same entity that appears on the invoice? Is the subprocessor list a live URL or a dated annex? A list that updates silently is a governance risk dressed as a convenience. Where the answer is a live page, capture a dated screenshot on day one; that capture becomes the baseline for every later comparison.

Day two: training-data provenance

The central question is whether the organisation's inputs can reach a training corpus, and under what conditions. Vendor language varies widely: some exclude customer data from training by default, some require an opt-out, some permit training on aggregated or derived data in terms broad enough to cover almost anything.

Read for four things. First, the default position, stated without qualification. Second, the mechanism for changing it and the notice period. Third, whether the exclusion survives product tiers, beta features and free trials, which frequently carry different terms. Fourth, whether prompts, uploaded files, embeddings and outputs are treated identically or differently.

Where the answer is ambiguous, do not resolve it by inference. Record it as an open item and route it to the vendor in writing. A written answer from a named account contact is evidence; a help-centre article is not.

Day three: who owns what comes out

Output ownership attracts confident assumptions. The safer reading is that ownership is only as good as the warranties behind it: a vendor can assign its rights in an output, but cannot warrant that the output does not reproduce a third party's material. For UK firms operating in regulated sectors, the practical question is narrower and more useful. Can the organisation demonstrate, if challenged, that it had a right to use the input and a clear basis for using the output?

Check three clauses: the assignment of output rights, the indemnity that accompanies it, and the exclusions that hollow the indemnity out. Note also whether outputs may be used to train the vendor's models and whether that permission is separable from the licence to use the tool. Record the answer in the scorecard in plain English, not in the vendor's phrasing.

Day four: follow the subprocessor chain

Model providers, hosting regions, observability tools and evaluation vendors form a chain that is rarely visible from the buyer's side. Obtain the current list, map it against the organisation's own restricted-data rules and note any entity in a jurisdiction the board has previously excluded.

Two tests matter. The first is notification: how much notice is given before a new subprocessor is engaged, and does the organisation hold a genuine right to object? The second is flow-down: are the vendor's own obligations to the buyer passed to its subcontractors in equivalent terms? Where data residency has been promised, confirm it at subprocessor level rather than at contract level, because the promise is only as strong as the weakest link in the chain.

Day five: exit, deletion and the shape of the archive

Exit clauses are read at the worst possible moment. Read them now. Establish what data can be exported, in what format, over what period, and at what cost. Establish what happens to fine-tuned models, prompt libraries, conversation histories and embeddings. Establish the deletion timeline and whether a certificate of destruction is available.

Then test it lightly. Request a sample export of a single workspace and time how long it takes. A portability rehearsal of this kind costs an afternoon and routinely reveals that the theoretical right to export is practically constrained by a format nobody can ingest.

A scorecard that fits on one page

Score each dimension from one to four, with a written justification rather than a bare number.

• Provenance: default training position, opt-out mechanism, tier exceptions, treatment of prompts and embeddings.
• Ownership: assignment of output rights, scope of indemnity, exclusions, permission to train on outputs.
• Subprocessors: completeness of list, notice period, objection right, flow-down of obligations, residency confirmation.
• Exit: export formats, timescales, costs, treatment of derived artefacts, deletion evidence.
• Evidence: documents captured, written answers received, date-stamped screenshots held.

A total below twelve should trigger a conversation before renewal, not after. A single score of one on provenance or exit is sufficient grounds for escalation regardless of the total, because those two dimensions carry the least recoverable risk.

Making the sprint repeatable

Run the exercise once and it produces a file. Run it as a standing control and it produces a register: every AI arrangement described in the same vocabulary as the systems it depends on, refreshed at renewal and at any material change of terms. That register is what allows a data governance lead to answer the audit committee's question without a fortnight of discovery.

The vendors will keep shipping. The terms will keep moving. The organisations that fare best will be those that treat the contract as a governed dataset rather than a PDF in a shared drive, and that read it on a schedule rather than under duress.