Build vs buy for enterprise AI platforms: how to decide

For most enterprises the right split is to buy the AI platform and build on top of it. Buy the shared plumbing every use case needs (data connections, a model gateway, permissions, audit logs, tracing and approvals), and build the parts that are specific to your business: the workflows, prompts, retrieval content, test sets and rules about what the AI may do. Build the platform itself only if you can staff a permanent team to run it and you have a requirement no product meets.

That answer sounds like a vendor talking, so it needs defending. The argument is about where the cost of an AI system sits. It is mostly not in the first version. It is in the years of upkeep after it, and almost all of that upkeep is in the shared layer, where your company has no special advantage.

The question is usually framed wrong

"Build or buy" suggests one decision. In practice an enterprise AI setup has at least three layers, and each deserves its own answer.

At the bottom are the models. Almost nobody trains a frontier model, so this layer is rented: from an API provider, or as open weights you host. In the middle is the platform: the code that connects to databases, files and camera streams, routes calls to models, runs agents with tools, retrieves documents, checks who is allowed to see what, and records what happened. On top are the applications: the invoice checker, the support triage agent, the store footfall report.

The cost and the advantage are distributed unevenly across these layers. Your competitors can rent the same models you can. A platform that connects to Postgres and logs tool calls is the same job for every company. The application layer is where your process knowledge lives: which exceptions matter in your invoices, what your support team calls an urgent ticket, which approval chain a refund needs. That is the part worth owning.

Which way the market is moving

The best recent number I could find comes from Menlo Ventures' State of Generative AI in the Enterprise report, published on 9 December 2025. It surveyed 495 US enterprise AI decision-makers in November 2025 and found that 76% of AI use cases were purchased rather than built internally. The same report puts the 2024 split at 47% built and 53% purchased. It also estimates that companies spent $37 billion on generative AI in 2025, up from $11.5 billion in 2024.

Read that carefully before using it in a board slide. It is one survey, of US companies, run by an investor in AI companies, and it counts use cases rather than platforms. What it does show is that a year of experience pushed many large buyers away from building. People who built the first wave of internal chat tools in 2023 and 2024 found out what it costs to keep them running.

The demo is the cheap part

A working prototype of an internal AI assistant takes a capable engineer a week or two now. Connect a model API, add a vector store, write a system prompt, put a chat box in front of it. The demo goes well and someone asks why you would pay a vendor for something your own team built in a sprint.

D. Sculley and nine co-authors made the case against that reasoning in 2015, before LLMs, in Hidden Technical Debt in Machine Learning Systems. The paper's point is that ML systems pick up maintenance costs ordinary software does not: entangled components where changing one input changes everything, undeclared consumers of a model's output, data dependencies nobody tracks, configuration sprawl, and a world outside the system that keeps changing. In their words, "it is dangerous to think of these quick wins as coming for free."

Everything they listed applies to LLM systems, and LLM systems add a few of their own. Here is what the prototype did not include.

Permissions. The prototype used one service account that could read every document in the index. In production, a sales rep must not get answers drawn from HR files, so access control has to follow each user through retrieval, through tool calls and into the logs. Our article on RBAC for AI agents covers how that works.

Audit. When someone asks "who saw this salary data, and through which question?", you need a record of every query, every retrieved document and every tool call, kept in a form a compliance team can read.

Many teams handle these two separately for each use case, so five AI projects end up with five permission schemes and five log formats. That fragmentation is the main reason I would buy this layer. CloudOEngine's data layer connects databases, files and camera streams to pipelines and the AI runtime under one permission model and one audit trail, so a new use case inherits the controls instead of reinventing them.

The bills that arrive after launch

Three kinds of maintenance never stop once you build the platform yourself.

Models retire on someone else's calendar

Model providers retire old models, and requests to a retired model fail. OpenAI's deprecation policy promises at least 6 months' notice for generally available models, at least 3 months for specialised variants, and much shorter notice (2 weeks is the example given) for preview models. Anthropic promises at least 60 days' notice for publicly released models, and its deprecation page lists four separate retirement notices in 2026 alone, issued in February, April, June and September.

Each notice means work for whoever owns the integration. Prompts tuned for one model behave differently on its replacement, so the job is: find every place the old model is called, run your test set against the replacement, fix what regressed, and ship before the date. Anthropic's own guidance tells customers to test replacements "well before the retirement date". A team that built its own gateway does this for every provider it uses, for every application. A team that routes everything through a shared gateway does the switch once and runs the tests per application.

The attack surface keeps growing

OWASP's Top 10 for LLM Applications (2025 edition) lists prompt injection first, then sensitive information disclosure, supply chain risks, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption. A homegrown platform has to track this list and patch against it, indefinitely. We went through the first item in depth in prompt injection and AI agents.

Excessive agency is the one I would worry about most in a built-in-house agent. The prototype agent could call the ticketing API, the refund API and the email API, because that was the quickest way to make the demo work. Nobody went back to add an approval step. CloudOEngine's Autopilot runs triggered agents under approval rules, so a person approves an action in the app or through an email approve link before it executes.

Connectors rot

Source systems change their schemas, auth methods and rate limits. Every connector you wrote is a small product with its own maintenance queue. This is the least interesting work in the stack and one of the most time-consuming, and nobody's career is built on keeping a connector alive.

Where building really is the right call

None of this means "buy everything". Some layers are worth building, and some companies should build the platform too.

The last row is the one teams forget. A test set built from your own traffic, with the right answers marked by your own staff, is the most valuable asset in the whole system. It is what lets you change models, prompts or vendors without guessing. Build it yourself and keep it portable, whatever else you buy. Assemble it from real requests, not invented ones.

Building the platform does make sense in a few cases. Large technology companies with an existing internal platform team can absorb AI as one more service. Organisations with legal or contractual rules that no vendor satisfies may have no choice. And a company whose product is an AI platform obviously builds it. If you are not in one of those groups, a homegrown platform usually means two or three of your best engineers spend their time on plumbing rather than on the applications the business asked for.

Buying has failure modes too

The opposite mistake is buying a separate finished tool for every problem. The support team buys a chatbot, finance buys an invoice reader, operations buys a meeting summariser. Each one stores a copy of company data, has its own logins and its own admin console, and keeps its own logs, if any. Six months on, nobody can answer the audit question above across all of them.

Lock-in is the other worry, and it is fair. Ask before you sign:

• Can we export our prompts, workflow definitions, test sets and logs in an open format?
• Does one permission model apply to data, retrieval and agent tool calls, or is each configured separately?
• Is every agent step and tool call traced, and can we inspect a single run end to end?
• Can a person approve an action before an agent executes it?
• Can we change the underlying model for one application without changing the others?
• Where is our data stored and processed, and how do we get it back if we leave?

The tracing question deserves a demo, not a slide. Ask the vendor to show you one failed agent run and how they would work out why it failed. The article on agent observability describes what a useful trace contains. In CloudOEngine's AI runtime, agents run real tools (filing a ticket, for example) and every step and tool call is traced and inspectable, which is the level of detail to hold any vendor to.

An illustration of the arithmetic

Here is a made-up example to show the shape of the comparison. The numbers are invented for illustration and are not benchmarks.

A company plans three AI use cases this year. The build option assigns four engineers to build a shared platform for six months, after which two of them stay on to maintain it. In year two, those two engineers handle a model retirement every few months, fix connectors when the ERP is upgraded, add access control for a new department and respond to a security review. That is two engineer-years per year for as long as the platform exists, before any application work.

The buy option pays a subscription, and the same four engineers spend the first six months shipping the three applications and building test sets for them. In year two they are working on use cases four to six.

The decision then comes down to comparing the subscription with two engineer-years plus the delay to the first use case. The delay is usually the bigger cost, and it is the one people leave out, because six months of a working invoice checker or triage agent has a value the business can measure.

A decision process you can run in a week

1. List the AI use cases you expect over the next 18 months, including the ones after the first. Build vs buy looks different for one use case than for ten.
2. For each use case, write down the data it needs, who may see the results and which actions it may take on its own. This becomes your platform requirements list.
3. Mark any requirement you believe no product meets. Check each one with two or three vendors before trusting that belief.
4. Estimate the upkeep of a homegrown platform per year, including model migrations, connector fixes and security work as well as the initial build.
5. Pick one real use case and run it on the platform you are considering for four weeks, with your own data and a test set your staff labelled.
6. Decide, and write down which layers you are building and which you are buying, so the next project does not reopen the question.

If step 3 leaves nothing on the list, buy the platform and put your engineers on the applications.

How CloudOEngine helps

CloudOEngine is the platform layer described above, so your team can spend its time on the applications and the test sets that are specific to your business.

It is one platform and console for connecting data (databases, files and camera streams), pipelines, an AI runtime with an LLM gateway, agents with tool access and RAG, plus Vision AI and live video. All of it runs under one permission model with one audit trail, so the fifth use case inherits the same access rules and logs as the first.

Governance is included rather than sold as an add-on: tenant isolation, role-based access, audit logs and per-tenant encrypted secrets.

To get started, the AI reads your real data schemas and proposes KPIs from them, which is a quick way to see what your connected data can already measure. Agents run real tools, such as filing a ticket, and every step and tool call is traced and inspectable, so when an agent does something unexpected you can see exactly what it did and why.

For actions with consequences, Autopilot runs triggered agents with approval rules: a person approves the action in the app or through an email approve link before it runs. That covers the excessive-agency risk without your team building an approval system.

If video is part of your plans, Vision AI counting uses two independent trackers, sends disagreements to a human review queue checked by your staff, and ships each finalised count with a published accuracy report showing every counted crossing.

CloudOEngine is built in Bengaluru, India.

Book a demo or see the AI runtime.

Frequently asked questions

Should an enterprise build or buy its AI platform?

Most should buy the shared platform layer (connectors, model gateway, permissions, audit logs, tracing and approvals) and build what is specific to them: workflows, prompts, retrieval content, evaluation sets and business rules. Building the platform makes sense only when you have a permanent platform team and requirements no product meets.

What are the hidden costs of building an AI platform in-house?

The running costs after launch: migrating when model providers retire models, patching against new attack patterns such as prompt injection, maintaining connectors as source systems change, and keeping access control and audit logs consistent. The Hidden Technical Debt in Machine Learning Systems paper argues that early quick wins in ML systems should not be treated as free for this reason.

Are most companies building or buying AI now?

In Menlo Ventures' survey of 495 US enterprise AI decision-makers (published December 2025), 76% of AI use cases were purchased rather than built internally, up from 53% purchased in 2024. That is one survey of US enterprises, so treat it as a direction, not a rule.

How often do AI models get retired?

Often enough to plan for. OpenAI's policy gives at least 6 months' notice for generally available models and Anthropic's gives at least 60 days for publicly released ones; Anthropic's deprecation page lists four separate retirement notices issued between February and September 2026.

What should I check before buying an AI platform?

Check that it connects to your real systems, applies one permission model across data and agents, keeps an audit trail you can export, traces every agent step and tool call, lets a person approve risky actions, and lets you take your prompts, test sets and data with you if you leave.

Sources

1. 2025: The State of Generative AI in the Enterprise (Menlo Ventures, 9 December 2025)
2. Hidden Technical Debt in Machine Learning Systems (Sculley et al., NeurIPS 2015)
3. Model deprecations (Anthropic documentation)
4. Deprecations (OpenAI API documentation)
5. OWASP Top 10 for LLM Applications 2025 (OWASP GenAI Security Project)

#build vs buy #ai platform #enterprise ai #ai strategy #total cost of ownership