How to Run a Paid Pilot for an AI Project

A pilot with no fee, no deadline and no agreed definition of success is not a pilot, it is unpaid work with a hopeful name. Charging for it changes the outcome less because of the money and more because of what a fee forces into existence: somebody who had to approve it, and who therefore expects to hear how it went. Build the rest around a scope narrow enough to finish in weeks, one success metric written down before you start, and the price of continuing agreed while nobody is under pressure.

Why free pilots die

The failure rate for corporate AI pilots is unflattering and widely cited. MIT Media Lab's NANDA initiative reported in 2025, in a study drawing on 52 executive interviews, 153 leader surveys and 300 public deployments, that roughly 95 percent of generative AI pilots delivered no measurable impact on profit and loss. The coverage of that finding mostly blamed the technology. The report itself pointed at integration and organisational learning.

From the delivery side the pattern is recognisable. A free pilot has no internal owner because nobody had to defend a budget line for it. With no owner, nobody supplies the data, nobody schedules the review, nobody says out loud what would count as success. It ends when everyone is busy, and the word used afterwards is inconclusive.

A fee fixes this less because of the money and more because of what the money forces: an approver, a stake, and a date the approver expects to hear something.

The four things to fix before starting

1. Scope narrow enough to finish. One workflow, one team, one measurable output. Not a platform, not a strategy, not an assessment of where AI could help.

2. A fee that requires approval. Large enough to need a signature, small enough not to require a committee. This is the whole mechanism.

3. One success metric, in writing. Chosen jointly, measurable from data that already exists, with today's baseline recorded before you start.

4. The continuation price. What the full build or the ongoing engagement costs if the pilot works, agreed now, while nobody is negotiating under pressure.

The fourth is the one most people skip and the one that decides whether success converts. A client who sees a good result and then discovers the real number for the first time will go back to procurement, and momentum dies in the queue. Naming it up front also disciplines your scope, because you have to make the pilot representative of the thing you are quoting.

What to charge

Price the pilot as a real piece of work with a real deliverable, not as a discount on the future project. A useful anchor is somewhere between ten and twenty percent of the expected full engagement: enough to require a decision, small enough to be a rounding error against the value if it lands.

Fixed fee, not hourly. Hourly invites scope questions in week two, and a pilot is precisely the phase where you do not want to be relitigating scope. If you are unsure where your number sits, the general logic in what to charge for an AI automation project applies to the pilot as a small project in its own right.

The one metric rule

Agree exactly one number, measurable from data the client already collects, with the current value written down before you start. Not three metrics, not a dashboard. Three metrics means one improves and the argument moves to whether that was the important one.

Good pilot metrics share a shape: they are countable, they are already tracked, and someone would notice if they moved. Median first-response time on support tickets. Hours spent on monthly invoice reconciliation. Percentage of quotes returned within a working day. Bad ones are unfalsifiable: better insight, improved efficiency, greater agility.

Record the baseline yourself, in writing, in week one. Clients routinely misremember their own numbers in the direction that makes the pilot look worse, and without a recorded starting point you have no way to establish otherwise.

Find out who actually wants this

Before you scope anything, work out who inside the client organisation is personally better off if the pilot succeeds. Not who is enthusiastic in the meeting, but who has a number in their own objectives that this moves. If you cannot name that person, you are selling to curiosity, and curiosity does not survive a busy quarter.

Three questions surface it quickly. Whose budget is the fee coming from? Who will present the result internally, and to whom? What happens to that person if nothing changes? An honest answer to the third question tells you whether you have a project or a conversation, and it is worth asking before you spend a week writing a proposal nobody has a reason to approve.

What to put in writing

• The exact workflow in scope, and one line naming what is explicitly out of it

• The success metric, its baseline, and the threshold that counts as a pass

• What the client supplies, with dates. Data access is the usual thing that slips

• Who signs off, by name

• The continuation price and what it buys

• What happens to the code and the data if you do not continue

That last line matters more than its length suggests. A client who fears the pilot creates a dependency they cannot exit will hesitate, and answering it unprompted removes an objection you would otherwise meet in week three. The rest of this belongs in the same document as your usual project proposal, which is where the scope boundary earns its keep.

Ending it on purpose

Pilots should end on a date, with a meeting, and a decision. Not by fading out. Book the review meeting at the start, before anyone has an incentive to avoid it.

1. Present the metric against its baseline first, before any narrative about what you learned.

2. State plainly whether the threshold was met. Resist the urge to reframe a miss as a partial success.

3. If it passed, ask for the continuation decision in that meeting, at the price already agreed.

4. If it failed, say what you would change and what it would cost to test that. Sometimes the honest answer is that this workflow is not the one.

5. Either way, leave them a written summary they can forward. Most decisions get made by someone who was not in the room.

A pilot that fails cleanly and is documented well is a better business development asset than a vague success, and it is frequently the thing that turns into a case study worth putting in front of the next client. It also protects the relationship, which usually outlives the project, and paid pilots sit naturally alongside the other ways to make money with AI work rather than replacing them.

One thing to check before you scope

If the workflow touches hiring, credit, essential services or anything else that lands in a regulated category, the obligations attached are not a pilot-stage detail. The EU AI Act's high-risk regime became enforceable in August 2026, and discovering during the continuation conversation that production carries duties you did not price is an avoidable way to lose the deal.

Questions people ask

What if the client refuses to pay for a pilot?

Sometimes it is a budget cycle problem worth waiting out. Often it signals the internal sponsor lacks authority, which is exactly the situation where a free pilot goes nowhere. A smaller paid scope is a better response than a free full one.

How long should a pilot run?

Long enough to gather real data, short enough to stay in one attention span. Two to six weeks covers most cases. Anything past two months has stopped being a pilot and become an unpriced project.

Should the pilot use production data?

Where it can be done lawfully, yes, because synthetic data hides the mess that determines whether the thing actually works. Agree access in week one and treat delays as a schedule risk, since data access is the single most common reason a pilot overruns.

What if it works but they still do not continue?

Usually the metric was not one the decision-maker cared about, which is a lesson about metric selection rather than about delivery. Ask what would have made it obvious, and use the answer to pick better next time. The pre-agreed continuation price at least means the reason was not sticker shock.