September 8, 2026 7 min read AI Consulting · SOWs · Contracts

How to Write an AI Project SOW That Protects Both Sides

A surprising number of AI project SOWs say something like "deliver a document classification system," with no accuracy target, no acceptance criteria, and no shared definition of done. Months later the client still wants the vendor on the project because it isn't "done" — and neither side can say what done means.

Here's what actually needs to go into an SOW for an AI project to protect the vendor and the client.

The anatomy of a real AI SOW

1. Deliverables vs. outcomes

This is the most important distinction in the whole document. A deliverable is a thing you produce. An outcome is the result the client gets.

Bad SOW: "Deliver a machine learning model for invoice classification."

Good SOW: "Deliver infrastructure that classifies invoices by department with 95%+ accuracy. Deliverables include: trained model, Lambda function for real-time inference, CloudWatch dashboard, Terraform code, runbook, and a 90-minute knowledge transfer session."

The second version defines success. 95% accuracy is measurable. Real-time inference is specific. A dashboard and runbook mean the client can operate the system without you, and the knowledge transfer is time-boxed instead of open-ended.

2. Acceptance criteria

Agree on how you'll know the work is done before you start it.

Acceptance Criteria for Invoice Classification System:

- System correctly classifies ≥95% of invoices across the following
  department codes: AP, AR, Operations, R&D, Admin
- The invoice line-item extraction from the same pipeline achieves
  ≥90% accuracy (measured against manual validation of 200 sample
  invoices from the last 12 months)
- The Lambda function processes a typical invoice in <3 seconds
- Error logs are queryable in CloudWatch with a retained 30-day window
- The system rejects unparseable documents to a manual queue instead
  of guessing
- Documentation includes a decision tree for "what to do when
  classification confidence is below 75%"
- The client team can run inference against the model without vendor
  involvement (via provided Lambda wrapper)
- All code is in a GitHub repo the client owns

Notice these are testable. Not "the system works well," but "95% accuracy on these specific documents, measured this specific way."

3. Change order process

Scope creep kills fixed-price AI projects. Agree, before you sign, on what happens when the client asks for something new.

Change Order Policy:

- Any request outside the original scope requires a written change order.
- Scope changes include: adding new document types, raising accuracy
  targets above 95%, adding new department codes, expanding the team
  requiring additional knowledge transfer.
- The vendor estimates the impact in hours/cost and timeline. The
  client approves before work begins.
- Change orders don't extend the project deadline unless both parties
  agree in writing.
- If the client approves a change order mid-project, the vendor may
  re-estimate the original scope impact and adjust accordingly.

None of this is about being difficult with the client. It keeps the project from turning into a black hole.

4. IP ownership

Who owns the code? The weights? The documentation? I recommend the client owns everything.

Intellectual Property:

- All code, Terraform configuration, prompts, and documentation
  produced under this SOW are owned by the Client.
- The Client may use, modify, and distribute these materials without
  further compensation to the Vendor.
- The Vendor retains the right to reference the completed project
  (anonymized) in case studies and portfolio materials.
- Any pre-existing tools, libraries, or frameworks licensed under
  open-source licenses retain their original license terms.

The client is paying you. They should own what you build. It also makes your exit clean, with no arguments afterward about what they can or can't do with it.

5. SLA and support commitments

Be explicit about what you're on the hook for after handoff.

Post-Handoff Support:

Phase 1 (0-30 days): Included. The Vendor is available during business
hours (9 AM - 5 PM Pacific, weekdays) to answer questions, troubleshoot
issues, and help the Client's team operate the system.

Phase 2 (31-90 days): Optional, paid separately. Support is $2,000/month
for 20 hours of availability. The Client can use these hours for
troubleshooting, retraining the model on new data, or optimization work.

Post-90 days: No ongoing commitment. The Client operates the system
independently. The Vendor may be available for consulting at standard rates.

SLA for Support Phase 1:
- Acknowledged within 4 business hours
- Initial diagnosis within 1 business day
- Resolution target: 5 business days (best effort, not guaranteed)

Some clients want ongoing support. That's fine, but price it separately so it doesn't quietly eat your fixed-price margin.

6. Data and privacy

If you're handling the client's data, be clear on how you use it.

Data Handling:

- All training data provided by the Client remains the Client's
  confidential information.
- The Vendor will not share, store, or use training data for purposes
  other than building the specified system.
- Intermediate artifacts (logs, model checkpoints) are deleted 30 days
  after project completion.
- The Client is responsible for obtaining all necessary data rights and
  ensuring data is representative of production use cases.
- If data contains PII, the Client is responsible for anonymization or
  redaction before providing to the Vendor.

This protects both of you. You're not liable for how the client obtained their data, and the client knows it isn't used for anything else.

7. Definition of done

The project isn't done when the model is trained. It's done when the client can operate the system without you.

Definition of Done:

The project is complete when:

1. All acceptance criteria are met and verified in writing by the Client
2. Code is committed to the Client-owned GitHub repo, with CI/CD
   configured
3. Documentation includes:
   - Architecture diagram (infrastructure and data flow)
   - Runbook: "How to deploy a new model version"
   - Operational guide: "What to monitor and what metrics matter"
   - Troubleshooting guide: "Common errors and how to fix them"
   - Cost projection: "Expected monthly AWS and Claude API costs"
4. The Client's team has completed a 90-minute knowledge transfer session
   and demonstrated they can:
   - Deploy an updated model
   - Interpret CloudWatch metrics
   - Recognize when the system is behaving abnormally
5. All project artifacts are in the Client's control (repos, secrets,
   credentials, etc.)
6. A post-project retrospective is scheduled (optional, 30 minutes) to
   discuss what went well and what could improve

None of this is ambiguous. The client knows what they're getting. You know what's required to call it done.

Real example

Here's a section from a sample invoice-processing SOW:

PROJECT: Invoice Processing Automation with Line-Item Extraction

Scope:
- Build infrastructure to ingest invoices (PDF) via S3 upload
- Use Claude to extract structured data: vendor name, invoice number,
  date, line items (quantity, description, amount)
- Store results in DynamoDB for further processing
- Provide a dashboard showing processing history and error rate
- Deliver source code and operational documentation

Acceptance Criteria:
- Correctly extract vendor name and invoice number from ≥98% of test
  invoices
- Correctly extract line items (quantity, description, amount) from
  ≥92% of line items in test set
- Process cost is ≤$0.15 per invoice (at 2026 Claude pricing)
- Dashboard shows ≥95% uptime
- Error handling routes unparseable invoices to a manual review queue

Not In Scope:
- Integration with accounting software (QuickBooks, NetSuite, etc.)
- Historical invoice processing (invoices created before project start)
- OCR/image processing for scanned invoices (if needed, separate project)

Timeline: 8 weeks from kickoff to final acceptance
Budget: $42,000 fixed

Assumptions:
- Client provides 50 representative invoices for training and testing
- Client has AWS account with appropriate IAM permissions
- Client will assign 1 FTE to knowledge transfer sessions

That's clear. Both sides know what they're getting.

What to avoid

Time and materials for AI projects. The model doesn't converge, scope expands, and vendors end up spending four times the hours they estimated. Scope to fixed deliverables with clear acceptance criteria instead.

Vague accuracy targets. "The model should be accurate" doesn't hold up. "93% accuracy on these specific documents, measured this way" does.

Undefined data is another one. "You'll provide training data" needs a format, a size, and a statement of how representative it is — get that in writing before you start. And if you're supporting the system after handoff, formalize it with an SLA and a price. Otherwise you'll answer email for six months and never get paid for it.

A good SOW takes four to six hours to write. It saves weeks of project pain, because it forces both you and the client to think clearly about what success looks like before anyone spends money.

Ready to scope your next AI project with clarity and protection? Book a call to talk through your project scope and how to write an SOW that works for both sides.

Get the free AI Readiness Checklist

15 questions to diagnose your team’s AI readiness, where you’ll see ROI fastest, and what to tackle first.

✓ Takes 5 minutes ✓ Actionable next steps ✓ No sales pitch

No spam. Unsubscribe anytime.

Ready to build AI that actually works?

Let’s talk about how SRE discipline transforms AI from a risky experiment into a reliable business system.

Start the Conversation

About the author

Charles Harvey is the founder of Three Moons Network and a site reliability engineer who builds production-grade AI automation for small businesses — monitoring, cost visibility, and documentation included. He writes about his hands-on AI experiments at floggingclaude.com. Connect on LinkedIn or see the code on GitHub.