Ask three vendors what an AI pilot costs and you will get $8,000, $45,000, and "let's discuss". They are describing different objects. The first is a demonstration, the second is a working system, and the third is a discovery call. Knowing which one you are buying is most of the battle.
What follows is the shape of a pilot that ends with software running in your business, based on how these engagements actually decompose.
Where the money goes
The single most common budgeting error is assuming the model is the expensive part. It rarely is. Here is roughly how a $40,000 pilot on one workflow distributes.
| Phase | Share of budget | What it covers |
|---|---|---|
| Scoping and data access | 15 to 20 percent | Defining correct output, finding where the data lives, getting credentials and permissions |
| Integration | 30 to 35 percent | Reading from and writing to the systems the workflow touches, error handling, retries, auth |
| Model and prompt work | 10 to 15 percent | Prompt design, structured output, retrieval if needed, model selection |
| Evaluation harness | 15 to 20 percent | Building a labelled test set, scoring, regression checks, quality dashboard |
| Deployment and guardrails | 15 to 20 percent | Monitoring, cost ceilings, escalation paths, human-in-the-loop interface, handover |
Notice that the two line items people imagine to be the project, prompts and models, are together about a quarter of the work. The rest is the unglamorous business of connecting to real systems and proving the thing is right. That ratio is why a pilot priced as an experiment cannot become production software: the parts that were cut are precisely the parts production requires.
Ongoing inference cost is usually a rounding error against staff time at pilot volumes. For a workflow processing a few thousand items a month, expect tens to low hundreds of dollars monthly. Model it, set a hard ceiling, and then stop worrying about it, because the expensive resource is engineering attention, not tokens.
What the price bands actually buy
| Budget | What you get | Honest use |
|---|---|---|
| Under $15,000 | A prototype on sample data, run by hand | Convincing a sceptical board that the capability exists |
| $25,000 to $60,000 | One workflow live in production, evaluated, monitored, documented | Getting a real number for hours or errors removed |
| $60,000 to $150,000 | Two or three connected workflows, shared infrastructure, internal tooling | Expansion after the first workflow proved out |
If your budget is genuinely under $15,000, that is fine, but buy the prototype knowingly. Do not expect to deploy it, and do not let anyone plan around it as though you will.
Why most pilots never reach production
The failure is almost never technical. Four patterns account for the overwhelming majority.
1. Nobody owns the workflow
The pilot is sponsored by a technology function on behalf of an operations team who were not asked. It works, and then nobody changes how they do their job, because no one whose targets depend on it was ever accountable for adoption. Name an operational owner before the first line of code, and give them a say in the definition of done.
2. There was no success metric agreed in advance
Without a number set beforehand, evaluation collapses into taste. Someone finds three bad outputs, the room's confidence evaporates, and the project is quietly not renewed. Agree in writing what result justifies expansion, what result means stop, and who decides.
3. It ran on exported data
A pilot fed by a spreadsheet someone exported is a pilot that has skipped the hardest part. Live systems have permissions, rate limits, malformed records, and users doing things nobody documented. If the pilot has not touched the real system, the remaining work is not a deployment step, it is the majority of the project.
4. The budget covered the demo, not the delivery
The money ran out at the moment the interesting part was finished and the necessary part began. This is the most preventable failure on the list: fund the evaluation harness and the guardrails in the original scope, or accept that you are buying a demo.
A pilot scope worth paying for
A defensible pilot scope fits on one page and contains all of the following. If a proposal is missing two or more, ask why before signing.
- One named workflow, with the boundary of what is in and out stated explicitly.
- A named operational owner on your side, not only a technical one.
- A written definition of a correct output, agreed by a subject-matter expert.
- A labelled test set drawn from your real data, and a target score.
- Live integration with the systems the workflow actually uses.
- A human-in-the-loop step wherever a wrong output would be expensive.
- Cost ceilings and monitoring, with an alert when either is breached.
- A defined end date and an explicit expand or stop decision at it.
- Handover documentation and a walkthrough with your team.
How to judge the result
At the end, you are looking for one number and one capability. The number is hours or error rate removed from a real process, measured the same way it was measured before. The capability is whether someone on your team can now run, monitor, and modify the system without the vendor.
If you have both, expansion is a straightforward commercial decision and the second workflow will cost materially less than the first. If you have a demo and a slide deck, you have spent a quarter learning that the capability exists, which you already knew.