Every enterprise AI vendor wants to be your platform. The question is what you give up to let them.
It frames the decision as engineering. It is capital allocation. And the wrong frame routes the choice to the wrong people.
The board asks one question. Build it, or buy it. The CTO scopes a platform. The vendor sends a quote. Procurement runs the math. Six quarters later the thing is live, and the company discovers it licensed away the one layer that would have been its moat.
The framing did the damage. Build versus buy sounds like a make-or-buy decision about a component. A bolt. A payroll system. Something with a spec and a price and a clear owner. AI is not a component. It is a position. When you decide what to build and what to buy, you are deciding where your company will be different from every competitor that buys from the same five vendors. That is not a procurement question. That is a strategy question wearing a procurement costume.
The binary hides the only variable that matters: where your differentiation lives. Two companies can run the identical vendor platform and get opposite outcomes. The difference is not the platform. It is which parts of the system encode something the company knows that no one else knows. Buy that part, and the platform is a commodity you rent at a markup. Build the wrapper around it, and the same platform becomes leverage.
So the real decision is not build or buy. It is draw the line. Decide which layer carries your advantage, build that, and buy everything below it that a vendor can run more cheaply and more safely than you ever will. The companies that win do not pick a side. They pick a boundary.
There are three ways this goes. Two of them are failures that look like success on the day the contract is signed. One is rare.
Licensed the full stack from a vendor that promised to be the platform. Fast to launch, nothing proprietary inside. The advantage it paid for ships to every competitor on the next release. It rents its own future.
Decided AI was core, so it built all of it. Models, serving, evaluation, tooling, the lot. Two years of engineering, a beautiful architecture, and no business outcome. It out-built the vendors and lost to the ones who shipped.
Rented the commodity layers a vendor runs better. Built one thin layer on its own data, history, and process. The thing competitors cannot copy by signing the same contract. Rare, deliberate, and the only one that compounds.
The platform is not the project. The boundary is.The thesis of this report
This is a joint call between the chief executive and the chief financial officer, because it is a bet about where capital creates durable advantage. The CTO can tell you what is technically possible. The CTO cannot tell you what is worth owning. That is a question about the business, its competitors, and the half-life of the advantage on offer.
“If we buy this layer, can a competitor buy the same thing tomorrow and erase the gap?”
Decides which capability has to be ours forever. Reads the half-life. Names the one layer that, if commoditised, would cost the company its position.
“What is the total cost across five years, including the lines no one put in the quote?”
Prices the whole decision, not the licence. Build is an opex curve disguised as a project. Buy is a SaaS line that hides integration, exit, and the cost of being one release behind.
The case for building is real, seductive, and almost never the case the company actually needs to make.
Building gives you four things you genuinely want. It also gives you a bill, a timeline, and a maintenance burden that the demo never mentions.
Control. You own the roadmap. No vendor deprecates a feature you depend on. No surprise price increase at renewal. The system does exactly what you decide it does, when you decide it.
Differentiation. If you build it, no competitor can buy the same thing. The logic is sound for the one layer that carries your advantage. It is a trap for the ten layers that do not.
Data gravity. Your data never leaves your boundary. For a regulated business, this is not a preference. It is sometimes the whole reason build is on the table at all.
Unit economics at scale. Rent looks expensive when you multiply it by every transaction. A build amortises. At sufficient volume, owning the asset is cheaper per call than paying a per-seat or per-token markup forever.
Every one of these is true. And every one of these is the argument an engineering team makes for building the entire stack, when the same argument only justifies building one part of it.
Build is a curve, not a project. The line on the slide stops. The spend does not.What the engineering deck leaves out
It assumes the team that builds it will still be there to run it in year three. AI engineers are the most mobile labour in the company. The system outlives the people who understand it.
It assumes the build is the cost. The build is the deposit. The cost is evaluation, monitoring, retraining, drift, on-call, security review, and the slow accretion of edge cases that no one budgeted. The model is two percent of the lifetime spend. The other ninety-eight percent is operating it.
It assumes you are building the thing competitors cannot copy. Most internal build programs spend most of their effort rebuilding the commodity layers a vendor would have run for a fraction of the cost, and they run out of money before they reach the one layer that mattered.
The most expensive AI failures are not the ones that broke. They are the ones that were architected for two years and never met a customer.
A decade of enterprise AI gives the same lesson in different logos. Ambition aimed at the infrastructure layer, not the outcome layer, ends in a write-down.
The pattern is consistent. A capable company decides AI is too important to rent. It assembles a serious team. It builds a platform that, on its own terms, is excellent. And it loses, because the competitor who bought the floor and built only the top shipped eighteen months earlier and learned from real usage while the cathedral was still under scaffolding.
The point of the examples below is not that these were foolish companies. They were not. The point is that the failure mode is structural. Building the whole stack is a decision that feels most justified at exactly the companies with the resources to attempt it, which is why the most sophisticated organisations make this mistake most reliably.
The platform that out-engineered the market. A team builds a custom model-serving and orchestration layer because the off-the-shelf options were not good enough on the day they started. Twelve months later the commercial layer is better than what they built, cheaper, and maintained by someone else. The build is now a liability the company maintains out of sunk-cost loyalty.
The moat that was a feature. A company builds an entire AI capability to protect a differentiation that turns out to have a six-month half-life. By the time it ships, three vendors offer the same thing as a checkbox. The build defended a position that no longer existed.
The team that left. The system works. The five people who understand it do not work here anymore. The company now owns an asset it cannot safely change, which is the most expensive kind of asset to own.
The cathedral is finished the year the congregation leaves for the church that opened first.On building the whole stack
Model it the way the CFO would. The licence you avoided is the smallest number on the page.
A build has four cost phases, and three of them recur forever. Price only the first and you will be right about ten percent of the spend and wrong about the decision.
From a financial-modelling point of view, build is not a capital expenditure that converts to a depreciating asset. It is a standing operating commitment. The model has to carry a run-rate that does not end when the system ships. It begins when the system ships.
| Line | Nature | Share of 5-yr cost |
|---|---|---|
| Model assembly & initial buildThe part on the slide. Team, training or fine-tuning, first integration. | One-time | ~12% |
| Integration to systems of recordReaching the core. Often longer and harder than the build itself. | One-time, recurring upkeep | ~22% |
| Evaluation, monitoring & driftKnowing the system still works. Never stops. | Recurring | ~20% |
| On-call, retraining & edge casesThe long tail. Grows with usage, not with the roadmap. | Recurring | ~26% |
| Security, compliance & auditReviews, attestations, controls. Rises with autonomy. | Recurring | ~14% |
| Talent risk premiumThe cost of the system outliving the people who built it. | Recurring & unbudgeted | ~6% |
| Of which one-time, visible at decision | ~12% | |
Read the bottom line. The number the build case is approved on is the build. The number the company actually pays is everything below it, every year, for as long as the capability is in production. A build is the right call only when the layer it produces has a long enough Strategic Half-Life to earn that run-rate back in durable advantage.
You do not buy a build. You marry an operating expense.The CFO's correction
A traditional SaaS line is one number that does one job. An AI platform is one number that hides four.
SaaS taught the enterprise to trust the per-seat line. AI platforms inherited the pricing model and broke the assumptions underneath it. The licence is real. The total is not on the quote.
Classic SaaS is predictable because the vendor does a fixed thing and you consume it. The cost is the subscription, integration is a one-time project, and the value you get is roughly the value every other customer gets. None of that holds for an enterprise AI platform.
Consumption is the cost, not the seat. The line item is per-seat or per-token, and usage is the variable you cannot forecast at signing. The platform that costs forty thousand in the pilot costs four hundred thousand in production, because production is where people actually use it.
It will not bend to what you need. SaaS configures. AI platforms are trained on a general shape of the world and resist the specific shape of yours. Most platforms cannot be made to do the precise thing your business does, the way your business does it, no matter how much you configure. You adapt to the platform. The platform does not adapt to you. For the layer that carries your advantage, that is fatal.
It does not reach your core. The demo runs on sample data. Your business runs on the policy admin system, the ERP, the ledger, the PLM. None of the major AI platforms connect to those out of the box. The integration to make the platform reach your system of record is a project you pay for, on top of the licence, and it is covered in the next department because it is the line that decides everything.
Exit is not free. When the contract ends, the data the platform learned on, the workflows built inside it, and the institutional memory of how it works all stay with the vendor. Switching cost is the silent renewal lever. The longer you run it, the more it costs to leave, which is the opposite of a commodity.
Buy is the right call for any layer where standard is acceptable and the half-life is short. Most layers qualify. The discipline is refusing to buy the one layer that does not, no matter how good the demo is.
SaaS is a number that does one thing. An AI platform is a number that hides four.On reading the quote
No major AI platform connects to the systems your business actually runs on. That gap is the project. The licence is the deposit on it.
The demo runs in five minutes on sample data. The integration to the system of record runs for nine months on yours. The difference between those two numbers is the difference between a slide and a deployment.
Here is the line no vendor volunteers. The platform you are buying does not connect to the core systems that hold your real work. It connects to a sandbox, a sample dataset, an API that exposes a fraction of what the core actually does. Reaching the rest is bespoke, slow, and yours to pay for.
These are the mountains. Each is its own climb, and none of them ship with a connector that does what you need.
Each of these systems was built over decades, with its own data model, its own permission structure, its own assumptions about who writes to it and when. An AI agent that can read from one of them is a useful demo. An agent that can safely write to one of them is a nine-month project with a security review attached, and writing is where the value is. Reading tells you something. Writing changes something. The business case lives on the write side of the wall, which is the side no platform reaches by default.
Reading the core is a demo. Writing to the core is the entire job.The wall, in one line
This is also the line that breaks the buy economics. The licence assumed the platform reached your systems. It does not. The integration to make it reach is a custom build sitting on top of the bought platform, which means even a pure buy decision contains a build you did not price. There is no clean buy. There is only buy plus the integration the vendor left for you.
The agent inherits whatever your schema actually is and whatever your data exposes. Both are yours. Neither is on the order form.
A platform is only as good as the data it can reach and the schema it can understand. Your schema is a mess only you can fix, and your data exposes things only you can decide to hide.
Your data does not look the way the platform assumes data looks. The same customer exists three times under two spellings and a typo. The policy number means one thing in claims and another in underwriting. A field that should be a date is a free-text note in forty percent of records. The platform cannot resolve this, because resolving it requires knowing what your data means, and only you know that.
This is the work no vendor sells and no licence covers. Resolving entities, reconciling fields, building the canonical schema the agent reads from. It is unglamorous, it is expensive, and it is the precondition for everything above it. An agent on an unresolved schema does not fail loudly. It fails quietly, by being confidently wrong on the records where your data disagreed with itself.
An agent that can reach your data can expose your data. The question is not whether to connect it. The question is, at every boundary, what does it see, what does it say, and what does it remember. Answer it before deployment, because the agent will answer it for you otherwise.
| The angle | The exposure | The decision you must make |
|---|---|---|
| To the model | Data sent to a vendor model leaves your boundary and may train future versions. | What may cross the boundary, and what must never. Get it in the contract, not the assurances. |
| Across users | The agent answers one user with data another user was not allowed to see. | Enforce per-user permissions inside the agent, not just on the systems behind it. |
| In the prompt | Context assembled for the agent carries fields that should never have been in scope. | Minimise context. The agent should receive the least it needs, never the most it can reach. |
| In the output | The agent restates sensitive source data in an answer, an email, a log. | Redaction and output filtering as a layer, applied after the model, before the human. |
| In memory | The agent retains data across sessions and surfaces it later, out of context. | Decide what persists and what is forgotten. Default to forgetting. |
| In the logs | Sensitive data sits in plaintext in traces and monitoring, a quieter breach surface. | Treat logs as a system of record. Same controls, same audit, same restraint. |
| At the join | Two datasets safe apart become identifying when the agent joins them. | Govern the joins. Re-identification is an emergent risk no single dataset reveals. |
| By adversary | A user crafts input that argues the agent into revealing or doing what it should not. | The agent is the first system you deploy that can be talked into betraying you. Defend it accordingly. |
The agent learns whatever your data and your history actually contain, not what you wish they did.On schema and leakage
The answer was never build or buy. It is build the one layer that is yours, buy every layer a vendor runs better, and own the boundary between them.
Picture the stack as a horizontal line. On the left, what only you can do. On the right, what anyone can buy. The single most important decision in enterprise AI is where, exactly, you place each layer on that line.
The discipline is brutal and simple. For every layer of the system, ask the BEACON question. What is its Strategic Half-Life, and does it carry something only you hold. If the half-life is long and the input is proprietary, build it. If the half-life is short or the capability is standard, buy it. Most layers buy. One or two build. The skill is the honesty to keep the build list short.
Read the line top to bottom. The layers at the top, your data, your process, your context, sit on the build side because their half-life is long and their input is yours alone. The layers at the bottom, the model and the infrastructure, sit on the buy side because they are improving faster than you could ever match and they are identical for every customer. The model is the shortest half-life in the entire stack. It is the layer people most want to build and the layer they should most reliably rent.
The middle is where the craft is. Integration and orchestration are composed: you buy the platform and build the thin custom layer that makes it reach your core and behave like your business. This is build plus buy in one layer, and it is where most of the real engineering effort honestly belongs.
Buy the engine. Build the steering. Never confuse the two.The synthesis
If you have drawn the line, vendor evaluation stops being a feature comparison and becomes six sharp questions. Run every platform through them.
An insurer wants to automate claims with a vendor. Here is what actually goes on the plate to make it real, and which part of it has to be theirs.
Take the most common enterprise AI request in insurance: automate first-notice-of-loss and claims triage. A vendor will sell you a platform. The platform is the easy half. Here is the whole dish.
The insurer runs claims on Guidewire or Duck Creek. It has decades of claims history, an adjusting philosophy that is genuinely its own, and a regulator that asks why every decision was made. It wants an agent that takes a claim, triages it, routes it, and handles the simple ones end to end. The vendor demos exactly this, on sample data, in fifteen minutes. Then the real work starts.
What goes on the plate to make claims triage real inside a live policy-administration core, split by what the insurer buys and what only the insurer can build.
Notice what the dish reveals. The vendor sold one thing. The deployment needed eight, and the four that decide whether the insurer wins are the four no vendor could supply. A claims operation that buys all eight from one platform has automated itself into a commodity. A claims operation that draws the line keeps the part that makes it a better insurer and rents the part that just makes it a faster one.
The vendor cooks the protein. You bring the recipe nobody else has.Claims automation, the whole dish
Most companies discover, after the contract is signed, that they licensed away the exact layer that would have been their moat.
The trap was the question. Build or buy forced a side, and a side was never the answer. The answer is a boundary, and a boundary is a strategy decision, which is why it belongs to the two people who own where capital creates durable advantage.
So end the meeting differently. Do not ask the CTO whether to build or buy. Ask the CEO which one layer, if a competitor could buy it tomorrow, would cost the company its position. That layer you build. Ask the CFO what the five-year total is for everything else, including the integration the vendor left out and the run-rate the build deck hid. Everything that clears the commodity test, you buy.
Build the moat. Buy the floor. Compose the middle. And own the boundary between them, because the boundary is the only part of this decision that no vendor can sell you and no competitor can copy.
The data, the judgement, the context. Long half-life, proprietary input. We build this and we never put it inside someone else's platform, no matter how good the demo.
Buy on five-year total, not licence. Integration is in the number. Build is an operating curve, not a project. Short half-life always rents.
The agents are ready. The boundary is the decision.
A field report on the capital and architecture of enterprise AI, read through the BEACON instrument. This edition uses the B dimension, Strategic Half-Life, to reframe the build-versus-buy decision as a question about where differentiation lives and how long it lasts. Written for the buyer committee, and in particular for the two people who jointly own the call: the chief executive and the chief financial officer.
The frameworks referenced, CORE and BEACON, are Global AI Forum instruments for locating where AI creates value and measuring whether an organisation is ready to capture it.