
Most organisations don’t have an AI governance problem. They have an AI governance theatre problem.
The policies exist. The frameworks have been signed off. The PDFs are in the shared drive. And somewhere between the document and the deployed model, absolutely nothing is being enforced.
The result is predictable: teams make judgment calls that weren’t theirs to make, exceptions quietly multiply, and governance becomes something that happens after the fact — in audits, in incident reviews, in uncomfortable board conversations. In regulated industries, that isn’t a process inefficiency. It’s a material risk.
The organisations getting this right aren’t producing better policy documents. They’re doing something more fundamental: they’re making governance executable.
The Document Is Not the Control
Here is the core problem with how most enterprises approach AI governance: they confuse the description of a policy with the enforcement of one.
A PDF that says AI systems must be registered before deployment doesn’t register AI systems. A framework that requires bias evaluation doesn’t run one. A committee that reviews high-risk use cases only meets when someone remembers to call it.
Documents describe intent. Controls enforce behaviour. These are not the same thing, and in a production AI environment, the gap between them is where risk lives.
The shift required is structural. Governance needs to behave like software: it needs inputs, outputs, enforcement points, and observable results. It needs to run continuously — not quarterly. And it needs to produce evidence automatically, as a byproduct of doing the work, rather than as a separate compliance exercise.
If a governance requirement cannot produce evidence without manual effort, it is a hope, not a governance requirement.
Risk That Is Calibrated, Not Bureaucratic
One of the most common objections to stronger AI governance is that it will slow everything down. In most cases, that objection is right – because the governance being proposed is poorly designed.
Treating a low-stakes internal productivity tool with the same scrutiny as an AI system making credit decisions, clinical recommendations, or hiring assessments isn’t rigor. It’s friction. And it creates exactly the dynamic organisations fear: teams routing around governance because it’s easier than engaging with it.
The NIST AI Risk Management Framework, published in 2023, offers a practical foundation here – mapping AI risk management across four functions (Govern, Map, Measure, Manage) with the explicit intention of being scalable to different risk levels and organisational contexts. A practical enterprise implementation builds on this with clear risk tiers: minimal controls for internal low-impact tools, progressively stricter requirements as stakes increase, and hard stops for use cases that should never be deployed at all.
The business value of this structure isn’t just compliance. It’s decision speed. Teams stop asking “what do we need to do here?” and start asking “which tier is this, and what does that automatically trigger?” Good governance removes ambiguity. Great governance removes debate.
Policy-as-Code: Where Intent Becomes Enforcement
The engineering principle that makes this work is well established, even if AI teams haven’t fully adopted it: policy as code.
The same way infrastructure is validated before it’s deployed, AI systems can be gated by automated checks embedded in the delivery pipeline. Does a registered use-case classification exist? Does required documentation meet the threshold? Have evaluation results cleared the defined benchmark? Is data access following least-privilege principles?
Tools like Open Policy Agent, a graduated Cloud Native Computing Foundation project widely used in enterprise infrastructure, demonstrate exactly how rules can be versioned, reviewed, and enforced consistently across systems without human intervention at every step.
The business implication is significant. Governance that runs in CI/CD doesn’t depend on a specialist reviewing every deployment. It doesn’t rely on anyone’s memory of what the policy says. It scales.
The GenAI Problem Is Different — And Harder
Traditional governance frameworks were not designed for the specific vulnerabilities of large language models. Prompt injection, output manipulation, and tool misuse aren’t abstract risks, they are documented, reproducible attack vectors that can affect any enterprise deploying GenAI in customer-facing or operational contexts.
The OWASP Top 10 for LLM Applications, now maintained by over 600 security experts across 18 countries, provides a taxonomy of these vulnerabilities. The practical controls they point to strict separation of system instructions and user input, controlled tool access, output validation before execution, safeguards against data exfiltration — require governance that was designed specifically for LLM behavior, not adapted from a checklist that predates it.
For enterprise leaders, the takeaway is this: GenAI governance is less about what the model knows and more about what the architecture around it permits. That is an engineering and governance problem, not a model problem.
Evidence Before Anyone Asks for It
The strongest audit position an organization can hold is one where evidence already exists before a regulator, a board, or a legal team asks for it.
A September 2025 Ernst & Young study found that just 10% of companies are fully prepared to audit their AI systems. The question regulators are beginning to ask is no longer just “did you have a policy?” but “can you demonstrate, with records, what your AI system did, under which policy, using which data, and with whose authorisation?”
Governance that ships answers that question automatically. Model cards, evaluation reports, data provenance documentation, decision logs – these aren’t created for audits. They’re created because the system requires them to function. The audit readiness is a byproduct.
The Strategic Case
The persistent framing of governance as a constraint on AI deployment gets this exactly backwards. Poorly designed governance slows organisations down. Well-designed governance is what allows AI deployment to accelerate safely.
When controls are standardised, checks are automated, and risk tiers are clear, the negotiation disappears. Releases become predictable. Liability becomes manageable. And the handful of governance specialists who currently review everything manually are freed to focus on the decisions that actually require human judgment.
The organisations building genuine competitive advantage in enterprise AI are not the ones with the most thorough policy document. They are the ones who made responsible behaviour the default, not through oversight, but through architecture.


