Enterprise AI: build, buy, or assemble

Build versus buy is the wrong frame for enterprise AI, because almost nothing gets built or bought outright. Nearly every production system is **assembled**: a bought model, bought inference, usually a bought vector store and observability stack — wired to retrieval, a permissions model, and an escalation policy that were built, because they could not have been bought. The useful question is not which column costs less. It is which parts of the system are specific to your business and therefore cannot be outsourced to anyone.

Three parts are always yours, whatever you buy. **Your records** — no vendor ships retrieval over your contracts, tickets and ledger, because the shape of that data is yours. **Your permissions model** — what a support agent may see is a policy decision about your customers, not a product feature. And **your definition of a wrong answer** — the threshold where a draft becomes an action, and which mistakes are recoverable versus reportable. A vendor can supply the machinery for all three. None of them can supply the content.

Everything else is genuinely purchasable, and buying it is usually right. Models, inference, embedding storage, tracing, secrets management, queueing — building any of those from scratch is a decision that needs a specific reason, not a default. The failure mode in one direction is a team that writes its own vector database; in the other, a team that buys a platform and assumes the three unbuyable parts arrived with it.

The second failure is the common one, and there is survey evidence for why. In Stack Overflow's 2025 developer survey, only **4.4%** of professional developers said AI handles complex tasks very well, while **66%** named "AI solutions that are almost right, but not quite" as their biggest frustration and **45.2%** said debugging AI-generated code takes longer than writing it (Stack Overflow, 2025 Developer Survey: AI). Every one of those numbers describes the gap between a capable model and a correct outcome — and closing that gap is judgement about your specific system, applied by someone accountable for it. That is the work no procurement process can hand you, which is why it keeps landing on whoever is left holding the incident.

The reason this is not just an architecture preference is that the risk surface of generative systems is treated as materially different by the people whose job is to categorise risk. NIST published a separate companion document for it — the **Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile**, NIST Trustworthy and Responsible AI 600-1, dated 26 July 2024, described as "a cross-sectoral profile of and companion resource for the AI Risk Management Framework (AI RMF 1.0) for Generative AI" (NIST, AI RMF: Generative AI Profile). A standards body does not write a second profile for a technology whose risks are already covered by the first. If the risk surface needed its own document, "we bought a platform" is unlikely to be a complete answer to it.

The part that surprises people is that buying does not move accountability. Under the EU AI Act, a deployer is defined as "any natural or legal person, including a public authority, agency or other body, using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity" (Regulation (EU) 2024/1689, recital 13). Using it under your authority is the test. Whether you wrote it, bought it, or assembled it from six vendors does not enter the definition.

That regulation binds systems placed on or used in the EU market, so whether it reaches you is a question about your customers rather than your head office — plenty of US software is in scope through a single European enterprise account, and the honest answer for most teams is that they have not checked. But the underlying principle survives the jurisdiction entirely: the organisation whose customers are affected is the one that answers for the output. Procurement can move a cost line. It cannot move that.

So the decision rule is not build versus buy. It is: **for each of the three unbuyable parts, name the person who owns it and the artifact that proves it works.** Retrieval — who decides which records are in scope, and what shows the answer came from them? Permissions — who approves a new field becoming readable, and what test fails if a boundary breaks? Wrong answers — who set the threshold, and where is the evaluation run that holds it? A team that can answer all three has an architecture. A team that answers "the platform handles that" has bought the quarter of the problem that was already solved.

Two shapes go wrong reliably. The first is buying a platform and treating its defaults as your policy — the permissions model that ships is the vendor's guess about a generic customer, and it is nobody's actual answer. The second is building to avoid vendor lock-in on the one layer that is genuinely commoditised, while the retrieval and permissions work that is actually differentiating gets whatever time is left.

There is a real cost argument for assembling, and it is not the one usually made. Assembled systems are cheaper to change, because the expensive parts are yours and the replaceable parts are replaceable. When a provider ships a model that behaves differently, a team that owns its evaluation harness runs it and decides. A team that bought the whole stack waits for a vendor to tell them whether anything changed — and the enterprise AI solutions that survive a model change are consistently the ones where that decision was in-house.

None of this argues for more building. It argues for being deliberate about a boundary that most teams draw by accident, usually under time pressure, and then discover during an incident. The AI integration services work is mostly this boundary: what plugs in, what gets written, and who owns each side of the line. An AI business-analytics platform we built is assembled in exactly this shape — bought models and infrastructure, built retrieval and permissions — because the parts that made it useful to that business were never available to purchase.

If you want the short version: buy the machinery, build the judgement. And before signing anything, read what an enterprise AI operating system actually includes and check which of the four parts the proposal in front of you actually covers.