What Should an AI Agent Development Contract Include? A 14-Clause Checklist for 2026

When ChatGPT answers that question, it searches for clause names, for each country's own government guidance, and for four phrases in particular: data ownership, service level agreement, return and deletion, and controller and processor. The law-firm pages it cites, from Mayer Brown and Morgan Lewis, are written for large enterprises and their lawyers. This page is for a company of 20 to 500 people signing its first AI build: a founder, an operations lead or a finance director who has a software development agreement on the desk and wants to know what to add before signing it.

The page covers the 14 clauses, then the two halves of the question most guides skip: how ongoing support can be structured, and which rules change in the US, the UK and Australia.

The 14 clauses at a glance

Read the table as a checklist. The middle column is what the AI contract should say; the right column is the wording that should make you stop and ask a question.

Why a standard software development agreement is not enough

A standard software development agreement (also sold as a software development contract agreement template, form, format, sample or example) handles scope, milestones, payment, warranty and a general IP clause. Those still matter. What it was not written for is software whose behaviour depends on a model you do not control, whose answers vary from run to run, and whose most valuable parts are text files: prompts, instructions and test cases.

Mayer Brown's note of 16 June 2026 on agentic AI integration deals lists eight contract issues: deal structure, performance commitments, technology stack selection, project governance, liability, security and data use, IP rights, and exit. Morgan Lewis, in part 1 and part 2of its 2025 series on AI agent contracts, adds decision-making risk, ownership of outputs, further training, drift and regulatory change. Two practical guides also get cited by AI assistants: Orbilon's eight-clause list of 7 October 2026 and Lucent Innovation's 12-point AI development contract checklist. On Google, LexisNexis's AI agreements checklist and Lexology's "Eight essential clauses for AI contracts" rank for "ai development agreement clauses".

This checklist differs from those in three ways:

1. It compares structures for ongoing support, the half of the data-and-support question the cited pages answer least.
2. It states the default ownership rule in each of the US, the UK and Australia, with the government page that says it.
3. It is written for a first AI build at a 10 to 50 or 50 to 500 person company, with plain sample wording you can hand to your lawyer.

Ownership, asset by asset: who owns the code?

"Who owns the code" is the question buyers ask first, and it is the wrong unit. An AI agent is several assets, and a contract that assigns "the deliverables" can leave half of them unassigned. Mayer Brown's note says the contract should define rights to background IP, company-specific deliverables, custom code, configurations, prompts, evaluation sets and fine-tuned weights. Split it out:

Background tools are the honest exception. Morgan Lewis's November 2024 post on who should own developed IPseparates a supplier's background IP and reusable developer tools from project-specific work, and notes that a customer who owns the bespoke work still needs a licence to anything the supplier brought with it. Expect that split and ask for the licence to be permanent.

Agent output is the newer question. The US Copyright Office's Part 2 report of 29 January 2025concludes that copyright does not extend to purely AI-generated material. So an assignment of "all rights in the output" may convey less than it sounds; protect valuable outputs as confidential information as well.

Data: use, location, return and deletion

Data ownership is the clause buyers assume is covered and often is not. Your company owns its data; the question is what the developer, and every AI provider it plugs in, may do with it. Write four things down.

1. Use.Your data, prompts, outputs, logs and evaluation sets are used only to build and run your agent. Mayer Brown advises that if the expectation is "no training", the contract should say so expressly and require provider tiers, settings and sub-processors that keep that promise.
2. Location. Name the countries or cloud regions where data may be stored and processed, and the sub-processors (the AI provider, the cloud provider, any logging tool).
3. Roles. Under UK GDPR, the ICO defines a controller as the party that determines the purposes and means of processing, and a processor as one that processes personal data on behalf of the controller. When a developer builds your agent on your instructions, it is usually your processor. If it decides for itself to use the data, for example to train its own product, it becomes a controller for that use. The ICO flags that this guidance is under review because of the Data (Use and Access) Act.
4. Return and deletion. The ICO's page on what an Article 28 processor contract must includesays that at the end the processor must, at the controller's choice, delete or return all the personal data, and delete existing copies unless the law requires storage. For an AI agent, "every copy" means databases, vector stores (the search index an agent reads from), logs, backups and test sets.

Those Article 28 minimum terms are what a data processing agreement holds: processing only on documented instructions, confidentiality, security, sub-processors, data subject rights, assistance to the controller, end-of-contract deletion or return, and audits. Buyers covered by GDPR need them in writing; US and Australian buyers lose nothing by using the same list.

The 30 days in the sample is a placeholder for you and your lawyer to set; it is not a legal requirement.

Accounts and API keys in your name

This clause is short and protects more than any other. If the AI provider account (OpenAI, Anthropic, Google), the cloud account (AWS, Azure, Google Cloud) and the code repository sit in your company's name, three things follow. You see every bill directly. You decide who has access. And if the relationship ends, the agent keeps running while you choose what happens next. The developer works inside your accounts with named logins you can remove. Ask for the account list as a schedule to the contract, with the owner of each one.

Model changes: what happens when OpenAI, Anthropic or Google retires a model

Your agent runs on a model you rent, and the provider can retire it. The notice period is set by the provider, not by your developer, so the contract has to say what happens inside that window. These are the published minimums as we read them on 18 October 2026:

OpenAI also states that it may retire a model sooner if safety or compliance concerns require it. Anthropic notes that partner platforms such as Amazon Bedrock and Google Cloud set their own schedules. So the model clause should cover four points: who watches for deprecation notices, who moves the agent to the replacement, who reruns the evaluation set before the switch, and who pays for that work. Add a line on repricing too: if a provider changes its price or its data terms, Mayer Brown suggests the contract give you migration rights. Avoid preview models for anything a customer depends on.

Acceptance criteria for answers that are never the same twice

Ordinary software is accepted when it does the same right thing every time. An AI agent can answer the same question two ways. Mayer Brown puts it plainly: a single successful test is not enough, and acceptance should rest on statistical performance against an agreed evaluation set. In practice:

1. Collect 50 to 200 real past cases from your own records: emails, orders, tickets, invoices.
2. Write down the correct result for each, signed off by the person who does that job today.
3. Agree the pass rate before the build starts, and list the errors that fail the build outright (a wrong price, a refund to the wrong account).
4. Run the set at handover and after every model change, and keep the results.
5. Name who on your side signs acceptance. Never the developer alone.

Weak acceptance terms are one of the patterns behind stalled projects; we cover the others in why AI agent projects fail, and the path from a test to live use in AI proof of concept to production.

Security, human approval and audit logs

An agent that can read your systems and act in them needs security terms written for agents. Mayer Brown lists least-privilege access, credential management, approval gates for privileged actions, tool-use logging, human review thresholds for high-risk actions, and testing against prompt injection and data poisoning. Morgan Lewis part 2 describes three newer rights: a customer kill switch to suspend the agent even if the vendor disagrees, shadow-mode running alongside staff before the agent touches live decisions, and retraining windows when behaviour drifts.

For a mid-sized company, five lines cover most of it:

• The agent gets only the access its job needs, through accounts you can switch off.
• Named actions (payments, refunds, price changes, anything sent to a customer as binding) wait for a person to approve.
• Every action is logged, and you can read and export the log.
• The developer tells you about a security incident within an agreed time, and names its sub-processors.
• You can pause the agent at any time.

The NIST AI Risk Management Framework, released 26 January 2023 for voluntary use, and its Generative AI Profile of 26 July 2024 give your team a shared vocabulary for these risks. Our AI agent security guide and AI governance policy for mid-sized companies turn them into controls.

Liability and indemnity

Mayer Brown's suggested principle is to align responsibility with control: the party that makes a decision carries more of the risk for it. If you insist on a model the developer advised against, expect relief for the developer when that model fails. If the developer chose the stack and designed the workflow, it should stand behind the result where better design or monitoring would have prevented the harm. The note also warns that caps set as a multiple of fees can be small next to the harm an agent acting at speed could cause, and that traditional IP indemnities may not cover claims arising from what an agent does. Two practical asks: caps that apply to both sides, and an indemnity for third-party IP claims on the code delivered to you.

On the US side, the FTC's Operation AI Comply announcement of 25 September 2024quoted Chair Lina M. Khan: "there is no AI exemption from the laws on the books." That applies to what your agent tells your customers. Keep claims about the agent in your own marketing as careful as any other claim.

Ongoing support: four ways to structure it

Half of the buyer question is about support after launch, and it is the half the ranking pages say least about. Mayer Brown separates primary support (the developer runs, monitors and adapts the agent) from secondary support (the developer trains your team and handles escalations). Inside either, payment usually takes one of four shapes:

1. A standing monthly support plan. A set amount each month for an agreed scope of monitoring and changes.
2. Hourly billing per change. You ask for a change and pay for the hours it takes.
3. Each change quoted and approved. The developer describes and prices each change in writing; work starts only after you approve it.
4. AI and cloud bills passed through at cost. AI provider and cloud bills sit in your own accounts and you pay the providers directly, with no markup, whichever of the three above you choose for the people time.

Whatever you pick, two lines belong in every AI contract. First, a defect cover period after launch, agreed before work starts, during which bugs in the delivered work are fixed inside the build price. Second, the right to change structure later: many companies start with changes quoted one by one and move to a monthly plan once they know their pace. A monthly minimum that starts before the agent is live is the term to question.

One example of the third and fourth structures together is how we work, set out in full in the FactoryJet section below. For a wider view of who should run the agent after launch, see AI agency vs in-house vs freelancer and our AI agent monitoring service.

Service levels: what an AI service level agreement can and cannot promise

An AI service level agreement can promise what the developer controls: how fast someone responds, how fast a fix lands, and how often the agent is checked against your test set. It cannot honestly promise that every answer will be correct. Morgan Lewis part 1 describes contracts that commit to response times for critical errors while avoiding guarantees of specific outcomes; part 2 adds monitoring for outputs that drift away from expected results, with a duty to pause or fix the agent even when it is technically up.

A workable AI SLA has five parts:

1. Severity levels defined by business effect: agent down, agent wrong on money or customers, agent slow, cosmetic.
2. A response time and a fix or workaround time for each level, set with your lawyer.
3. An accuracy check against the evaluation set on a fixed schedule, with results shared with you.
4. A named person on each side and a path for escalation.
5. Your right to pause the agent, and what happens to the work it was doing while paused.

Exit and handover

Mayer Brown notes that the operating knowledge of an agent lives in prompts, configurations, orchestration logic, evaluation sets, monitoring rules, runbooks and integration documents, and that without clear terms a company can find at exit that it lacks what it needs to run the agent. Its advice is to negotiate exit rights at signing, while you have the most bargaining power. The handover list:

1. The code repository, transferred to your account with its full history.
2. Prompts, system instructions and agent configurations.
3. The evaluation set and the latest test results.
4. Architecture notes, runbooks and support procedures in plain language.
5. A list of every account, API key and sub-processor, with keys rotated on the last day.
6. A data export in a format named in the contract (for example CSV or JSON), plus logs.
7. A transition period during which the developer answers questions from you or your next provider.

US, UK and Australia: the rules that change the contract

The ownership default is the rule that most surprises buyers, and it differs by country. In all three, the fix is the same: a written assignment in the agreement for software development.

United States

Circular 30 says a specially ordered or commissioned work is made for hire only if all four tests are met: it falls in one of nine categories (such as a contribution to a collective work, a translation, a compilation or a test), there is a written agreement, it expressly says the work is made for hire, and all parties sign it. If any test fails, it is not a work made for hire. Code written by your own employees within their regular duties is treated differently. For an outside developer, ask for an assignment of copyright in addition to any work-for-hire label.

United Kingdom

The UK IPOsays that when you commission someone to create a copyright work, "the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing". It adds that courts may find an implied licence where the contract is silent, which does not necessarily transfer ownership. On data, the ICO pages above set the controller, processor and Article 28 rules; check both for updates under the Data (Use and Access) Act. See our AI agents for UK businesses page for how we work with UK teams.

Australia

business.gov.au says that under IP laws the contractor automatically owns any IP they create, and if the hirer wants to own it, the contract must state this. On privacy, the OAIC's guidance on commercially available AI products (published 21 October 2024) says privacy obligations apply to personal information put into an AI system and to output that contains it, and asks businesses to check whether the product was tested for the use, how human oversight is built in, and who can access the data. As best practice it recommends not entering personal information, particularly sensitive information, into publicly available generative AI tools. More on hiring in Australia in hiring AI developers in Australia and on our AI agents for Australian businesses page.

Eight clauses to refuse

Each of these is common in an AI vendor contract, and each one shifts a risk onto you that the developer is better placed to carry, or removes a right you will need later.

1. The vendor owns the prompts. They encode how your business works. Ask for ownership or a permanent licence.
2. Your data can train their product. Replace "to improve our services" with an express no-training promise.
3. API keys only in their account. You lose control of access and of the bills.
4. A monthly minimum before go-live. You pay for support on something that does not run yet.
5. No exit clause. Without a handover list, leaving means starting again.
6. Acceptance "at the vendor's discretion". Acceptance should rest on your test set and your sign-off.
7. Liability caps that protect only them. Caps and exclusions should apply to both sides.
8. Automatic renewal without notice. Ask for written notice before any renewal and a simple way to end it.

For the questions to ask before the contract stage, see questions to ask an AI development company and how to hire an AI agent developer.

The one-page checklist: 14 yes or no questions

Print this and answer each line against the draft contract. Every "no" is a question for the developer.

1. Is the code and repository assigned to us in writing?
2. Are the prompts, instructions and evaluation set ours, or permanently licensed to us?
3. Does the contract forbid training on our data, prompts, outputs and logs?
4. Does it require return or deletion of every copy at the end, with written confirmation?
5. Are the AI provider, cloud and repository accounts in our company name?
6. Does it say who moves the agent to a new model, who retests, and who pays?
7. Is acceptance based on an agreed test set and pass rate, signed off by us?
8. Are sub-processors named, and is there an incident notice time?
9. Are human approval steps and audit logs written in for named actions?
10. Do liability caps and indemnities work for both sides?
11. Is the support structure named, with a defect cover period agreed before work starts?
12. Is every change described, quoted and approved in writing before work begins?
13. Is there a handover list, a transition period and a data export format?
14. Is the governing law one we can live with?

How FactoryJet's contracts handle this

We design, build and support custom AI agents, including integrations with Odoo, NetSuite, SAP Business One, ERPNext, Salesforce, HubSpot, Xero and WhatsApp. Our standard terms answer most of the checklist above:

• You own the code and the repository from day one.
• The AI and cloud accounts can run in your own name, at cost, with no markup.
• Defects are fixed inside the build price for a cover period we agree before work starts.
• Support is optional: each change is quoted and approved before we start it, and there is no monthly minimum.
• Each phase is scoped, priced and signed on its own.
• We show working software on your own data before you sign.

If you would rather not run it yourselves, we can keep managing the servers, AI models and APIs so your team does not have to. FactoryJet quotes a fixed price in writing after a short scoping call. See AI agent development and AI consulting. If you are still weighing build cost, read what an enterprise AI agent costs and AI MVP development cost.

Sources

Pages opened and read on 18 October 2026.

• Mayer Brown, Key Contract Issues in Agentic AI Implementation and Integration Deals (16 June 2026)
• Morgan Lewis, Contracts for AI Agent Development and Implementation, Part 1 (September 2025)
• Morgan Lewis, Contracts for AI Agent Development and Implementation, Part 2 (October 2025)
• Morgan Lewis, Service Agreements: Who Should Own Developed Intellectual Property? (November 2024)
• US Copyright Office, Circular 30: Works Made for Hire
• US Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (29 January 2025)
• UK Intellectual Property Office, Ownership of copyright works
• ICO, What are controllers and processors?
• ICO, What needs to be included in the contract?
• business.gov.au, Prepare a contract
• OAIC, Guidance on privacy and the use of commercially available AI products (21 October 2024)
• FTC, FTC Announces Crackdown on Deceptive AI Claims and Schemes (25 September 2024)
• NIST, AI Risk Management Framework
• OpenAI, Deprecations; Anthropic, Model deprecations; Google Cloud, Model versions and lifecycle
• Orbilon, AI Development Contract: 8 Clauses B2B Buyers Need (7 October 2026); Lucent Innovation, AI development contract checklist
• Our own research: Google results, People Also Ask and keyword volumes for the US, UK and Australia (DataForSEO), and 36 buyer questions across five AI assistants, all on 18 October 2026

This is a buyer's checklist, not legal advice. Have a lawyer in your country review the contract.