Governance: A Policy Document Is Not a Control
When I ask a new client or prospect business about their AI governance, I always get some version of the same answer: “we’ve got a policy”.
Someone sends me a document. It says things like “use AI responsibly”, “do not input client data into public tools”, “always verify outputs before use”, and “only authorised tools can be used for work purposes”. Sensible enough words, mostly drafted using an AI tool ironically, but signed off and circulated in an all-staff email.
Well intentioned, but missing any true sense of practical operationalisation. And, in practice, either none of it is effectively enforced anywhere, or there’s no way to know if it really has been.
A policy is a statement of intent. It is not a control. And in my experience from the businesses I’m working with who are moving from “experimenting with AI” to “running AI at scale”, this is the single most common gap I’m seeing. It’s also one of the most dangerous, because it feels like the box tick is the only assurance and insurance against the risks involved.
Hope is not a control
There’s a simple question I ask to test how effective your AI governance is: if an employee pasted a client’s confidential data into a public AI tool tomorrow, would your systems have stopped it? or would you even have known, at all?
For most, the honest answer is the second one. The policy says not to, but the system doesn’t prevent it from happening. The gap between what’s written down and what’s technically possible is where the real risk lives.
I’ve seen exactly the same pattern for years in process automation, long before generative AI arrived. A process document for example states to always check the invoice total before approving, but the system doesn’t enforce it. Eventually someone doesn’t check, and the business finds out the hard way that intent is not the same as a safeguard. AI hasn’t changed this lesson. It’s just made the stakes bigger and the pace faster.
Governance that only exists on paper is gesture governance. It gives the comfort and illusion of control, and it’s what the board wants to hear, but it doesn’t actually stop anything bad from happening, and it certainly doesn’t tell you what already has.
What structural governance actually looks like
Real AI governance needs to be configured and built-in to the make-up of your tools. It can really only live in the access controls, the data source permissions, the guardrails, the audit trail, and the system architecture itself.
Practically, that means being able to answer a small set of questions with absolute certainty:
What can this AI tool or agent actually access? Not what it’s supposed to access. What it can. If an AI tool can access more than it needs, then you have a structural gap, not a training issue.
Is there a record of what it did? If something goes wrong, can you reconstruct exactly what data was touched, what decision was made, and why? If not, your audit trail is lacking.
Who is accountable when it gets something wrong? It’s not the AI team, they may build the guardrails, but it’s the process owner who’s accountable for the outcome. Interestingly, this is one of the clearest points McKinsey made in their recent work on this, and it’s worth summarising here: no production agent should exist without a clear business owner who knows what it does, what it can touch, and what happens when it’s wrong.
None of this should feel like a revelation, it’s the same sound discipline any business would apply to their controls or to data protection, or indeed anything else where you have outcomes with consequences that truly matter. Your AI controls just haven’t caught up to that level of standard yet, mostly because it simply moved fast to keep pace.
AI needs it’s own SDLC
Software development went through its own reckoning decades ago, when software was being written however an individual developer felt like writing it. There were almost none of the controls we take for granted now – no version control, no testing standard, no review process. And that worked until it didn’t, and the industry responded with the creation of the Software Development Lifecycle (SDLC). It’s a formal framework for how code gets brought into existence – designed, built, tested, reviewed, and released.
Fast forward to today, and AI agents are being built in a not too dissimilar way to how software was before SDLC existed.
Anyone with access to a no-code builder or an AI platform can stand up an agent in an afternoon. No formal training. No framework. No review. If it works, it spreads. This is “vibe coding” at the agent level, and it’s happening inside businesses that would never tolerate the equivalent behaviour from their software engineering team.
The fix for AI governance is going to be pretty much the same that the software industry got. Businesses need an AI Development Lifecycle (ADLC): a defined, repeatable process for how an agent comes into being. Model selection. Guardrails. Data connections. Access levels. Testing before release. Sign-off before production. Review after deployment. This last one is actually the most important of all.
This isn’t to add bureaucracy for its own sake, it’s the same discipline SDLC brought to software, applied to a new kind of build. Sometimes you need to slow down in order to speed up. The businesses that skip it won’t find out they made a mistake immediately. They’ll find out some time from now, when nobody remembers which of the forty agents floating around actually has access to what.
Drowning in manual, repetitive work? Tell us the task and we’ll show you what to automate.
The uncomfortable truth
Structural AI governance is less comfortable than policy governance, because it’s specific and involves skills and experience that most businesses are still acquiring. A policy can stay vague forever. Let’s face it, the term “Use AI responsibly” doesn’t offend anyone and doesn’t really commit anyone to anything much. Whereas actual configuration forces decisions such as: which tool can access what data; which agent can take what action; which accountable person owns which outcome. You first have to make those decisions in the configuration stage, and then somebody has to be able to defend them later.
That’s exactly why most businesses haven’t done it yet. It’s genuinely easier to write a policy than it is to configure and enforce one. But easier isn’t the same as sufficient, and those that get caught out won’t be the ones without a policy. They’ll be the ones who had a very well-written policy but their systems didn’t actually uphold any of it.
If the AI exploration phase was about proving the tools could work, governance is where the serious phase actually begins. It’s the first pillar for a reason: none of the other four, literacy, tokenomics, lifecycle, orchestration, mean very much if you can’t answer basic questions about what your AI is allowed to do and who’s accountable when it doesn’t.
The policy document isn’t wrong. It’s just nowhere near enough.
Practical starting points
In each part of this series, I want to leave you with some practical next steps and some links to helpful tools to get you started, and here’s the first lot for your AI Governance imperatives.
Run an AI Amnesty Survey. Before you can govern anything, you need the full picture, not the sanctioned one. Survey all staff on what they’re actually using, for what, and how, with no consequence attached to honest answers. Most businesses are surprised by what surfaces. You cannot govern what you don’t know exists.
Define what you actually want AI to achieve. “We should be using AI more”, is not an actual goal. Faster close times, better advisory capacity, reduced manual review, whatever it is for your business. Governance without a defined objective just becomes a set of restrictions with no clear purpose behind them.
Confirm your AI Development Lifecycle (ADLC). Treat this the way software engineering treats SDLC: a formal, repeatable process for how agents get built, not something left to whoever’s confident enough to try. Model selection, guardrails, data connections, access levels, testing, sign-off. If this only exists in someone’s head, it isn’t a process, it’s a habit, and habits don’t survive staff turnover.
Name an owner for every agent already in production. If you can’t say who owns an agent and its outcomes right now, that’s your first governance gap to close, before adding anything new.
Check whether you have an audit trail, or just a memory. If reconstructing what an agent did last month depends on someone recalling it, you don’t have governance, you have luck.
Know where you stand
Most people reading this will recognise at least one gap from the above. That’s normal. Some will recognise them all – don’t panic!
The hard part is knowing how serious each gap actually is, and where to start.
We’ve got two tools specifically to help at this stage:
Our AI Amnesty Survey gives you that honest, judgement-free picture of what’s actually being used across your business right now, the starting point for everything else on this list.
Contact us to take the AI Amnesty Survey
Our AI Governance Assessment then gives you a clear baseline of where your business currently sits against structural governance, not policy governance, along with a prioritised set of next actions rather than a generic list of best practices.
Contact us to take the AI Governance Assessment
Next in this series: Part 3, AI Literacy, and why your best AI hire might already be sitting in your team.
Daniel Lawrence is the CEO and co-founder of bots for that, creators of the Automation Operating System (AOS) and Agent Console. He has spent more than a decade deploying enterprise automation and AI in regulated industries including accounting and professional services. AI: The Serious Phase, is a six-part series exploring what AI-native operations look like for mid-tier and large UK accounting firms.
