In 2025 a report from the MIT NANDA initiative drew wide coverage for a stark headline: that about 95% of generative AI pilots stall without reaching scaled adoption or measurable financial return. We are relying on press coverage of the report here, and the coverage itself notes that terms like 'pilot' and 'success' are not clearly defined and that the sample was modest — roughly 150 leader interviews, a survey of 350 employees and an analysis of 300 public deployments. Treat the exact percentage with caution. Two other findings are more useful.
Finding one: the money goes where the returns aren't
As reported, over half of corporate AI budgets went to sales and marketing, while the strongest returns appeared in back-office areas such as business process automation, reduced outsourcing and operational efficiency. A plausible reason is measurability: back-office work has clear volumes, costs and error rates, so improvements show up in the books. Front-office gains are real but harder to attribute.
Finding two: bought beat built, more often
The coverage reports that tools bought from vendors or built through partnerships succeeded about two-thirds of the time, against about one-third for internally built systems. The lead author attributes failures to integration with enterprise workflows more than to model quality. That is his interpretation as reported, but it matches experience: the hard part is rarely the model.
Read together, the two findings argue for starting where outcomes are countable, and for buying or partnering where a mature product already does the job. Custom building earns its place where your process is genuinely different.
Test the pattern on your own spending
- List where your AI spend is going — by function, not by vendor. Then list where you can already measure a cost or error rate.
- Compare the two lists — if spend is concentrated where nothing is measurable, you are paying for hope. Add a measurement plan or move the money.
- Look at the back office first — invoice handling, document processing, reconciliation, support triage and similar work with stable volumes and clear costs.
- Decide build versus buy per process — buy where a product fits; build where your workflow, data or risk profile is unusual. Our own comparison of the two is in the library.
- Ask who owns the integration — if nobody is responsible for connecting the tool to the workflow, the project is already at risk.
What to take from it
You do not need the 95% figure to be exact to act on the pattern. Put the first project where the return is countable, make integration an explicit workstream with an owner, and be honest about when a bought tool beats a custom build. Those choices cost nothing extra and remove several of the most common reasons pilots stall.