You are reading the proposal. The fee is in the band you expected. The scope says “build a working AI pilot for client onboarding.” The success measure says “improved efficiency.” The timeline says “approximately 8 to 12 weeks.” It looks fine. It is not fine.
This is the most common pattern I see in AI pilot proposals across the UK SME market. The fee is sized correctly. The deliverable list is vague enough that the consultant can deliver almost anything and call it complete, and the buyer cannot prove otherwise. Nine specific items separate a proposal that protects your investment from one that does not, and they apply across every price band from £10,000 freelance to £60,000 agency.
Why do most pilot proposals look fine and aren’t?
The fee tells you nothing about whether the engagement will deliver. MIT’s NANDA research published in August 2025, drawing on 150 interviews and a 350-employee survey, found that 95% of GenAI pilots delivered zero ROI. The headline number is alarming. The diagnostic underneath it is more useful: most pilots fail on specification, not on technology. The model trains, the prototype runs, and the deliverable technically lands. The pilot still produces no operational value because the specification did not require it to.
Specification is what separates the 5% of pilots that work from the 95% that do not, and specification is what you control at proposal stage.
The nine specs that protect your investment
Nine items belong in any AI pilot proposal regardless of price band. Each one closes a specific failure mode that surfaces in the post-mortem of pilots that did not deliver.
Bounded scope is the first. One use case. One data source. One stated boundary, written into the Statement of Work. A scope that says “build an AI pilot for client onboarding” is too broad to fail or succeed; a scope that says “classify incoming client documents into one of five intake categories with at least 90% precision” is testable.
Audited data is the second. Joint review of data quality before the fee is fixed, with an agreed acceptable quality threshold for the pilot. Most pilots that stall do so because the data turned out to be worse than anyone assumed, and the audit moves that conversation from week six to week zero.
Quantitative success metrics are the third. Tied to outcomes you can actually measure, agreed before work begins, written into the contract. Not “improved efficiency” but “reduce manual effort by 40% on the named workflow” or “achieve 90% precision on the test dataset.” If the metric is not measurable, the pilot cannot be honestly assessed.
A mid-engagement go/no-go gate is the fourth. A defined review point at week four or five with explicit pivot, continue, or exit options, and pro-rata payment if either party exits. This single spec is the most important one in the list, and it gets its own section below.
A trained model with comprehensive runbook is the fifth. Delivered in artefact form, not slide form. The model itself, the input format, the operating procedure, and the limitations all in writing. A pilot whose deliverable is a slide deck is not a pilot, it is a proof-of-concept presentation.
Five to ten hours of hands-on knowledge transfer is the sixth. With a named internal owner who will run the deliverable after the consultant leaves. Without the named owner and the transfer time in the proposal, the pilot will be operationally orphaned the day the consultant leaves.
A written exit report is the seventh. Results against the named metrics, lessons learned, scaling estimate, all in writing and delivered to the client. The exit report is what makes the pilot defensible to the board and reusable for the next engagement.
Full client ownership of code, weights, and documentation is the eighth. You own the artefacts. You can take them elsewhere if you choose. You can maintain them yourself. Without ownership, the pilot becomes a hostage; you cannot walk and you cannot scale on your own terms.
No scaling lock-in is the ninth. The contract should not require you to use the same consultant for production scaling. If the pilot succeeds, you may want to. If it does not, you need the freedom to take a different path.
Why is the mid-engagement gate the single most important spec?
The mid-engagement go/no-go gate is the spec that converts a fixed-fee gamble into a structured experiment. Without it, the buyer pays the full fee regardless of how the work is going at week five, when most of the early signal about whether the pilot will work has already arrived. With it, the buyer has a defined exit at the moment when a continuing engagement would be throwing good money after bad.
A 2025 analysis of 127 enterprise AI implementations found that phased delivery succeeded 89% of the time against 27% for traditional waterfall delivery. The mid-point gate is what turns a fixed-fee pilot into a phased delivery, and the difference in success rate is the reason it belongs in every proposal.
What ownership and lock-in look like
Ownership and lock-in are the two specs most often missing from pilot proposals, because they protect the buyer at the consultant’s expense. A consultant who hosts your trained model on their infrastructure, requires you to use their team for any modification, and prices the production rollout as a separate engagement is in a strong position when the pilot completes. The buyer is in a weak one.
Three sentences in the contract close this gap. Client owns all code, model weights, training data documentation, and operational runbooks. Client can take all artefacts to any vendor for production scaling without penalty or licence transfer cost. Consultant retains no exclusive rights to the deliverable. Three sentences. Most contracts do not contain them, and the buyer who does not ask for them often finds out at month nine that they are tied in.
How to use these specs at proposal stage
You do not need to redraft the consultant’s proposal. You need to compare it against the nine specs and ask for what is missing. The conversation is straightforward and rarely adversarial.
Read through the proposal once, marking each of the nine specs as present, partial, or missing. Take the list back to the consultant. Ask what they would need to add to the proposal to cover the partial and missing ones. A good consultant will respond constructively. They have heard these questions before and will adjust the language without changing the fee, because the specs are mostly about how the work is described rather than how much of it gets done.
A consultant who pushes back hard on most of the nine specs is telling you something. Either they have not done a proposal at this level of rigour before, or they prefer the looser version because it gives them more room. Both are reasons to be careful about signing.
When to push back, when to walk away
One missing spec is normal. Two missing specs is workable if the consultant is willing to add them. Three or more missing specs is structural, and the proposal is biased toward the consultant rather than the engagement.
If the mid-engagement gate is missing and the consultant will not add it, walk. That single spec does more to protect the buyer than the other eight combined. If ownership of artefacts is missing and the consultant will not concede it, walk. That spec determines whether you control the asset or rent it. The remaining seven are negotiable. The two structural ones are not.
The nine specs are not a gotcha list. They are what fair proposals already contain at the senior end of the UK market, and what most proposals do not contain because most consultants prefer the looser version. Asking for the rigorous version is buyer protection, and the conversation about what is missing usually tells you more about the consultant than the deliverables list does.
If you would like to talk through how a fair AI pilot proposal looks for your situation, book a conversation.
