What Should Be in an AI Consulting Proposal or Statement of Work?
Gartner expects at least 30% of generative AI projects to be abandoned after proof of concept. A tight proposal and statement of work is what keeps the delivery risk with your supplier, not you.
By Ivan Pylypchuk, CEO of SoftBlues. Has led Claude implementations for finance, legal and healthcare teams across the UK and Ireland.
A strong AI consulting proposal or statement of work (SOW) fixes eight things in writing: the business problem, the exact scope, the deliverables, milestones with dates, acceptance criteria, data handling and security, who owns the IP, and how either side can exit. If any of those is vague, the risk sits with you, not the supplier.
At SoftBlues, an AI consulting firm working with regulated mid-market companies across the UK and Ireland, we read and write these documents every week. This guide is the checklist we wish more buyers used before signing, so the contract protects you rather than the person who drafted it.
Key facts
Who this is for, and who it isn't
This is for a 50 to 500-person UK or Ireland firm, often in finance, legal, healthcare or professional services, reviewing its first serious AI proposal and deciding whether to sign. If you buy technology rarely and the numbers are large enough to matter, read on.
It is not for a solo founder who wants a weekend prototype, or for a large enterprise with an in-house procurement and legal team that already runs a mature vendor process. You will find parts of this obvious.
What is a statement of work, and how is it different from a proposal?
A proposal is a sales document. It describes the problem, the approach and the price, and it exists to win your signature. A statement of work is the operational contract underneath it: the specific list of what will be built, by when, to what standard, and what happens if it is late or wrong.
The two often arrive as one PDF, which hides the distinction. Read them as separate things. Ask yourself of every claim in the glossy proposal section: is this also written down in the SOW in a way I could hold someone to? Marketing language such as "transform your operations" belongs in the proposal. It should never appear in the scope.
Why does an AI project need a tighter SOW than an ordinary software project?
Because the output is probabilistic and the goalposts move. A traditional software feature either works to spec or it doesn't. An AI system produces answers that are right most of the time, and "most of the time" is exactly the number you need to agree in advance.
Gartner's own explanation for the abandonment rate above is that "as the scope of initiatives widen, the financial burden of developing and deploying GenAI models is increasingly felt" (market: Gartner, July 2024). Scope creep is the default failure mode. A tight SOW is the main thing standing between a fixed budget and an open-ended research project you are quietly funding.
What are the essential clauses every AI consulting SOW should contain?
Work through these eight before you sign. If a clause is missing or vague, that is where the argument will happen later.
1. The problem statement. One or two sentences naming the business problem and the measurable outcome, for example "cut invoice processing time from four days to one". Vague purpose leads to vague delivery. If the SOW opens with the technology rather than the problem, push back.
2. Scope and exclusions. What is in, and just as important, what is explicitly out. The exclusions list is the most valuable part of any SOW. Good suppliers write down what they are not doing so nobody assumes it later.
3. Deliverables. Named, countable things you will receive: a working integration, a trained assistant, documentation, a handover session, source code. "A solution" is not a deliverable. "A Claude assistant deployed to your finance team's Slack, with an admin guide and two hours of training" is.
4. Milestones and dates. A short timeline with real dates and what is due at each. This is how you spot slippage in week three rather than month three.
5. Acceptance criteria. The measurable test each deliverable must pass before you accept and pay for it. For an AI system this usually means an accuracy or quality threshold on an agreed sample, plus who signs it off. Agree the target and the test data before work starts.
6. Data handling and security. Which of your data the supplier touches, where it is processed and stored, how long it is kept, and what happens to it at the end. This clause should reference UK GDPR and name the sub-processors (for example the model provider). More on this below.
7. IP ownership. Who owns the code, the configuration, the prompts and any fine-tuned model at the end. Get this in writing before, not after.
8. Exit and termination. How either side ends the engagement, what you keep, and whether you can take the work to another supplier. An engagement you cannot leave is a dependency, not a partnership.
How should the SOW handle your data and security?
For a regulated firm this clause is where a proposal is won or lost. It should state, in plain terms, exactly which data the supplier and any AI model will see, where that processing happens, and how long anything is retained. It should confirm your data is not used to train third-party models unless you have explicitly agreed to it.
Name the framework your compliance team will ask about. In the UK that means UK GDPR and the Information Commissioner's Office (ICO) as the regulator, plus your sector rules on top: the FCA and SM&CR in financial services, the SRA in law, or the CQC and clinical-safety standards in healthcare. A supplier who cannot answer where your data goes should not get near it. Ask them to state whether they follow ISO 27001 principles and whether they are certified, and treat those as two different answers.
Who owns the IP, the model, and the prompts?
This is the clause buyers most often skip and later regret. Three questions settle it. Do you own the code and configuration that is written for you? Do you own the prompts, the system instructions and any fine-tuned model produced with your data? And can you keep running everything if the relationship ends?
The honest default for a fixed-price build is that you own what you paid to have built, while the supplier keeps its own pre-existing tools and general know-how. That is reasonable. What is not reasonable is discovering that the assistant running your operations lives inside the supplier's account and leaves with them. Read our take on the questions to ask before you sign for the wider list.
How should pricing and payment be structured?
There are three common models, and each puts the risk of an overrun in a different place. The table below is the trade-off in one view.
| Pricing model | How it works | Best for | Avoid if |
|---|---|---|---|
| Fixed price | Agreed scope, agreed price, supplier absorbs overruns | A well-defined build with clear acceptance criteria; first-time buyers who want budget certainty | The scope is still genuinely unknown, in which case you will pay a risk premium or get a padded quote |
| Time and materials | You pay for time spent, usually against a cap | Genuine discovery or research where scope cannot be fixed yet | Nobody is managing the burn rate, or there is no cap and no reporting |
| Retainer | A monthly fee for ongoing capacity or support | Continuous improvement and support after a build ships | You have a one-off project with a clear end |
For a first engagement with a defined outcome, fixed price protects you best because the supplier carries the risk of getting it wrong. Tie payments to the milestones and acceptance criteria from the SOW, not to the calendar. You should never pay for a deliverable you have not accepted. For realistic numbers behind each model, see our breakdown of AI consulting costs in the UK.
What acceptance criteria and exit clauses actually protect you?
Acceptance criteria turn "we think it's good" into a test. For an AI assistant, a workable criterion reads like: "on an agreed 100-item test set drawn from your real cases, the assistant reaches the target accuracy, a named person reviews the sample, and payment for that milestone follows sign-off." Agree the sample and the threshold before work begins, or acceptance becomes an opinion.
Exit clauses matter because AI engagements create operational dependencies fast. A good SOW says how either side can end things, how much notice is required, what you keep (code, configuration, data, documentation), and that the supplier will support a reasonable handover. If leaving is expensive or undefined, factor that into the decision now.
What does a well-scoped engagement look like in a regulated sector?
A UK financial-advice firm we scoped wanted to speed up its monthly compliance file reviews, a slow, rules-heavy task with real regulatory weight. The SOW named the exact task, fixed the scope to file review only, set an accuracy threshold on a sample of real files with a compliance officer signing off, and kept a human in the loop for every decision. Data handling and retention were written down and mapped to FCA expectations. You can see how we approached that compliance file-review work as an anonymised discovery engagement.
The point is not the technology. It is that every risky assumption was written into the scope and acceptance criteria before anyone built anything.
Red flags in an AI consulting proposal
Frequently asked questions
What is the difference between a proposal and a statement of work?
A proposal is the sales document that describes and prices the approach. A statement of work is the contractual detail underneath it, fixing scope, deliverables, dates, acceptance criteria and price. The proposal persuades; the SOW is what you can enforce.Should an AI consulting engagement be fixed price or time and materials?
For a defined outcome with clear acceptance criteria, fixed price protects a first-time buyer best because the supplier carries the overrun risk. Time and materials suits genuine discovery where scope cannot be fixed yet, but only with a cap and regular reporting.Who should own the AI models and prompts after the project?
For a fixed-price build, the sensible default is that you own the code, configuration, prompts and any model produced with your data, while the supplier keeps its own pre-existing tools. Confirm it in the SOW before work starts, not after.What data protection clauses should an AI SOW include?
It should name UK GDPR, identify sub-processors such as the model provider, state where data is processed and stored and for how long, and confirm your data is not used to train third-party models without consent. Regulated firms should also map it to their sector rules (FCA, SRA or CQC).How detailed do acceptance criteria need to be for AI work?
Detailed enough to test. For an AI system that means an agreed quality or accuracy threshold on a named sample of real data, plus who signs it off. Agree the sample and threshold before the work begins.What is a realistic number of milestones for a first AI project?
For a 90-day engagement, three to five milestones works well: discovery and scope sign-off, a first build, testing against acceptance criteria, and handover. Enough to spot slippage early without drowning the work in admin.Can I take the work to another supplier if it doesn't work out?
Only if the SOW says so. Look for an exit clause that lets either side end the engagement with notice, confirms you keep the code, configuration, data and documentation, and commits the supplier to a reasonable handover.We put Claude into production for regulated UK and Ireland teams in 90 days, at a fixed price, with acceptance criteria and data handling written into the scope before anyone builds anything. We are a registered Anthropic Partner Network member and a Google Cloud Partner, and we work as practitioners rather than slide-writers. If you want a second read on a proposal or SOW you have received, or a shortlist to compare it against, start with how to compare AI consulting proposals and delivery risk.
