By Shaun Modi, CEO, Capitol AI

TL;DR In our prior piece we argued that structure, not just access to a model, is what turns AI into something an institution can use to attain transformation in the age of AI. The follow-on question is how institutions acquire that structure and should they build internally or buy off-the-shelf tools. The choice is non-binary and most institutions are hybrid. They rent models, buy a few point tools, and build something internally. The real decision is which layer you own, and what you are left with when the models change. That decision is critical and will make the difference between fully leveraging AI or leaving value on the table.

For enterprise, the answer is a hybrid approach

The buy vs. build question is a familiar one for enterprise but training a foundation model from scratch is out of reach for any enterprise outside a handful of labs. When your team calls a model API, you are renting: paying for access and usage on someone else's servers. And almost every institution has someone internally wiring that API into a process of their own.

So the question was never a binary buy-or-build choice, the way it would be for an internal notes app or a CRM. It is a question of proportion: how much are you buying, how much are you building, and which layer of the system are you willing to be responsible for over the next five years. 

Responsibility here means keeping it working, not fully owning it. You are not going to "fix" the model when it hallucinates, that is a bigger and largely unsolved problem. But you are responsible for setting the right guardrails to minimize hallucinations, or at least to increase the chances of catching them. And you are responsible for those guardrails still working after the model underneath them changes. 

There is one more thing you are responsible for, and it is something you can’t buy or rent. Your institution's memory: how your best people do the work and the thought process that drives outcomes at your firm. The structure you build or buy is either going to leverage that asset and let it compound in value or leave it untapped. 

Hybrid, weighted toward buy

There are two versions of this hybrid solution. The first is to bet on one of the big foundation vendors and take their enterprise product. Anthropic, OpenAI, and Google all sell one, they are good, and this route gets a large firm from zero to something that provides value in a matter of weeks. Depending on the deal size you may need forward deployed engineers to wire things up. You take on their roadmap and their model lineup becomes your model lineup. When they deprecate something, you migrate to a different model and when they reprice, you absorb it or have to go back to the drawing board. It could work but that the cadence of your AI capability is now set by someone else. You also give up some control of your data and must trust the big labs’ contracts to treat your data with secrecy and never train on it.

The second version is buying narrow tools for specific jobs. Something like an off-the-shelf tool that turns a brief into a pitch deck, or something that reads contracts and flags non-standard language & terms. These are narrow tasks for select teams they provide real value. Some tools now on the market are very good, better at that one job than anything your team would build in a quarter, and you can have them running quickly.

Both are reasonable early on. Cheaper than a full build, with wins you can point to, and you also learn which workflows your firm cares about enough to change their workflows in exchange for greater productivity or efficiency. 

But a collection of point tools is not a foundation. Each one comes with its own permissions, its own interface and its own record of what it did. Work that crosses two of them is not a truly cohesive, governed workflow, it is an analyst exporting a file from one and uploading it to the other. Adoption fragments as well, since the person who got good at the deck building tool has no particular reason to learn the contract tool. When the “deck expert” leaves, their expertise with a niche tool and their process leaves with them and institutional memory is not preserved.

Eventually there will be a question at a board meeting about AI adoption strategy and which AI tools the firm is running, who owns it, what data it has access to and what it costs. With several tools floating around, multiple stakeholders, and no holistic oversight over all of it, these questions are tough to answer. 

Hybrid, weighted toward build

“We have engineers, we could build this.” This is heard often at organizations with large engineering teams.

Typically, engineers are not simply idling and have their normal responsibilities. But the pull of digital transformation can be compelling and AI projects tend to shake up priorities. So the team takes an API from a frontier provider and starts building its own workflow system.

The obvious upside is control. It fits your process perfectly, because you wrote it for your team knowing exactly the way they work. You decide where the data goes and there is no per-seat contract with a vendor who may reprice you next year.

The downside is that your engineering team will now be tied up building a complex technology product to support the entire organization. Even though you are not training a model, the work needed to build the right structure is easy to underestimate. To build this properly, the system has to be model-agnostic, so you keep the freedom to choose between frontier labs or maybe even open weight models. It needs data pipes, entitlements, and workflow tools that put a human in the loop at the right step. It needs roles like admins, SMEs, and users, each with their own permissions. And the work does not end at launch as every model update and API change becomes yours to absorb. 

This is a huge endeavor for the build and also a large commitment for the maintenance. If that capability is your product, there is a strong argument for building and maintaining it internally. A firm whose business is the AI system should own the AI system. But if your product is consulting, advice, diligence, administration, underwriting, or compliance, then the plumbing is undifferentiated heavy lifting that pulls your best minds off the work clients pay for.

Hybrid, Balanced: Build your plane, buy the engine (What we at Capitol Recommend)

Aircraft manufacturers do not build their own engines, they buy them based on their needs for the plane. What the manufacturer builds is everything else: the airframe, the systems, the procedures the crew runs. That is where the aircraft becomes truly theirs.

A model is just an engine that powers your work processes. What is differentiated inside your institution is your SMEs and the process they run. It is how your best diligence lead structures an analysis, your own data gathered over the years, your judgment of which figures get checked twice, and where a human signs before anything goes out. That knowledge sits with a handful of senior people, is applied inconsistently across teams, and leaves when they do.

So, many organizations choose to buy the engine and build the plane. Model-agnostic underneath means each task routes to the right approved model for the job, including frontier APIs where policy allows, private models, open-source models, or models deployed inside your own environment. Some steps are better handled without a language model at all, by deterministic code or a lookup. When a better model ships, you change the routing, not the workflow.

Governed on top means the work is decomposed into sequenced nodes rather than expressed as one long prompt, with claim-level traceability produced by design and human approval at the node where the organization has decided the risk actually is. This is critical for accountability and trust. 

But this still does not make a large language model deterministic. Models are non-deterministic by nature and the same model can return a different answer to the same request. What structure does is improve the odds of getting the right output and make a bad result auditable vs. a black box. This also serves as a foundation with which to scale AI beyond a few isolated use cases. 

That is where Capitol can help. While we do not sell models, we give you the platform to build the right structure, and let your people build the plane with it.

You will still have your three roles, or something like them. The admin who decides who can build and who can run. The builder, usually a senior SME, who turns the way your firm actually works into a workflow. The user who runs it and relies on the result. You will still have your agents do the heavy lifting but humans in the loop will ensure that the inputs are all approved and the outcomes are up to par. That is how your institution’s memory is preserved and leveraged fully.

That documented, repeatable process is your edge, your secret sauce that no one else can claim. You build that yourself, because you and your team are the only ones who run the process exactly this way.

What you are actually choosing

You are not really choosing between build and buy, you are choosing what differentiates your institution.

Build your plane and buy the engine. The models will keep getting better and cheaper, and none of it will do much for your firm if the thing that makes it distinctive is still sitting in three people’s heads.

See what this looks like on your own data. Capitol AI runs governed agentic workflows inside your perimeter, on any approved model, with auditable output. Book a demo and watch a decision-grade artifact get produced on your proprietary data, governed by the deployment you choose.

Frequently Asked Questions

Should we build or buy our enterprise AI platform? In practice you will do both, so the useful question is which layer you own. Almost no institution builds its own foundation model, which means the model layer is bought. The orchestration and governance layer is where most firms overspend, building infrastructure that gives them no competitive advantage. The workflow and judgment layer, meaning your methodology and your standard for a good output, is the layer worth building, because nobody can sell it to you.

Can you build enterprise AI without training your own model? Yes, and nearly everyone does. Training a foundation model is not a moat for a firm whose business is advice, diligence, or compliance. The durable advantage comes from encoding your own process on top of models you can swap.

What is the real cost of building an AI platform in-house? The visible cost is the initial engineering. The larger cost is the maintenance tail: evaluation infrastructure, audit trails, versioning, human-review checkpoints, entitlements, deployment and key management, and absorbing every model and API change indefinitely. Most in-house estimates price the first part and not the second.

Does buying an AI platform mean vendor lock-in? It depends what you bought. A platform tied to a single model provider trades one lock-in for another. A model-agnostic control plane is the opposite: it is the thing that lets you change models without rebuilding the workflows sitting on top of them.

How do you keep proprietary data inside the perimeter? Deployment should match the sensitivity of the work, whether that is managed infrastructure, your own cloud tenant or VPC, or fully on-premise. Access is governed by role, source, workflow, and purpose rather than granted wholesale to a model, and where an external model is called, the workflow sends only the scoped data that step requires.