Why Your AI Proof of Concept Never Became a Product

A PwC Japan survey across six countries, published in spring 2026, contains the two numbers that describe the situation here better than anything else I have seen.

Adoption of AI among large Japanese companies is 87%. The United States is 90%. There is no adoption problem.

The share saying results exceeded expectations is 9%. The United States is 38%. Japan came last of the six.

So the problem is not getting started. It is what happens after, and in the projects I have been brought into, it fails at the same point almost every time.

A proof of concept is designed to succeed

The purpose of a PoC is to show that something is technically possible. So you arrange the conditions for it. Clean data, a process with few exceptions, and cooperative users who want it to work.

Under those conditions it almost always works. That is not a surprise, and it is not really the finding.

What the PoC has not shown is anything about whether this can be a product. It showed that it works when conditions are arranged, and real operations are never arranged.

Three things that appear on the way to production

The distance between a working PoC and a working product is mostly not technical.

The exceptions. A PoC succeeds if it handles ninety percent of cases. A product has to define what happens in the other ten. What the system does when it is wrong, when it is uncertain, when it has no answer. An AI feature with no design for being wrong stops being used the first time it is wrong in front of someone.

Who is accountable. When the output is incorrect, who owns the consequence. If a human checks every result, then the checking is part of the process, and you have to measure whether the whole thing is actually faster. I have seen several deployments where the review step cost more than the original task.

Where it sits in the work. If using the AI means leaving the tool people already work in and going somewhere else, it will not be used. Not because it is bad, but because it is asking for effort in exchange for convenience, and that trade only works when the convenience is very large.

What the nine percent do differently

The deployments that produce results have something in common, and it is not ambition. It is scope.

One process. End to end. With the person who actually performs that process involved in the decisions.

The ones that stall start from a broad theme spanning several departments. The wider the scope, the more decisions there are, the more people must agree, and the fewer decisions actually get made.

Starting small is not about reducing risk. It is about being able to have one person decide.

Decide these before the PoC, not after

Three things written down in advance change the outcome more than any technical choice.

What result means we proceed. Not "if it looks promising". A number, or a specific operational condition. A PoC with no defined threshold does not progress even when it succeeds, because there is nothing to point at when asking for the production budget.

Whose job changes, and how. Both the people whose work gets easier and the people who acquire a review step. A plan that does not name the second group stalls when it reaches them.

What happens when it is wrong. An AI feature without this defined reliably dies at the approval stage. That is not a technical failure, it is a governance one, and it is entirely predictable.

On the subsidies

From 2026 the IT introduction subsidy was renamed the digitalisation and AI adoption subsidy, with AI explicitly in scope. It covers up to 4.5 million yen, at a subsidy rate of up to three quarters.

Separately, the human resources development subsidy has a reskilling course that covers up to seventy five percent of training costs.

None of that changes anything above. Subsidies reduce the cost, they do not do the scoping. If anything they help, because the application forces you to write down what you are actually going to do before you start, which is exactly the step that gets skipped.

The short version

The distance between 87% and 9% is not capability. It is that designing a PoC to succeed and designing a product to work are two different jobs, and most projects discover this only after the first one has already succeeded.

Decide what happens after the proof of concept before you start the proof of concept. That single change moves you a long way towards the smaller number.