Gartner predicted 30% of generative AI PoCs would be abandoned. It was worse

Most generative AI proofs of concept die for reasons that were visible before they started: nobody agreed on what the PoC had to prove, nobody estimated what it would cost at scale, and nobody had the authority to decide what to do with the result. The model almost always works. What's missing is the path from "it worked in the demo" to "it's worth funding."

What Gartner said, and what happened

On July 29, 2024, Gartner published its prediction that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. The reasons it cited: poor data quality, inadequate risk controls, escalating costs and unclear business value. At the same event, analyst Rita Sallam said executives were impatient to see returns on GenAI investments while organizations struggled to prove and realize value. She estimated that efforts to change a business model with generative AI can cost between $5 million and $20 million.

The prediction turned out to be conservative. In a later article, Why 50% of GenAI projects fail, Gartner itself states that by the end of 2025 at least 50% of generative AI projects had been abandoned after PoC, for the same four reasons.

Other research reaches similar conclusions by different routes. RAND's 2024 report The Root Causes of Failure for Artificial Intelligence Projects interviewed 65 data scientists and engineers and cites estimates that more than 80% of AI projects fail, twice the rate of IT projects without AI. The most cited root cause wasn't technical: it was business leadership misunderstanding, or miscommunicating, what problem the AI was supposed to solve.

The four reasons, translated for your next meeting

Unclear business value. The PoC proved the model answers well, but nobody wrote down beforehand which number it was supposed to move. Without that, the result is always "interesting" and never "approved." The question that fixes it: if this PoC succeeds, which metric changes, by how much, and who will notice?

Escalating costs. A PoC with 20 users and 500 questions a day costs little. The same application with 3,000 users, conversation history, document retrieval (RAG) and human review costs something else entirely. Gartner describes the effect well: per-token cost looks negligible until it's multiplied across thousands of users and dozens of use cases. If the PoC doesn't estimate cost per transaction at scale, the first production invoice becomes the reason for cancellation.

Poor data quality. The PoC was built on 200 hand-picked documents. In production, the assistant runs into duplicate versions, scanned PDFs with no text layer and outdated policies nobody deleted. Accuracy drops and user trust drops with it.

Inadequate risk controls. Legal, security and privacy get called in only when the project wants to go live. That's when questions surface about data protection law, decision logging, customer data flowing to a third-party model. If the PoC wasn't designed to answer them, the project goes back to square one, or stops.

Notice that none of the four reasons is the model getting things wrong. They're project design failures, and every one of them shows up in the questions any CFO would ask during a budget approval. The difference is timing: when those questions arrive after the PoC, answering them costs weeks of rework; when they arrive before, they cost one meeting. There's a less visible effect too. Every PoC abandoned without explanation leaves the leadership team a little more skeptical, and the next AI proposal starts with less credit, even if it's a good one. A PoC discarded with clear criteria and numbers preserves that credit, because it shows the company knows how to stop what doesn't work.

What changes when a PoC is designed to decide

A PoC that ends in a decision has five things defined before day one:

1. The business hypothesis, with a number. For example: "the assistant cuts response time to sales-policy questions by 40%, with an incorrect-answer rate below 5%."
2. The exit criteria, in three bands: what has to be true to scale, what justifies adjusting and what justifies discarding.
3. The cost estimate at scale, using real production volume, not PoC volume.
4. Real data, or a representative sample of it, including the bad documents.
5. The decision owner, one person with budget and authority to say yes or no when the result comes in.

Hypothetical example: a sales-policy assistant

The scenario below is a hypothetical example built to illustrate the reasoning. It is not a client result.

A company with 400 sales reps wants an assistant that answers questions about pricing policy, discounts and payment terms. Today those questions go by email to a 4-person team, with an average response time of one day.

Criteria agreed before the PoC: the assistant must correctly answer at least 90% of a set of 300 real questions from the last six months, graded by the policy team, and estimated production cost must stay below $1.50 per rep per month.

The PoC runs for four weeks. Result: 86% accuracy. Analysis shows almost all the errors come from two outdated policy documents still in the knowledge base. Estimated cost: $1 per rep per month.

The decision is easy to make: adjust. Update the two documents, rerun the same 300 questions and, above 90%, scale to a pilot group of 50 reps. Without written criteria, the same PoC would have turned into a debate about whether 86% is good or bad, and would probably have been shelved.

Signs your PoC is headed for abandonment

• The success criterion is "see if it works."
• Nobody knows the cost per transaction in production.
• The test set was chosen by the team that built the PoC.
• Legal and security haven't seen the project.
• The PoC's sponsor has no budget for the next stage.
• There's no date on the calendar for the decision meeting.

If three or more of these describe your project, pause and rewrite the scope before spending another week of engineering time.

Checklist for a PoC that ends in a decision

• The hypothesis has a business metric and a number.
• The scale, adjust and discard bands are written down and signed off by the sponsor.
• The test set uses real data, including the hard cases.
• The cost estimate reflects production volume.
• Privacy and security risks were mapped in week one.
• The decision meeting is on the calendar before kickoff.

Next step

Before approving the next PoC, ask the team to present the three decision bands and the cost estimate at scale. If they can't, the PoC isn't ready to start.

That's why we built the Cyborg Forge as a 3-to-6-week process, with success criteria agreed before day one and a Decision Package at the end that recommends whether to scale, adjust or discard. The details of each stage are in our methodology.