How to approve an AI PoC: what the board should demand

The short answer

A proof of concept is not a smaller product. It is a controlled experiment designed to reduce uncertainty before you commit real money. Approve it only when it has a clear question, a pass mark agreed in advance and a path to production if it passes.

Why most PoCs go nowhere

Most PoCs are approved as a way to try the technology. They end with a demo that looks good, a report that says it is promising, and no decision. Six months later the same company approves another PoC on a different idea.

The problem is not the technology. It is that nobody wrote down, before starting, what result would justify the next investment.

Six things to demand before approving

• The question: one operational problem, stated in business terms, with what it costs today.
• The success criteria: the metric, the baseline and the target that count as a pass, signed off by whoever owns the budget.
• The data: confirmation that the data needed exists, is accessible and can legally be used.
• The integration: which systems the PoC must touch to be realistic, even in a thin version.
• The failure modes: what happens when the system is wrong, and who reviews it.
• The path to production: what it would cost and how long it would take to go live if the PoC passes.

What a good PoC measures

A good PoC measures two things. The first is technical quality: how often the system is right, how often it is wrong, and how fast it answers. The second is operational value: how many hours, losses or days of waiting it removes in a real slice of the process. The scale decision should rest on the second, not on the first alone.

How long and how much

A focused PoC usually takes four to six weeks. Longer than that and it tends to become an unplanned build. The cost should be small relative to the loss it addresses; if it is not, the problem is probably too small to be worth solving.

A one-page PoC brief

Before signing, ask for a one-page brief that answers, in plain language:

• Which process, and what it costs today, with the source of the number.
• The metric that will decide the result, its baseline and the target.
• The data that will be used, who owns it and whether it can legally be used.
• Which systems the PoC will touch and who on your side will give access.
• Who reviews the system's mistakes during the test.
• What production would cost and take if the PoC passes, as a range.
• The date of the decision meeting.

If a provider cannot fill this page, the PoC is not ready to start.

Mistakes that waste a PoC

Testing on clean demo data. The result will not hold on real data, so test on a real slice of the operation, with its mess.

Changing the question halfway. If the problem turns out to be different, stop and write a new brief, rather than stretching the PoC.

Nobody from the business involved. If the people who own the process are not in the review, the decision at the end will not be trusted.

No decision meeting in the calendar. Book it on day one. A PoC without a decision date drifts into a pilot that never ends.

The decision at the end

At the end there are only three honest outcomes: scale, adjust and retest, or stop. Decide in advance which result leads to each one. A PoC that fails clearly is a good use of money; a PoC that ends in "promising" is not.