Build versus buy for enterprise AI: a decision framework

The question almost nobody asks first

"Should we build this or buy it?" is the wrong opening question. It produces bad answers because it treats an AI application as a single object, and it is not. A production AI system is a stack of six layers, and the right call is usually different at every layer. Almost no organization should build all six. Almost none should buy all six. The useful question is which layers you own, which you rent, and what it costs when you change your mind.

The six layers, bottom to top: infrastructure (compute, storage, the security boundary); models (foundation and embedding models, anything you train); orchestration (retrieval, tool calling, workflow, caching); domain logic (your schema, your rules, the judgments your organization makes); interface; and evaluation and governance (the test set, the metrics, the audit trail, the documentation an assessor reads). Write those on a whiteboard and score each separately. The conversation gets shorter and more honest.

Six variables decide each layer. We weight them, score them, add them up. The weights below are a starting point: a regulated health system moves data up, a company chasing a market window moves time-to-value up. Set the weights before anyone sees the scores, so the rubric decides the answer instead of ratifying one somebody already picked.

Variable one: how differentiated is the use case

The test is simple. If your closest competitor bought the same product tomorrow and switched it on, would they be doing your job as well as you do it? If yes, that capability is a commodity and you should buy it. Meeting transcription, generic document search, code assistance, and ticket summarization are commodities. Dozens of vendors sell them, the quality gap narrows every quarter, and no board has ever been impressed by an in-house transcription service.

The other end is work specific to you: how a specialty insurer prices a risk nobody else writes, how a utility picks the next asset to inspect, how a program office judges whether a test article passed. That logic is in no vendor's product. Building there is the only path to a system that reflects how your organization thinks.

Federal buyers have this preference in regulation. FAR 12.101 directs agencies to acquire commercial products and services when they meet the agency's needs, and FAR 39.103 pushes modular contracting for information technology. That same rule is why agencies still fund development: the preference applies only when a commercial item meets the need, and for a large class of mission problems none does.

Variable two: the data, and whether it can leave

Proprietary data is the strongest build signal there is. If value comes from a corpus nobody else has, a vendor's general-purpose model cannot reach it. Eighteen years of adjudicated claims, forty years of scanned test reports, a maintenance history nobody else recorded: those are assets, and a system built on them is defensible in a way a subscription never is.

The second half of this variable is legal. Some data cannot cross a boundary. Controlled Unclassified Information is governed by 32 CFR Part 2002 with NIST SP 800-171 Rev. 3 as the control baseline for nonfederal systems. Federal Tax Information carries IRS Publication 1075. Protected health information requires a HIPAA business associate agreement. Criminal justice information falls under the FBI CJIS Security Policy, student records under FERPA at 20 U.S.C. 1232g, and DoD workloads under impact levels IL2 through IL6 in the DoD Cloud Computing Security Requirements Guide. Each narrows the buy option to vendors already authorized at that level, or pushes the system inside a boundary you control.

Variable three: the cost nobody budgets

Build estimates are usually honest about the visible part and silent about everything after go-live. The year-two lines are consistent across production AI systems: re-embedding a corpus when the embedding model is deprecated, rebuilding an evaluation suite when the base model changes behavior, drift monitoring, CVE patching, STIG re-baselining, annual assessment evidence, on-call rotation, and continuous re-ingest as the corpus grows. Our planning figure is 15 to 25 percent of the original build cost per year, and 30 to 40 percent in the first year after a regulated system goes live, because the first assessment cycle always finds work.

Buy has its own invisible lines. Per-seat pricing that scales with adoption instead of value. Connector and integration work, which is real engineering whatever logo is on the product. Data preparation, which the vendor does not do. And the evaluation burden, which does not transfer: if the system makes a decision your organization answers for, you still have to prove it works on your data at your error tolerance. Buying moves the code, not the responsibility.

On compute, plan with real numbers. On-demand H100 capacity in commercial cloud regions runs roughly $10 to $13 per GPU-hour and A100 capacity roughly $4 to $5, with government regions carrying a premium. Fine-tuning a mid-sized open-weight model takes hundreds to low thousands of GPU-hours, so training is rarely the dominant cost. Steady-state inference over three years is. Compare on a five-year horizon, exit cost included in both columns.

Variable four: the hiring reality

A build decision is a hiring decision, and this is where most plans quietly fail. A production AI system takes four distinct roles: an ML engineer who owns model behavior, a data engineer who owns ingest and pipeline reliability, a platform and security engineer who owns the boundary and the assessment evidence, and an owner of measurement who did not build the model. Staffing four skill sets with one enthusiastic generalist produces a laptop demo and a system nobody can operate at 2 a.m.

The market cost is real. A senior machine-learning engineer in a major U.S. market runs $230,000 to $300,000 fully loaded, hiring takes three to six months, and ramp takes another quarter. Federal organizations face a harder version of it: locality-adjusted General Schedule pay is capped at Level IV of the Executive Schedule under 5 U.S.C. 5304(g), well below private-market machine-learning compensation. That constraint explains much of why federal AI work runs through contracts rather than direct hires.

This is where an engineering partner changes the arithmetic. Precision Federal fields those four roles as a working unit, and the people we assign to a build like this have spent twenty years putting production systems into federal environments. Hiring one person is a bet on one person. Bringing in a bench is not.

Variable five: lock-in, and what it costs to leave

Vendor lock-in in AI is not mainly contractual. It is technical, and it accumulates in places that never appear in a procurement review. Five vectors account for most of it.

Embedding coupling. Change the embedding model and you re-embed the whole corpus, re-tune retrieval thresholds, and re-validate every answer your evaluation set covers. On a multi-million-document corpus that is a project, not a config change.

Prompt and behavior coupling. Prompts, tool schemas, and guardrails tuned against one model's behavior degrade against another. The work stays invisible until you try to move.

Format and contract coupling. Proprietary index formats, managed vector stores with no clean export, chunking metadata that lives only inside the vendor's service, plus auto-renewal windows, minimum annual commitments, and data-deletion terms that read fine until you are the one leaving.

Infrastructure coupling. This one has improved. The major cloud providers dropped data-transfer-out fees for customers migrating away during 2024, and the EU Data Act, Regulation (EU) 2023/2854, became applicable on 12 September 2025 with rules on switching between cloud services. Egress is no longer the wall it was, which pushes real exit cost onto the technical vectors above.

Federal buyers have direction here. OMB memorandum M-25-22, "Driving Efficient Acquisition of Artificial Intelligence in Government," issued in April 2025, tells agencies to protect government data in AI acquisitions and to avoid vendor lock-in when structuring them. It is a reasonable standard for commercial buyers to borrow. Write the exit runbook during the evaluation, not after the incident.

Variable six: time to first value

Buy almost always wins this one, and it earns the smallest weight in the rubric. A bought pilot reaches users in weeks; a built system rarely does. We hold the weight down because a fast pilot that cannot reach production is worth less than a slower one that can, and pilots stall on data access, security review, and evaluation, none of which move faster because the code came from a vendor.

The rubric, and how to score it

Score each variable 0 to 10, where 10 strongly favors building. Multiply by the weight, sum, divide by 10. The result lands between 0 and 100.

Variable	Weight	Scores 10 (build) when	Scores 0 (buy) when
Differentiation	25	The logic is specific to how your organization decides	Three vendors sell it and quality is converging
Data	20	Value comes from a corpus nobody else holds, or the data cannot leave your boundary	Public or generic data, no residency constraint
Five-year cost	20	Seat or usage pricing scales past build plus maintenance inside five years	Subscription stays well below a loaded build
Staffing	15	You have or can retain all four operating roles	You cannot staff on-call for a system you own
Exit cost	12	Leaving means re-embedding, re-tuning, and rewriting an unbounded amount of work	Clean export, documented, provable in a test migration
Time to value	8	No credible product exists to pilot against	A working pilot is available in weeks

62 and above: build the differentiating layers in-house or with an engineering partner, buying the infrastructure underneath.
39 to 61: hybrid. Buy the platform, build the differentiator. Most organizations land here.
38 and below: buy, negotiate the data and exit terms hard, and put engineering budget where it creates advantage.

Three worked examples

Case	Diff / Data / Cost	Staff / Exit / Time	Score	Call
A. State agency call-center answer assistant 40,000 public policy documents, 300 agents	2 / 1 / 3	2 / 4 / 1	22	Buy
B. Specialty insurer risk model 18 years of adjudicated claims, regulator-facing explanations	10 / 10 / 6	5 / 8 / 4	77	Build
C. Federal program office document extraction 40 years of scanned test reports, CUI, provenance required	7 / 9 / 5	3 / 6 / 2	59	Hybrid

Case A scores 22 and the answer is buy. The documents are public, the use case is answering policy questions, and four vendors sell a competent version. Building spends a year of engineering to reach parity with a product costing less than one engineer. Negotiate instead for an export of the index and conversation logs, a written statement that agency data is not used to train models serving other customers, and accuracy measured on the agency's own question set.

Case B scores 77 and the answer is build. The corpus is the moat, the logic is the company's product, and a state regulator will ask why a specific decision was made. The build is more tractable than it looks: a model, an explanation layer, and an evaluation set, on infrastructure that is entirely bought. A build verdict never means building everything.

Case C scores 59 and the answer is hybrid. The corpus is unique and CUI-bound, driving the data score high, but the program office cannot retain four engineers, driving staffing low. So it buys the platform layer, an OCR and document-processing service already authorized at the required impact level, and builds what is specific to the mission: the extraction schema for these document types, span-level provenance tying every field to a page and a bounding box, a confidence policy that routes weak fields to a human, and the evaluation set proving the false-extraction rate is inside tolerance. Roughly a third of the code, nearly all of the value.

The hybrid path: buy the platform, build the differentiator

The rule that makes hybrid work: buy anything where a vendor's roadmap moves faster than yours and switching cost is bounded and provable. That covers compute, storage, identity, base models, orchestration frameworks, observability, and vector storage with a clean export. Build what encodes judgment: the domain schema, retrieval tuned to your corpus, the business rules, the escalation policy, the audit trail, and the evaluation set.

The evaluation set matters most because it survives every other decision. Models get deprecated, vendors get acquired, frameworks fall out of fashion. Several hundred labeled examples from your real work, with agreed correct answers and a scoring script, let you swap any component and know within a day whether the swap made things worse. Own it and you have the upper hand in every renewal. Skip it and you are negotiating on vibes.

Own these regardless of which way the decision goes

• The evaluation set and its scoring script, in your repository
• The labeled gold data, with the labeling guidance that produced it
• The domain schema or ontology, in a portable format
• Prompts, tool definitions, and configuration under version control
• An export of source documents, chunks, and embeddings, tested at least once
• The metrics history, so quality regressions are visible over time
• A written exit runbook with named steps and an estimated duration

The federal overlay

Public-sector buyers carry constraints that change the math. Cloud services used by federal agencies must be FedRAMP authorized under the FedRAMP Authorization Act, Title LIX of Public Law 117-263, so a SaaS product not already on the marketplace can add a year before it is usable. Building inside a boundary the agency already authorized inherits controls and skips that wait, a build advantage that rarely appears in a cost model. DoD adds impact-level segregation, and CMMC requirements began flowing into DoD solicitations under the acquisition rule effective November 2025.

Two more apply to both columns. Section 508 conformance is a legal obligation for any interface an agency deploys, and retrofitting costs far more than specifying. And accountability does not transfer: the authorizing official signs the risk acceptance for a purchased system exactly as for a built one.

A thirty-day way to decide

Thirty days works because every expensive unknown is measurable inside it. Whether a vendor's product handles your documents is measurable. Whether your data can legally sit in their boundary has a written answer. Whether your team can build the differentiating slice is answered by having them build a small one. Everything else is opinion, and opinion is what makes these decisions take six months and still come out wrong. We run this sprint for federal, state, and commercial customers, and the deliverable is the same either way: a scored rubric, an evaluation set that belongs to the customer, a costed five-year model, and a recommendation that holds up under questioning.

Bottom line

Build versus buy is not a philosophy. It is arithmetic across six variables, and the answer is layer-specific for almost every organization. Buy the commodity. Build what encodes your judgment. Own the evaluation set and the exit runbook either way. Weight the decision before you score it, because the fastest route to a bad answer is picking one and reasoning backward.

Frequently asked questions