The AI proof of concept in 2026: what it should produce, what it costs, and when not to run one

No research firm publishes a benchmark for what an AI proof of concept costs or how long it takes. What is documented is that the average organisation scraps 46% of them. Here is the method, and the no-go condition to agree before you start.

A proof of concept exists to produce a decision, not a demo. Two to four weeks, on your own data, ending in a go or no-go that someone will actually sign.

Before the method, one thing worth saying plainly, because almost every article on this topic gets it wrong.

Nobody publishes a benchmark for this

We went looking for what an AI proof of concept costs and how long one takes. There is no research firm, academic body or industry association that publishes either figure. Every "a PoC costs $50,000 to $250,000" page on the open web is a development shop quoting its own price list and dressing it as an industry number.

So what follows is our own method, presented as ours. What is not ours is the failure data, and that is well evidenced.

How often this goes wrong

How often proofs of concept do not become production

Four sources, four methodologies. The direction is consistent.

Source: S&P Global via CIO Dive, March 2025; Gartner, January and April 2026; Deloitte State of AI in the Enterprise 2026.

The trajectory matters more than any single number. Gartner predicted in 2024 that 30% of generative AI projects would be abandoned after proof of concept. By January 2026 its assessment was that more than 50% had been. S&P Global, surveying over 1,000 organisations, found the average company scrapped 46% of its proofs of concept and that 42% abandoned most of their AI initiatives in 2025, up from 17% a year earlier.

You will also see a claim that 95% of AI pilots fail. It comes from a July 2025 preprint built on 52 interviews and 153 survey responses collected at conferences, it measures "getting zero return" rather than failure, and its authors were commercialising the systems it recommends. It is the most quoted statistic in this category and the weakest. The Gartner and S&P figures make the same point and survive scrutiny.

Why they fail

Why they fail, according to the people who ran them

Cited by leaders reporting AI use case failures. Respondents could cite more than one.

• Unrealistic expectations, expected too much too fast
• Persistent skill gaps
• Poor data quality or limited data availability

Source: Gartner press release, 782 infrastructure and operations leaders surveyed November to December 2025, published April 2026.

The most human finding is Gartner's April 2026 survey of 782 infrastructure and operations leaders: among those reporting failures, 57% cited unrealistic expectations, described as expecting too much too fast. Only 28% of use cases fully succeeded and met ROI expectations, and 20% failed outright.

Notice how few of these causes are technical. Data readiness appears, but lack of business value, cost surprises, governance as an afterthought and change management are organisational. A proof of concept that only tests whether the model works is testing the thing least likely to be the problem.

What a two-to-four week proof of concept should produce

What a two-to-four week proof of concept should hand over

A decision and the evidence behind it. Not a demo.

• Measured accuracy on your data, not the vendor's. Whole-task success rate, counted on a representative sample including the difficult cases.
• Where the failures cluster. By document type, customer segment, edge case. The pattern matters more than the rate.
• A unit cost you can multiply by your volume. Built bottom-up from published list prices plus the human time the system could not remove.
• The no-go condition, written before you started. A threshold agreed in advance is worth more than any analysis produced afterwards.
• A named person who makes the decision. If you cannot fill this in at the outset, do not start.
• A working demo and nothing else. This answers the easy question. It is not a proof of concept.

The test of a good proof of concept is whether a no-go is as useful as a go.

Source: Thinklytics AI readiness practice, 2026. Presented as our own method; no research body publishes a PoC standard.

The test of a good proof of concept is whether a no-go is as useful as a go. If the only acceptable outcome is proceeding, it was a procurement exercise with extra steps.

When not to run one

If the blocker is already known and is organisational, skip it. Four teams defining revenue three ways is not a hypothesis that needs testing, it is a decision that needs making. Gartner's April 2026 finding that organisations with successful AI initiatives invest up to four times more as a share of revenue in data and analytics foundations points the same direction: the foundational work is not a detour from the AI programme, it is the part that determines whether there is one.

A proof of concept is for genuine uncertainty. Whether the model can read your documents well enough. Whether the signal is in your data at all. Whether the team will use the output. Those are worth two weeks. Whether your data is messy is not, because you already know.

What we would do first

Write down the decision the proof of concept is meant to unlock, and who makes it. If you cannot name the person, stop there. Then write the no-go condition before starting, because a threshold agreed in advance is worth more than any amount of analysis afterwards.

Our AI readiness assessment is the version of this that runs before a build decision, and the AI Opportunity Finder ranks candidate use cases by impact against effort in about three minutes if you are still choosing what to prove. For the data-layer prerequisites that decide most of these, see what production AI automation requires from data.

Frequently asked questions

How long should an AI proof of concept take?

Two to four weeks for a go or no-go on your own data. That is our own scoping standard rather than an industry benchmark, and it is worth saying plainly that no research firm publishes a PoC duration benchmark. The only traceable duration data is MIT NANDA's finding that mid-market companies averaged 90 days from pilot to full implementation while enterprises needed nine months or longer, and that measures the whole span rather than the proof stage.

What does an AI proof of concept cost?

There is no published benchmark, and any figure presented as one is a consultancy quoting its own price list. We checked specifically. What you can build without guessing is a bottom-up estimate: cloud extraction and inference are published list prices, and the dominant cost is almost always the people time to get your data into a usable state. Ask any firm quoting a PoC price to show you the split between their time and the platform cost.

What share of AI pilots reach production?

Fewer than most leaders expect. S&P Global Market Intelligence found the average organisation scrapped 46% of AI proofs of concept before they reached production, and that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before. Gartner's position moved from a 2024 prediction that 30% of generative AI projects would be abandoned after proof of concept to a January 2026 assessment that more than 50% were.

Why do proofs of concept fail to convert into production?

Gartner names five causes: lack of business value, data not being ready, escalating total cost of ownership, responsible AI treated as an afterthought, and poor change management. Its April 2026 survey of 782 infrastructure and operations leaders adds the most human one: 57% of those reporting failures cited unrealistic expectations, meaning the organisation expected too much too fast. Only 28% of AI use cases fully succeed and meet ROI expectations.

Should we build the proof of concept internally or with a partner?

The available evidence favours a partner, though the source is weak enough that you should weigh it lightly. MIT NANDA reported that pilots built with external partners reached deployment around 67% of the time against 33% for internally built tools. That report has real methodological problems and its headline claim is widely criticised, so treat the two-to-one ratio as directional. The mechanism it points at is sound: internal teams are usually doing this alongside their day job.

What should a proof of concept actually produce?

A decision, and the evidence behind it. Not a demo. At minimum: the measured accuracy on your own data rather than the vendor's, the specific failures and where they cluster, a unit cost you can multiply by your volume, and an honest statement of what would have to be true for production to work. A proof of concept that only produces a working demo has answered the easy question.

When is a proof of concept the wrong move?

When the blocker is already known and is not technical. If four teams define the metric differently, or the customer record does not resolve, a proof of concept will simply rediscover that at expense. Gartner's finding that organisations with successful AI initiatives invest up to four times more in data and analytics foundations points the same way. Fix the known thing, then prove the uncertain thing.