A colleague recently shared a sharp post about what he called the "Initiative Trap" - an employee subscribes to a SaaS AI tool, productivity goes up briefly, then IT, Finance, Procurement, and HR each react in sequence and kill the momentum. His conclusion: AI governance is not a policy problem, it is a governance problem.
I want to go further. The people designing AI governance frameworks often cannot explain how an LLM makes a decision. They don't know what a context window is. They don't understand why an agentic AI with tool access is a categorically different risk surface than a chatbot. Without that foundation, you are not doing governance. You are doing paperwork.
HERE IS THE PROBLEM.
Enterprise AI governance fails in repeatable patterns. Here are the three I encounter most.
1. AI GOVERNANCE-AS-DOCUMENT
The hundred-page policy. Written by people who have never deployed a model. Approved by a committee that has never used one. Reviewed annually while the technology ships meaningful capability changes monthly. It creates the appearance of governance with zero enforcement mechanism. A permanent structural lag that nobody inside the governance function is incentivised to fix.
2. AI GOVERNANCE-AS-BLOCKADE
The overcorrection. Faced with uncertainty, governance defaults to restriction. Red flags multiply. Every new tool needs a six-week security review. The result is precise and predictable: you punish exactly the people your organisation can least afford to lose - the engineers and architects who already understand what AI can do and are willing to act on it. They don't wait for the governance cycle to catch up. They leave. You are not managing risk. You are manufacturing a talent exodus.
3. AI GOVERNANCE-AS-SILO
The structural failure. IT, Legal, Risk, HR, and Data all running separate AI policies with no coherent cross-functional ownership. A single AI deployment can be simultaneously approved by IT, blocked by Legal, and entirely invisible to the Data team. Nobody owns the full picture. Nobody is accountable for the aggregate risk posture. Meanwhile the risk accumulates in exactly the places nobody is looking.
The consequences are not theoretical. Shadow AI proliferates when governance blocks legitimate use - your people do not stop using AI, they hide it. Agent sprawl accelerates when no cross-functional owner exists to track what is deployed, what it connects to, and what data it touches. Compliance exposure compounds silently in both cases - because governance-as-document gives you a paper trail, not actual control. By the time your audit surfaces the risk, it has been running in production for months.
THE PROBLEM
Governance leaders lacking technical depth is fixable. Hire differently. Bring AI practitioners - not just compliance specialists - into governance functions. Make technical fluency a prerequisite for roles making decisions about AI deployment. Hard, but tractable.
Governance structures architecturally incapable of dynamic updating is harder. A governance operating model designed for annual policy reviews cannot respond to a technology that moves monthly. No amount of upskilling the CISO fixes a process built for a different rate of change. That requires redesign.
Most organisations are trying to solve a process problem with a training budget. It won't work.
THE SOLUTION - AI GOVERNANCE AS DYNAMIC INFRASTRUCTURE
The enterprises that win the AI productivity race will be the ones that figure out how to absorb AI innovation - to turn one person's productivity gain into an organisational capability.
AI governance is not a control function. It is an infrastructure function.
1. Embedded, not bolted on. Controls should live in the workflow, not above it. Enforced at the point of AI interaction - in the tool, in the agent, in the API call - not at an approval gate three weeks before deployment. If governance only activates at deployment, it has already lost.
2. Programmable and versioned.Static documents cannot govern dynamic systems. Enterprise AI governance needs to be expressed as code - configurable, testable, deployable, updated on the same cadence as the systems it governs. This is what shift-left means applied to AI governance: move risk controls upstream into the development pipeline, not downstream into the audit cycle. If your governance team finds out about a risk at deployment, they are already six months too late.
3. Designed to enable as much as it constrains. The question is not 'how do we stop unsafe AI use?' It is 'how do we create a bounded, observable environment where AI use is both safe and fast?' Define the bounds programmatically. Monitor within them. Update them continuously.
ARCHITECTURE TO PROVE THE POINT: NVIDIA NeMo Guardrails
Here is what governance-as-infrastructure looks like when someone actually builds it.
NVIDIA NeMo Guardrails embeds programmable safety controls directly between the application and the model - not at the perimeter, not in a policy document sitting on an intranet, but in the call stack itself. Every input intercepted - and every output checked. At runtime, at low latency, without blocking the work.
The controls are expressed in Colang - a domain-specific language for defining AI behaviour as versioned, testable code. Not a policy - a deployable artefact. It ships with the system, updates independently of the model, and fails visibly, not silently.
Because the rails are composable, different teams own different layers. Data privacy is one rail. Topic restriction is another. Output moderation, tool access control - each owned, independently testable, and applied to the same system without anyone needing a six-week cross-functional review to change one of them.
The governance function defines the bounds. The architecture enforces them. That is the model.
THE BOTTOM LINE
Your governance is probably a document, a blockade, a silo, or all three. The people who know this most acutely are the ones trying to build on your platform. They are working around your governance, not with it.
The path forward is not more policy. It is a different architecture. Governance that is embedded, programmable, and composable. Governance that moves at the speed of the technology it governs. Governance that enables as much as it constrains.
Not control. Not enablement. Both - simultaneously and by design.
The enterprises that solve this first will have a structural advantage that compounds. Those still debating whether to allow Canva AI will be playing catch-up for years.
WANT TO GO DEEPER?
I've been building a technical blueprint for this - architecture patterns, shift-left implementation, ownership models. It's a working document, not a finished product. If you're wrestling with this at enterprise level, DM me. Compare notes. No pitch.
