Last year I spent a week talking to C-suite members individually as part of a wider governance assessment. The company was already using AI in several places. Some of it sanctioned. Some of it not. A couple of tools had been quietly adopted by teams who never thought to ask permission because they did not think of them as AI.
When the executive discussion came, the agenda item was “AI policy.”
Five minutes in, it was clear the room was really talking about three different things. One person was worried about staff using generative AI to draft client-facing content. Another wanted to know whether the analytics tools already had ML running underneath them. The most senior person kept saying “we need to embrace AI” without ever defining what that meant for the business.
The draft response was heading toward a single document that tried to cover everything from machine learning to automation to generative AI in one sweep. The kind of thing that looks responsible and does very little.
That meeting is why I think the most common AI governance mistake right now is not a lack of policy. It is treating “AI governance” as one problem when it is actually three.
Three problems disguised as one
What I have learned since, partly through client work and partly through sitting three AI certifications back to back, is that most organisations are mixing three different governance problems together without realising it.
The first is an estate problem. What AI does the organisation actually have, use, buy, or permit? Not just the generative AI tools making headlines. The ML sitting inside analytics platforms. The automation in third-party software. The decision-support tools that nobody calls AI but probably should.
The second is an operating model problem. How do AI use cases get approved? Who signs off? What are the data boundaries? Where is human review? What happens when the output is wrong?
The third is a leadership narrative problem. What is the leadership team actually trying to say yes to? Productivity? Cost reduction? Controlled experimentation? Because if that is not clear, policy becomes theatre.
In that particular client, the leadership team did not have an estate problem first. They had a leadership narrative problem and an operating model problem. Nobody had decided what AI was supposed to be for. And people were already using AI-adjacent tools with no approval path, no use-case triage, and no control structure.
The single grand policy they were trying to draft would not have solved any of it.
What the certifications actually reveal
I did not set out to study three AI certifications to prove a point about governance framing. I sat them because AI governance is becoming a bigger part of my advisory work and I wanted to pressure-test my own understanding across the three platforms my clients actually use.
Microsoft AI-900. AWS AI Practitioner. Google GenAI Leader. All entry-level. None of them makes you an AI engineer. But sitting them back to back revealed something I was not expecting.
They are not teaching the same thing. Not even close.
Microsoft AI-900 is the broadest. It covers machine learning, computer vision, natural language processing, and generative AI across the Azure estate. Responsible AI is in there but it is part of the landscape rather than a standalone governance domain. The current exam retires in June 2026, which tells you Microsoft is already rethinking the framing.
Where AI-900 is most useful from a governance perspective is scope. A lot of organisations are building “AI governance” when what they actually mean is “controls for ChatGPT and Copilot.” If your business is also using OCR, classification, recommendation engines, predictive modelling, or anomaly detection, a governance regime that only covers generative AI misses part of the estate. AI-900 pushes you to think wider than the headline tools.
AWS AI Practitioner was the one that changed my thinking most.
The syllabus keeps pulling you back to foundation model use in business context and then immediately pairs it with security, compliance, and governance. Not as an afterthought. As a named domain with real weight in the exam.
That matters because it reflects something I see with clients constantly. The real governance question is usually not “do we have an AI policy?” It is “who decided this use case was acceptable, on what basis, using which data, with what human review, and what happens when the output is wrong?”
The AWS material pushed me away from framing AI governance as a policy exercise and toward something more operational. Most clients do not have an AI policy problem first. They have a use-case approval problem first.
I immediately thought of the sort of client who says “we are only piloting it internally” or “we are just using a managed model” or “no decisions are being made automatically.” That is exactly where weak governance creeps in. The client hears “pilot” and thinks low risk. Governance should hear “unstructured approval path.”
Google GenAI Leader is the narrowest of the three but the most honest about what it is. Google describes it as a business-level certification for people in any role. The emphasis is on how generative AI transforms organisations and how to adopt it responsibly.
It is not really a broad AI exam. It is a leadership positioning exam. And for the right audience that is not a weakness. A lot of leadership teams need someone who can translate generative AI into the language of executive decision-making. Where it creates value. Where it creates risk. Where leadership needs to make explicit decisions rather than vague statements of support.
The limitation is obvious. Because it is specifically about generative AI, it does less for someone trying to govern the full AI estate. And because it is leadership-oriented, it does less than AWS to reinforce operational governance and control thinking.
What “good” looks like
If I went back to that executive meeting now, I would change the conversation in the first five minutes.
Instead of letting the room drift toward a single AI policy document, I would say: we need to decide which problem we are actually solving first. Because right now we are mixing three different governance problems together.
Then I would split the work into four things.
A short leadership team position statement. Not a policy. A statement of what the organisation is trying to achieve with AI and what risks it will not accept. One page. Plain language. Forces the leadership narrative question before anyone starts drafting controls.
An AI use-case intake and review process. This is the operating model piece. Every meaningful AI use case needs a named business owner, a defined purpose, a data boundary, a risk view, a human review position, and a record of why its use is acceptable. Not because bureaucracy is the goal. Because “we are only piloting it internally” is not a governance position.
An acceptable-use standard for current generative AI tools. Separate from the broader policy. Specific to the tools people are already using. Short enough that someone actually reads it.
A separate exercise to understand the broader AI estate over time. Not urgent. Not blocking the other three. But necessary, because most organisations do not know what AI-adjacent tooling is already running inside their supply chain, analytics platforms, or third-party services.
That is four deliverables instead of one. It takes roughly the same effort. But it solves the right problems in the right order instead of producing a document that covers everything and governs nothing.