Most AI proposals are not scope documents. They are budget commitments dressed up as scope documents. The vendor knows what they’re selling. The client usually doesn’t know what they’re buying. That asymmetry is where projects go wrong; before any code is written, before any model is selected, before the first invoice.
Why AI Scope Is Harder to Pin Down Than a Normal Web Project
A website project has a finish line most clients can picture. AI projects don’t. “We’ll build you an AI integration” can mean almost anything, and that ambiguity is where vendor revenue comes from.
The “Chatbot” Problem
Ask five AI agencies to quote you a chatbot. You’ll get prices ranging from $15,000 to $80,000 or more for what appears to be the same thing. A basic FAQ bot that matches keywords to canned answers is $15k. A context-aware agent with retrieval-augmented generation, multi-turn memory, CRM integration, and fallback logic is $80k+. Same word. Five-times price difference. If the proposal doesn’t tell you exactly which one you’re getting, the price is fiction.
The Gap Between Pilot and Production
49% of AI teams are running pilots. Only 4% reach meaningful production deployment. That gap, from a demo that works in a controlled environment to a system that handles real edge cases without breaking, is where most budgets and timelines get destroyed. Agencies rarely price that gap honestly at proposal stage. They price the pilot, then scope-creep their way to production revenue.
Before You Negotiate: Know What You’re Actually Buying
You cannot negotiate a scope you haven’t defined. Most clients show up to negotiations having described a problem and assumed the agency will define the solution. That’s backwards.
Three Decisions That Define Every AI Project
Before any negotiation, you need to know three things in writing:
- The business outcome, not “an AI tool”, but “reduce invoice processing time from 4 hours to 45 minutes per week”. Measurable. Specific. Not a technology description.
- The approved data sources, which systems the AI will read from, which it will write to, and who owns access. This determines integration complexity, cost, and security posture. If the agency hasn’t asked about your data sources, they haven’t started scoping.
- What human action follows the output, an AI that flags anomalies is different from one that takes action on them. The boundary between AI output and human decision is the most important architectural choice in any integration, and it must be explicit.
How to Define “Done” Before Money Changes Hands
Ask for a written acceptance criteria document before you sign. It should name the exact condition under which the project is considered complete, not “system is live” but “system processes 95% of incoming invoices without manual review, measured over 30 days of production use”. Vague completion criteria are how change orders multiply after launch. If the agency can’t write down what done looks like, they don’t know what they’re building.
Note: acceptance criteria only protect you if the metrics themselves are well-chosen. A vendor who agrees to “95% processing rate” can hit that number while failing on the cases that matter most to you, high-value invoices, exceptions, edge cases. Define which inputs the acceptance window must include, not just the rate.
The Three Red Flags in Any AI Proposal
Three patterns consistently predict a bad outcome. Any one of them should put you on alert. All three together means walk away.
A Price Quoted Before a Deliverable Is Named
If you receive a proposal with a number before it names a specific deliverable, the number is a placeholder designed to anchor you. Real scope produces real prices. If section one says “AI Integration Package: $45,000” and section three eventually gets around to describing what that includes, in vague language, the vendor is pricing their time, not your outcome.
A Tool Recommendation Before Any Workflow Review
An agency that recommends GPT-4, Claude, or any specific AI model before they’ve mapped your actual workflow is selling a product, not solving a problem. Tool selection follows requirements. If the sequence is reversed, you’re being fitted to a pre-built solution the agency already knows how to sell. That solution may or may not fit what you actually need.
No Exit Clause in the Engagement Letter
Every AI engagement should include a defined exit condition, a point at which you can terminate without paying for work that hasn’t been delivered. If the contract has no exit clause, or if the exit clause requires you to pay 100% of remaining fees on termination, you are locked in regardless of performance. This is not standard. It is a negotiating choice by the vendor. Demand a phased exit with fees tied to completed deliverables, not projected timelines.
Specific Contract Language to Demand (and Language to Strike)
The proposal narrative doesn’t matter. The contract language does. These are the specific clauses to require and the ones to remove.
Performance Baselines and Acceptance Criteria, What to Require
Require a clause that names the performance baseline before the project starts and defines the threshold for acceptance. Something like: “System is deemed accepted when it meets or exceeds the performance baseline defined in Appendix A, as measured over 30 consecutive days of production operation.” Appendix A is where you define the specific metrics, accuracy rate, processing time, error rate, negotiated and agreed before signing.
The “Vendor May Adjust Deliverables” Clause, Strike It Every Time
This phrase, or variations of it, appears in boilerplate AI consulting contracts: “Vendor reserves the right to adjust deliverables, timelines, or technical approach as project requirements evolve.” It means the vendor can change what they’re building whenever they want, for any reason. Strike it. Replace it with: “Any change to deliverables, technical approach, or timeline requires written agreement from both parties prior to implementation.”
Change Order Triggers, What Counts as Scope Change, What Doesn’t
Define in writing what constitutes a scope change requiring a new change order. Bug fixes in delivered work should not be billable as change orders, that’s a warranty issue. A new data source, a new integration endpoint, or a new output format is a legitimate scope change. Get a list of examples in the contract. According to PMI research, projects with formal change management processes are significantly less likely to exceed costs or miss deadlines, the list of examples costs nothing to add and prevents the most common billing disputes.
Phased Contracts: Protection or Trap?
Agencies pitch phased engagements as the safe, low-risk way to work together. “We’ll start with a discovery phase, then move to build.” That framing sounds client-friendly. It isn’t automatically. It depends entirely on what’s written into the phase transitions.
When Phased Scoping Is Legitimate
Discovery phases are legitimate when there’s genuine technical uncertainty, when you need to map an undocumented workflow, audit data quality before committing to an AI approach, or test whether a specific integration is feasible. Paying $5,000–$15,000 to answer those questions before committing to a $60,000 build is reasonable. What’s not reasonable is a discovery phase where the output is a recommendation to buy the build phase from the same agency.
Legitimate discovery produces a scope document you can take to any vendor. If the deliverable from discovery is an internal presentation only the selling agency can act on, it’s not discovery, it’s a paid sales pitch.
How to Negotiate Phase-Exit Conditions
Every phase should have an explicit, measurable exit condition and a defined decision point. Write it in: “At the conclusion of Phase 1, client receives [specific deliverable]. Client may proceed to Phase 2, commission Phase 2 from a different vendor, or terminate. Proceeding to Phase 2 with Vendor requires a separate signed SOW.”
That language gives you real optionality. Most phased contracts don’t include it because it reduces vendor lock-in, which is exactly why you need to put it there. Remember: 49% of AI teams run pilots and only 4% reach production. The phase-exit clause is your protection against being one of the 45% who paid for a pilot but never got a working system. It does not protect you if the delivered work is low quality or the vendor’s team turns over mid-project, which is why the acceptance criteria in every phase need to be specific enough to catch that.
Frequently Asked Questions
What should an AI project SOW include that a regular web project SOW wouldn’t?
An AI SOW needs three things a standard web SOW typically omits: a data source inventory (which systems the AI reads from and writes to), a performance baseline with acceptance criteria (specific metrics, not “system works”), and an explicit model or architecture specification. It should also define what happens when the underlying AI model updates, model behavior changes can break integrations, and who bears that maintenance cost needs to be agreed upfront.
How do I evaluate whether a paid discovery phase is legitimate or just a revenue grab?
Ask one question: what is the deliverable, and who can act on it? A legitimate discovery phase produces a scope document, architecture map, or data audit that any qualified vendor can use. If the agency can’t answer that question clearly, or if the deliverable is “a strategic recommendation”, you’re paying for a sales process, not technical discovery.
What’s a fair change order threshold for AI projects?
Define change orders by type, not dollar amount. Any new integration endpoint, data source, user role, or output format is a scope change. Bug fixes, performance issues in delivered work, and clarifications on already-agreed requirements are not. Establishing this list in the contract costs nothing and prevents the most common billing disputes.
How do I define success metrics for an AI integration before the project starts?
Start with the business outcome, then work backwards to measurable proxies. If the goal is reducing invoice processing time, the metrics are: average time per invoice (before and after), error rate, and percentage processed without human intervention. Set a baseline from your current process before the project begins. Require the vendor to document that baseline with you, if they’re unwilling to, they don’t intend to be held to it.
What exit clause language should I require in an AI consulting contract?
At minimum: the right to terminate on 14 days’ written notice, with payment limited to work completed and accepted per the SOW, not projected remaining fees. Also require that on termination, all work product, code, prompts, and documentation transfer to you within five business days. Some vendors will push back on this. The ones who do are the ones most likely to hold your project hostage. Take that as data.
If you’re looking at an AI proposal right now and it doesn’t name a specific deliverable, a performance baseline, and an exit clause, it isn’t a scope document. It’s a budget commitment with conditions attached later. If you want to talk through what a properly scoped AI project looks like for your operation, start a conversation, we’ll tell you directly what we’d need to see before quoting anything. See how we scope and build this at designodin.com/ai.