Why 95% of Enterprise AI Projects Fail — and the Scoping Discipline That Beats the Odds
MIT found 95% of integrated enterprise AI pilots delivered zero measurable P&L impact. The problem isn't the technology. It's how enterprises decide what to build, in what order, and with which tool.
In August 2025, MIT published The GenAI Divide: State of AI in Business 2025. The headline was direct: 95% of integrated enterprise AI pilots delivered zero measurable impact on profit or loss, despite $30 to $40 billion in combined spending during the year. Only 5% produced a real business result. Gartner’s forecast points the same way — more than 40% of agentic AI projects will be canceled by the end of 2027.
The problem isn’t the technology. Foundation models, agent frameworks, and vector databases are more capable than they were a year ago. The problem is how enterprises decide what to build, in what order, and with which tool. On episode 93, Jacob Andra, CEO of the AI consulting firm Talbot West, named the pattern: “The most common issue we see is a client who has already decided the answer is an LLM, and they want us to help them wrap a workflow around it. That is scoping in reverse.”
Improper scoping is the root cause
MIT’s data showed how the 5% differed from the 95%. Strategic partnerships, where an outside team helped scope the work, deployed successfully 67% of the time. Internal builds, scoped and executed alone, succeeded only 33% of the time. The gap isn’t vendor magic — outside teams ask harder questions earlier and insist on a measurable baseline before building anything.
Three scoping mistakes repeat across failed projects: solving a problem the business isn’t actually paying to solve; ignoring the data pipeline that feeds the model, so the AI works on a clean sample and fails on production data; and treating AI as a single capability instead of a toolkit, committing to an LLM before asking whether an LLM is even the right fit.
Map dependencies before you pick a tool
Before selecting a model or vendor, draw the full dependency map of the workflow the AI will touch. Andra calls it “finding the iceberg under the demo.” A dependency map has four layers: data (where the input lives, how clean it is, who owns it), process (what happens before and after the AI call, and what breaks if the output format changes), human (who reviews, overrides, and is accountable when it’s wrong), and security and compliance (what data classification is touched, what audit trail is required). The cost of that last layer is often larger than the model cost itself, especially in regulated sectors — and it’s exactly where an AI data bill of materials and agent least-privilege decisions get made. The output of this step isn’t a tool choice. It’s a scoped problem statement.
Know when an LLM is the wrong answer
Only after the dependency map is complete do you pick the AI approach — and this is where the 95% go wrong most often, assuming the answer is an LLM because that’s what leadership has heard of. “LLMs are one tool in a toolbox,” Andra said. “They are extraordinary at some things. They are genuinely bad at others.” Four categories often do better without an LLM as the primary engine: deterministic decisions with known rules (a rules engine beats an LLM on accuracy and auditability); numeric forecasting on structured data; structured extraction with a fixed schema; and anything requiring a numeric guarantee. The right pattern is often a blend — an LLM front end for language, classical models for the numeric work, a symbolic layer for decisions that must be correct. That’s the neuro-symbolic approach covered in the same conversation.
The human layer
Even a technically perfect deployment fails if the humans downstream don’t adopt it. Three patterns recur: no one is trained to use the output, so usage sits at 3%; no one is trained to override it, so staff either rubber-stamp everything or reject everything; and no one owns the feedback loop, so the model drifts unnoticed. Change management is a line item, not a footnote. As Andra put it: “If your pilot succeeds but your people do not adopt it, you have built a science project, not a business system.” The same principle shows up in security tooling, where shift-left programs fail not because the tools are bad but because the human workflow was never redesigned around them.
A disciplined framework
Talbot West runs a three-round process. Round 1 — problem cataloging: list every workflow where AI could plausibly help, score each on business value and data readiness, pick no tool yet. Round 2 — dependency and fit analysis: map the full graph for the top candidates and identify the right AI class for each, including the option “not AI.” Round 3 — pilot design with a measurable baseline: design the narrowest possible pilot, set the success threshold before starting, time-box it, and kill it if it misses. The structure costs more upfront than “pick a tool and prototype.” It saves ten times that by not shipping another project into the 95% bucket.