Build the governance infrastructure before engineers touch the AI code

A primary reason AI agents fail enterprise governance review is not that they are poorly built. It is that governance review happens after they are built. By then, fixing the gap means re-architecture, not configuration.

The pattern is consistent across organisations we have worked with: a team builds an AI proof-of-concept over several weeks, it works technically, it gets handed to the enterprise security or compliance team for review, and it stalls. The governance questions (who authorises these tool calls, where are the audit logs, how do we demonstrate data scoping holds for all inputs) were never asked at design time. They surface at deployment as blockers that require re-architecture, not configuration.

This is a sequencing problem. The fix is not a better governance framework. It is a different build order.

Why governance always ends up last

The way AI proofs-of-concept get staffed makes this almost inevitable. An engineering or data science team builds the prototype, optimising for speed and demonstrating capability. Governance teams (cybersecurity, enterprise architecture, legal, compliance) are not in the room. They are consulted at the end, if at all.

The result is what it always is when you build something and then retrofit constraints onto it: the constraints do not fit the design, and changing the design at that point costs more than starting over was supposed to save.

The data governance industry ran this experiment for two decades. Organisations invested in data governance platforms, wrote data dictionaries, assigned stewards to data assets. In many implementations, the governance layer sat above the actual databases and pipelines with no enforcement link between them: the catalogue described the estate, but the estate kept changing while the catalogue didn't. The documentation and the reality diverged. AI governance is positioned to repeat this pattern: frameworks get adopted, agents get deployed, and the governance layer describes what was intended rather than what is enforced.

The structural cause is the same: governance was added after the system was built, by a separate team with no authority over the design decisions that determine whether governance is actually enforceable.

What "governance first" means in practice

This build order applies to the category of agents the first post in this series identifies as enforcement-layer candidates: agents that query production databases, access regulated data, or take actions with audit implications. A writing assistant or a summarisation tool has a different risk profile and the overhead may not be warranted. For agents in the enforcement bucket, sequencing is everything.

Before a line of AI code is written, three things need to exist.

The telemetry layer. Every tool call logged, every model invocation recorded, every input and output captured with enough context to answer audit questions later. Not as a nice-to-have: as a prerequisite. An agent with no telemetry is ungovernable regardless of how carefully the compliance constraints were specified. This is the foundation everything else depends on.

The enforcement layer. The deterministic checks that run regardless of what the model outputs: code-level controls that enforce data scoping, block unsafe operations, and validate model outputs before they reach production systems. The first post in this series covers what these look like in practice. They need to be designed alongside the compliance team, not submitted to them for review after the system is complete.

The access model. Which agents have access to which systems, under which conditions, and which team owns those decisions. Deciding that is an enterprise architecture call, the same way access controls on other privileged systems are. A junior analyst does not have access to a risk team's database; an agent built for one domain should not have access to another domain's systems. Engineers should inherit access constraints. They should not be the ones setting them.

The AI code comes after these three things exist.

The counterargument

Building governance infrastructure for a proof-of-concept feels like installing load-bearing walls in a temporary structure. POCs are supposed to be fast and disposable. If the prototype fails technically, the governance infrastructure gets thrown away with it.

The counterargument is right about the risk. The real version of it is harder than "POCs should be disposable": we cannot get budget for the governance layer until the capability is proven, and we cannot prove the capability without building first. That is a genuine constraint, not a framing error.

The practical answer is to build a thin version. Not the full estate: minimal telemetry hooks, one or two enforcement checks covering the highest-risk operations, a documented access decision. Enough to demonstrate that the governance model is viable alongside the capability. That scaffold costs a fraction of what retrofitting costs, and it carries forward directly into production rather than getting thrown away with a failed POC.

The infrastructure built during a POC also does not disappear when the POC ends. The telemetry hooks, the enforcement layer design, the access model: these carry forward. The first time costs more. Every subsequent project in the same organisation builds on an established template rather than starting from scratch. The organisations that have the hardest time with AI governance are the ones that let each project team figure it out independently.

Who owns this

The governance infrastructure should not be built by the same team building the AI. It should be owned by whoever in the organisation is responsible for the equivalent layer on other privileged systems: a compliance team, an enterprise architecture team, a platform engineering team with security accountability.

The principle is direct: product engineers should not govern their own systems. Not because engineers cannot be trusted, but because governance is a separate concern with a separate accountability structure. Conflating

them produces the same result in AI that it produced in data governance: technically sound systems that cannot reach production because no one with the authority to authorise them was involved in building them.

This is where governance frameworks that focus on model quality or agent capability miss the point. The question enterprises are actually asking is not "is this model safe?" It is "who decided this agent can access that system, and where is that decision recorded?" Those are organisational and process questions. The answer is built into the design, or it does not exist.

For the class of agents this post is about, the teams getting to production are the ones that built governance into the design. The stalled pipeline is what retrofitting at deployment looks like.

What that governance infrastructure looks like in practice, and how to implement it with tools development teams already use, is what the next post in this series covers.