Build vs buy AI: how to decide, use case by use case

contents10 sections

key points

1. Decide per use case, not per company: score differentiation, data sensitivity, integration depth, talent and three-year cost, then apply a capacity gate and a data gate before trusting the total.
2. Companies mostly buy: Menlo Ventures' November 2025 survey of 495 US enterprise AI decision-makers found 76% of AI solutions purchased rather than built, against 53% in the firm's separate 2024 report, and the firm is an investor in AI vendors ¹.
3. The widely cited 67% versus 33% gap in reaching deployment, external partnerships against internal builds, comes from an interview sample of 52 organizations; its authors call it preliminary and self-reported, and say it may reflect organizational capability rather than approach ².
4. Buying does not remove governance work: NIST says third-party systems can complicate risk measurement, and EU AI Act Article 25 can make a deployer the provider if it changes the intended purpose of a system not classified as high-risk so that it becomes high-risk ^3,4.
5. The price of a fixed capability level has fallen fast: Stanford's 2025 AI Index reports inference cost for a GPT-3.5-level system down more than 280-fold from November 2022 to October 2024, so re-price a three-year cost model every year ⁵.

Short answer: decide build, buy or build on top of a bought platform one use case at a time, not once for the whole company. Buy when many companies need the same thing and a vendor already does it well. Build when the capability is how you compete, runs on data you cannot hand over, or needs integration a vendor cannot reach, and you can staff it for years. In between, buy the platform and build the workflow on top. Score five criteria, then apply two gates before you trust the total.

What are the three options?

"Build" and "buy" blur once models are sold through an API, so we separate the paths by who owns the application and its day-to-day behavior.

4 columns: the table scrolls sideways inside its frame

Calling a model provider's API from code you wrote is the middle row: you own more than a buyer does, and you still depend on a vendor whose model can change under you.

Which five criteria decide it?

Ask the same five questions about every use case.

1. Differentiation. If a competitor had exactly this capability tomorrow, would you lose an edge? If not, a vendor probably already sells it.
2. Data sensitivity. What data goes in and comes out, and can contract terms cover it? Buying does not settle this. Microsoft's documentation for its hosted models, for example, says prompts and completions are not used to train any generative AI foundation models without the customer's permission or instruction. The same page describes abuse monitoring in which a sample of prompts and completions may be selected for review, mostly automated with human review as necessary and flagged content stored for that review, unless the customer is approved for modified abuse monitoring. It also describes "Global" deployment types, where prompts and responses may be processed in any geography where the model is deployed, although data stored at rest stays in the customer's chosen geography ⁶. Read the equivalent terms for every vendor you shortlist.
3. Integration depth. How many internal systems must it read, and how many must it write to? A tool that reads a few documents is easy to buy. One that writes to your case system under your own permission model is hard to confirm from a demo.
4. Talent and operating capacity. Who owns it in year two, retests it when the model changes and responds when it fails? In a June 2025 report based on a survey of 100 CIOs and conversations with more than two dozen enterprise buyers, the investor Andreessen Horowitz wrote that companies were finding internally developed tools difficult to maintain and frequently not a source of business advantage ⁷. That is one investor's reading, but it is a reason to ask early.
5. Three-year total cost. Compare 36 months of cost lines for each path, not the year-one invoice.

How do you score a use case?

Score each criterion from 1 to 5, where 1 favors buying and 5 favors building. The anchors keep two people from scoring in different languages.

4 columns: the table scrolls sideways inside its frame

Add the five scores. Our suggested reading is 5 to 10 for buy, 11 to 19 for build on a bought platform, and 20 to 25 for build. Near a boundary, pick the more reversible path, which usually involves buying, and revisit it at the next review.

Then apply two gates that override the total:

• The capacity gate. If no named person or team can run the system for three years, do not build it, whatever the score. Buy, or build a thin layer on a platform whose vendor supports it.
• The data gate. If the data cannot leave your environment and no vendor can run inside it on terms your legal team accepts, buying is off the table. That leaves building, or self-hosting a model you operate.

Have two people score separately before comparing. Their disagreements are the useful output.

What do worked examples look like?

These three hypothetical use cases are scored for illustration. They are not real companies, and the scores are judgments you may disagree with.

8 columns: the table scrolls sideways inside its frame

Example A is a buy. The work is governance rather than engineering: deciding what staff may put into it, which an AI acceptable use policy covers.

Example B lands in the middle. What you build is the part that makes it yours: the routing rules, the connection to the case system and a test set of real requests. The platform supplies the model and hosting.

Example C scores as a build, but the capacity gate decides it. If nobody can own it for three years, start with a smaller version on a platform while you build the team.

How do you compare three-year cost without inventing numbers?

List the cost lines for each path first.

• Buy: licenses or usage fees, integration, security and privacy review, administration, training and change management, vendor management, and the cost of leaving.
• Build: the team's time to build and to keep it running, model usage or hosting, data pipelines, evaluation and monitoring, security review, on-call cover, and rework when the underlying model changes.
• Build on a platform: most of both lists, with vendor usage fees in place of hosting.

Price each line three ways (low, expected, high) from your own quotes and time estimates, and compare totals at your expected volume and at double. The price of a given capability can fall fast: Stanford's 2025 AI Index reports that the inference cost of a system performing at GPT-3.5 level fell more than 280-fold between November 2022 and October 2024 ⁵. That is one capability level, not every model, but a cost model that freezes today's rates for three years may be wrong, so re-price it every year.

Any claim that one path wins by a given year rests on assumptions about volume, team cost and future prices. Ask to see them, and treat a claim that does not state them as a sales argument.

Do buyers or builders succeed more often?

Three widely cited sources bear on this, each with a limit.

• Menlo Ventures, December 2025. In a survey of 495 US enterprise AI decision-makers run in November 2025, 76% of enterprise AI solutions were purchased rather than built internally. The comparison figure, 53% purchased and 47% built, comes from the firm's separate 2024 report, and the page does not define "built" or "purchased", so read the change as a direction, not a measured shift ¹. It counts what companies bought, not what worked, its sample is limited to US enterprises, and the firm is a venture investor that marks a number of the vendors it names, such as Anthropic, as portfolio companies.
• MIT NANDA, July 2025. In its interview sample of 52 organizations, external partnerships with learning-capable, customized tools reached deployment about 67% of the time, against about 33% for internally built tools. The authors call the findings preliminary, say the figures are self-reported, note that success definitions varied across organizations, and write that the gap may reflect organizational capability rather than approach ².
• Andreessen Horowitz, June 2025. A report drawing on a survey of 100 CIOs across 15 industries (data as of 8 May 2025) and conversations with more than two dozen enterprise buyers describes a marked shift toward buying third-party applications over the previous twelve months, except in regulated or high-risk industries such as healthcare, where data privacy and compliance weigh more ⁷. The firm is an investor, and its disclosures say some of the information it publishes comes from third-party sources, including portfolio companies, which it has not independently verified.

Menlo and Andreessen Horowitz both describe a move toward buying, and the NANDA interviews and the Andreessen Horowitz report both describe internal builds as harder to carry through. None measures your situation or shows that building is wrong. They are why the method includes a capacity gate.

What does each path mean for governance?

The NIST AI Risk Management Framework organizes AI risk work into four functions: Govern, Map, Measure and Manage. It says third-party data or systems can accelerate development but may complicate risk measurement, partly because the developer's risk metrics may not match the deployer's. It also sets outcomes for third-party material: policies and contingency processes for third-party risk (Govern 6), mapping risks for all components including third-party software and data (Map 4), and regular monitoring of third-party resources and pre-trained models (Manage 3) ³.

• Buy. You inherit a system you did not test, so the work moves into procurement and oversight. NIST's Generative AI Profile suggests contract clauses that let an organization evaluate third-party generative AI processes and standards, an inventory of third-party entities with access to organizational content, and procurement due diligence that covers intellectual property, data privacy and security ⁸.
• Build on a bought platform. You own testing for your workflow but still rely on a model you did not train. The Profile notes that value chains involve procured datasets, pre-trained models and libraries, and that a problem can be hard to trace to any one source ⁸.
• Build. You own measurement, documentation, change control and incident response end to end, and you will usually still use third-party components.

Regulation can shift with the path. Under Article 25 of the EU AI Act, a deployer is treated as the provider of a high-risk system, with the provider's obligations, if among other things it modifies the intended purpose of an AI system that was not classified as high-risk, including a general-purpose one, so that it becomes high-risk ⁴. Putting a bought general-purpose model to a high-risk use can therefore move provider obligations toward you. The Commission's service desk says its summaries are not legally binding, so check the current text with counsel if you operate in the EU.

Whichever path you choose, our AI implementation plan covers the rollout around it.

How do you record the decision and keep it reversible?

1. Write one page per use case. Record the owner, scores, gates, the path chosen, and the assumptions that would change the answer, such as volume, price, vendor terms or headcount.
2. Keep what makes a switch possible: your own evaluation set of real examples, your prompts and rules in your systems, an export of your data, and an exit plan in the contract.
3. Review on a date. Revisit every six months or at renewal, whichever comes first, because vendor products and model prices move quickly.
4. Prove value cheaply first. A bought pilot is usually cheaper to abandon than a built one.