What a general-purpose template leaves out
A software statement of work assumes the deliverable is determinate. You describe a screen, a service, an interface, and either it does what the paragraph says or it does not. An AI deliverable is statistical. It is right most of the time and wrong some of the time, and the whole commercial question is where that line sits and who gets to say so. A template with sections for scope, tasks, deliverables, schedule, and payment has nowhere to record that. So the number ends up in a slide deck, the test set ends up on the vendor's laptop, and eleven months later two reasonable parties disagree about whether the thing works.
The fix is not a longer document. It is about eight added paragraphs, each answering a question that only arises because the system learns. What is the number. On what data is it measured. Who holds that data. What is it compared against. Who owns the model afterward. What may the vendor do with what you fed it. What happens when the underlying model changes. And what happens when the output is wrong in front of a real person.
Federal buyers have a head start, because the government wrote these questions down. OMB Memorandum M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government, issued April 3, 2025, rescinded and replaced M-24-18 and told agencies which terms must appear in an AI contract. Its companion, M-25-21, sets minimum risk management practices for what it calls high-impact AI. Neither binds a commercial buyer, and both are the best free checklist a commercial buyer will find.
Pick the instrument before you write the scope
The first decision is not a clause. It is which document you are writing. The choice matters more on AI work than almost anywhere else, because the buyer usually knows the outcome it wants and not the method that will get there.
FAR 37.601 requires performance-based contracts to include a performance work statement and measurable performance standards, and lets a solicitation use either a performance work statement or a statement of objectives. FAR 37.602 says agencies should describe work in terms of required results rather than how the work is done or how many hours it takes, and lists the minimum contents of a statement of objectives: purpose, scope or mission, period and place of performance, background, performance objectives, and operating constraints. One detail catches people out. A statement of objectives does not become part of the contract; the performance work statement the vendor writes in response does.
M-25-22 pushes agencies toward that shape, naming both documents as preferred techniques because they avoid what it calls unnecessary or overly-limiting requirements in statements of work, and pairing them with a quality assurance surveillance plan. For a first-time buyer the advice reduces to this: describe the outcome and the acceptance test precisely, and let the vendor own the architecture.
| Instrument | Who writes the method | Best fit for AI work |
|---|---|---|
| Statement of work | The buyer specifies tasks and often the approach | Weakest fit. Locks in a method before anyone has seen the data, and every architecture change becomes a modification |
| Performance work statement | Buyer states required results and measurable standards; method is the vendor's | Strong fit when the buyer already knows the metric and the threshold |
| Statement of objectives | Buyer states objectives and constraints; offerors propose the performance work statement | Strong fit when the buyer knows the outcome but not the achievable number. Note it does not become part of the contract |
| Quality assurance surveillance plan | Buyer, often negotiated | The companion document, and where the measurement cadence actually lives |
An objective is a metric, a test set, and a threshold
Write the acceptance sentence before anything else in the document, because everything else is downstream of it. It has four parts and none are optional: the metric, the population it is measured over, the threshold, and the consequence of missing it.
"Improve document processing accuracy" is not an objective. "Field-level exact-match accuracy of at least 92 percent across the fourteen extracted fields, measured over a stratified sample of 1,000 held-out documents, with the second milestone payment contingent on the measured result" is an objective. It is also a sentence a stranger can execute without calling either party. That is the test: hand the paragraph to somebody who was not in the room and see whether they can run it.
Pick the metric that matches the cost of being wrong, not the one that looks best. If a false positive costs an analyst ten seconds and a false negative costs a missed case, accuracy is the wrong headline and you want precision and recall reported separately at a stated operating point.
Then name the baseline. A number with nothing beside it is unreadable. Ninety-two percent is excellent if the current process runs at seventy and unremarkable if it runs at ninety-four. Write the current-state number in as a measured fact, or make measuring it the vendor's first deliverable. M-25-22 makes the same point from the agency side: before setting performance incentives, agencies are told to consider whether they can adequately measure baseline performance at all.
The evaluation set is yours, and the vendor should not hold it
This is the most common defect in a first AI scope and the cheapest to fix. If the vendor selects, holds, and scores the test data, the acceptance number is a self-report. Nobody has to act in bad faith for that to go wrong. Ordinary development pressure is enough: a hard batch gets called out of distribution, an ambiguous label gets corrected, and the reported number drifts up while field performance stays flat.
The federal rule here is unusually blunt. M-25-22 requires agencies to use data they have defined when running independent evaluations, says that data should not be accessible to the vendor, and says it should be as similar as possible to what the system sees in deployment. Where the vendor runs the test instead, the memo requires results detailed enough to be independently verified or reproduced, and bars contract terms that would stop the agency from internally disclosing how the vendor tests or what the results were.
In a commercial scope three sentences carry the same weight. The buyer selects and holds the evaluation set. The vendor does not receive it before the acceptance run. Acceptance means executing the delivered system against that set in a session both parties attend, with the script and the raw outputs retained.
Data access is the schedule
AI projects do not slip because the modeling is hard. They slip because the data arrives in month four of a six-month engagement. The scope has to treat access as a dated obligation of the buyer, not a background assumption, and it has to name a person.
Four lines cover it. The data owner, by name and title, who can authorize the transfer. The date the environment and credentials are available. The form of the transfer: the system, the extract format, the volume. And the consequence of a miss, usually an equitable adjustment to schedule and sometimes to price. Write that last one plainly. A vendor who has to absorb a two-month access delay silently prices the risk into the bid, and you pay for it whether or not the delay happens.
Say the security level out loud in the same section. Whether the data is controlled unclassified information, whether it carries personal or health information, whether inference may cross a network boundary, and whether anything may reach a commercial API endpoint. If the answer to the last one is no, say it here rather than in legal review, because it changes the architecture and therefore the price.
Three assets, three different rights conversations
Buyers tend to write one intellectual property paragraph. An AI engagement produces several assets that behave differently, and lumping them together is how a buyer ends up owning a folder of code it cannot run and a model it cannot move.
| Asset | What gets contested | What to write |
|---|---|---|
| Input data and labels | Labels you paid to create are frequently treated as vendor work product and kept | Buyer owns the corpus and every annotation produced under the contract, delivered in a stated format on a stated date |
| Model, weights, and training code | A fine-tuned model built on your data can be positioned as the vendor's platform | Name the delivery: weights, training and inference code, environment definition, and the configuration needed to reproduce the accepted result |
| Outputs and derived data | Predictions, embeddings, and telemetry accumulate value and are rarely mentioned | Buyer owns outputs and derived artifacts, including embeddings and indexes built from buyer data |
| Evaluation harness and results | The scoring code leaves with the vendor and cannot be rerun next year | Harness, test scripts, and result logs are deliverables, not internal tooling |
| Documentation | Delivered as a slide deck rather than something a successor can act on | Model and data documentation sufficient for another engineer to operate, monitor, and retrain |
Federal buyers work inside a fixed license framework rather than a negotiation. Under FAR 52.227-14, Rights in Data—General, the Government takes unlimited rights in data first produced in performance of the contract. On the defense side, DFARS 252.227-7014, retitled in its August 2025 revision as Rights in Other Than Commercial Computer Software and Other Than Commercial Computer Software Documentation, sets the familiar ladder: unlimited rights for software developed exclusively with government funds, government purpose rights for mixed funding that run five years by default before converting to unlimited, and restricted rights for software developed entirely at private expense.
The trap sits in FAR 12.211 and 12.212. For commercial products the Government acquires only the data and rights customarily provided to the public. If a vendor delivers a fine-tuned model as a commercial item, the buyer may get a license and nothing more. That can be the right answer. It should be a decision taken in writing, not a surprise found in an addendum.
Say what the vendor may not do with your data
The clause missing from nearly every first draft restricts what the vendor may do with the material you hand over. It has the longest tail of any clause in the document, because a model trained on your corpus outlives the engagement.
A permanent prohibition, not a term-limited one
M-25-22 directs agency processes to ensure contracts "permanently prohibit the use of non-public inputted agency data and outputted results to further train publicly or commercially available AI algorithms," consistent with applicable law, absent explicit agency consent. Three details make it work: it is permanent rather than tied to the contract term, it covers outputs as well as inputs, and consent has to be explicit rather than assumed from silence.
Commercial buyers can lift that sentence almost verbatim, then extend it one step: name the subprocessors. If the vendor calls a third-party model API, buyer data is crossing a boundary into a company that never signed the contract. Require the list, require notice before it changes, and require the training prohibition to flow down. A vendor who cannot tell you which model providers touch your data does not yet know its own architecture.
Retention belongs in the same paragraph: how long the vendor may hold buyer data, what gets deleted, what gets returned, and what evidence of deletion looks like. M-25-22 has agencies retain data only when reasonably necessary to serve the purposes of the contract, which is a good commercial default too.
The model underneath will change during the period of performance
A conventional software subcontract can assume its dependencies hold still. An AI engagement built on a third-party foundation model cannot. Providers deprecate versions, retire endpoints, change safety filters, adjust prices, and ship new default behavior. Any of that can move your measured number after acceptance, and none of it is the vendor's fault.
Four clauses handle it. Pin the version, so the accepted result is tied to a named model version and a substitution requires re-running the acceptance test. Require notice before a change, which M-25-22 addresses by having agencies consider requiring vendors to notify stakeholders before integrating new AI enhancements, features, or components into a delivered system. Require a rollback: the memo encourages agencies to make vendors meet performance standards before deploying a new version, or return to the previous one if the new version fails. And state who pays for the re-test, because that is the argument you are actually preventing. On a long engagement, add a line for what happens when per-call pricing from a provider outside the contract moves in either direction.
Human oversight, and the path for a wrong answer
Every AI system in a real workflow is eventually wrong about a specific person on a specific day, and the scope should already say what happens next. The minimum practices for high-impact AI in M-25-21 are the clearest published list, written as verbs a contract can attach to.
- Conduct pre-deployment testing with risk mitigation plans reflecting expected real-world outcomes. Where the buyer cannot see the source code, model, or training data, the memo expects alternatives: query the service and observe outputs, or supply evaluation data and obtain results.
- Complete an impact assessment covering intended purpose and expected benefit, the quality and fitness of the data, potential impacts, a reassessment schedule, costs, an independent review by someone not involved in development, and a signature accepting the risk.
- Conduct ongoing monitoring for performance and adverse impacts, designed to catch changes to the system after deployment and changes in the context of use or the underlying data.
- Ensure adequate human training and assessment so the people reading the output can interpret it and manage the risk, refreshed periodically and specific to the system in use.
- Provide human oversight, intervention, and accountability, including a fail-safe that limits the risk of significant harm where practicable.
- Offer consistent remedies or appeals, giving an affected person timely human review and a chance to contest a negative outcome.
- Consult and incorporate feedback from end users and the public, and use it in decisions about the system.
The memo reserves those practices for high-impact AI: output that is a principal basis for decisions with legal, material, binding, or significant effect on civil rights and privacy, on access to education, housing, insurance, credit or employment, on health and safety, on critical infrastructure, or on strategic assets. A commercial buyer can use that list as a triage question, because it describes the deals where a wrong answer becomes a legal problem rather than a support ticket.
Monitoring after acceptance is a clause, not a hope
Model performance decays because the world moves. New document formats appear, a policy change shifts the mix of cases, a season changes the inputs. A scope that ends at acceptance has bought a snapshot. M-25-22 requires contract terms giving the agency the ability to regularly monitor and evaluate performance, risks, and effectiveness, suggests a quarterly or biannual cadence based on the program's needs, and requires contracts to detail the vendor's examination, testing, and validation procedures.
Borrow that structure, then decide who retrains. If drift is the vendor's obligation, the engagement is longer and costs more, and the buyer needs a support agreement rather than a project. If it is the buyer's obligation, the training pipeline, the harness, and the documentation become acceptance-blocking deliverables, because without them the obligation cannot be met.
Acceptance: what done means, and who says it
Acceptance is where an AI engagement either closes cleanly or turns into a negotiation. In federal contracting the roles are set: FAR 46.501 describes acceptance as acknowledgment that supplies or services conform with contract quality and quantity requirements, and FAR 46.502 makes acceptance the contracting officer's responsibility, delegable to a contract administration office. It may occur before, at, or after delivery depending on the contract terms.
Commercial scopes have no contracting officer, so name the equivalent. One person accepts. One person can approve a change. If either is a committee, the engagement stalls at the end and the vendor carries unpaid weeks it never priced.
Then write the acceptance procedure as a procedure. The buyer supplies the held-out set. The delivered artifacts run against it, in the buyer's environment where possible. The result is compared to the threshold in the objective sentence. Both parties sign the result log. If the threshold is missed, the scope already says what happens: a cure period, a stated number of re-tests, and a stated outcome if the number still is not reached. A partial-credit ladder is often more honest than pass-fail on a first engagement, and it keeps a vendor working the hard last few points instead of arguing about the test.
Write the exit before you sign
The moment to negotiate the exit is before award, when the vendor wants the work. Afterward the cost of leaving is whatever the vendor says it is.
M-25-22 treats this as a competition problem and lists what agencies should ask for: knowledge transfer, data and model portability practices, clear licensing terms, pricing transparency, and rights to code and models produced under the contract. At closeout it directs agencies to settle ongoing rights and access to any data or derived products, including the format of that data and a plan for transferring it, and to set sunset criteria so a change in cost, need, or measured performance becomes a defined trigger rather than an argument.
A commercial exit package is short and specific: weights and code in a stated format, the harness and the last result log, the documentation, the labeled data, an export of derived artifacts, and a fixed number of transition hours at a rate agreed now. Price it in the original scope. It costs very little at signature and a great deal at divorce.
Where the rules are moving, and how to write around that
Three of the frameworks a first-time buyer gets pointed at are in motion, and a scope that hard-codes a date is a scope that will be wrong.
The EU AI Act. The regulation entered into force on 1 August 2024, prohibitions applied from 2 February 2025, and general-purpose model and governance obligations from 2 August 2025. The high-risk timeline has since been amended. The European Commission's regulatory framework page describes an AI Omnibus in force from 27 July 2026 that moves obligations for several Annex III high-risk areas, including biometrics, critical infrastructure, education, employment, and border control, to 2 December 2027, with AI embedded in regulated products following on 2 August 2028. Confirm the operative text at signature rather than citing a date from memory.
NIST. The AI Risk Management Framework remains NIST AI 100-1, published 26 January 2023, organized around Govern, Map, Measure, and Manage, with the Generative AI Profile issued as NIST AI 600-1 on 26 July 2024. NIST has said the framework is being revised under the federal AI action plan. Cite it by name and function rather than paragraph number, so a revision does not break your clause.
The FAR. The acquisition regulation overhaul has been running through agency class deviations, with OMB advancing formal publication of the changes. Part numbering and clause text are moving in places, so check the deviation text your contracting activity is using. The substance cited here has not changed.
The order to draft it in
Most first-time AI scopes are written front to back, which puts the acceptance criteria last and starves them. Invert it.
Drafting order for an AI scope
What to strike from a vendor's draft
Accuracy stated without a population. A percentage with no test set behind it is a marketing number in a contract font. Send it back with one question: measured on what.
A license to use buyer data to improve the vendor's services. This is the sentence that lets your corpus become someone else's product. It usually sits as one line inside a longer paragraph about service improvement.
Acceptance deemed to occur after N days of silence. Deemed acceptance shifts the burden of running the test onto the buyer at the moment the buyer is busiest. Replace it with a scheduled acceptance session.
Weights described as vendor background intellectual property when they were fine-tuned on buyer data. Base model, fine-tuned artifact, and inference wrapper are three things. Say which is which in the deliverable list.
Any clause restricting the buyer from circulating test results internally. M-25-22 forbids this for agencies, and a result you cannot circulate is a result you cannot act on.
Bottom line
An AI statement of work is a normal statement of work plus a measurement regime, and the measurement regime is small. One objective sentence with a real metric and threshold. One baseline. One held-out set the vendor never touches. One acceptance procedure both parties execute together. One rights split across five artifacts. One prohibition on training with your data. One version-control clause. One monitoring cadence. One exit package priced at signature. Everything else is ordinary contracting, and every remaining paragraph only describes how the vendor reaches a number that is already written down.
Frequently asked questions
The buyer. M-25-22 directs agencies to use data they have defined for independent evaluation, says that data should not be accessible to the vendor, and says it should be as similar as possible to what the system sees in deployment. Where the vendor runs the test instead, the memo requires results detailed enough to be independently verified or reproduced, and prohibits terms that stop the agency from internally disclosing how the testing was done or what it found.
Only if the contract says so. M-25-22 directs agency processes to ensure contracts permanently prohibit using non-public inputted agency data and outputted results to further train publicly or commercially available AI algorithms without explicit agency consent. Commercial buyers can use the same wording, and should extend it to any third-party model provider the vendor calls, with those providers named and notice required before the list changes.
Whatever the deliverable list names, split across five artifacts: input data and labels, model weights and training code, outputs and derived data such as embeddings and indexes, the evaluation harness and its result logs, and documentation. Federal buyers work inside FAR 52.227-14 and, for defense work, the DFARS ladder in 252.227-7014, where government purpose rights on mixed-funded software run five years by default before converting to unlimited. For anything delivered as a commercial item, FAR 12.211 and 12.212 limit the Government to what is customarily provided to the public.
Pin the accepted result to a named model version, require notice before the vendor integrates new AI features or components, require a new version to meet the performance standard before deployment or roll back to the prior one, and state who pays to re-run the acceptance test. M-25-22 recommends all four to agencies, and they translate directly into a commercial contract. Pair them with a monitoring cadence, which the same memo suggests at quarterly or biannual intervals depending on the program.