Strategy · 4 minute read
AI Statement of Work Template: Scoping AI Projects That Ship
An AI statement of work defines the business outcome, the specification and acceptance evidence that prove it, scope and non-scope, data and system access, the evaluation method and thresholds, deliverables including specifications and golden datasets, governance and oversight design, intellectual property and data terms, and change control, so that acceptance is measured against evidence rather than demos.
Statements of work for AI projects are usually adapted from software templates, and they fail in the same place every time: acceptance. A feature list can be checked; an agent's behavior on the thousand cases it will see next month cannot, unless the SOW defined the evidence in advance. This template builds the SOW around specifications, evaluation, and autonomy, which is how FISTA scopes its own engagements. It complements how to write an AI RFP and the AI vendor due diligence whitepaper. Contract language here is general guidance, not legal advice.
What does the template contain?
| Section | Purpose |
|---|---|
| 1. Business outcome | What changes for the buyer, in measurable terms |
| 2. Scope and non-scope | The workflow, case types, systems, and autonomy level at delivery; what stays human |
| 3. Specification and acceptance evidence | The correctness criteria, the golden dataset, thresholds, and how acceptance is demonstrated |
| 4. Data and access | What data and systems the vendor touches, where processing runs, retention, and return |
| 5. Deliverables | System, specification, golden dataset, harness, runbooks, dashboards, training |
| 6. Approach and milestones | Sequence with evidence at each milestone; estimated durations |
| 7. Governance and oversight | Identity, permissions, approval gates, audit, incident handling |
| 8. Roles and responsibilities | Buyer's process owner, vendor's engineers, decision rights |
| 9. Commercials | Pricing basis, payment against milestones and evidence |
| 10. IP and data terms | Ownership of specifications, datasets, code; data use restrictions |
| 11. Change control | How discovery and scope changes are handled |
| 12. Warranties, limits, and exclusions | What is and is not promised |
How should the business outcome be written?
State the workflow, the current baseline (volume, cycle time, cost per case, error rate), and the targeted movement in those measures, with the caveat that targets are validated in shadow mode. Avoid promising savings; state the measurement method. The measurement framework is in the AI ROI measurement framework whitepaper.
What goes in scope and non-scope?
Name the case types the system handles and, with equal precision, those it does not. State the autonomy level at delivery: suggest, act with approval, or act with sampling, and the evidence required to advance it after delivery. Name the systems integrated and the integration method. Non-scope is a control; write it as carefully as scope.
How is acceptance evidence defined?
| Element | Content |
|---|---|
| Correctness criteria | Written with the buyer's process owner before build |
| Golden dataset | Size and coverage by category; who supplies cases; who verifies outcomes |
| Thresholds | Quality by category; zero-tolerance criteria; latency and cost per task |
| Shadow-mode period | Duration and agreement-rate target against the existing process |
| Production sampling | Sampling rate and quality target over a defined period after go-live |
| Acceptance event | Evidence report reviewed by the process owner; sign-off against thresholds |
The discipline is evaluation-driven development. A SOW without a golden dataset has no acceptance criteria.
What should the data and access section cover?
Data categories the vendor may access; environments and regions where processing occurs; model providers used and their data terms; retention and deletion; access provisioning through scoped identities; return or destruction of data at the end. Regulated data adds obligations; align with the private AI for regulated industries whitepaper.
What are the deliverables?
The system in the buyer's environment; the specification; the golden dataset and evaluation harness; identity and permission configuration; runbooks and dashboards; the audit-trail design; training for the process owner and exception handlers; and the handover record. Specifications and datasets are deliverables because they are what makes the system maintainable without the vendor.
How should milestones and change control work?
Milestones follow the onboarding sequence: specification signed, baseline captured, integration and identity in place, golden dataset verified, shadow-mode report, go-live at the agreed autonomy level, first performance review. Each has evidence and a go or no-go. Change control anticipates discovery: shadow mode reveals undocumented rules, and the SOW defines how specification changes are proposed, priced, and approved. The onboarding sequence is in how to onboard a Digital FTE.
What language should be avoided?
- Fixed delivery dates independent of evidence.
- Guaranteed accuracy, savings, or outcomes.
- "Best efforts" without a method.
- Vendor ownership of the buyer's specifications or datasets.
- Unbounded data use by the vendor or its model providers.
What are the common mistakes?
- Acceptance by demo.
- No golden dataset in the deliverables.
- Autonomy level unstated, so "done" is contested.
- Data terms left to the master agreement that never contemplated model providers.
- No change control, so discovery becomes a dispute.
How does FISTA Solutions help?
FISTA Solutions scopes engagements with this template, delivers specifications and golden datasets as buyer-owned artifacts, and accepts work against evidence. Engagements run through forward deployed engineers, AI enablement, and AI agents delivery. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.
To scope a project against this template, message FISTA on WhatsApp, or read outsourcing contract checklist for the commercial side.
Share-ready article cover
Download the generated social format.
Clear answers
Questions raised by this field note.
Straightforward guidance for evaluating scope, fit, and the next step.
01How is an AI statement of work different from a software SOW?
It defines acceptance as evaluation evidence against agreed thresholds rather than as features delivered, includes the specification, golden dataset, and harness as deliverables, states the autonomy level and the human oversight design at delivery, and covers data handling and model governance explicitly. Probabilistic systems need probabilistic acceptance criteria.
02What should acceptance criteria look like?
Quality thresholds by category on a golden dataset agreed before the build, zero-tolerance criteria for prohibited actions, latency and cost per task budgets, and a production sampling result over a defined period. Criteria are numbers and evidence, not adjectives, and the buyer's process owner signs off on what correct means.
03Should an AI SOW fix a timeline?
It should fix the sequence, the milestones, and the evidence at each milestone, with estimated durations. Discovery in shadow mode routinely changes the specification, and a SOW that promises a fixed date regardless invites either corner-cutting or a dispute. Time- boxed phases with go or no-go evidence are the honest structure.
04Who owns the specification and the golden dataset?
The buyer, and the SOW should say so. They are the buyer's definition of correct for their own workflow, and they are what makes the delivered system maintainable and portable. A vendor that retains them retains control of the buyer's process. This is general guidance, not legal advice; IP terms need counsel.
Continue exploring
Related capabilities
Start with the hard problem
Need the outcome owned, not merely analyzed?
Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.