"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.
Comparison criteria for reading two SOWs side by side
If you're weighing proposals from more than one shop — say a firm from the generative AI specialty filter against one from MLOps — score both documents on the same six sections above, not on price or page count. A shorter SOW that specifically names the test set, the data deletion policy, and the named team beats a longer one padded with boilerplate legal language and generic scope statements.
FAQ
What should happen if the system doesn't hit the evaluation target defined in the SOW? The SOW should name a defined remediation period, not leave it to a follow-up conversation. If the document is silent on this, ask before signing — it's one of the more common points where engagements sour after delivery.
Who should own fine-tuned model weights? You should, by default, if the fine-tuning used your data — stated explicitly in the SOW, not implied. If the shop wants to retain rights to a base framework it reuses across clients, that's a separate, disclosed item, not something bundled silently into your deliverable.
Should ongoing inference and hosting costs be in the SOW or billed separately? Either can work, but it must be explicit. Some shops fold ongoing infrastructure costs into a retainer; others hand off a working system and step back, leaving you to manage hosting and API costs directly. The failure mode is a SOW that's silent on this and leaves you to discover it in the first invoice after launch.
Does a free prototype or discovery call replace a formal SOW? No. A free prototype or an initial scoping conversation is how some shops — including asaasin.ai — get to a mutual go/no-go before a fuller SOW is signed, but it's a precursor to the document, not a substitute for the scope, data, evaluation, and IP terms a real SOW needs to spell out.
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. </content>