"AI development services" is broad enough to mean almost anything — a two-week prompt-engineering sprint or a year-long platform build. The statement of work (SOW) is where that gets pinned down. Most disputes with AI dev shops trace back to something the SOW left vague. Here's what a real one covers.
Scope: what gets built, and what doesn't
A good SOW names the specific system, not a category. "Build a RAG-based support assistant that answers from our help-center docs and escalates to a human when confidence is below X" is a scope. "AI-powered customer support solution" is a pitch deck line, not a scope.
Look for an explicit out-of-scope section too. Shops that skip it tend to have "scope creep" conversations later that turn into change orders. Anything not named — a second language, a mobile client, an admin dashboard — should be listed as excluded, not assumed.
Data: whose it is, and what happens to it
The SOW should state, in writing:
- What data the shop needs from you, and how it's transferred and stored during the engagement.
- Whether your data is used to fine-tune a model, and if so, whether that fine-tuned model and its weights belong to you or the shop.
- A data deletion clause — what happens to your data on the shop's systems when the engagement ends.
- Compliance requirements that apply to your data (HIPAA, SOC 2, GDPR) and who's responsible for meeting them during the build, not just at handoff.
If your data touches health records, financial data, or anything regulated, this section should be longer than a paragraph. A shop that treats it as boilerplate hasn't thought about it carefully.
Evaluation: how "done" gets measured
This is the section most proposals skip, and it's the one that prevents arguments at delivery. A serious SOW defines:
- The specific metric — accuracy, precision/recall, latency, cost per inference, task success rate — that the system is measured against.
- The test set or benchmark used to measure it, and who builds that test set (ideally you, or you and the shop together, not the shop alone).
- What happens if the system doesn't hit the target: a defined remediation period, not silence.
No credible shop will guarantee a specific accuracy number before seeing your data — that's a sales claim, not an engineering one. What they can commit to is a transparent method for measuring the result together.
Team and staffing terms
If you're paying for engineers' time rather than a fixed deliverable, the SOW should name who's assigned, their role, and their allocation (full-time, part-time, hours/week). It should also say what happens if someone leaves mid-project — replacement timeline, handoff process, whether you're notified before or after the change. "A dedicated team" without names attached is not a staffing commitment, it's a placeholder.
Cost structure and what it does not include
A SOW covering only the build, with no mention of what happens after launch, is incomplete. Ask specifically whether the following are in scope or billed separately:
- Model inference costs (API calls to a hosted LLM, or hosting costs for a self-hosted one).
- Monitoring for model drift and degraded performance after launch.
- A defined maintenance window or support tier post-delivery.
Shops vary in how they structure this — some build ongoing infrastructure costs into a retainer, others hand off a working system and step back. Neither is wrong, but it needs to be explicit in the document, not discovered in the first invoice after launch.
IP and ownership
Confirm in writing that you own the code, the fine-tuned model artifacts, and any custom tooling built specifically for you. Separately, ask whether the shop reuses its own proprietary frameworks or agent orchestration layers across clients — that's common and not inherently bad, but it should be disclosed, licensed to you clearly, and not silently create lock-in you didn't agree to.
A short checklist for reading a SOW before you sign
- Scope is specific to your system, with an explicit out-of-scope list.
- Data handling, fine-tuning rights, and deletion terms are spelled out.
- Evaluation metrics and the test set are defined before work starts.
- Named team members, allocation, and a replacement process are included.
- Post-launch costs — inference, hosting, monitoring — are addressed, not silent.
- IP ownership is explicit for code, models, and any reused frameworks.
Shops differ in how they package these terms — a boutique team like asaasin.ai structures engagements around a free prototype before a fuller SOW is signed, while larger firms tend to formalize the document earlier in the sales process. Either way, don't sign until every section above has a specific answer, not a category. If your project needs a particular technical depth, start from the specialty filters on this site, narrow by company size, and take the SOW conversation into the first call already knowing what you're asking for — see also our guide on how to choose an AI dev shop.