The build-versus-buy discussion in enterprise AI is typically run by technology teams. It is framed around technical capability, engineering headcount, and integration complexity. This framing produces the wrong answer because it asks the wrong question.
Build versus buy is not a technology decision. It is a capital allocation decision. It should be evaluated with the same rigour applied to any significant investment — across multiple dimensions, with clear-eyed assessment of trade-offs, and with explicit attention to what the organisation is optimising for over its planning horizon.
Five dimensions matter.
1. Total Cost of Ownership
Building an AI system carries high fixed costs and comparatively low variable costs. The investment is front-loaded: engineering, infrastructure, data preparation, testing, deployment. Once the system is operational, the marginal cost of each additional query or workflow is modest. The cost structure resembles a capital expenditure.
Buying — typically through a SaaS subscription — inverts this. Fixed costs are low. There is no large upfront outlay. But variable costs accumulate steadily: per-seat licensing, per-query fees, storage charges, premium support tiers. The cost structure resembles an operating expenditure that compounds over time.
This is an operating leverage question. At low volumes and short time horizons, buying is cheaper. The subscription looks affordable. At higher volumes and longer horizons, the economics shift. The recurring fees accumulate. The build option, with its high initial outlay but flat ongoing costs, begins to produce a lower per-unit cost.
Most organisations evaluate this over a single budget cycle. That is too short. AI systems, once embedded in workflows, tend to expand in scope. The volume of queries grows. The number of users increases. The cost trajectory of a subscription model is not linear — it accelerates as adoption deepens. The cost trajectory of a built system flattens.
The analysis must account for the full expected life of the system, not just the first year.
2. Time to Value
Buying delivers faster initial deployment. A vendor has already built the system, tested it, and packaged it. The time from contract signature to first usable output is measured in weeks, sometimes days. For organisations under immediate pressure to demonstrate AI capability, this speed is attractive.
The cost of that speed is customisation debt. A purchased system is built for a general market, not for one organisation's specific processes. It will handle the common cases well and the specific cases poorly. Over time, the gap between what the system does and what the organisation needs widens. Workarounds accumulate. Users develop parallel manual processes. The system delivers value, but less than it should, and the shortfall grows.
Building takes longer to reach initial deployment. The first months produce infrastructure, not outputs. But the system, once operational, is shaped to the organisation's actual requirements. There is no gap between capability and need — or at least, the gap is under the organisation's control. Customisation is not debt to be serviced later. It is equity built from the start.
The question is whether the organisation can afford to wait for a system that fits, or must accept a system that approximates.
3. Data Sovereignty
Every enterprise AI system processes sensitive data. Contracts, financial records, personnel files, strategic plans, client information. The question is where that data resides, who can access it, and under what conditions.
Cloud-based purchased systems offer contractual protections. Service agreements specify data handling practices. Encryption is standard. Compliance certifications are maintained. These are real protections, and for many use cases, they are sufficient.
They are also, fundamentally, promises. The organisation does not control the infrastructure. It does not control the access logs. It does not control the model's training pipeline or whether its data is used to improve the vendor's general product. Contractual promises can be renegotiated, reinterpreted, or breached. The remedy for a breach is legal, not preventive.
On-premise or private-cloud deployment provides absolute control. The data does not leave the organisation's environment. Access is governed by the organisation's own policies, monitored by its own tools, restricted by its own infrastructure. This is not a contractual assurance. It is an architectural fact.
For organisations handling highly sensitive data — financial institutions, legal firms, government agencies, healthcare providers — the distinction between contractual control and architectural control is material. The risk assessment must reflect this.
4. Competitive Moat
A SaaS subscription is not a moat. A proprietary AI system trained on your institutional knowledge is.
When an organisation buys an AI tool, it gains the same capability as every other customer of that vendor. The tool may improve the organisation's efficiency. It does not differentiate it. Every competitor can purchase the same subscription, deploy the same system, and achieve the same results. The advantage is temporary — it lasts until the next firm signs the same contract.
A built system, by contrast, is shaped by the organisation's own data, its own processes, its own institutional knowledge. A document analysis system trained on a firm's twenty years of transaction history develops pattern recognition that no general-purpose tool can replicate. A contract review system calibrated to a firm's specific risk appetite and negotiation patterns reflects institutional judgment, not generic capability.
This distinction matters most in industries where knowledge is the primary asset. Law firms, investment banks, consultancies, specialised lenders — these organisations compete on the depth and specificity of their expertise. A general-purpose AI tool does not capture that specificity. It cannot. It is designed to serve a broad market, not one firm's accumulated wisdom.
The capital allocation question becomes: is the organisation investing in a tool that everyone can access, or in a system that embodies its own competitive advantage?
5. Exit Optionality
Vendor lock-in is a familiar concept, but its implications for AI systems are more severe than for traditional software.
A purchased AI system typically bundles several components: the model, the retrieval layer, the fine-tuning, the integration logic, the data pipelines. When the organisation wants to change vendors — because of pricing, capability gaps, strategic shifts, or regulatory requirements — it must replace the entire stack. The transition cost is high. The data prepared for one vendor's format may not transfer cleanly to another. The fine-tuning is lost. The institutional knowledge embedded in the system's configuration disappears.
A built system is composed of discrete components. The model can be swapped independently of the retrieval layer. The data pipelines are owned and can be redirected. The fine-tuning data remains with the organisation. If a better model becomes available — and in this field, better models become available regularly — the organisation can adopt it without rebuilding the entire system.
Component-level upgradeability is a structural advantage. It means the organisation is never locked into a single vendor's roadmap, a single model's limitations, or a single architecture's constraints. The system evolves at the organisation's pace, not the vendor's.
The Allocation Framework
Not everything should be built. Not everything should be bought. The decision depends on where the capability sits relative to the organisation's core operations.
Build what touches sensitive data. Build what differentiates. Build what embeds institutional knowledge. Build what must be controlled absolutely.
Buy the periphery. Buy the utilities. Buy the capabilities that are genuinely commodity — where no firm-specific advantage exists and where the vendor's scale produces better results than internal development would.
The error most organisations make is treating AI as a single, monolithic decision. It is not. It is a portfolio of capabilities, each of which should be evaluated on its own merits against these five dimensions. Some components belong in-house. Others belong with vendors. The allocation should be deliberate, not defaulted.
Technology teams will tend toward building, because that is what they do. Procurement teams will tend toward buying, because that is what they do. The decision should sit with neither. It should sit with the people responsible for long-term capital allocation — the people who understand that every investment is a trade-off, and that the right trade-off depends on what the organisation is trying to become.