Governance without gridlock: building AI policy that doesn’t slow delivery

Ask most engineering teams what "AI governance" means in practice, and you'll hear some version of the same story: a form, a committee, a queue, and a wait measured in weeks rather than days. Ask the people who built the governance process, and they'll tell you it exists to manage risk. Both things are true, and that's the problem. A process that manages risk by making everything slow doesn't actually reduce risk; it just teaches people to avoid the process. The shadow AI usage inside most large organisations, the tools nobody registered and the models nobody classified, didn't appear because staff don't care about risk. It appeared because the official route was slower than the unofficial one.

Proportionality is the whole design problem

The instinct behind most first-generation AI policy is understandable: something new and unfamiliar arrived, so leadership put a single, cautious gate in front of all of it. The trouble is that a chatbot summarising internal meeting notes and a model making automated lending decisions are not the same category of risk, and treating them the same way is expensive twice over. The low-risk use case gets slowed down for no benefit. The high-risk one, precisely because the process is so painful, gets the same box-ticking treatment as everything else rather than the scrutiny it actually needs.

Good governance starts by sorting the population before it tries to control it. A simple, honest risk tier, roughly: does this system make or materially influence a decision about a person; does it touch regulated data; could getting it wrong cause harm that reaches a regulator, a customer or the board, does most of the design work. Most use cases sort into "low risk, register and go" within minutes. The minority that touch employment, credit, health or safety decisions earn the deeper review, and because that review isn't competing for the same queue as everything else, it can actually get the time it deserves.

Build paved roads, not just checkpoints

A checkpoint asks "is this allowed?" after someone has already built something and wants to ship it. That's the most expensive place in the process to discover a problem. A paved road does the opposite: it pre-approves a set of patterns, an approved model list, a standard logging and human-oversight pattern, a template for the model card and the risk assessment, so that a team building inside those boundaries never has to ask permission at all. The governance work happens once, upfront, when the pattern is designed, instead of being repeated for every team that wants to use it.

This is where a lot of governance functions undersell themselves. Their real value isn't the review meeting; it's the reusable scaffolding that makes most reviews unnecessary. A platform team that ships an approved, pre-governed way to call an LLM with the right logging, redaction and escalation built in has done more for delivery speed than any amount of process documentation, because it moves the governance decision from "every time" to "once, well."

Put oversight where the decision actually gets made

The other common failure is timing: governance that sits at the very end of the pipeline, as a launch gate, catches problems after most of the cost of fixing them has already been spent. A data or model choice made in week two is far cheaper to change than the same choice discovered in a pre-launch review in week fourteen. Effective governance puts a light-touch check at the point where the consequential decisions are actually made, choosing the training data, choosing the human-in-the-loop pattern, deciding what the system is allowed to do autonomously, rather than saving all scrutiny for a single gate that everyone has already committed to clearing.

Give one person the authority to say yes

A committee that meets fortnightly is the single most reliable way to turn a two-day decision into a six-week one, not because the people in the room are slow, but because a group has no natural deadline and no individual owner. The most common structural fix I've put in place, inside an enterprise architecture practice and inside a GxP-regulated SaaS business, is the same: collapse the committee into a named accountable owner for each risk tier, with the committee kept for genuinely contested or high-risk cases rather than as the default route for everything. Low-risk approvals sit with a single delegated owner who can say yes in a day. Only the cases that actually warrant multiple perspectives, the ones that are genuinely high-risk or genuinely novel, go to a group, and that group has a real decision to make rather than a rubber stamp to apply.

This matters more than it sounds like it should, because ambiguity about who can say yes is what causes teams to over-escalate everything out of caution. If nobody knows whether they're allowed to approve something themselves, everything ends up in the committee's queue by default, and the committee becomes the bottleneck it was never designed to be.

Use existing frameworks as scaffolding, not as the whole job

You don't need to invent a governance framework from nothing, and organisations that try usually end up with something worse than what's already available. ISO/IEC 42001 gives a management-system structure for how an AI governance function should actually run, roles, documentation, continual improvement, that maps sensibly onto how most regulated businesses already run quality and information-security management. The NIST AI Risk Management Framework offers a practical vocabulary for the map, measure, manage cycle that most risk-tiering exercises end up reinventing anyway. Neither framework does the proportionality work for you, and neither replaces judgement about your specific business. What they do is save you from re-deriving structure that's already been through the fire elsewhere, so the effort goes into calibrating it to your risk appetite rather than inventing the scaffolding from a blank page. Life sciences worked out a version of this proportionality problem decades ago under GxP, and what that culture has to teach other regulated sectors turns out to transfer directly to AI governance design.

What good looks like

The tell for governance that's actually working isn't a low number of AI projects; it's a high number of low-risk ones moving fast and a small number of high-risk ones getting real scrutiny, with almost nothing sitting in an unofficial grey zone because the official route was worse than going around it. That's a design outcome, not a culture outcome. It comes from sorting risk honestly, pre-approving the boring 80% of use cases, and putting the expensive scrutiny where the expensive decisions actually happen, not at the end of the runway where it's too late to change anything cheaply.

← Back to Insights