Contract Clauses for an AI-Built App

Standard software contract templates were written for projects where a human wrote every line, the running cost after launch was hosting, and the thing you delivered behaved the same way next year. None of those hold on an AI build. The six contract clauses for an AI-built app below are the ones where a generic template leaves a gap, with wording you can adapt.

Everything else in your template is probably fine. These are the parts that are not.

1. Ownership of generated code

The usual clause assigns "all intellectual property in the deliverables" to the client. On an AI build that may be assigning something that does not exist in the form everyone assumes, because copyright protection for material generated without sufficient human authorship is contested in several jurisdictions.

You do not solve that in a freelance contract. You solve the practical problem, which is the client wanting certainty that nobody else can stop them using what they paid for.

> The Developer assigns to the Client all right, title and interest the Developer holds in the Deliverables, and grants an irrevocable, worldwide, royalty-free licence to use, modify and distribute the Deliverables for any purpose. The Developer makes no representation that every element of the Deliverables attracts copyright protection, and the Client acknowledges that some elements may have been produced with AI assistance.

That gives the client everything you can actually give and stops you warranting something you cannot. The underlying legal position is unpacked in who owns AI-generated code.

2. Prompts and configuration

Prompts, system instructions and evaluation sets are assets, and they are the part you are most likely to want to reuse. Say which way it goes rather than letting the deliverables clause swallow them by default.

> Prompts, system instructions and model configuration developed under this agreement are licensed to the Client for use with the Deliverables. The Developer retains the right to use generalised techniques and non-client-specific prompt patterns in other work.

If the client insists on owning them outright, price that, because you are selling a tool rather than a job. Who owns the prompts you wrote for a client covers how that negotiation usually runs.

3. Who pays for API usage

This is the clause most missing from most contracts, and the one that generates the worst arguments, because the cost arrives monthly after you have been paid once.

> Model and API usage costs are the Client's responsibility from the Acceptance Date. During development, the Developer bears usage costs up to [amount]. The Client will hold the account and provide API credentials, or reimburse the Developer monthly against invoice.

Having the client hold the account is the cleaner arrangement whenever they will accept it. It puts the bill in front of the person whose usage drives it and takes you out of the position of fronting a cost that scales with their success. Where you are reselling access rather than passing it through, the margin question is separate and worth settling in advance.

4. Acceptance criteria that survive a non-deterministic system

"The software shall be free from material defects" is unworkable when the same input can produce different output. Acceptance has to be defined against a test set, agreed before you build.

> Acceptance is met when the Deliverables process the agreed test set of [n] representative cases, provided by the Client at project start, with correct output on at least [n-k] cases, and no case producing output that is incorrect without being visibly flagged as uncertain. The Client has 10 working days from delivery to test and must specify any failure by reference to a named test case.

The second half matters more than the threshold. A wrong answer the system flags as uncertain is a different failure from a wrong answer delivered confidently, and a contract that treats them identically will either never be satisfiable or will let real defects through. The 10-day window stops acceptance drifting indefinitely.

5. Model change and deprecation

The model you built against will change or be retired, and your contract should say whose problem that is.

> The Deliverables depend on third-party AI models whose behaviour, pricing and availability the Developer does not control. The Developer warrants the Deliverables against the model versions specified in Schedule A as at the Acceptance Date. Changes required by a provider deprecating, altering or repricing a model are chargeable as new work at the Developer's then-current rate.

Name the actual model versions in a schedule. Without that, "it used to work" becomes a warranty claim rather than a change request.

6. Handover artifacts

List what the client receives, by name. A dispute about whether a handover happened is a dispute nobody wins.

> On final payment the Developer will provide: the source repository with full commit history, a database schema export, environment variable names and their purposes excluding secret values, deployment instructions sufficient for a competent developer to redeploy, and the prompt and configuration files referred to in clause 2.

Note what is excluded. You hand over variable names and purposes, not live credentials, which the client rotates on their own account. Handing off an AI-built app to a developer covers what a genuinely usable handover looks like beyond the list.

Extra contract clauses for an AI-built app when a client is cautious

A disclosure line saying which categories of tool you use avoids the discovery problem entirely, and costs you nothing at proposal stage. Where the client goes the other way and wants AI excluded, the clause needs unpicking rather than accepting, which is the subject of a no-AI clause in a client contract. If you want clients to sign inside your own product, adding e-signatures to an AI-built app explains how.

If the contract is drafted on your standard terms, be aware that liability-limiting clauses are not automatically enforceable. In England and Wales, section 3 of the Unfair Contract Terms Act 1977 provides that where one party deals on the other's written standard terms, a term excluding liability for the drafter's own breach only binds if it satisfies the reasonableness requirement. A cap set at the project fee tends to read as reasonable. A total exclusion often does not.

FAQ

Do I need a lawyer to use these clauses?

For a small fixed-fee build, adapting tested wording is normal practice. Get a lawyer involved once the contract value or the liability exposure is large enough that losing the argument would hurt, and always for anything involving regulated data.

What if the client supplies their own contract?

Read these six areas specifically and propose amendments where they are silent, which they usually are on API costs and model change. Silence favours whoever drafted the rest of the document.

Should the contract name the AI tools I use?

Naming categories is safer than naming products, because products change mid-project. "Commercial large language model APIs under business terms that exclude training on submitted data" ages better than a brand name.

How do I set the acceptance threshold?

From the test set, before you build. Run your first prototype against it, see where it lands, and set the threshold at a level you have evidence you can hit, not at the number that sounds impressive in a proposal.