The AI clauses every client contract now needs

If AI now touches the work you deliver, or the work your suppliers deliver to you, your contracts need to say so. A standard services agreement written before AI entered the room is silent on the questions that now matter most: who may use AI on the work, whose data trains it, who owns what it produces, and who pays when it gets something wrong. That silence is not neutral. It defaults to whatever a court or a client decides later, which is the worst position to negotiate from. Seven clauses close the gap. You do not need to become a lawyer to ask for them, and you should not sign a contract that ignores them.

This is guidance, not legal advice, and the exact wording should be checked by your own solicitor. But the shape of the problem is now well understood. A useful reference point is Kennedys' 2025 note on AI and commercial contracts, which sets out the clauses in-house legal teams are being told to review now: compliance with emerging AI regulation, IP infringement protection, liability allocation, ownership of AI outputs, and data security. What follows turns that into a practical checklist for a smaller firm, plus the two clauses that matter most when you are the buyer.

Why standard contracts are now exposed

Most service contracts assume a human does the work. They allocate liability, assign intellectual property and set confidentiality on that basis. The moment AI enters delivery, several of those assumptions quietly break.

Ownership is the clearest example. Copyright law protects human authorship, and the status of purely AI-generated output is unsettled in both the UK and the EU. If your contract simply says the client owns the deliverables, and part of a deliverable was produced by an AI tool, you may be assigning rights you do not cleanly hold. Confidentiality is the next crack: a standard non-disclosure clause says nothing about whether client material can be typed into a public AI tool that may retain or train on it. And liability clauses written for human error do not obviously cover a tool that invents a figure with complete confidence.

None of this means AI should be kept out of the work. It means the contract has to catch up with how the work is now done.

The seven clauses to add

1. Definition and scope of AI use. Start by defining what counts. A short definition of "AI tools" and a statement of where they may and may not be used stops every later clause from being argued over. Name the categories that are off limits by default, such as anything involving personal data or client-identifiable information, unless separately agreed.

2. Disclosure and approval. Say whether AI may be used on the work at all, and if so, whether its use must be disclosed and approved in advance. Many clients are relaxed about AI for drafting and research and firm about it for final advice. A disclosure clause lets both sides set that line on purpose rather than discover it in a dispute.

3. No training on the other side's data. This is the clause most standard agreements miss. It should prohibit either party, and any AI tool they use, from using the other's confidential data to train or improve a model without explicit written consent. Pair it with a requirement that any AI service used to process the other side's data is contracted not to retain or train on it. That single sentence closes the most common confidentiality gap AI creates.

4. Ownership and assignment of AI-assisted outputs. Because default ownership of AI output is uncertain, spell it out. State who owns AI-assisted deliverables, assign whatever rights can be assigned, and confirm the supplier has the right to grant them. If a tool's terms retain any rights in what it generates, that has to be surfaced here, not buried in a vendor policy nobody reads.

5. Output quality and acceptance. AI raises the odds of a plausible but wrong deliverable. A quality clause should require human review of AI-assisted work before it is delivered, set the standard the output must meet, and give a clear acceptance and correction process. This protects the client from unchecked output and protects you from being held to a standard nobody named.

6. Security and incident handling. Set out how data is stored and processed when AI is involved, which tools are approved, and what happens if something goes wrong. A short incident clause, telling the other side who to contact and how fast, turns a data problem into a managed event rather than a breach of contract argument.

7. Compliance, termination and deletion. Require both sides to comply with applicable AI and data-protection law, including UK GDPR and, where it applies, the EU AI Act, and to keep pace with changes to it. Add what happens at the end: return or deletion of data, and confirmation that no copies persist inside an AI tool. Regulation here is moving, so a clause that references "applicable law as amended" ages better than one that names a single rule.

Sample wording to start from

You do not need dense legalese. A plain clause a client can actually read is often stronger than a borrowed template. For the no-training point, something as simple as this gives your solicitor a clear starting position:

Neither party shall input the other party's Confidential Information into any artificial intelligence tool that uses such information to train or improve its models, or that retains such information beyond the term, without the other party's prior written consent.

Treat wording like this as a draft to refine, not a finished clause. The value is in having named the risk plainly enough that both sides know what they are agreeing to.

When you are the buyer

The same clauses work in reverse, and this is the half most firms forget. When a supplier delivers work to you, ask them to disclose their AI use, confirm they will not train on your data, warrant that AI-assisted outputs do not infringe third-party rights, and carry insurance that covers AI-related error. If you resell or build on what a supplier gives you, their AI risk becomes yours the moment it reaches your client. A short set of questions at procurement is far cheaper than discovering the gap after a deliverable has gone out.

This connects to the wider controls a firm should already run. Contracts sit alongside a clear internal position on tools and data, which is exactly what a one-page AI policy is for, and alongside a plan for what happens if a key AI vendor changes or disappears. Where AI is used to help make decisions about people, the contract also needs to sit on top of the UK rules on automated decisions, not replace them.

UK and EU notes

The two regimes point the same way but land differently. UK GDPR governs how personal data may be processed by any AI tool, and the UK's approach to AI regulation is principles-based rather than a single statute, so contracts should reference the principles and the sector guidance that applies to you. The EU AI Act adds duties that bite hardest where AI supports higher-risk decisions, and it reaches firms that serve EU clients regardless of where they sit. A compliance clause that references applicable law "as amended from time to time" covers both without needing a rewrite every time the rules move.

What to do on Monday

Pull your current standard client contract and read it once with a single question in mind: if AI produced part of this deliverable, does the contract say who may use it, whose data trains it, who owns the output and who is liable when it is wrong. Mark every place the answer is silence. That marked-up copy, seven clauses long at most, is the brief for your solicitor, and it is the fastest way to turn an exposed contract into one that protects both sides.

If you want help working out where AI touches your delivery and which of these clauses your contracts actually need, book a session and we will map it to how your firm works.