AI project statement of work: a template and checklist

A services contract between two companies usually comes in two layers. The master services agreement (MSA) holds the legal terms that apply to every piece of work: liability, confidentiality, insurance, payment terms and termination. Each statement of work (SOW) then describes one project under it: what gets built, by when, for how much, and how you will decide it is done. You negotiate the MSA once and sign a new SOW for each project.

The AI-specific terms can live in either, and I would split them by how often they change. Rules that hold for every project, such as whether the supplier may train models on your data, belong in the MSA or a data addendum to it. Anything that depends on this project, such as the test cases, the pass thresholds and the model in use, belongs in the SOW. If you have no MSA yet, the template below still works as a project document, but your counsel will need to put the legal terms around it.

A software SOW assumes that once a feature is specified, you can test whether it works: the form either saves the record or it does not. An AI system gives you a spread of results instead. It will be right on many cases and wrong on some, and the mix moves when the data, the prompt or the model changes. That changes three parts of the document.

Acceptance becomes a measurement. You agree a set of real cases and a pass rate before the work starts, and the system passes or fails against them. US federal buying has asked for this shape for a long time: the Federal Acquisition Regulation (FAR) tells agencies, where practicable, to describe work by the results required rather than by how it is done or the hours spent, and to assess it against measurable performance standards [1]. A 2025 memorandum from the White House Office of Management and Budget (OMB) on how federal agencies buy AI goes further. It tells agencies to run independent evaluations on data the vendor cannot access, and encourages them to require vendors to meet performance standards before deploying a new version, or to roll back to the previous one [2].

Your data needs its own terms. The supplier needs it to build and test the system, so the SOW should say which data, through what access, for what use, for how long, and what happens to it at the end. The same memorandum tells agencies to write into their contracts a permanent prohibition on using their non-public data to train publicly or commercially available AI, absent explicit consent [2]. A private company can ask for the same.

And the system depends on a model that someone else controls. Providers release new versions and retire old ones on their own timetable, so the SOW should name the model and provider in use, say who is told before either changes, and treat a change as something that reruns the acceptance tests.

Copy it into your own document, delete what does not apply and fill in the brackets. The sections after it explain the parts that decide most disputes. It is a starting point for your counsel, not a finished contract.

Scope sections fail in a predictable way. They list activities, such as design, build and test an AI assistant, instead of results, so a supplier can do all of them and still hand over nothing you can use. Write the objective as the change you want in a piece of work you can measure, with today's baseline beside it, so everyone can see whether it moved. It is the rule the FAR sets for performance-based federal contracts: describe the results required, not the method or the hours [1].

Be just as specific about what is out of scope. Adjacent workflows, extra user groups, other languages and integrations with systems nobody named are where the arguments start. The customer responsibilities matter as much, because access, data and a process owner's time set the pace of an AI project far more often than the engineering does. A date against each one makes a delay visible, and shows whose it was.

List deliverables as things you can open or run: a working system in a named environment, a test suite, a runbook. Say that they live in your repositories and your accounts from the first commit, because moving them at the end is slow and tends to go badly.

This is the section I would spend the most time on. An AI deliverable is accepted against a test set: real cases, chosen by your process owner, with the right outcome already agreed for each. Set the pass threshold before anyone sees a score. Set it afterwards and it tends to land wherever the scores did.

Keep part of the test set back. OMB tells federal agencies to run independent evaluations on data the vendor cannot access, as close as possible to the data the system will meet in use [2]. The logic holds for a private buyer too: if the supplier has tuned against every case you hold, a pass tells you less than it appears to. The AI Risk Management Framework from the National Institute of Standards and Technology (NIST) asks for test sets, metrics and the tools used in testing to be documented [3], which is what lets someone rerun the result after the supplier has gone.

Measure two things. One is how well the system does its task. The other is whether the work improved: time per case, error rate, or how often reviewers override the output. A system can score well on the first and still be ignored by the people meant to use it. An acceptance line can be as plain as this, with your own numbers in the brackets: the system proposes the correct [field] for at least [X]% of the [N] cases in the acceptance test set, and sends every case it is less sure of than [threshold] to a reviewer.

Then write down what happens on a fail: a fix and a retest, a limit on the number of rounds, and a remedy after the last one. Without that, a failed test turns into a negotiation. For actions with consequences, put the approval step in the SOW as well; the pattern where the model proposes and a deterministic check decides is one way to build it.

Name every data source, how the supplier reaches it and in which environment. Limit use to the project, and say in plain words that your data, prompts and outputs will not be used to train or improve any model or product outside it without your written consent: the term OMB tells federal agencies to write in [2]. Set a retention period, and ask for deletion to be confirmed in writing at the end.

Regulated data brings its own agreement. If your company is a covered entity under the Health Insurance Portability and Accountability Act (HIPAA) and the supplier will create, receive, maintain or transmit protected health information on your behalf, HIPAA requires its assurances to be documented in a written contract or other written arrangement that meets the business associate requirements [8]. If your company is a financial institution within the jurisdiction of the Federal Trade Commission (FTC), the FTC's Safeguards Rule requires you to choose service providers able to protect customer information, to require those safeguards by contract, and to assess the providers periodically [7]. Neither agreement belongs inside a SOW. The SOW's job is to flag the data and make signing the right agreement a condition of access. This is not legal advice.

For models, name the model and provider in use, and keep the accounts and keys in your company's name. A provider can change or retire a model version on its own schedule, so treat a model change as a release: notice first, the acceptance tests rerun before it goes live, and a way back to the previous version. OMB's memorandum lists the same three as terms for federal agencies to consider: notice before new AI features are added, performance standards met before a new version is deployed, and a roll-back if it falls short [2].

Under US copyright law, copyright belongs first to the author of a work, and a transfer of ownership is only valid in writing, signed by the owner or their authorised agent [6]. A supplier's code is the supplier's until they sign it over. The work-made-for-hire label does less than many buyers expect: for work by someone who is not your employee, it covers only nine listed kinds of commissioned work, and only with a signed written agreement, and software is not named among them [5]. So ask for an express written assignment, and list what it covers: source code, prompts, configuration, evaluation sets, infrastructure definitions and documentation, not only software.

Material generated by AI adds a complication. The US Copyright Office concluded in January 2025 that copyright does not extend to purely AI-generated material, or to material where there is not enough human control over the expressive elements, and that prompts alone do not currently provide that control [4]. Work made with AI help is still protected where a person's contribution is enough, which the Office says is decided case by case [4]. The practical consequence for a SOW: an assignment passes on whatever rights exist. So also ask the supplier to say which AI tools it used, to list third-party and open-source components with their licences, and to confirm that you may use, change and run everything delivered. NIST's framework asks organisations to have policies for AI risks from third parties, including the risk of infringing someone else's intellectual property [3]. This is not legal advice.

AI projects change scope more than most, because the first results teach you something about the problem. That is healthy if it goes through a change order: a written request, the supplier's statement of what it does to fees, schedule and acceptance criteria, and both signatures before the work starts. A change agreed on a call and never written down is how a fixed-scope project quietly becomes an open-ended one.

Write the handover as a test. The pack holds a runbook, an architecture overview, a dated decision log, documentation of the data, models and prompts, the evaluation suite and the list of third-party components. Then one of your engineers deploys a change without the supplier's help. OMB counts knowledge transfer, data and model portability, and rights to the code and models produced under a contract among the protections against vendor lock-in [2]. If your own team cannot ship that change, the handover has not happened, whatever the pack says.

For IT operations work, write the order of handover into the scope as well: the agent suggests before it acts, and fixes that change systems come later, once they have passed review. Our guide to AI for IT operations sets out that order.

Read the draft against these ten lines. Any line the SOW does not answer is a question for the supplier before signature, not after.

A fixed-scope engagement at 1AYM is written as a statement of work with defined outputs, a defined price and acceptance criteria, much like the template above. We take small fixed-scope statements of work as well as larger builds, and work can start within a day of the scope being signed. Where the contract needs it, copyright in the deliverables is assigned to you, and US clients can contract through 1AYM's US entity.

If you cannot yet write the objective or the acceptance tests, that is what our AI opportunity and feasibility sprint is for: typically two to four weeks, ending in a scope you can put in a SOW. A fixed-scope architecture and production build then delivers it. Depending on the scope, the SOW names the evaluation suite, human review points and handover pack as deliverables. If you already have a scoped job and need people to deliver it, we can resource it with embedded engineers on contract, drawn from the collective of associates who work with 1AYM and held to the same standard. On the 30-minute call, your account manager will go through your draft SOW, from any supplier. That is a working read, not a legal review.