AI development contract terms: what to fix in writing first

An AI development contract needs everything an ordinary software contract has, plus six terms most software contracts never mention: what “done” means when the output varies, whose accounts and keys the system runs on, who pays the model bill, what happens when the model is retired, what anyone may do with your data, and how you leave. Fix all six in writing before the first invoice. After that, you are negotiating from a weaker seat.

None of this is legal advice. It is the checklist we would want in your hands before a lawyer reads the final draft, written by people who sign these contracts from the builder’s side.

Why an AI build needs more than a software contract

A standard development contract assumes the software does the same thing every time it runs. An AI system does not. The same input can produce a different answer tomorrow, the model underneath can be withdrawn by its vendor on a published schedule, and your data passes through a third company you never signed anything with.

Governments noticed first. The US Office of Management and Budget issued memo M-25-22 on 3 April 2025, and it tells federal agencies to write AI-specific terms into every AI contract: limits on training with agency data, performance tracking, and protections against vendor lock-in. In Europe, the Public Buyers Community, supported by the European Commission, published updated model contractual clauses for AI procurement on 5 March 2025, with a full version for high-risk systems and a light version for everything else.

A company buying one agent does not need a procurement department. It does need the same six answers.

1. Acceptance: define done as a test, not a demo

Acceptance for an AI system should be a written test set: real inputs from your business, the expected output for each, and the share that must pass. A demo proves the builder can pick good examples. A test set proves the system handles yours.

Write down three things. First, the inputs: 30 to 50 real cases, including the ugly ones (the scanned invoice, the email in two languages, the order with a missing field). Second, what counts as a pass for each, in plain words. Third, what the system must do when it is unsure: stop and ask a human, flag the record, or refuse. A system that says “I don’t know” correctly is worth more than one that guesses well most of the time.

If the contract says “the agent will process invoices”, you have agreed to nothing. If it says “the agent posts these 40 sample invoices correctly and routes every invoice it cannot read to the finance inbox”, you have an acceptance test.

2. Accounts, keys and the model bill

The contract should name whose accounts everything lives on: the code repository, the database, the hosting, and the API keys for the AI model. The answer you want is yours, from day one, with the builder given access during the build and removed after it.

This matters for money as much as control. An AI system has a running cost that a website does not: every call to the model is billed. If the builder holds the API key, you pay that bill through their invoice, with their markup, and you cannot see what each run costs. If you hold the key, the bill comes to you directly and you can rotate the key the day the engagement ends.

Ask for a written estimate of the monthly model cost at your expected volume, and state in the contract who pays it during the build and who pays it after.

3. Model retirement is a scheduled event

The model your system runs on will be retired, on a date its vendor publishes in advance. Anthropic, for example, commits to at least 60 days’ notice before retiring a publicly released model. As of September 2026 its deprecation page shows Claude Opus 4.1 announced for retirement on 5 June 2026 and retired on 5 August 2026, and Claude Sonnet 4 and Opus 4 announced on 14 April 2026 and retired on 15 June 2026.

Sixty days is enough time to migrate, if someone owns the migration. The contract should say who watches the vendor’s notices, who moves the system to the successor model, who reruns the acceptance tests, and who pays for that work. If the build is finished and the builder has left, that is either you, a retainer, or a new fixed-price order. Pick one in writing.

4. Your data: the builder, and the vendor behind the builder

Two parties touch your data during an AI build: the builder, and the model vendor the builder calls. The contract should cover both.

For the builder, write down what data they may access, where copies may live, how long they keep them, and that they delete them at handover. For the vendor, check the vendor’s own business terms and name them in the contract. Anthropic’s Commercial Terms, effective 17 June 2025, say Anthropic may not train models on customer content from its services, and that the customer owns the outputs. Consumer chat products often carry different terms, so the contract should say the build uses business API accounts only.

The US federal standard is stricter than most private contracts. M-25-22 tells agencies to permanently prohibit vendors from using non-public agency data, and the results it produces, to train publicly or commercially available AI without the agency’s explicit consent. A private buyer can ask for the same sentence.

One more line worth reading: the same Anthropic terms cap Anthropic’s liability at the fees paid in the previous 12 months. Your protection sits in your contract with the builder, not in the builder’s contract with the model vendor.

5. Ownership and exit

The contract should assign you the code, prompts, configuration, documentation and data outright, in a signed written assignment, and describe exactly what the handover package contains. We covered the ownership mechanics in the handover test for AI agency builds; the short version is that paying for code does not by itself make you its owner.

M-25-22 lists the protections against vendor lock-in it expects: knowledge transfer, data and model portability, rights to the code and models produced under the contract, and transparent licensing and pricing. That list works as a private checklist too. Add one test of your own: if the builder disappeared tomorrow, could your team, or a different builder, run and change the system using only what the contract says you receive?

6. Change control and the price

AI projects change shape once real data arrives. The contract should say what happens then. The workable answer is that the build continues to the written scope, and anything new becomes a separate written order with its own price and date. We explained why that keeps prices honest in how a fixed price gets fixed.

Watch for the opposite: an hourly contract with a “not to exceed” estimate and no definition of scope. That structure moves every surprise onto your side of the table.

The six terms side by side

Term	What to write down	What goes wrong without it
Acceptance	A test set of real inputs, pass criteria, and the “unsure” behaviour	You accept a demo and discover the edge cases in production
Accounts and keys	Your repo, database, hosting and API keys from day one	The system lives on the builder’s accounts and leaves with them
Model bill	Monthly cost estimate, who pays during and after the build	Usage costs arrive marked up inside someone else’s invoice
Model retirement	Who watches notices, who migrates, who pays	A 60-day notice lands with nobody assigned to it
Data	Access, storage, deletion at handover, business API terms only	Your data sits in places nobody listed
Ownership and exit	Signed assignment, itemised handover package	You paid for a system you cannot legally or practically move

What our contracts say

We publish our terms so you can compare them against this list without a call. A workforce sprint starts from $9,500, fixed before we start, with a written scope covering inputs, outputs, edge cases and what done means. We build on your GitHub, Supabase and Netlify accounts from day one, you hold the API keys, and acceptance is against the written scope. Handover includes documentation, a recorded walkthrough and two weeks of written support. Change is a new written order.

If you do not yet know what the scope should be, that is the job of the AI operations audit: $1,900, fixed, 10 working days, with a full refund if we find nothing worth building. The fee is credited against the build if you go ahead.

We hold ourselves to the same terms we sell. Our own companies run 41 agents in production as of July 2026, each a tomte, our word for one production agent with one defined job, and every one of them runs on accounts the business owns. The agent fleet proof page shows how.

Start with the scope

Describe the process you want built at /start. You get a written reply within one business day, no meeting required, and you can hold our answer up against the six terms above before you commit to anything.