An AI statement of work that holds up: scope, acceptance, handover

An AI statement of work decides whether a build succeeds or becomes a procurement lesson nobody records. The GAO examined 13 AI acquisitions across four federal agencies in April 2026 and found none systematically collecting lessons from their AI procurements (GAO-26-107859, April 2026). If agencies spending millions cannot learn from past AI contracts, a company spending five figures needs to get the paperwork right the first time.

The SOW is not the contract. We covered the contract terms in what to fix in writing before work starts. The SOW comes before that: it describes the work, defines what done looks like, and says what you receive at the end. Get the SOW wrong and the contract protects nothing, because nobody agreed on what was being built.

This is the structure we use, stripped of any pricing or timeline, so you can hold it against whatever your builder hands you.

Key Takeaways

• More than 80% of AI project failures trace to organizational causes, not code (RAND RRA2680-1, 2024)
• Seven SOW sections separate builds that ship from pilots that stall
• Acceptance criteria must test production conditions, not curated demos
• A handover package should pass the “disappeared tomorrow” test

Why does scope fail more AI projects than code does?

More than 80% of AI projects fail, roughly double the rate for non-AI IT projects, according to RAND’s interviews with 65 data scientists and engineers (RAND RRA2680-1, 2024). Four of the five root causes are organizational. Bad code did not make the list.

The first cause RAND identified: leadership failed to define and communicate the problem. That is a scope document failing, not a model failing. The second: data quality. Third: teams chased technology instead of solving the problem. Fourth: underinvestment in deployment infrastructure. Only the fifth sits with engineering.

Deloitte’s January 2026 survey of 3,235 executives reinforced the pattern. Only 25% of organizations had moved 40% or more of their AI pilots into production (Deloitte State of AI in the Enterprise, January 2026). Pilots are not failing in the lab. They are failing in the handoff between “this works on my laptop” and “this runs in the business.”

We have shipped 41 agents across our own group companies. The ones that stalled early were scope problems: unclear inputs, unstated edge cases, no written definition of what the agent should refuse to do. Not code. Scope.

What seven sections should an AI statement of work carry?

IEEE published the first consensus standard for AI procurement in May 2025, defining a six-step process from problem definition through contract monitoring (IEEE 3119-2025, May 2025). The standard includes 26 tools and rubrics. You do not need all 26. But you do need these seven sections in your SOW.

1. Problem statement

State the business problem, not the technology. “We need an agent that processes inbound freight quotes” is a technology statement. “We receive 120 freight quote emails a day and a human spends 4 hours keying them into the TMS” is a problem statement. Acceptance criteria flow from the problem, not from the solution. If you cannot write down what happens today, how long it takes, and what breaks, the SOW is not ready.

2. Scope and exclusions

Name every input the system will handle and every input it will not. AI projects expand silently because “it could also do X” is always true and always unpriced. Carry a numbered list of inclusions and a second numbered list of exclusions.

Exclusions keep the price fixed and the delivery date real. We explained why in how a fixed price gets fixed.

3. Data requirements

Specify what data the system needs, where it lives, what format it arrives in, and what quality it must meet. RAND found data quality was the second most common root cause of failure. If the SOW says “client will provide data” and nothing else, the builder will discover the problem on your timeline and your budget. Include sample data as an appendix. Real samples, not clean ones.

4. Acceptance criteria

This section gets its own heading below. The short version: acceptance is a test, not a meeting.

5. Handover package

Also covered in detail below. The SOW should list every item the buyer receives at completion: code, configuration, documentation, credentials, runbooks, and recorded walkthroughs.

6. Change control

State what happens when scope changes. The workable answer: any change after the SOW is signed becomes a new written order, quoted and agreed before work starts. Without this clause, scope expands and nobody reprices.

7. Assumptions and dependencies

List what must be true for the build to succeed. “Client provides API access to the TMS by day 5.” “Client assigns one point of contact who responds within one business day.” If the assumption breaks, the timeline and price may change, and the SOW should say so explicitly.

SOW section	What most software SOWs say	What the AI version needs
Problem statement	”Build feature X”	The business process, current cost, volume, failure points
Scope and exclusions	Feature list	Numbered inclusions AND exclusions, input types handled
Data requirements	”Client provides access”	Format, quality floor, sample data, who cleans it
Acceptance criteria	”Client signs off”	Written test set, pass rate, edge cases, failure behavior
Handover package	”Source code delivered”	Code, config, prompts, runbooks, credentials, walkthrough
Change control	Often missing	New written order for any post-signature change
Assumptions	Often missing	Dependencies with dates, consequences if broken

How do you write acceptance criteria that test production, not a demo?

The PMI published the first global standard for AI in project management in June 2026, covering five performance domains (PMI Standard for AI in Project Management, June 2026). Its acceptance guidance names what most SOWs leave out: performance in realistic scenarios, known failure modes, edge cases, security testing, data quality checks, monitoring readiness, and rollback capability.

Test with production data, not curated samples

Build your test set from real inputs, including the messy ones. The invoice with a missing PO number. The email in mixed languages. The order referencing a product code you discontinued last quarter. If the system passes 50 handpicked examples and fails on the 51st from your actual queue, the acceptance criteria were decorative.

Define the failure behavior

What should the system do when it is wrong or uncertain? Stop and escalate? Flag the record? Refuse to act? Write that into the SOW. Silent failure is worse than loud failure, because you do not discover it until a customer does.

Most SOWs define what the system should do when it works. Almost none define what it should do when it doesn’t. That second definition is what separates a production system from a demo.

Include a rollback plan

The PMI standard lists rollback and containment as acceptance requirements. Before go-live, you should know how to revert to the manual process within a defined window. If the answer is “we can’t,” the system is not production-ready.

We covered the contract-level mechanics of acceptance in the contract terms post. The SOW is where you write the specific tests. The contract is where you write what happens if they fail.

What does a handover that actually transfers ownership look like?

Only 21% of organizations planning agentic AI deployment have mature governance models (Deloitte State of AI in the Enterprise, January 2026). The handover section of the SOW exists for the other 79%. It should answer one question: if the builder disappeared tomorrow, could your team run and change the system using only what you received?

The handover checklist

The package should include, at minimum:

• Source code in a repository the buyer owns, with commit history
• Configuration and environment variables, documented, not buried in a deploy script
• Prompt templates and system instructions, versioned and explained
• Runbooks for common operations: restart, scale, debug, update a prompt
• Monitoring setup with alerts for the failure modes identified in acceptance
• Credential rotation instructions so you can cut the builder’s access cleanly
• A recorded walkthrough of the system architecture, not just a slide deck

We build on the buyer’s accounts from day one, not ours. GitHub, Supabase, hosting, API keys. When we hand over, there is nothing to migrate, because nothing lived on our infrastructure. The handover is removing our access, not transferring yours.

The government is codifying this

GSA’s draft clause GSAR 552.239-7001, effective October 2026, requires contractors to identify all AI systems used in contract performance within 30 days (GSAR 552.239-7001, March 2026 draft). If federal procurement is codifying AI disclosure, private buyers should ask for the same: a written inventory of every AI model, API, and third-party service the system depends on.

How do you know if your SOW is strong enough?

Run three tests before you sign.

The stranger test. Hand the SOW to someone outside the scoping conversations. Can they tell you what is being built, what done looks like, and what is excluded?

The dispute test. Imagine the build is finished and you disagree about completeness. Does the SOW give a clear answer, or does it leave room for two honest readings?

The disappearance test. If the builder vanished the day after handover, does the SOW describe everything you need to operate and modify the system?

The GAO found that all four agencies concurred with its recommendation to capture lessons from AI acquisitions (GAO-26-107859, April 2026). They concurred because they had no process for it. Your SOW is that process, scoped to one project.

Start async

Describe your process at /start. You get a written reply within one business day, no meeting, with a scoping outline you can hold against the seven sections above.

We run builds as AI workforce sprints, each one a tomte, our word for one production agent with one defined job, scoped and priced before the first commit. You own the delivered code, accounts, and keys. The agent fleet page shows how we run the same structure on our own companies. If you want to ask harder questions first, we have written the list.

Frequently asked questions

What is the difference between an AI statement of work and an AI contract?

The SOW describes the work: what is being built, how it will be tested, and what the buyer receives. The contract covers the legal terms: liability, intellectual property, payment, data handling, and termination. IEEE 3119-2025 treats them as separate steps in a six-stage procurement process (IEEE 3119-2025, May 2025). You need both, and the SOW should be written first.

How long should an AI statement of work be?

Long enough to pass the stranger test. For a single-agent build, that is typically 3 to 8 pages. What matters is specificity, not length. A 2-page SOW with numbered acceptance criteria and explicit exclusions is stronger than a 20-page document full of paragraphs about “the AI solution.”

Should an AI SOW include model selection?

Name the model family and tier, but leave room for the builder to select the specific version. Models are retired on published schedules. Locking to a version creates an expiry date on the document. Specify capability requirements and let the builder match them.