Companies have spent billions on AI, and most projects are still stuck in the experimental stage with little to show for it. This is not a model problem. It is a method problem. Here is what separates the projects that die in the graveyard from the few that survive and return value, and how to put yours on the right side.
How many AI projects actually fail?
95 percent. The study "The GenAI Divide: State of AI in Business 2025," from MIT's NANDA initiative, found that 95 percent of corporate generative AI pilots deliver no measurable financial impact, and only 5 percent reach rapid revenue growth.
The study drew on 150 interviews with business leaders, a survey of around 350 employees, and analysis of 300 real deployments. The conclusion is not that AI is overhyped, but that most companies are using it the wrong way.
Why do they fail? Is it the models?
No. The study concluded the barriers are organizational, not technological. It calls it the "learning gap": the inability of companies to integrate models into their workflows, structures, and culture. The model itself may be excellent, but it is left isolated from the process it is supposed to improve.
Generic tools like ChatGPT shine for individuals thanks to their flexibility, but they stall inside the enterprise because they do not learn from or adapt to the workflow. A project that starts with the tool, not the problem, stops at the prototype.
Where does the ROI actually live?
In operations and the back office, not where the budgets concentrate. The study found that more than half of generative AI budgets go to sales and marketing tools, while the highest returns come from automating operations, customer service, and back-office tasks that actually cut cost.
This mismatch between where money is spent and where returns appear is a primary cause of failure. Companies invest in what is visible and impressive, not in what creates value. Start where the ROI is, not where the hype is.
Do you build in-house or buy from a specialist?
Partnering with a specialist wins by a clear margin. The study found that tools bought from specialized vendors or built through partnerships succeed about 67 percent of the time, roughly twice the success rate of internally built systems, which succeed at about a third of that rate.
The reason is that an internal build carries the full learning burden: expertise, integration, and maintenance. A specialist partner brings patterns they have run before. This does not mean never build. It means do not start by building before value is proven.
What signs predict a project will fail, early?
Four signs that appear before a single line of code is written:
- It starts with the tool, not the problem. The question is "which tool do we use?" instead of "which problem do we solve?"
- No numeric success metric. No one knows what "success" looks like in numbers before starting.
- No workflow integration. A tool on the side that never touches the daily process.
- No internal owner. A distant central team leads, not the person who owns the problem in their department.
Any one of these alone is enough to send a project to the graveyard. Together, they make failure nearly certain.
How do you get into the 5 percent?
By reversing every failure sign. The difference is not the model, it is the way you enter:
| Dimension | Tool-first pilot (usually fails) | Outcome-first integration (HBS) |
|---|---|---|
| Starting point | "Which tool do we use?" | "Which problem, and by what metric?" |
| Success metric | Vague or absent | A specific number before starting |
| Integration | Separate from the workflow | Embedded in the daily process |
| Ownership | A distant central team | An internal owner in the department |
| Fate | Stops at the prototype | Scales and returns value |
How do you buy AI the right way?
With three steps that come before any tool:
- Start with a problem and a metric. Pick one costly process, and set a success number before you begin.
- Ask for a diagnosis, not an immediate build. A good partner starts with an audit that finds where the ROI is, not by selling a tool.
- Confirm integration and ownership. Ask: how does this fit our workflow, and who owns it internally?
The takeaway
The graveyard is full of projects that started with the tool and ended with no impact. The few survivors started with the problem, measured the result, and embedded the solution in the process. At HBS we start from the outcome, not the tool: we diagnose where the ROI is and build integration that scales, not a pilot that gets demoed and forgotten.
Start with a diagnosis, not a build, and let us see where your ROI actually is.
