So You Decided to Build. Now You Have to Govern It.

A $500 million headline makes building your own AI look like the obvious move. In late May 2026, Kirkland & Ellis said it would spend that sum building its own AI platform over three to four years. Most mid-market firms cannot write that cheque. Yet the urge to build AI in-house reaches well beyond the largest players, and the governance bill arrives whatever your budget.

The choice to build, buy or co-develop is really a choice about how much you want to own. Each step toward ownership hands you more control and, in the same motion, more obligation. That trade is the whole story, and it pays to understand it before you commit.

From buyer to builder: the obligations shift

When you buy an off-the-shelf tool, the vendor carries most of the load. They log activity, document the system and handle incidents. You still owe due diligence and oversight, but the heavy duties sit firmly with them.

Move toward a co-developed or proprietary tool and those duties migrate to you. Under the EU AI Act, building can push you from deployer toward provider, and a provider answers for documentation, logging, oversight and incident handling directly. Teams that build AI in-house inherit the provider’s responsibilities along with the code. The feature you wanted may be identical; the accountability is not.

Auditability is the real price when you build AI in-house

The sticker price of a build is the part everyone sees. The running cost is the part that surprises people. When you build AI in-house, you have to show your work, repeatedly, to auditors who were nowhere near the room when you made each choice.

Evidence you must be able to produce

A proprietary build calls for a full provider evidence base. That means system documentation, data and model provenance you can actually show, your own logs, oversight records and incident procedures. A co-developed tool instead needs shared design and risk records, a clear split of responsibility with your partner, and an agreed plan for logging, oversight and exit. Buying demands far less of this, which is precisely why buying is cheaper to govern.

Logging and oversight become your job

With a vendor tool, logging is usually contractual. With your own build, it is operational. Someone on your side has to capture what the system did, review it and keep the record, which is where release readiness as a discipline earns its keep. Skip that work and your build is not governable; it is merely running.

Who runs it decides whether governance holds

Owning the code is not the same as owning the capability. A build only stays compliant if a defined operating model keeps it that way after launch.

The operating model question

Decide early who runs the thing. A central team gives you consistency but can become a bottleneck. A federated model spreads ownership but invites drift. A hub-and-spoke arrangement tries to hold both, with a core setting standards while local teams apply them. None is correct in the abstract, since the right answer depends on your size and your risk. The point is to choose deliberately, because an unowned build governs itself, which is to say it does not.

Tested exit keeps your own build from becoming lock-in

People often build to escape vendor lock-in. Done carelessly, a proprietary tool simply relocates the lock-in inside your own walls. The cure is portability designed in from the start, plus an exit you have tested rather than assumed.

Ask the blunt question. If the team that built this leaves, or the underlying model is withdrawn, can you carry the capability elsewhere without starting over? If the honest answer is no, you have built a dependency, not an asset, and the same controls that answer three regimes at once will not save a tool you cannot move.

One more duty catches builders out. A purely internal tool stays outside the Cyber Resilience Act. The moment you place a built product on the market, the Cyber Resilience Act applies, and you take on technical documentation, CE marking and vulnerability handling. With reporting obligations arriving on 11 September 2026, and where cyber duties and AI duties now meet, the timing is no longer comfortably distant. A recognised management-system standard such as ISO/IEC 42001 gives you a structure for running an in-house system without inventing governance from scratch.

Before you commit to build AI in-house

Building can be the right call. It is rarely the cheap one, and it is never the hands-off one. Owning more of the stack means owning the evidence, the operating model and the exit that travel with it.

So before you commit to build AI in-house, work back through the build, buy or co-develop decision sheet and answer the gates honestly. Then explore the three Prep Tracks at futureprep.eu/tracks/suite to put the operating discipline in place.