What Is a Statement of Work? SOW Essentials for AI Delivery

Most delivery disputes trace back to a document that was vague where it needed to be precise. The statement of work is that document: it defines what will be delivered, how it will be judged, what it costs, and how changes are handled. For AI engagements, where outputs are probabilistic and data assumptions carry most of the risk, the SOW has to be more precise than for conventional software. This explainer covers what an SOW contains and how to write one that prevents disputes, drawing on FISTA Solutions' staff augmentation and delivery practice. Procurement context is in the AI procurement for CIOs whitepaper and acceptance practice in the ai acceptance testing checklist.

What is a statement of work?

A statement of work (SOW) is a contractual document, usually issued under a master services agreement, that defines a specific engagement: its purpose, scope and exclusions, deliverables, acceptance criteria, schedule and milestones, roles on both sides, assumptions and dependencies, pricing and payment terms, and the process for handling changes. It converts the legal relationship into a concrete commitment that both parties can measure performance against.

What sections does an SOW contain?

Section	What it defines
Purpose and objectives	Why the work is being done and what outcome is expected
Scope	What is included and, explicitly, what is excluded
Deliverables	Each artifact, system, or service with its definition
Acceptance criteria	How each deliverable is judged complete
Schedule and milestones	Dates, phases, and dependencies
Roles and responsibilities	Who does what on both sides, including client obligations
Assumptions and dependencies	Data, access, environments, staff availability
Pricing and payment	Model, rates or fixed amounts, invoicing triggers
Change control	How changes are requested, assessed, and approved
Governance	Meetings, reporting, escalation, points of contact

What makes an AI SOW different?

Outputs are probabilistic, so "works as expected" is not an acceptance criterion; thresholds on named datasets are. Data access, quality, permissions, and labeling effort are assumptions that determine feasibility and must be written down with consequences if they fail. Model providers change models during engagements, so the SOW needs a process for re-evaluation. And the deliverable often includes evaluation assets, documentation, and handoff, not only the system. Specification practice is in the spec-driven development whitepaper.

How should acceptance criteria be written?

Each criterion names the metric, the dataset it is measured on, the threshold, the evaluation method, and the person who signs off. Examples: task success above a stated rate on the agreed golden dataset by category; latency and cost within limits at defined load; adversarial safety suite passed; runbooks, model card, and evaluation assets delivered; client owners trained. Criteria that cannot be measured cannot be accepted. Evaluation design is in what is a golden dataset and handoff in the ai project handoff checklist.

How do pricing models shape the SOW?

Time-and-materials SOWs define rates, estimates, caps, and reporting, with scope managed through prioritization. Fixed-price SOWs require tight scope and acceptance definitions because the vendor carries estimation risk. Outcome-based SOWs tie payment to measured results and need the most precise metrics and baselines. Hybrids, such as a fixed-price discovery followed by time-and-materials delivery, are common for AI work where feasibility is uncertain. Engagement model comparison is in agency vs forward deployed engineer.

What are common SOW pitfalls?

Scope without exclusions; acceptance criteria stated as expectations rather than measurements; client obligations left implicit; assumptions about data quality unwritten; no change control, so every request becomes an argument; payment triggers tied to dates rather than accepted deliverables; and IP and data terms left to the MSA without confirming they cover AI artifacts such as prompts, evaluation datasets, and fine-tuned models. IP considerations are in the ip protection checklist for offshore development.

How does change control work in practice?

A change request records what is changing, why, and the impact on scope, schedule, cost, and acceptance criteria; named approvers on both sides sign before work proceeds; and the SOW is amended or the change log maintained as part of the contract. Well-run engagements process changes weekly as routine. Governance rhythms are in the forward deployed engineering playbook.

What does a good AI SOW look like in practice?

An SOW for a document extraction system defines the document types in scope and excludes handwritten forms; lists deliverables including the pipeline, evaluation harness, golden dataset, model card, runbooks, and training; sets acceptance at field-level accuracy thresholds by document type on an agreed labeled set, throughput at defined volume, and cost per document under a ceiling; records assumptions about sample document availability and labeling support; prices discovery fixed and delivery on time-and-materials with a cap; and includes change control and weekly governance. This article is general guidance, not legal advice.

How FISTA Solutions writes statements of work

FISTA Solutions drafts SOWs from the specification, with measurable acceptance criteria tied to golden datasets, explicit assumptions and client obligations, evaluation and documentation as named deliverables, and change control built into weekly governance. The staff augmentation practice supports dedicated teams, forward deployed engineers deliver embedded engagements, and AI enablement delivers platforms, each under SOWs written this way. The record behind the approach is 150+ projects for 50+ companies.

To scope an engagement with acceptance criteria both sides can measure, message FISTA on WhatsApp, or read the ai rfp checklist for what to define before the SOW.