home  /  insights  /  should-your-firm-build-its-own-ai
Automation & Building

Should your firm build its own AI, or configure what it already pays for?

MIT NANDA found internally built systems succeeded roughly a third as often as bought ones. For most firms the real question is neither build nor buy but configure, because the capability is often already inside a contract the firm signed years ago.

September 4, 2026 · 5 min read

The short answer

Most firms should configure and connect rather than build. MIT NANDA’s "The GenAI Divide: State of AI in Business 2025" (August 2025) found that internally built systems succeeded roughly one-third as often as buying from specialised vendors, against a 67% success rate for buying. The gap between "AI is transformative" and "our AI project worked" is rarely model quality; it is data hygiene, permissions, evaluation and whether anyone owns the thing. Building is defensible where the workflow is genuinely proprietary and the firm can staff its maintenance, which is a much narrower set of cases than the enthusiasm suggests.

What this article establishes

  • MIT NANDA (August 2025) found internal builds succeeded roughly one-third as often as buying from specialised vendors, with buying at a 67% success rate.
  • The widely circulated "95% of pilots fail" headline from the same study measures pilots reaching measurable P&L impact, not technology failing to work, and should be cited as a contested working-paper claim.
  • Most projects die on data readiness rather than on model capability, and a law firm’s document estate is unusually hostile to retrieval.
  • The cheapest real capability at most firms is already inside an existing Microsoft or Google contract and has not been switched on.

What does the evidence say about firms building their own AI?

The most cited finding is that internal builds fail more often than purchases. MIT NANDA’s "The GenAI Divide: State of AI in Business 2025" (August 2025) — 150 leader interviews, a 350-employee survey and 300 public deployments — reported that internally built systems succeeded roughly one-third as often as buying from specialised vendors, with buying showing a 67% success rate.

That build-versus-buy differential is the most useful number in the study, and it is not the number that got the coverage.

Is it true that 95% of AI pilots fail?

That figure is widely over-read and should be cited carefully. The MIT NANDA study reported that about 95% of enterprise generative-AI pilots stalled with no measurable profit-and-loss impact, which is a statement about pilots reaching demonstrated P&L impact — not a statement that the technology did not work in 95% of cases.

It is also a working-paper claim rather than settled fact, and it deserves that label whenever it is quoted. The honest version is less dramatic and more useful: most pilots do not produce a measurable financial result, largely because most pilots are not designed to be able to.

Which points at a design problem worth naming. A pilot with no baseline, no control and no pre-committed success measure cannot produce a negative result. It can only produce enthusiasm or silence.

Why do internal builds fail more often than purchases?

Because the hard parts are not the model. They are data hygiene, permissions, evaluation and ownership — the unglamorous infrastructure that a vendor has already paid for and that a firm building in-house has to fund out of its own overhead, indefinitely.

Ownership is the one firms underestimate most. A bought system has a vendor whose business depends on it continuing to work. A built system has whoever built it, until that person is busy on a matter, or leaves.

What does "configure" mean in practice?

It means switching on and tuning capability the firm has already bought rather than acquiring or constructing new capability. For most firms the largest untapped surface is inside an existing Microsoft 365 or Google Workspace agreement, followed by whatever the practice-management and document-management systems already ship.

This matters commercially as well as technically, because of a pricing pattern the Institute has documented across categories: the product tier that satisfies a firm’s confidentiality obligations is frequently priced for organisations ten times the buyer’s size. A three-lawyer firm can often afford a tool and not the tier that makes it defensible. Using what is already inside an enterprise agreement sidesteps that problem entirely, and costs nothing further.

When is building actually the right answer?

When the workflow is genuinely proprietary, the data to support it is already clean, and the firm can staff its maintenance for years rather than months. Those three conditions have to hold together; two out of three produces a system that works impressively for a quarter and then decays.

There is a middle path that is frequently the right one and rarely considered: connecting systems that already exist rather than building a new one. Practice-management, document-management and research systems increasingly ship permission-bound connectors, and wiring those together is a configuration exercise with a much shorter failure tail than construction.

One caution on that path. Where a connector is community-maintained rather than vendor-published, it may hold credentials to an entire practice-management system, and that is a serious trust decision rather than an installation step. Read the code, or do not run it.

Where do these projects actually die?

On data readiness, almost always, and earlier than anyone plans for. The MIT NANDA finding is substantially a data-readiness story dressed up as a technology story.

A law firm’s document estate is unusually hostile to retrieval: twenty years of document management with near-duplicates in the dozens, files called Document1.doc, fourteen versions of the same brief with no indication which was filed, PDFs of scans of faxes, matter numbers in four incompatible conventions, and an email archive nobody has indexed. No model fixes that. The assessment is boring, it is skipped almost universally, and it determines the outcome.

The Institute’s Automation & Building area covers the build-buy-configure decision in more depth.

For informational purposes only. Not legal advice and not ethics advice. Professional conduct rules are adopted state by state and diverge, and this record changes monthly. Anything here that reads as a holding should be checked against your own jurisdiction before it is relied on.

Related

The practice area

AI adoption conciergeorientation · not legal or ethics advice
Happy to. Tell me roughly how big the firm is and what it already pays for — Microsoft 365, Google Workspace, a practice-management system — because the honest answer to most AI questions at a firm your size starts with what you have already bought rather than what you should go and buy.