AI clauses in a software development agreement

Most software is now written with AI coding assistants, and most development agreements assign to the client code the developer may not own, warrant that the code is free of third-party material the developer cannot trace, and say nothing about the tools that saw the client's codebase. The clauses deal with disclosure, ownership, open-source contamination, security review, the client's data in the tools, and the warranty and liability position for generated code, and they can be drafted for the developer or for the client. I draft or review the AI provisions for the agreement for a fixed fee of £595, delivered in five working days.

Who this is for

Software developers, agencies and freelancers in England and Wales using AI coding tools on client work, and clients commissioning software who want to know what they are getting.

What matters in AI clauses for a development agreement

Disclosure of the tools and the client's right to say no

The agreement states that the developer may use AI coding assistants and names the categories, states the terms the developer will use them under (business tiers, no training on the client's code, limited retention), gives the client the right to restrict or prohibit their use on stated parts of the work (with the price and timetable adjusted), and requires the developer to record where generated code has been used so that provenance can be shown; a client that discovers the assistant after the fact, or a developer that discovers a prohibition after the fact, is the dispute the clause removes.

Ownership of generated code and the assignment that assumes an author

whoever made the arrangements is the author of a computer-generated work under section 9(3) of the Copyright, Designs and Patents Act 1988, a provision untested on modern tools, and only original works are protected, so the assignment of intellectual property in the deliverables is reworded to assign the developer's own work and whatever rights it holds in generated code (under the tool's output terms, which the developer should have read), to license what cannot be assigned, to carve out the developer's pre-existing libraries and know-how, and to state that generated code may be unprotected; where the developer's staff or contractors generated the code, the developer's own employment and contractor terms must assign their rights to the developer first, which the agreement warrants.

Open-source contamination and the licence warranty

Generated code may reproduce code from the training data under licences (copyleft licences in particular) whose terms would, if the code is incorporated, impose obligations on the client's product, and the standard warranty that the deliverables contain no third-party code except as listed becomes a warranty the developer cannot give blind; the clause requires the developer to run licence scanning on generated code, to use the assistant's duplication filter where offered, to list the open-source components with their licences, and to warrant the result of those steps rather than an absolute absence of third-party material, with an indemnity for breach of the steps and a remedy (replacement of the affected code) for contamination found later.

Security, review and the vulnerability the tool introduced

Generated code contains vulnerabilities and insecure patterns and can suggest dependencies that do not exist (which attackers then register), and the agreement requires generated code to pass the same review, testing and static analysis as any other with the reviewer knowing it was generated, requires dependencies to be verified before they are added, keeps the security review independent of the tool that wrote the code, and provides for security defects found after acceptance under the agreement's warranty and support provisions; the client's security requirements schedule is updated to say so, because a customer's security questionnaire will ask the client what its developers' practices are.

The client's data, the codebase and the tools that see it

confidential information, trade secrets and clients' data must not be entered into tools whose terms permit the provider to use inputs for training or to retain them, which the Trade Secrets (Enforcement, etc.) Regulations 2018 and the business's own confidentiality obligations make a question of reasonable steps, and a client's codebase, credentials and data are confidential; the clause permits the developer to use the client's code in tools meeting stated conditions, prohibits credentials, keys and production data in any tool, and requires the assistant to be disabled in repositories the client designates; any personal data that goes into an AI tool is being processed under the UK GDPR, which calls for a lawful basis, transparency to the individuals, an Article 28 agreement with the provider and an Article 35 impact assessment where the use bears on people, and test data should be synthetic or anonymised.

Acceptance, liability and the warranty on generated code

Acceptance testing applies to generated code as to any other, the developer's warranties (conformance to specification, reasonable care and skill, the licence and security steps) apply to it without an AI carve-out, the developer's indemnity for infringement is limited to its own work and the steps it has warranted, liability sits within the agreement's cap, and the developer's insurance is checked for AI-related exclusions; for the client the clauses give a warranty it can enforce and a record it can rely on, for the developer they replace an absolute warranty with one it can meet, and either side can instruct the drafting or the review.

What it costs

AI provisions in a contract, £595. Review or draft AI-specific terms in a supply or customer agreement. Five working days.

AI use policy, £995. Internal policy plus the accompanying contract provisions. Five working days.

Email me at geoffrey@caesar.co.uk with what you need and any documents, and I will confirm the scope and the fee in writing, usually the same working day.

What you get

• An internal AI use policy your staff will follow, rather than a document that bans everything and is quietly ignored
• Contract provisions covering output ownership, training data, confidentiality and liability
• A defensible position to give customers who ask what your AI governance looks like
• Review of your AI suppliers' terms, including what they reserve the right to change
• Practical guidance on what to permit, what to restrict and what to prohibit outright
• One round of amendments

What is not included

• Technical AI assurance, model testing or bias auditing
• Sector-specific regulatory approval
• Advice on non-UK regulatory regimes beyond flagging where they apply
• Ongoing regulatory monitoring

Questions I am often asked

Can the developer assign IP in code an assistant generated?

Its own work and the rights it holds in generated code under the tool's terms, with the rest licensed and the client told that generated code may be unprotected. The developer must also have taken the rights from its own staff and contractors first.

How do we protect against open-source code in generated output?

The clause requires licence scanning and the duplication filter, a listed bill of components, a warranty of the steps rather than an absolute absence, and replacement of contaminated code found later.

Can the client ban AI coding tools on its project?

The clause gives it the right to restrict or prohibit them on stated parts of the work, with price and timetable adjusted. A ban imposed after the work has started is a change request.

Related guidance and services

• AI contracts and AI use policies, £595, the service this page describes
• SaaS and technology contracts, £995
• Data protection agreements and privacy terms, £795
• AI use policy for a software company
• AI-assisted coding and intellectual property for a software house

This page is general guidance for businesses in England and Wales, not advice on your own circumstances. Last reviewed: October 2026. Email geoffrey@caesar.co.uk.