Buy, Build, or Orchestrate

In healthcare, public safety, and financial services, the stakes on that question are unusually high. A wrong AI vendor can put PHI on the wrong cloud. A wrong build can burn a year of engineering on a capability the market catches up to in a quarter. A wrong strategic posture can leave a whole organization locked into a single provider whose incentives will not stay aligned with yours. The framework below is the one I use with boards and executive teams to make the call clearly, defensibly, and in a way that ages well.

Start with the spec, not the vendor

Almost every failed AI initiative I have reviewed started with a vendor demo, not a specification. The team saw something impressive, worked backwards to a business case, and only later discovered the actual behavior they needed did not match what the demo showed. The first work is not procurement. It is writing down precisely what the system must do, what it must never do, and how you will measure both. That is the spec. Every subsequent decision hangs off it.

When to buy

Buy when a mature product already satisfies the spec, the vendor's roadmap aligns with yours, the compliance posture is clean, and the capability is not a source of durable competitive advantage. Ambient documentation for a specific EHR is a buy. Enterprise search over your own documents is a buy. A commodity chat interface is a buy. The test is simple: if three competitors are offering the same capability at parity, ownership does not help you. Speed to value does.

The failure modes of buying are all avoidable if you look for them: data flowing to a training set you did not consent to, a business model that pivots after you commit, a compliance certification that turns out to be aspirational. Do the due diligence once and make the decision.

When to build

Build when the capability is core to your competitive position, you have proprietary data that no vendor can match, the spec is unique to your operating model, and you have the engineering depth to operate the system for its useful life. Building is not a technology decision. It is a commitment to run, secure, evaluate, and evolve a system for a decade. If the organization is not prepared to staff for that, do not start.

In regulated industries, building has a hidden advantage: you control the data path end to end. No BAAs to renegotiate, no vendor breach in your incident report, no surprise about where inference is happening. That control is worth real money when the alternative is explaining a third-party incident to a regulator.

When to orchestrate

Orchestration is the option most executives have not yet been pitched, and it is the right answer more often than either buy or build. Orchestration means you own the spec, the evaluation harness, the routing logic, and the data path, but you rent the underlying capability from whatever combination of models and vendors performs best at any given moment. When a better model appears, you point your orchestrator at it. When a vendor changes terms, you route around them. When a new use case appears, you extend the spec instead of buying another product.

The orchestration layer is the piece that is durably yours. The models below it are commodities that will keep improving. This is the same logic that made cloud infrastructure a strategic capability while individual servers became disposable.

The regulated-industry decision matrix

• Data sensitivity high, capability commodity:buy from a vendor with a clean compliance posture, isolate the data path, keep the switching cost low.
• Data sensitivity high, capability differentiating:build or orchestrate. Never let a differentiating capability depend on a single external vendor.
• Data sensitivity low, capability commodity:buy. Do not spend engineering cycles on undifferentiated work.
• Data sensitivity low, capability differentiating:orchestrate. Own the spec and the evaluation harness, rent the intelligence.

What the orchestration layer actually contains

1. The behavior spec. Written down, versioned, reviewed like code.
2. The evaluation harness. Runnable, gated, and used as the promotion criterion for every model swap.
3. The routing layer. Decides which model, which tools, and which fallback path a given request uses, based on cost, latency, sensitivity, and eval scores.
4. The audit trail. Every decision, every input, every output, retained for as long as your regulators require.
5. The kill-switches and escalation paths. Because a regulated system that cannot be stopped safely is not a regulated system.

The trap of "we use OpenAI"

The most common anti-pattern in healthcare AI right now is treating a foundation-model API as a strategy. It is not. It is one input to a strategy. Without a spec, without evals, without an orchestration layer of your own, "we use OpenAI" means the vendor has your roadmap. Every price change, terms change, or capability shift moves through your business unmediated. That is a hostage situation dressed up as a partnership.

How spec-driven development changes the calculus

A decade ago, the argument against orchestration was that building the layer above the models was itself a large software project. Spec-driven development, agent frameworks, and modern evaluation tooling have collapsed that cost. A small team can now build and operate an orchestration layer that would have required a platform organization five years ago. The economics have moved. Most boards have not caught up yet.

The through-line

In regulated industries, the winning AI posture is neither maximum outsourcing nor maximum in-house engineering. It is owning the pieces that compound, such as the spec, the evals, the routing layer, and the audit trail, and renting the pieces that commoditize. Buy what is commodity. Build what is differentiating and sensitive. Orchestrate everything in between. And write it all down before the first vendor conversation.