The buy-versus-build conversation around enterprise AI was a religious war eighteen months ago. Some CIOs were determined to build everything custom. Others were determined to buy everything from the vendors and avoid the engineering exposure. By May 2026 the conversation has matured into something more useful — a set of decision frames that most experienced CIOs broadly agree on, with the disagreements now happening at the margins.

This is what the framework looks like in practice, drawn from the conversations I’ve been having with peers across financial services, retail, professional services, and government.

Buy when the use case is undifferentiated

The clearest pattern is that undifferentiated AI use cases should be bought, not built. Email summarisation. Meeting notes. Generic document Q&A. Code completion. The vendors are pouring engineering effort into these, the products are getting good fast, and the differentiation a custom build would deliver doesn’t justify the engineering cost.

The CIOs who built generic productivity AI in 2024 are mostly regretting it now. The features the vendors shipped in 2025 made the custom builds look dated. The maintenance overhead of keeping a custom productivity AI competitive with the vendor versions is higher than most internal teams can sustain.

The pattern of “buy what’s undifferentiated, build what’s differentiated” is not unique to AI. It’s the same logic that drove the SaaS adoption wave a decade ago. AI is following the same path on a faster cycle.

Build when the use case is differentiated and the data is yours

The other end of the spectrum is also clearer now. AI use cases that depend on proprietary data, proprietary workflows, or proprietary domain knowledge generally need to be built. The vendors don’t have the context to build them, and the off-the-shelf tools don’t access the data they need.

Examples I’ve seen working well as builds: AI agents that operate against the organisation’s actual customer data and workflows; AI models that score opportunities based on the organisation’s actual conversion patterns; AI tools that draft work product specific to the organisation’s matter types and house style.

The build patterns that work are not full from-scratch builds. They’re builds on top of foundation models, with the differentiation in the data, the orchestration, the evaluation, and the integration. The model itself is bought; the value sits in everything around it.

The middle is where the interesting decisions are

Most enterprise AI use cases sit in the middle and that’s where the buy-versus-build decision is genuinely contested.

Customer service AI is the canonical example. There are good vendor products. There are also strong arguments for custom builds where the support workflows, the product knowledge, and the customer history are proprietary enough to make the custom version meaningfully better. Different organisations are coming to different conclusions on the same use case.

The decision factors I see CIOs weighting most heavily in the middle ground:

Time to value. A vendor product can be in production in 8-12 weeks. A custom build is 6-12 months. If the business case depends on early value capture, the vendor option is hard to beat unless the gap in fit is severe.

Differentiation. If the use case directly touches the customer experience and the differentiation matters for retention or growth, the build case strengthens. If the use case is internal-facing and incremental, the buy case strengthens.

Total cost of ownership. The headline cost of vendor products is often less than the headline cost of building. The TCO is usually less clear cut once you account for integration, customisation, ongoing licensing as usage grows, and the cost of switching vendors later.

Capability. CIOs with strong internal AI engineering capability can build credibly. CIOs without it cannot, regardless of how much they want to. The honest assessment of internal capability is one of the harder parts of this conversation.

The pattern that’s emerging

The pattern I see most often in mature enterprise AI programs is a layered approach. The foundation is bought — the foundation models, the AI platform, the basic productivity tools. The middle layer is configured — vendor products, customised heavily for the organisation. The top layer is built — the AI applications and agents that touch the differentiating workflows.

This pattern works because it concentrates the build effort where the differentiation is highest, while leveraging vendor velocity for everything else. The CIOs who try to build everything end up with a thinly stretched engineering team that can’t keep pace with vendor product cycles. The CIOs who try to buy everything end up with workflows that don’t fit the organisation and an integration mess between vendor products that don’t talk to each other.

For the build component, there’s a recurring pattern of bringing in external delivery partners. The internal team owns the strategy, the architecture, and the long-term operation. The external partner brings delivery velocity and AI engineering depth. Engaging an AI consultancy for the delivery while keeping ownership internal has worked well in several of the programs I’ve seen succeed.

The pitfalls

A few specific pitfalls show up regularly in AI buy-versus-build decisions.

Underestimating integration. The vendor product looks good in the demo. The integration into the actual environment — identity, data, observability, governance — adds 30-50% to the headline cost and timeline. CIOs who don’t budget for integration are consistently surprised.

Overestimating internal capability. AI engineering at production scale is a specific skill. Senior generalist engineers don’t always have it. CIOs who assume their existing team can pick it up on the job often end up with stalled builds.

Ignoring vendor lock-in. Some vendor products embed your data and workflows in ways that are hard to extract from later. The decision to buy needs to factor in the future cost of switching. Some vendors are better than others on this.

Over-building. Custom builds that try to replicate vendor functionality are usually mistakes. The build should focus on the parts that genuinely differentiate, not on reimplementing what’s available off-the-shelf.

The mid-2026 take

The honest CIO assessment in May 2026 is that buy-versus-build for AI looks more like buy-versus-build for any other major enterprise technology decision. The questions are familiar. The trade-offs are familiar. The discipline of asking “where is the differentiation, where is the capability, what’s the time to value” is unchanged.

The new wrinkle is that the vendor velocity in this space is faster than in most other technology categories. A custom build that looks differentiated today may be undifferentiated in six months. The dynamic argues for building thinner layers of custom on top of fatter layers of vendor product, and for revisiting the buy-versus-build line more frequently than has been usual for enterprise IT.

The CIOs doing this well are the ones who treat the buy-versus-build line as a moving target, not a one-time decision.