I enjoy building things. This is useful professionally and dangerous financially.

When a company sees an AI opportunity, building feels like progress. There is a team, a repository, a model comparison, and eventually a demo. Buying can feel less ambitious. Waiting can feel like failure.

None of these feelings belong in the decision model.

The question is not whether your team can build it. Good engineers can build many things. The question is whether this capability deserves to become part of what the company must understand, maintain, govern, and defend.

Start with differentiation

If the capability is central to why customers choose you, building may create real advantage.

For a financial decision product, the way evidence becomes a signal, how uncertainty is handled, and how the customer receives an explanation may be the product itself. Outsourcing the whole decision to a black box could remove the thing you are supposed to be good at.

But if the capability is meeting transcription, generic document extraction, or a standard support assistant, the market may improve faster than your internal team can justify.

A useful test is: If a competitor bought the same component tomorrow, would our advantage disappear?

If not, your advantage probably lives somewhere else—in workflow, distribution, data, trust, domain knowledge, or execution.

“Buy” still contains a lot of verbs

Buying software does not remove implementation. It changes the work.

You still need to evaluate data handling, model behaviour, integration, access control, logging, user experience, contracts, incident response, and exit options. In a regulated workflow, you may also need evidence about the provider and the ability to explain how your use of the system is governed.

The vendor’s polished demo is not your production environment.

Ask direct questions:

  • Which model and version produce the result?
  • Can that change without our approval?
  • Is our data retained or used for training?
  • What logs and evaluations can we export?
  • How are regional processing and subprocessors handled?
  • What happens to service and price at ten times the volume?
  • Can we move our prompts, evaluations, and history elsewhere?
  • Who supports an incident on a Sunday?

Vendor lock-in is not only an API problem. It can be operational knowledge, evaluation data, user habits, and a contract that becomes painful precisely when the product succeeds.

Integration is often the grown-up answer

Many companies should not build a foundation model or accept a complete vendor workflow. They should integrate a commodity capability inside a product boundary they control.

That can mean owning:

  • the customer experience;
  • the workflow and decision rights;
  • retrieval and permitted data;
  • evaluations and acceptance thresholds;
  • fallbacks and human review;
  • audit history;
  • the interface that makes a provider replaceable.

The external model then becomes a component, not the company’s judgement.

This approach is less exciting in a pitch. It is often more resilient in production.

Waiting is not doing nothing

Sometimes the technology is changing too quickly, the use case is weak, or the data is not ready. Waiting six months can be rational.

But “wait” should have a plan.

Clean the source data. Measure the manual workflow. Define an evaluation set. Improve permissions. Negotiate data access. Test vendors with historical cases. Document the current cost. Decide which regulation and internal policy may apply.

Then waiting becomes preparation rather than avoidance.

The EU AI Act is being applied in stages, with obligations depending on the role and risk of the system. The timetable and supporting guidance continue to develop. For European companies, this is another reason to maintain an AI inventory and a clear description of purpose now, even when the final technical choice is not made.

My simple decision grid

I score the options across six dimensions:

  1. Strategic value: is this where the company should be unusually good?
  2. Time: how quickly can we learn with real users?
  3. Control: what behaviour, data, and evidence must remain ours?
  4. Capability: can the team operate this after the builders leave?
  5. Economics: include integration, review, monitoring, and switching—not only licence or development cost.
  6. Reversibility: what happens if the vendor, model, regulation, or business case changes?

No option wins every row.

Build when ownership creates advantage. Buy when the capability is genuinely standard. Integrate when you need control around a commodity engine. Wait when uncertainty is expensive and preparation can reduce it.

The boring decision is often the one that saves the exciting project.

Sources and further reading