Build vs buy for AI infrastructure: 5 questions

The build-vs-buy question on AI infrastructure is hard because the wrong answer is expensive. Build everything and you burn two years reinventing wheels other people already shipped and tested. Buy everything and you don't own what actually differentiates you. The right answer is almost always a mix, and five questions help you find it.

1. Domain advantage

Question one: where is your domain advantage?

If your company has a specific competitive advantage in how you understand or process a particular kind of data, that advantage is worth owning. A finance firm with 30 years of credit-scoring expertise on Norwegian SMBs shouldn't buy a generic credit model. The model layer in that area should be owned. But registry integration, document parsing and general agent orchestration can be bought.

2. Regulation

Question two: how regulated is the decision?

The more regulated, the more important it is to own the traceability. You can buy the engine, but you have to own the log, the evaluations and the overrides. If the vendor doesn't give you full visibility into what the agent did and why, it isn't an option for regulated decisions regardless of how good it is otherwise. Traceability is your defence in an examination, and it can't be a black box.

3. Requirement stability

Question three: how stable is the requirement?

If requirements change monthly because the sector is in motion, building is expensive. You update your own wheel while others already have the next one ready. If requirements are stable because they're built around your own processes that won't change in five years, building gives more control. In practice, this means standardised fields (KYC, invoice, contract typification) are good buy candidates, while your own process decisions are candidates to build.

4. Swap risk

Question four: how easy is it to swap vendors?

The most important trade-off is what happens if the vendor disappears, gets acquired, or doubles the price. If you've built on the vendor's data model and nobody else can read it, you're locked in. If the vendor's layer sits above your own structured data, you can swap. Build the layer that holds your data. Buy the layers that read from it.

5. Required specialisms

Question five: how many different specialisms do you need to build?

AI infrastructure needs several types of competence: ML engineering, data engineering, agent orchestration, evaluation, security, compliance. If the company doesn't have or can't recruit several of these, building is risky. You end up with parts that don't fit together. Buy what requires skills you don't have, and build what sits inside what you already do well.

A useful mix

A useful mix that fits many Norwegian mid-sized companies in 2026 looks like this.

Build candidates: your own customer and process layer (the ontology). Domain-specific models where your experience is the edge. The traceability log and the evaluation engine. The operator surface where humans actually work.

Buy candidates: document parsing and OCR. General language models. Standard agent orchestration. Vector databases. General observability. Standard integrations into ERP, CRM and communication tools.

The most common mistake is building everything because it feels like control. In practice it's delay and fragmentation. The second most common is buying everything because it feels faster. In practice it's lock-in on a platform that gives you no competitive edge.

The right answer requires honesty about where your real edge sits and where you have the discipline to build with quality. The five questions help you navigate it without ending up at either extreme.