“Should we build or buy?” is one of the oldest questions in enterprise technology, and AI has quietly broken it. The question assumes two options. The 2026 reality is a spectrum with at least five meaningful positions, and most organisations will end up occupying several of them at once, sometimes within a single use case. Treating the sourcing decision as binary produces the two classic failures: the organisation that buys everything and wakes up with fifteen overlapping subscriptions, no differentiation, and no leverage; and the organisation that builds everything and wakes up eighteen months later with a bespoke system the market now sells for forty dollars a seat.
This article maps the spectrum, gives you a decision framework that assigns each use case to the right position, and covers the portfolio-level posture that keeps the individual decisions coherent.
The sourcing spectrum
Figure 1 lays out the five positions, from least to most ownership, and the honest trade each one makes.
Position one: embedded AI features. The AI that arrives inside software you already own: the copilot in your office suite, the assistant in your CRM. Zero build effort, instant deployment, and zero differentiation, because your competitors get the identical feature on the identical day. Right for commodity productivity; wrong for anything you would call an advantage. The strategic task here is governance, not sourcing: these features arrive whether you plan for them or not, and the approved-tools register from the governance article is what keeps them from becoming shadow AI with a purchase order.
Position two: AI-native SaaS. Purpose-built products for a function: an AI customer-support platform, a contract-analysis tool. Fast time-to-value, vendor-maintained quality, and per-seat or per-usage pricing that looks cheap at pilot scale and compounds alarmingly at production scale. Right when the workflow is common across your industry and your data adds little edge. The risks are lock-in and data flow: your prompts, documents, and outcomes may be improving a product your competitors also rent.
Position three: platform assembly. Building your use case from managed components: frontier model APIs, your cloud’s AI services, orchestration frameworks, your own data and integration layer. This is the centre of gravity for serious enterprise AI in 2026, because it balances speed (the hard components are rented) with differentiation (the assembly, the data, and the workflow are yours). Requires real engineering capability, but of an integration kind, not a research kind.
Position four: fine-tuned open models. Taking open-weight models and adapting them to your domain, deployed on infrastructure you control. The economics shifted decisively in the last two years: open-weight models now trail the proprietary frontier by only around three months on average, and on many production tasks (extraction, summarisation, standard code generation) the quality gap is negligible. Right when volume is high (self-hosting typically crosses over somewhere between 10 and 30 million tokens a day), when data cannot leave your infrastructure, or when deep domain adaptation is the differentiator. The next article treats this position in full, because it has become a board-level question rather than an engineering preference.
Position five: full custom. Training or heavily adapting models on proprietary data at serious scale, owning the entire stack. Reserved for organisations where AI capability is the product, or where a truly unique data asset meets a truly strategic use case. For most enterprises, most of the time, this position is a vanity trap. The test is brutal and useful: would this system, built, constitute a durable competitive advantage that positions one through four cannot replicate? If the answer requires optimism, buy.
The decision framework
For any individual use case, four questions place it on the spectrum, asked in this order.
Question one: is this differentiating or commodity? The most important cut, and the one that determines which half of Figure 1 you are even shopping in. Commodity capability (meeting summaries, generic drafting, standard classification) belongs at positions one and two, full stop; every hour spent building commodity is an hour stolen from differentiation. Differentiating capability (anything where your data, your workflow, or your domain judgement creates an edge competitors cannot rent) belongs at three or four. Be stingy with the “differentiating” label. Most things are commodity, and that is fine.
Question two: what does the data permit? The governance labels from earlier in the track do real work here. If the use case needs restricted data that cannot flow to third-party APIs, positions one and two are eliminated and position four gets a strong pull. Sovereignty and residency requirements have made this a primary driver in regulated sectors, and here in Australia the supervisory attention on third-party data flows makes the question sharper each year.
Question three: what does volume do to the economics? Model the cost at production scale, not pilot scale, using your actual expected token volumes and seats. API pricing that costs hundreds a month in pilot can cost tens of thousands at scale; per-seat SaaS across a five-thousand-person function is a permanent tax. Conversely, self-hosting carries a real fixed cost: infrastructure plus roughly half to one full-time engineer of MLOps attention, a number teams routinely underestimate. The crossover maths deserves an actual spreadsheet, and my ROI track walks through it properly.
Question four: can we operate what we choose? A position four decision made by an organisation without MLOps capability is a decision to fail slowly. Capability can be built or hired, but the build time belongs in the plan, not in the assumption. Match ambition to the maturity assessment from earlier in the track: position three assumes Stage 3 maturity; position four sits most comfortably at Stage 3 to 4.
Figure 2 assembles the four questions into the decision flow, with the typical portfolio distribution that results.
The distribution at the bottom of Figure 2 is worth internalising, because it is what a healthy answer looks like for a typical enterprise: the large majority of use cases landing at positions one to three, a meaningful minority at position four where volume or sovereignty demands it, and position five empty or nearly so. If your portfolio shows everything at one extreme, the framework is being skipped somewhere, and it is worth asking whether enthusiasm (everything built) or procurement habit (everything bought) is doing the deciding.
Portfolio-level posture
Individual decisions need a portfolio-level policy above them, or you accumulate incoherence one reasonable choice at a time. Three postures to set explicitly, ideally in Box 6 of your strategy canvas.
A default, with justified exceptions. For most organisations the sensible default is position three (platform assembly) for differentiating cases and position two for commodity, with four as the justified exception. Defaults concentrate learning: your teams get good at one pattern instead of mediocre at five.
A routing architecture, not a single bet. The dominant technical pattern of 2026 is hybrid, multi-model routing: a gateway that sends simple, high-volume tasks to cheap models (often self-hosted open weights), complex reasoning to frontier APIs, and sensitive-data tasks to the sovereign path. Designing for routing from the start costs little and buys enormous flexibility, because it converts model choice from an annual agony into a configuration change. It is also your negotiating leverage: a vendor who knows you can route away prices differently from one who knows you cannot.
An exit test for every entry. Before any sourcing commitment: what does leaving cost? For SaaS, can you export your data, prompts, and fine-tuning artefacts? For APIs, how abstracted is your integration? For open models, the exit risk inverts: the model cannot be taken away, but its maintenance can stop, so what is the succession plan? Lock-in is not avoidable, only priceable, and the time to price it is before signing.
Revisit dates, not permanent answers
One final discipline, and it may matter more than the framework itself: every sourcing decision gets a revisit date, typically twelve months out, written down when the decision is made. Put the date in the decision record itself, alongside the assumptions that drove the choice (the volume forecast, the capability gap, the price per token), so the future review can check the assumptions rather than relitigate the argument from scratch. The ground moves too fast for permanent answers. Open-weight quality moved three years of progress in eighteen months; API prices have fallen repeatedly; capabilities that justified custom builds now ship as commodity features. A decision that was right when made can be wrong within a year, and the organisations handling this well are not the ones that predicted correctly, they are the ones that re-decided cheaply.
The framework in this article deliberately deferred its most strategic branch: position four, the open-weights question, which has graduated from engineering preference to genuine strategic posture, with sovereignty, cost, and control arguments that boards now ask about directly. That is the next article.