MIT AI research: Vendor vs Internal Builds (2025)

MIT NANDA's 2025 research shows vendor-led AI projects succeed twice as often as internal builds — but the real question is whether that gap is causal or a selection effect.

Most executives reading MIT NANDA's The GenAI Divide: State of AI in Business 2025 land on the same number: 95% of generative AI pilots fail to reach production. The follow-on statistic gets less attention. Vendor-led specialized AI projects succeed 67% of the time. Internal builds succeed roughly one-third as often. That gap is the one worth sitting with, because it is not self-explanatory.

The number that needs explaining

The instinct is to read the 67% figure as a verdict on vendors. It is not. CloudFactory's analysis of the MIT finding makes a more uncomfortable argument: data preparation, domain fit, and realistic rollout planning explain AI outcomes more than delivery method does. TheDataExperts extends this further, arguing that organizational adaptation is the actual variable. If both are right, the 2:1 success ratio may describe which projects get assigned to vendors, not what vendor delivery itself produces. Vendors tend to get projects that have already survived budget scrutiny, defined their data scope, and agreed on what success looks like. Internal teams often get handed the messy ones.

This is the strongest version of the counterargument, and it deserves a direct answer.

Where the selection-effect argument breaks down

MIT NANDA researchers, as quoted in Fortune's August 2025 coverage, attributed the success gap specifically to adoption method, not to pre-project preparation quality. That is a meaningful distinction. If the gap were purely a selection effect, you would expect the researchers to point at data readiness or organizational maturity as the explanatory variable. They pointed at how the project was delivered.

The 95% pilot failure rate also cuts against the selection-effect story. If internal teams were routinely doing the preparation work that explains vendor success, that failure rate would be lower. The preparation is not happening by default. Vendors appear to enforce it structurally, through contract scope, defined deliverables, and the simple fact that an external team asking for your data forces you to find out whether your data is usable. That forcing function is real, even if it is not what the vendor's sales deck says it is.

When the MIT finding does not apply to you

The thesis has a condition built into it. MIT NANDA's finding applies most cleanly to specialized AI projects where you have no proprietary data advantage and no competitive reason to own the underlying model. If your differentiation is the data itself, the vendor argument weakens considerably. A financial services firm with 20 years of proprietary transaction data training a fraud detection model is not in the same situation as a mid-size manufacturer buying an AI-powered demand forecasting tool. Handing the first project to a vendor means handing over the asset. The second project has no such risk.

Fortune's coverage frames the build-versus-buy decision as one that belongs in CFO review, not purely in the CTO's office. That framing is right for a specific reason: the CFO is the person most likely to ask what proprietary advantage the internal build actually creates, and whether that advantage justifies the cost and timeline difference. Most internal AI builds cannot answer that question cleanly.

The four factors that actually move the decision

No source in the research I reviewed provides a validated four-factor framework for this decision. What the evidence does support is a set of questions that separate the cases where the MIT finding applies from the cases where it does not.

Does your proprietary data create a model performance advantage a vendor cannot replicate? If yes, build. If no, the vendor case is strong. Does the project touch data that cannot leave your infrastructure for regulatory or competitive reasons? If yes, vendor delivery gets complicated fast. Is your internal team currently succeeding at AI projects of similar scope? The MIT data suggests most are not, but yours might be an exception worth testing against your actual track record, not your team's confidence. Finally, does the business outcome require deep integration with internal systems that a vendor will not maintain after go-live? Integration debt is real and it compounds.

I have watched three separate enterprise AI initiatives stall because the team chose a vendor for the wrong reason: the vendor's demo was impressive and the internal build felt risky. That is backwards. The demo is not the product. The question is whether the vendor's delivery model forces the organizational discipline that the internal team has been avoiding. If it does, the MIT finding holds. If you are buying the demo, you are going to end up in the 33%.