Contract Terms That Matter for AI Projects

The clauses that decide how an AI project ends

The reason these gaps exist is not that lawyers are careless. It is that software contracts were built around a deterministic deliverable. A payments integration either posts the charge or it does not, and you can point at the failure. An extraction pipeline reads the invoice number correctly on most invoices and incorrectly on the ones with two invoice numbers printed on them. Both parties can look at the same running system and disagree in complete good faith about whether it works, and a feature list gives them no instrument to settle it. Six weeks of that is how projects go to war.

Everything below is written for the technical schedules: the parts describing what the thing is, what it must score, what happens when the ground moves, and what you get on the way out. Your lawyer owns the frame those schedules sit inside.

Acceptance is a score on a frozen set, not a list of features

Write acceptance as a score on a case set both parties agreed to before any code existed. A feature list is unenforceable for an LLM system, because the system will do every listed feature some of the time, and the disagreement is about the rate rather than the capability.

1. The client supplies the cases. They come from real history and they include the ugly ones. If the supplier picks the cases they will build the test they can pass, and they will not be doing anything dishonest. They will simply pick the cases they understand.
2. The supplier supplies the harness and the scoring code. That is engineering work and it belongs on their side of the line. What it must produce is a result file broken down per failure category, not a single number.
3. Both parties sign the pass bar before the build starts. A number, on a named metric, on a named case set, at a named model version. All four parts or the clause means nothing.
4. Split the set. A visible portion the supplier may tune against, and a held out portion nobody sees until acceptance. Without a holdout you are paying to have your test memorised, and neither party finds that out until production traffic arrives.
5. Score per failure category with a floor on each. An aggregate of 94 percent conceals the fact that all six failures landed on the case type that carries the money. Categories are agreed at the same time as the pass bar.
6. Put the set size in the contract. A pass bar measured on twenty cases is noise wearing a percentage sign. Method for building the set properly is in building a golden dataset.

The Drift Clauses

An AI system changes its behaviour without anyone editing it, so a contract that only covers the build has covered the easy part. These five clauses handle the fact that the system's dependencies move on somebody else's schedule. Each one costs a paragraph before a price exists and is close to impossible to introduce afterwards.

What a model port actually costs, so you know what to negotiate

Put a number on the port before deciding who pays for it, because the number is usually smaller than the argument about it. The work scales with how many distinct prompts the system contains and how many output parsers depend on model formatting habits, not with the size of the codebase.

Use the last output to decide how hard to negotiate. If a port costs a small share of the fee, push for it to sit inside a support retainer and spend your negotiating energy elsewhere. If it is a large share, it deserves its own clause with a capped day rate agreed at signature rather than on the day the retirement notice arrives.

One honest caveat about this arithmetic: it prices the median port, which is boring. It does not price the tail case, where a newer model version is better at reasoning and worse at obeying a length constraint or a JSON schema, and a parser that has worked for a year starts failing on a shape it has never seen. Carry a contingency, and do not assume a version upgrade is an upgrade until the evaluation says so.

What you own, itemised, because 'all deliverables' does not cover it

List the assets individually in a schedule. A general assignment of deliverables was drafted for a world where the deliverable was code, and in an AI system the code is the part you could rewrite in a fortnight. The valuable artifacts sit outside it, and several of them will otherwise live in the supplier's accounts by default rather than by decision.

Data terms with technical teeth

Three data questions decide whether the data section is doing any work: who may train on your data, which companies your users' text physically reaches, and how long the logs live. Everything else in a typical data schedule is boilerplate that was already fine.

Training rights are three separate permissions

The first is whether the model provider trains on traffic sent through their API, which is a function of the account tier and the provider's own terms, and is not something your supplier grants or withholds. The second is whether the supplier may train or fine tune on your data for your system, which you probably want to allow. The third is whether the supplier may reuse your data for other clients, including as few shot examples pasted into a prompt template they carry between engagements. Write all three separately. A single sentence saying the supplier will not use client data for training covers the case you wanted to permit and misses the one that actually happens, which is a prompt template travelling to the next project with three of your real records inside it.

Name the model providers as sub-processors

A generic sub-processor clause pointing at a maintained list is standard practice and it is not sufficient here, because switching model providers is a one line configuration change that moves your users' text to a different company, a different jurisdiction and a different retention policy. Require the providers to be named, and require prior notice of a change rather than notification after the fact. The version pin clause and the sub-processor clause work together: one tells you the behaviour changed, the other tells you the destination changed.

Log retention has a technical floor and a legal ceiling

You need run logs to debug an incident, to build the next evaluation set, and to prove what the system did on a given date. Those logs contain whatever your users typed, which will include personal data that nobody intended to store. The usual failure is a retention window chosen implicitly by whoever configured the observability tool, which is effectively forever. Pick a number, write it into the schedule, and require redaction at write time rather than deletion later, because deletion later depends on somebody remembering. The mechanics are in personal data in AI pipelines.

Liability sized to permissions, not to the fee

Size the liability conversation to what the system is permitted to do. If the cap and the blast radius do not meet, take permissions away rather than negotiating the cap upwards, because reducing permissions is a change you can make and a higher cap is a payment you might receive.

The arithmetic is uncomfortable and worth doing anyway. If an agent can issue refunds, the worst case is bounded by the refund limit multiplied by the rate at which it can act before a human notices, so the exposure is a number you can calculate. If it can send email to your customer list, the worst case is reputational and unbounded, and no cap addresses it. A liability cap set at the project fee, which is the market default, is entirely reasonable for a reporting pipeline and is theatre for an agent holding write access to a billing system.

On indemnity for model output: ask whether the supplier indemnifies you against infringement claims arising from what the model generates, and expect the answer to be no or heavily qualified. That is not a supplier being difficult. They cannot control what the model produces, and they are mostly passing through whatever protection the provider offers at whatever account tier you are on. The useful version of this clause is not an indemnity at all. It is a term requiring specific provider tiers, and requiring that any generated asset reaching a customer passes a named review step, which is a control you can actually verify. Design of that step is covered in guardrails without breaking things.

Payment gates instead of a calendar

Tie payments to gates that produce evidence rather than to months elapsed. Each gate should be a thing that either happened or did not, verifiable by someone on your side, and the final one should sit on the far side of a production soak rather than on the day the repository is transferred.

The exit schedule you can lift

Write the exit schedule at signature, while both parties are optimistic and it costs nothing. The test of a good one is not its length. It is whether a client engineer could stand the system up from the listed materials without sending a single message to the supplier.

SCHEDULE E: EXIT AND CONTINUITY
Attach to the statement of work. This is the technical schedule. Have counsel
draft the legal frame around it.

E1) DELIVERY ON TERMINATION OR COMPLETION
Within ten business days of either event, the Supplier delivers into
repositories and cloud accounts controlled by the Client:

  a) application source, infrastructure as code, and build scripts
  b) all prompt templates and their full version history, together with the
     record showing which version was live on which date
  c) the acceptance evaluation set, the golden answers, the harness, and the
     last full result file broken down per failure category
  d) any fine tuning dataset and any resulting adapter or weights
  e) retrieval configuration: chunking parameters, embedding model and
     version, index build script, and the source document manifest
  f) run logs for the retention period defined in Schedule D, exportable in
     a documented format
  g) a credential inventory listing every secret the Supplier held, the
     system each one opens, and the rotation procedure
  h) a written model change procedure covering how to move the system to a
     new model version and re-run acceptance

E2) REPRODUCIBILITY TEST
Delivery is not complete until a Client engineer, working from the delivered
materials alone and without contacting the Supplier, brings the system up in
a Client environment and runs the evaluation suite to a score within ____
percent of the accepted score.

E3) TRANSITION ASSISTANCE
The Supplier provides up to ____ days of assistance at the rates in Schedule
B, available for ____ months after termination, usable for incident support
and for one model re-qualification.

E4) NO LOCK BY OMISSION
The Supplier warrants that the delivered system contains no dependency on a
Supplier owned service, account, licence or hosted component that the Client
cannot obtain directly. Any such dependency is listed below with the cost and
term of the Client's direct access:
  ____

E5) SURVIVING RESTRICTIONS
The training rights and data reuse restrictions in Schedule D survive
termination of this agreement.

E6) NO DEGRADED HANDOVER
Nothing in the delivered materials may be withheld, redacted or summarised on
the grounds that it constitutes Supplier method, except items expressly
listed in the Supplier retained materials schedule agreed at signature.

A word on source code escrow, which procurement often asks for and which is close to useless in AI work. The code is the part you could rewrite. What you cannot recreate is the evaluation set, the prompt history with results attached, and the knowledge of which twenty approaches were tried and rejected. If escrow makes someone comfortable, escrow the artifacts in E1. Better still, never let those artifacts live anywhere except your own repository from the first week, at which point the escrow question stops being interesting.

Clause E6 exists because of a specific pattern. A supplier delivers everything on the list and delivers the prompts as a cleaned final version with the history removed, on the reasonable sounding basis that the intermediate versions are their method. The history is precisely what you needed, because it records what was tried and what it scored. Agree the retained materials list at signature so the argument happens when it is cheap.

Terms worth being precise about, and the pre-signature check

Definitions

Acceptance evaluation set

A fixed collection of real input cases with the correct output recorded for each, agreed before the build starts and used as the sole instrument of acceptance. It is normally split into a visible portion the supplier may tune against and a held out portion revealed only at acceptance.

Held out set

The portion of the acceptance cases the supplier never sees during development. It exists because a system tuned against every case it will later be tested on measures memorisation rather than capability, and the difference between the two only becomes visible on production traffic.

Error budget

The failure rate a system is permitted in production, stated per failure category and measured on live traffic rather than on the evaluation set. It converts an argument about whether the system is defective into a comparison against a number both parties signed.

Model version pin

A named provider, model and version string written into the contract, to which every performance commitment attaches. Without a pin, a warranty describes an object that changes on the provider's release schedule rather than on yours, and it becomes unenforceable in both directions.

Sub-processor

Any third party that processes your data on the supplier's behalf, which for an AI system includes the model provider, the vector database host and the observability vendor. Each named sub-processor is a company your users' text physically reaches.

Holdback

A share of the fee retained until a post go-live gate is met, as distinct from a warranty period with no money attached to it. Its purpose is to keep the supplier commercially present during the weeks when the real failure modes appear.