Build vs buy vs embed: choosing an enterprise AI delivery model. Nucleo

Q: Why do build estimates for enterprise AI come in low?

Because they price the first version. The expensive parts arrive later: the integration surface against systems never designed to be read by software, the governance layer of audit trail, traceability, access control and retention, and the maintenance of both, indefinitely, by engineers who could be working on your own product.

Q: Does build vs buy get decided once for the whole company?

No. It is a per-workflow decision. A single company will correctly buy its expense approvals, build the pricing engine that differentiates it, and embed for the cross-system processes that no product covers. Deciding it once at the portfolio level is how organisations end up forcing a generic product onto a process that was never generic.

The short answer

Build, buy and embed are three different answers to one question: who ends up owning the intelligence. Buy when the workflow is a commodity and you hold no data advantage in it, build when the workflow is specific to you and you have an engineering bench you can permanently assign, and embed when the workflow is yours but the bench is not.

That third case is the common one in a European mid-cap, and it is the one the standard comparison has no column for.

Key takeaways

Build vs buy is an operating-model decision, not a procurement one. The question is not what a system costs, it is who is inside your stack while it is built and who owns it afterwards.

Buy is correct more often than build-side vendors admit. Three conditions have to hold together: commodity workflow, no proprietary data advantage, and acceptance of the vendor’s roadmap.

Build estimates price the first version. The integration surface, the governance layer and the maintenance of both are the actual cost, and they arrive in year two.

An agent platform sold without engineering attached is a licence, not a deployment. Somebody still has to reach the legacy database, the identity provider and the data-residency rule.

Decide it per workflow, not once for the company. The same company should correctly buy, build and embed in the same year.

The two-column table is the wrong table

Every build-vs-buy guide compares the same three rows: cost, time to value, control. Both columns quietly assume the same delivery shape, that someone finishes a system and walks away from it. Build hands it from your project team to your operations team. Buy hands it from a vendor to your administrators. The handover is treated as an event rather than as the place where the value is decided.

It is the place where the value is decided. Enterprise AI does not usually fail at the model, it fails at the seam between the system and the company, which is where most pilots stop. A comparison that leaves out who owns that seam is comparing invoices, not delivery models.

So the useful table has a third column, and its rows are different: who works inside your systems during the build, what exists at the end that you own, and who is accountable in month thirteen.

Buy: the case for it, stated plainly

Thoughtworks’ build vs buy analysis for generative AI frames the same trade-off from the engineering side, and reaches a similar conclusion about where the line sits.

Buying is the right answer more often than a company like ours has any commercial incentive to say. Three conditions, and all three have to hold at the same time.

The workflow is a commodity. Expense approvals, meeting capture, first-line ticket triage, contract redlining against a standard template. If your version of the process is not meaningfully different from your closest competitor’s version, there is nothing to own. Owning a commodity returns nothing and costs maintenance.

You hold no proprietary data advantage in it. The reason to build is data no vendor has: your pricing history, your claims decisions, your engineering change orders, the way your best account manager actually qualifies a deal. If the process runs on generic inputs, building it reproduces a product that already exists, more slowly.

You accept the vendor’s rate of change. You are buying their roadmap, their model choices, their pricing changes and their deprecations. That is a fair trade for a commodity workflow. It is a poor trade for a process your margin depends on.

If all three hold, buy the product and spend the attention somewhere it earns more. The expensive mistake is not buying. It is buying for a workflow that fails the first condition, then funding two years of configuration to force a generic product onto a process that was never generic, and calling the configuration work a transformation programme.

Build: the cost lands in year two

Internal build estimates are usually honest about the first version and silent about everything after it. The first version is not the expensive part.

The expensive part is the integration surface. Your data sits across systems that were never designed to be read by software, and a working agent has to reach all of them: the ERP, the CRM, the document store, the mainframe nobody wants to touch. That surface does not stabilise after launch, it moves every time one of those systems is upgraded.

Then the governance layer, which is a project of its own rather than a feature: the audit trail, decision traceability, role-based access, retention, and the evidence a regulator will actually accept. Enterprises building their first agent routinely discover this layer after the model works and before anything reaches production.

Then both of those, maintained indefinitely, by engineers who could have been working on the thing your company sells.

Build is the right answer when the workflow is genuinely yours and you have engineers you can assign permanently. The word doing the work there is permanently. If the four engineers who would build this are the same four keeping the ordering platform alive, you do not have a build option. You have a plan to acquire one, which is a different project with a different timeline.

Embed: the third column

The embedded model is no longer niche. Forward-deployed engineering has become the AI industry’s most contested hiring category, which is worth knowing before you assume you can staff it internally.

Embed means engineers work forward-deployed inside your stack, on your real data, under your governance, and what they build stays with you when they leave. Three distinctions make it a separate model rather than a synonym for outsourcing.

It differs from buying because you own the artifact, not a licence to use one. It differs from consulting because the deliverable is a system in production rather than a design for one, and the risk of getting it running sits on the delivery side. It differs from staff augmentation because the engineers arrive with the architecture already decided, having built the same layer before.

The model exists because of an asymmetry that buy and build both fail to address. The knowledge required to build this is inside your company, held by people who are too busy to be interviewed and who have never written any of it down. The engineering capacity to turn that knowledge into a system is not inside your company, and hiring it competes against the AI labs. Buying solves neither side. Building solves the second only if you already had it.

What embed should leave behind is specific, and worth naming in the contract: a context engine, the owned layer where your company’s knowledge is written down in a form software can read, kept model-agnostic, with agents running on top of it. Models change underneath every few months. The layer does not. That is the whole point of re-architecting rather than layering.

Embed is also wrong sometimes. Ask a forward-deployed team to build expense approval and you are paying senior engineering rates to rebuild something you could have licensed. It fails just as reliably when nobody internal is assigned to receive the system, because a system with no owner on your side becomes shelfware on a slower schedule.

The decision rule

One question, asked per workflow rather than once for the company:

Would this company be materially different if this workflow ran better than every competitor’s version of it?

No. Buy it. Stop evaluating.
Yes, and you have engineers you can assign permanently. Build it.
Yes, and you do not. Embed, and require that what gets built stays yours.

A single company should reach all three answers in the same year. Buy the expense tool, build the pricing engine, embed for the cross-system processes that no product covers because no product can see across your departments. Treating this as one portfolio-level decision is how organisations end up with a licence for everything and ownership of nothing.

For a European buyer there is a second question, and it is not a compliance footnote. Where does inference happen, which subprocessors touch the data, and who is accountable when a supervisory authority asks. Under the EU AI Act the line between deployer and provider is not fixed by the purchase order: put your name on a high-risk system, or change substantially what it does, and the provider’s obligations can follow you home. A delivery model that leaves you dependent on a single vendor’s hosting and a single vendor’s model has made that answer for you.

What to settle before you sign

Whichever column you land in, these five belong in the contract rather than in a kickoff deck.

The number that has to move, named before the build starts, with the baseline it is measured against and who owns the data that proves it. Our ROI benchmarks are a starting point for setting it, not a substitute for measuring your own.
Who owns what at the end. The code, the prompts, the evaluation sets, the context layer. Write it down. Silence here defaults to the vendor.
Whether the system runs on a different model without re-architecting. If swapping the model means rebuilding the system, you did not buy portability.
Who maintains it in month thirteen, by name and by team, on your side and theirs.
Where the data goes, including at inference time, and which subprocessors are in the path.

Most day-rate contracts answer none of these, because a day-rate contract sells effort rather than a working system. That is the honest difference between a delivery model and an invoice, and it is worth more attention than the cost comparison that usually takes up the whole evaluation.

FAQ

Should we build or buy AI for the enterprise? Buy when the workflow is a commodity, you hold no data advantage in it, and you accept the vendor’s roadmap and model choices. Build when the workflow is specific to your company and you have engineers you can assign permanently rather than borrow for a quarter. If the workflow is yours but the bench is not, neither answer fits, and the third option is to have engineers build it inside your stack and leave it with you.

What is the third option in build vs buy? Embed. Engineers work forward-deployed inside your systems, on your data, under your governance, and the system stays yours. It differs from buying because you own the artifact rather than a licence, and from consulting because the deliverable is a running system rather than a design for one.

When is buying an AI product the correct decision? When three conditions hold at once: the workflow is not meaningfully different from your competitor’s version, you have no proprietary data that would make your version better, and you are willing to inherit the vendor’s roadmap, pricing and deprecations. Owning a commodity workflow returns nothing.

Why do build estimates for enterprise AI come in low? They price the first version. The costly parts arrive later: the integration surface against systems never designed to be read by software, the governance layer of audit trail, traceability, access control and retention, and the maintenance of both.

Does build vs buy get decided once for the whole company? No. It is a per-workflow decision. The same company should correctly buy, build and embed in the same year.

If the workflow is yours and the bench is not, that is the conversation we are built for. Tell us which workflow it is.