What to Include in an AI Project Scope of Work or Contract

An AI SOW should list specific deliverables, measurable success metrics (accuracy, latency, cost per task), a written acceptance test, data handling and IP ownership terms, SLAs for uptime and support, pricing with milestones, who pays ongoing model and API costs, a change-request process, and an exit clause for code and data handover.

The most common gap is measurable acceptance criteria. Many contracts say the system should work well without defining a target accuracy, a test dataset, or a pass threshold. Without a written acceptance test tied to final payment, disputes over whether the AI is good enough become subjective and hard to resolve.

Ownership depends on the contract, so state it explicitly. Clarify who owns the source code, prompts, fine-tuned weights, embeddings, and the data pipeline once payment is complete. Many disputes arise because the vendor keeps ownership by default. If you want full ownership, name code, prompts, and configuration specifically, not just deliverables.

Specify what data the vendor can access, where it is stored and in which region, retention and deletion timelines, and whether your data is used to train shared or third-party models. Include a confidentiality clause and a guarantee that data is exported and deleted on exit. For EU work, name GDPR responsibilities and any sub-processors.

Ask for a target metric appropriate to the task, such as 95 percent task completion or a precision and recall figure, measured on an agreed test set. No model is 100 percent accurate, so also require a confidence threshold, a human-in-the-loop step for high-stakes actions, and a defined fallback when the model is uncertain.

Tie payment to milestones, not a single up-front fee. A common split is a deposit, a payment at a working prototype, and a final payment only after the system passes the written acceptance test on real data. This protects both sides and keeps the vendor accountable to measurable results rather than a demo.

Yes. AI systems keep incurring model, API, and infrastructure costs after launch, and these can exceed the build fee over time. State clearly who pays them, provide an estimated monthly range, and define what happens if a provider raises prices. Leaving this out is a frequent source of post-launch friction.

An acceptance test is a written procedure the build must pass before final sign-off. It runs the system on an agreed dataset and checks results against defined thresholds for accuracy, latency, and behavior. Document the dataset, the metrics, the pass bar, and how many test runs are allowed so acceptance is objective, not a matter of opinion.

Prevent scope creep with a written change-request process. Anything not in the original deliverables list is scoped, priced, and approved in writing before work starts. Keep deliverables as discrete items rather than vague goals, and tie acceptance to that list so additions are visible and billed rather than absorbed silently.

Include an uptime target such as 99.5 percent, response times by severity, resolution time commitments, and remedies (credits or fixes) if targets are missed. For agentic systems also define monitoring, alerting, and who is on call. An SLA without remedies is just a promise, so attach a consequence to each missed target.

Address them directly, since no model is error-free. Define acceptable error rates, a confidence threshold below which the system asks for human review, a human-in-the-loop step for high-stakes actions, and a logging requirement so errors are traceable. Assign responsibility for harm caused by incorrect output, especially in regulated or customer-facing use.

Yes if the system handles personal data, makes automated decisions, or operates in a regulated sector. Name applicable rules (EU AI Act, GDPR, sector regulations), state who is responsible for compliance, and require documentation such as data processing records. This is essential before any launch that collects data, sends email, or charges money.

An exit clause defines what you receive if the relationship ends: the source code, prompts, configuration, a usable data export, and credentials, with the vendor's access revoked. It matters because AI systems can create lock-in through proprietary pipelines. Without an exit clause, switching vendors or bringing the work in-house becomes expensive or impossible.

List deliverables as discrete, testable items: each agent, workflow, integration, dashboard, and document named individually with what done looks like. Avoid paragraphs of intent. Detailed deliverables make acceptance objective, expose scope creep, and give both sides a shared checklist, which is the single biggest factor in finishing an AI project cleanly.