What should an AI proof of value include before it starts?

An AI proof of value should include, written down before any work begins, the decision it will improve, how that decision is made and measured today, the person who owns the result, the full cost including running it afterwards, the bar for success and who judges it, and what happens when the bar is met or missed. If none of that is written down, the proof cannot fail, and a proof that cannot fail proves nothing.

Why do buyers walk away from AI pilots?

Buyers walk away when they cannot see where a pilot ends. Buyers raised this directly in our introductory calls over the past year. Between them they objected to savings estimates they had no way to check, to the risk of paying indefinitely for overruns, and to a paid discovery that ends in a much bigger proposal. One of them wanted clear cost and timing settled before anything else was discussed.

Their objections were about the shape of the commitment, and all of them came before anyone had asked what the software does. At Unloq we call the habit decision intelligence replaces the confident guess, and an open-ended engagement is an expensive version of it, because the money is committed before anyone has measured the value.

What is the difference between a proof of concept and a proof of value?

A proof of concept asks whether the thing can work at all; a proof of value asks whether it is worth paying for, measured against your own numbers. A value proof has to run on your data, inside the decision it claims to improve, with the people who make it, and then beat what they were doing before. That last condition needs something to compare against, which is the baseline.

What should be agreed in writing before an AI proof starts?

Agree each row of this table in writing and keep the page, because the result gets judged against it at the end.

The decision should fit in one sentence a finance director would recognise. “Which accounts the sales team calls first each week” works, and it is the example used below.

The baseline is the row that gets skipped, and writing it down is work in its own right. You have to find out who makes the call today, what they look at, how long it takes and how often it turns out well, and those answers usually live in somebody’s head or in a spreadsheet one person opens. For the sales example, the baseline is how this week’s call list gets built, who builds it, how many hours it takes and what last quarter’s conversion on that list was. In our experience the first real disagreement of an engagement turns up here, because finance and sales have been measuring the decision in two different ways, and settling it eats into time you had planned for the pilot. We would still spend that time, though we have no trick that makes the step quick, and we understand why a team under pressure is tempted to start without it.

HM Treasury’s Evaluation Task Force reached a similar view in its Magenta Book guidance on evaluating AI, updated in May 2026, which tells departments to document precisely what the business-as-usual consists of before the AI arrives. The guidance is written for civil servants, and its worked example imagines 12 grant officers spending four weeks assessing funding applications, but the principle crosses into a commercial team without much translation. Once the baseline exists, every figure in the result should trace back to it or to an assumption both sides signed, and the case for stopping deserves as much testing as the case for carrying on. That is also how Unloq goes on tracking outcomes against a baseline after a pilot ends.

The owner is one named person on your side who will act on the output and answer for what happens. In the sales example, that is whoever opens the output on the morning the call list is due.

The cost covers the pilot and what it would cost to run afterwards, and the second figure is the one you will live with.

The bar holds the success criteria for the pilot, and it should be a number, set before anyone sees a result, because a threshold chosen afterwards will always be met, and the people judging it should be your team. Be plain with each other about what six weeks can show: that the output was reliable, that the owner used it, and that it beat the baseline on a leading measure. It will rarely show that a recommendation caused a change in revenue, because a figure moving after a recommendation does not on its own prove the recommendation moved it, which is why so few AI adopters can prove what it changed. Agree which leading measure stands in for the financial outcome, and write down what will still be unproven at the end. We have not found a way to close that gap inside a short proof.

The conversion should be written down now: what production looks like if the bar is cleared, and how a clean stop works if it is not, including what you keep.

How long should an AI proof of value take?

An AI proof of value, or pilot, should run long enough for the decision to come round more than once and short enough that the cost stays bounded. Dart AI, which publishes guidance on AI proofs of concept, says to complete POC in 6-12 weeks maximum. Ours runs six.

We disagree with Dart on one point. Its guide suggests you allocate 10-20% of the anticipated production budget to the proof, which ties the size of the test to the size of a purchase you have not yet decided to make.

A quarterly decision may come round only once in six weeks, and our working answer there is to agree a leading measure up front.

How do we bound our own first engagement?

Our first engagement is bounded for the reasons those buyers gave. You choose one decision domain, and the work runs for six weeks alongside what you already run. Unloq is hosted in your cloud or ours, with read-only access either way. The bar is agreed in writing at the start and judged by your team, and the scope and full running cost are agreed before any work begins.

Some businesses want to begin one step earlier, before they have picked a decision. If that is you, ask us a question before you commission anything, because that conversation is worth having. We still run AI Discovery work for some clients, and Kevin Justice, CFO at Republic M, put it this way about his: “Their methodology gave us a clear view of our AI maturity, a practical roadmap for adoption, and a set of prioritised, fully scoped use cases.”

When should you not run a proof of value?

Do not run a proof of value if you cannot name the decision or its owner, because a pilot will not supply either. Spend the time naming both, which is useful work whatever you go on to buy.

Budget is the other test. Check there is a budget line and a rough date for production before you start.