Build vs. Buy Is the Wrong Question for Enterprise AI

The wrong frame

“Should we build our AI capabilities in-house or buy from a vendor?” This is the question every enterprise AI steering committee eventually confronts. And it’s the wrong question, not because the answer doesn’t matter, but because the framing obscures what actually matters.

Build vs. buy treats AI as a technology decision: which approach produces the best system at the lowest cost? But AI capability in an enterprise isn’t a system. It’s an organisational capability: a combination of technology, process, knowledge, and structural alignment that determines whether AI creates value or becomes another line item.

The right question isn’t “build or buy?” It’s “what do we need to understand deeply enough to control, and what can we safely treat as a commodity?”

What the build-vs-buy framing misses

The integration layer is always custom

Whether you build a model or buy one, the integration into your organisation’s workflows, data, and decision-making processes is always bespoke. The model is 15-20% of the value chain. The remaining 80% (data preparation, workflow integration, user trust calibration, feedback loops, process adaptation) is specific to your organisation and cannot be purchased.

Organisations that “buy” AI and expect vendor solutions to integrate smoothly are consistently disappointed. The vendor provides a model. The organisation needs a capability. The gap between the two is where all the hard work lives, and buying doesn’t eliminate it.

Knowledge asymmetry determines power

When you buy AI from a vendor, the vendor understands the model. You understand your business. The integration requires both kinds of understanding. If you don’t build sufficient internal knowledge of how the model works (its assumptions, limitations, failure modes, and appropriate use) you can’t effectively integrate it. You become dependent on the vendor not just for the technology but for the knowledge of how it interacts with your business.

This isn’t a licensing risk. It’s a strategic risk. The vendor’s interests and your interests aren’t aligned. The vendor is incentivised to maintain dependency. You’re incentivised to build capability. The build-vs-buy decision is also a decision about where knowledge, and therefore power, resides.

The maintenance question

AI systems aren’t static. Models drift. Data distributions change. Business requirements evolve. User needs shift. The question isn’t just who builds the initial system but who maintains, monitors, and improves it over time.

Bought systems create ongoing vendor dependency for maintenance and updates. Built systems require ongoing internal capability for the same. Neither is free. But they create different organisational dynamics: vendor dependency concentrates risk and reduces learning, while internal maintenance distributes knowledge and builds capability (but requires sustained investment in talent).

Build vs. buy isn’t a decision about technology. It’s a decision about where you want organisational knowledge to accumulate, and therefore where you want strategic control to reside.

A better framework

Instead of build vs. buy, we propose three questions:

1. Is this a differentiating capability?

If the AI capability is central to your competitive differentiation, if it’s how you serve customers differently, operate more efficiently, or make better decisions than competitors, the knowledge needs to be internal. You can use external models as components, but the integration, the training data strategy, and the improvement cycle need to be owned internally. This isn’t about building everything from scratch. It’s about maintaining understanding and control over the capability that matters most.

If the AI capability is operational but not differentiating (spam filtering, basic document classification, standard language translation), buy it. Commoditise it. Don’t invest scarce internal capability in things that don’t create strategic advantage.

2. How tightly coupled is the AI to your organisational context?

AI that operates on generic data with standard outputs (language models, image classification, translation) can be effectively bought because it doesn’t require deep organisational knowledge. AI that operates on your proprietary data, reflects your business logic, and integrates with your specific workflows needs internal knowledge because nobody outside can understand the context well enough to build it right.

The coupling question isn’t about the model but the data and the workflow. The more organisationally specific these are, the more internal capability you need.

3. What rate of improvement do you need?

If the AI capability needs to improve rapidly in response to changing business conditions, internal capability allows faster iteration. You see the problem, understand the context, and can adjust. If the vendor is in the loop, every improvement cycle includes a translation step (explaining your context to people who don’t live in it) that adds latency and information loss.

If the capability is relatively stable and improvements are incremental, vendor-managed updates may be sufficient.

The build-vs-buy question will continue to be asked in steering committees. But the organisations that answer it well will be those that see through the technology framing to the organisational capability question underneath.