Build vs Buy AI: A Decision Framework for Each Layer, With a Weighted Scoring Matrix

For most organisations the build vs buy AI answer is to buy or adopt the commodity layers, meaning foundation models and usually the platform, and to build where the work is specific to the business: the agents, workflows, prompts, evaluation sets and data pipelines that encode how you operate. Score each layer separately against weighted criteria, and treat non-negotiables such as data residency as pass-or-fail gates. Then write down what would make you change your mind, because model prices and capabilities move faster than contracts.

This guide is about the decision itself. Choosing between vendors once you have decided to buy is a separate exercise, covered in our guide to enterprise AI procurement and RFPs.

Build vs buy in the age of AI

The old question assumed two options and a single decision. Gartner now frames it as build, buy or blend. Its article on deploying AI, first published on 31 March 2025 and updated in May 2026, says AI reaches an organisation from three directions:

• Embedded AI: features added to software the organisation already licenses, such as ERP, CRM and case management. Gartner calls this the largest and fastest-growing source of AI capabilities.
• Bring-your-own AI: separate, best-of-breed products that departments buy for their own needs.
• Built and blended AI: capabilities owned by central teams, either built from scratch or “blended” by combining foundation-model APIs with the organisation’s own interfaces, integrations and customisation.

A Gartner research note from 9 April 2025, by Whit Andrews and Jim Hare, adds that the choice starts with the project’s strategic and tactical focus and weighs nine factors; the factors themselves sit behind Gartner’s paywall.

Survey data pulls in both directions. Menlo Ventures surveyed 495 US enterprise AI decision-makers in November 2025 and reported on 9 December 2025 that 76% of AI use cases were purchased rather than built internally, against 53% purchased the year before. McKinsey’s State of AI survey, published on 25 August 2026, found pressure the other way on ordinary software: 32% of respondents said their organisation had decided against buying at least one software product or feature because agentic coding tools let them build it in-house.

MIT NANDA’s July 2025 report on generative AI in business found that tools built with external partners reached deployment about 67% of the time, against about 33% for internal builds. Its authors add two cautions: the figures are self-reported by 52 organisations, and the gap may reflect differences between the organisations rather than the approach they chose.

The evidence does not settle the question either way. It does show that the answer differs by layer and by use case, which is how the rest of this guide treats it.

Decide build vs buy per layer, not once

An AI system has four layers, and each has its own default.

Foundation models. Very few enterprises should train a model. The decisions that matter are which models are approved for which data classes, and whether you can swap one without rewriting applications. Fine-tuning is a build decision with its own data, evaluation and maintenance costs, so try retrieval and better prompts first.

Platform and orchestration. Build costs hide here, because a first agent demo needs none of this layer and production needs all of it. Our analysis of what it really costs to assemble an agent platform from frameworks covers that layer in depth, so this guide does not repeat it.

Applications and agents. This is the layer most worth building, because it encodes your process. Before buying a new product here, check what your current vendors already ship: Gartner warns that piling separate AI tools on top of embedded features can create overlap, unnecessary cost and technical debt.

Data and retrieval. Buy the plumbing if it fits, but own the parts that carry your knowledge: which sources are connected, how permissions map, how documents are prepared and the test set that proves answers are right. A Gartner research note of 11 September 2025 observes that packaged retrieval-augmented generation products have appeared because enterprise RAG is complex to build, and advises assessing your own capabilities and differentiation before choosing.

The build vs buy AI framework: seven criteria

1. Differentiation

Ask whether a competitor using the same product would erase your advantage. If it would, building or blending protects it. If the task is identical in every company, building it is usually vanity. A quick test: would you describe this workflow in a customer pitch or an annual report?

2. Data sensitivity and residency

Classify the data the system will touch as public, internal, confidential or regulated. For the last two, the questions become where processing runs, who can read prompts and logs, and which models may see the data. Treat a hard residency requirement as a gate: an option that cannot keep data in the required place is out, whatever its score.

3. Skills and capacity

Building needs more than AI engineers: a product owner, platform and security engineers, someone who owns evaluation and someone on call. Count the people who will maintain the system in year three, not the people who will build it in the first quarter.

4. Total cost of ownership

Compare multi-year cost, not licence against salary. On the build side, count engineering, infrastructure, model usage, evaluation, security reviews, on-call support and upgrades. On the buy side, count licences, usage fees, integration, configuration, vendor management and the cost of switching later. Half of CIOs expect AI to push total cost of ownership up: 51% said so in Gartner’s survey published on 19 October 2026. For worked figures, see the breakdown of AI implementation costs, the on-premises AI total cost guide and the 2026 on-premises and cloud LLM cost comparison.

5. Speed to value

Buying usually reaches first value sooner because the product already exists. Building starts slower but can move faster later on work no product will cover. Estimate from comparable projects inside your own organisation rather than from anyone’s sales material.

6. Lock-in and exit

Every option locks you in to something: a vendor, a framework, a model family or the engineers who built it. Price the exit before you choose. Can you export prompts, agent definitions, conversation logs, audit trails and evaluation sets in a usable format? The guide to assessing vendor lock-in risk lists the contract clauses to check.

7. Compliance and audit

Building can change your legal role. Under Article 25 of the EU AI Act, a deployer or other third party is treated as the provider of a high-risk AI system, with the provider’s obligations, if it puts its name or trademark on one, makes a substantial modification to one, or changes the intended purpose of an AI system so that it becomes high-risk. Buying does not remove duties either: you still need evidence that the vendor’s logging, access control and data handling meet your requirements, which a structured vendor security questionnaire helps you collect.

Weighted scoring matrix for build vs buy AI

Score each option from 1 (poor fit) to 5 (strong fit) on every criterion, multiply by the weight, add the results and divide by 5 for a score out of 100. Agree the weights before anyone scores, and apply the hard gates first.

Worked example (fictional)

A fictional insurer with about 4,000 staff wants an assistant that drafts claims correspondence from the claim file for adjusters to approve. Its platform is already chosen, so this decision covers the application layer. Three options are on the table: build in-house on open-source frameworks, buy a claims product with drafting built in, or have an integrator build it on the insurer’s platform and hand it over. The hard gate is that claim files stay in the insurer’s data centre, which the product passes only in its on-premises edition, so that edition is scored.

The arithmetic for the partner option is (20×4 + 20×4 + 15×4 + 15×3 + 10×3 + 10×4 + 10×4) ÷ 5 = 375 ÷ 5 = 75. Build comes to 360 ÷ 5 = 72 and buy to 335 ÷ 5 = 67.

Now test the weights. If the insurer cut differentiation to 10 and raised skills and capacity to 25, build would fall to 66 and buy would rise to 73, while the partner option would stay at 75. That is the matrix’s real job: it shows which assumptions the decision rests on, so the steering group argues about weights rather than conclusions. When two options land within a few points, run a short, structured proof of concept on both before committing. The insurer in this example chose the partner route, with a contract that hands over the code, prompts and evaluation set at the end.

Buy vs build vs partner: when a partner is the better choice

Partnering covers several arrangements: an integrator builds on your platform, a vendor’s services team customises its product, or vendor engineers work inside your teams, a model now sold as forward-deployed engineering (FDE). It can pair a product’s head start with work shaped around your process, but only if the knowledge stays with you when the partner leaves.

Gartner is blunt about the risk. On 29 September 2026 it predicted that by 2028, 70% of enterprises will abandon agentic AI built by vendor forward-deployed engineering, trapped by soaring costs and unable to evolve it on their own, and that through 2028 fewer than 20% of FDE engagements will turn recurring customer needs into capabilities in the vendor’s core product. Its advice is to settle deliverables, knowledge transfer, intellectual property rights and exit responsibilities before signing, to embed the vendor’s engineers with internal domain experts, and to carry out the exit plan rather than extending the engagement.

Put these terms in any partner contract:

• Ownership of the code, prompts, agent definitions, tool configurations and evaluation sets
• Knowledge-transfer milestones with named internal owners
• Access to logs, traces and test results during and after the engagement
• Documentation good enough for another team to run the system
• An exit date, a handover plan and the price of support afterwards

Build vs buy for agentic AI

Agents make the layered view more important, because each agent is two things. Its behaviour, meaning the steps it takes, the tools it may call and the points where it must ask a person, is specific to your process and usually worth building or configuring yourself. Its runtime, meaning identity, permissions, approvals, orchestration, logging and evaluation, is common to every agent and usually cheaper to buy than to maintain.

Three published signals belong in an agent build-or-buy case:

• Agents will arrive inside software you already own. Gartner predicted on 26 August 2025 that 40% of enterprise applications will include task-specific agents by the end of 2026, up from less than 5% in 2025. Check for overlap before buying or building another.
• Running costs will rise. On 17 August 2026 Gartner forecast that inference costs per agentic workflow will increase more than fivefold through 2028, so model usage belongs in any comparison at production volume.
• Building ordinary software is getting easier. The McKinsey finding on agentic coding tools above suggests that integration code and smaller components are now more realistic to build in-house, even as agents become more expensive to run.

How to revisit the build vs buy decision

An AI build-or-buy decision has a shorter shelf life than most technology choices. Record it with the business case, name an owner and agree the events that trigger a review.

Review each layer once a year even without a trigger, and keep the assets that make switching possible: prompts, agent definitions, evaluation sets and logs in formats you control. Store the decision, the scores and the triggers in the business case template so the next review starts from the reasoning rather than from memory.

How VDF AI fits

VDF AI is a buy decision at the platform and orchestration layer that leaves the application layer with your teams. They build agents in VDF AI Agents, connect them into multi-agent processes with Networks and run private retrieval over company documents in VDF AI Chat, while the platform supplies role-based access control on every plan and audit logs of what users and agents did.

The model layer stays open. VDF AI Router chooses among the cloud models you approve and the on-premises endpoints you register, and its air-gap mode restricts routing to local models. The platform runs in VDF’s managed cloud or in your own data centre, private cloud or air-gapped network, which is what the residency gate in the matrix usually asks.

If the platform layer itself is still open, an on-premises bundle can begin with a three-month platform trial on your own infrastructure, so the scores rest on your systems and data rather than on a demo. Plan details are on the pricing page, and the agent platform overview shows what the platform layer includes.