The AI Statement of Work Checklist
Many AI statements of work are adapted from generic software development templates and miss the clauses specific to AI engagements that cause the most disputes: who owns the fine-tuned model weights when the contract ends, what happens to training data derivatives, and whether acceptance criteria are measurable numbers or a vague reference to client satisfaction. These gaps rarely surface during negotiation, when everyone is optimistic, and instead surface during a disagreement about scope creep or at contract end when ownership of the actual deliverable becomes unclear. This checklist covers the clauses an AI SOW needs that a typical software SOW template omits.
Scope Language That Prevents Creep
Define the exact use case in one sentence a non-technical stakeholder could repeat accurately, list the specific data sources in scope by name, state the deployment environment explicitly as on-prem, cloud, or hybrid, and write an explicit out-of-scope section listing adjacent work that sounds related but is not included. AI scope creep often happens through data source expansion: a project scoped for one document repository quietly grows to include three more because they seemed related, without a change order ever being signed.
- One-sentence use case definition any stakeholder could repeat accurately without technical translation
- Named data sources in scope, explicitly excluding any not named
- Deployment environment stated explicitly: on-prem, cloud, or a defined hybrid split
- An out-of-scope section naming adjacent work that is not included, to prevent silent expansion
IP and Model Ownership Clauses
State explicitly who owns the fine-tuned model weights, the prompt library, the evaluation harness, and any derivative training data once the contract ends. The default position worth insisting on as a buyer is that the client owns everything specific to their use case, including fine-tuned weights and the evaluation harness, while the vendor may retain reusable, non-client-specific tooling and methodology for use with other clients. Also confirm the license terms of any open-weight base model used, since some community licenses restrict commercial redistribution of derivative weights above certain usage or revenue thresholds, which matters if the fine-tuned model is core to your product or process.
- Client owns fine-tuned model weights, prompts, and the evaluation harness specific to their use case
- Vendor may retain reusable, non-client-specific tooling and methodology for other engagements
- Base model license terms confirmed in writing, including any commercial redistribution restrictions
- Explicit statement that client data is never used to train models for other clients or the vendor's general product
Acceptance Criteria That Are Actually Measurable
Tie contractual sign-off to specific numbers pulled from a golden evaluation set: an accuracy or precision threshold, a latency budget, and an escalation rate ceiling, rather than language like client satisfaction with the deliverable, which is unenforceable and invites disagreement. Specify who owns constructing the golden evaluation set and confirm both parties agree it is representative before build begins. Vague acceptance criteria are the single most common source of payment disputes on AI engagements, because both sides can genuinely believe in good faith that a subjective bar was or was not met.
Data Handling and Security Clauses
Specify data residency commitments explicitly, list any subprocessors involved in the data path including embedding or reranking services that are easy to overlook, state the data deletion timeline at contract end, and confirm in writing that client data is never used for training beyond the specific engagement. For regulated clients, reference the specific compliance framework, such as CMMC or ITAR-adjacent handling requirements, and require the vendor to disclose any change in subprocessors or architecture that would affect compliance status during the contract term.
Payment Milestones Tied to Deliverables
Structure payment around concrete deliverables rather than pure time elapsed: kickoff and discovery, signed baseline and golden evaluation set, shadow-mode results meeting the pre-agreed accuracy threshold, production go-live, and a 30-day post-launch review confirming the system is operating within SLA. Tying payment to deliverables rather than calendar dates aligns incentives on both sides and gives the client leverage to withhold final payment if the shadow-mode or go-live criteria genuinely were not met.
How Netray Structures SOWs for Regulated Clients
Netray writes measurable acceptance criteria into every SOW, tied to a golden evaluation set both parties agree on before build starts, and explicitly assigns fine-tuned model weights, prompts, and the evaluation harness to the client at project completion. For regulated clients we include named subprocessor disclosure, explicit data deletion timelines, and a compliance framework reference matched to the client's actual regulatory obligations, reviewed by the client's own compliance team before signature rather than presented as a take-it-or-leave-it template.
Frequently Asked Questions
Who owns the model after an AI consulting project ends?
This should be stated explicitly in the SOW rather than left implicit. The buyer-favorable default is that the client owns everything specific to their use case, including fine-tuned model weights, the prompt library, and the evaluation harness, while the vendor retains only reusable, non-client-specific tooling. Confirm the base model's license terms separately, since some open-weight licenses restrict commercial redistribution above certain thresholds.
What acceptance criteria should be in an AI statement of work?
Measurable numbers tied to a golden evaluation set: an accuracy or precision threshold, a latency budget, and an escalation rate ceiling, agreed by both parties before build begins. Avoid subjective language like client satisfaction with the deliverable, which is unenforceable and is the most common source of payment disputes on AI engagements because both sides can disagree in good faith about whether it was met.
Should an AI SOW specify data deletion terms?
Yes. The SOW should state explicitly when and how client data is deleted at contract end, whether the vendor retains any derivative artifacts such as embeddings or fine-tuning datasets, and confirm in writing that client data was never used to train models for other clients. This is especially important for regulated manufacturers where data handling terms are subject to audit.
Key Takeaways
- 1Scope Language That Prevents Creep: Define the exact use case in one sentence a non-technical stakeholder could repeat accurately, list the specific data sources in scope by name, state the deployment environment explicitly as on-prem, cloud, or hybrid, and write an explicit out-of-scope section listing adjacent work that sounds related but is not included. AI scope creep often happens through data source expansion: a project scoped for one document repository quietly grows to include three more because they seemed related, without a change order ever being signed..
- 2IP and Model Ownership Clauses: State explicitly who owns the fine-tuned model weights, the prompt library, the evaluation harness, and any derivative training data once the contract ends. The default position worth insisting on as a buyer is that the client owns everything specific to their use case, including fine-tuned weights and the evaluation harness, while the vendor may retain reusable, non-client-specific tooling and methodology for use with other clients.
- 3Acceptance Criteria That Are Actually Measurable: Tie contractual sign-off to specific numbers pulled from a golden evaluation set: an accuracy or precision threshold, a latency budget, and an escalation rate ceiling, rather than language like client satisfaction with the deliverable, which is unenforceable and invites disagreement. Specify who owns constructing the golden evaluation set and confirm both parties agree it is representative before build begins.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
ERP Contract Negotiation Checklist
Work through the license, pricing, statement of work, support, and exit terms that determine your ERP total cost of ownership long after the sales team has moved on.
Free ToolAI Roadmap Priority Scorer
Score a candidate AI initiative on business value, feasibility, data readiness, and risk to get a single weighted priority number for roadmap sequencing.
Free ToolAI Model License Compliance Checklist
A practical control checklist for tracking open-weight model license obligations, from commercial use restrictions and attribution requirements to fine-tuned derivative model terms.
Terms used in this article
Reviewing an AI consulting proposal and want to know what the SOW is missing? Netray will walk through this checklist against your draft contract before you sign.
Related Resources
RACI and Governance for AI Projects
RACI and governance for AI projects: the decisions that actually need a defined owner, a sample assignment for manufacturing, and a lightweight steering model.
AI & AutomationSelecting an AI Implementation Partner: Evaluation Criteria
Selecting an AI implementation partner: a weighted evaluation scorecard, reference-check questions, and why a pilot-first contract beats a big-bang one.
AI & AutomationThe AI PoC to Production Playbook: Why 80% of Pilots Stall
Why an estimated 80 percent of enterprise AI pilots never reach production, and the playbook to define production-ready criteria before the pilot even starts.