Artificial intelligence
What a proof of value should actually prove
Most AI pilots succeed and go nowhere. Usually because nobody agreed, before the build, what result would justify funding the next stage, so the demo becomes an opinion rather than a decision.
Key takeaways
- A demo proves capability once. A proof of value proves repeatability at a measured quality on your own data.
- Write the success criteria before the build, or the result becomes a matter of opinion.
- A labelled evaluation set is the deliverable that outlives the pilot. It is how you measure every later change.
- Measure the exception path, not just the happy path: what the system does when it is unsure is the thing that decides whether it can run unattended.
- "It worked" is not a result. "It handled 340 of 400 real cases at 96% accuracy, routing 60 to a person" is.
A striking number of AI pilots succeed and then go nowhere. The technology worked, everyone in the room was impressed, and eighteen months later it is still a pilot. The failure is almost never technical. It is that nobody agreed in advance what the pilot needed to show in order to justify the next cheque.
So the demo lands, and the conversation that follows is about impressions rather than evidence. Impressions do not survive a budget cycle.
A demo and a proof of value are different things
A demo answers: can this be done at all? It runs on data somebody chose, in a session somebody controlled, and it is genuinely useful for deciding whether an idea is worth pursuing. It is also the cheap half.
A proof of value answers a harder question: will this hold up on the fiftieth run, against the messy end of your own data, at a quality you can put a number on, and what happens on the runs where it does not?
Anyone can get a good answer out of a chat window. The hard part is getting the same quality of answer from five different people, every time, six months from now.
Agree the criteria before the build
Before any code is written, we want four things written down and agreed by the people who will decide the outcome.
- 01The decision this pilot informs. Usually: do we fund production, and at roughly what scale? If nobody can name the decision, the pilot has no job.
- 02The measure and the threshold. Not 'improve accuracy' but 'extract these nine fields at 95% or better across a representative sample'. State the number you would accept before you know the result.
- 03The sample. A realistic slice of real data, including the awkward cases. A pilot run on clean examples measures the examples, not the system.
- 04The cost of being wrong. What a false positive actually costs here, and what a missed case costs. This is what sets the confidence threshold and decides where a person has to sit in the loop.
The number to be most suspicious of
An accuracy figure quoted without a denominator. 'It got them all right' means very little until you know how many there were, whether they were representative, and how the hard ones were counted.
Build the evaluation set that outlives the pilot
The most valuable artefact a proof of value produces is rarely the prototype. It is the labelled test set: a body of real cases with the correct answers recorded, agreed by the people who know what correct looks like.
That set is what turns quality from an impression into a number you can track. It is how you tell whether next quarter's model change helped or hurt, whether a prompt revision actually improved anything, and whether performance has drifted since go-live. Build it during the pilot and you own it permanently. Skip it and every future change is a guess.
Measure the exception path, not just the happy path
Most pilots are demonstrated on the cases that work. The cases that decide whether something can run unattended are the other ones.
- What does it do when confidence is low? Does it stop, or does it guess confidently?
- Where does an uncertain case go, and does it arrive with enough context for a person to resolve it quickly?
- Does the resolution feed back, so the same class of case is handled better next month?
- Is every decision logged with its inputs and its reasoning, in a form that would satisfy an auditor rather than a colleague?
What a good result reads like
"It worked really well" is not a result. This is:
A result you can act on
Across 400 real cases from the last quarter, it processed 340 end to end at 96% field-level accuracy, routed 60 to a person for review, and logged every decision. Two error classes account for most of the failures, and both are addressable.
That sentence is a decision, not an impression. It tells you what to fund, what to fix first, and where a person still needs to sit. It also tells you honestly if the answer is no, which is a perfectly good outcome for four to six weeks of work, and considerably cheaper than finding out in month nine.
The short version
Decide what the pilot has to prove before you build it. Measure against real data including the hard cases. Keep the evaluation set. Test the exception path as seriously as the happy path. And be willing to accept a clear no. A pilot that ends a bad idea early has done its job.
Read next
Why the guardrails are the expensive part of an AI agent
Getting a model to read a document well is the afternoon. What makes it safe to run unattended is everything around it, and that work costs the same whether the agent is for one client or fifty. Which is precisely why it keeps getting skipped.
Governance decisions that are cheap on day one
Nobody books a governance workshop. It arrives later as a question from an auditor, a client security review or a privacy complaint. Four decisions cost close to nothing at the start and a great deal once there is data in the system.