Building an enterprise AI governance framework in seven phases
Somewhere in your organisation there is a beautifully formatted AI policy that nobody has opened since the day it was approved. I've read a few of them. They tend to be thorough, well-intentioned and completely disconnected from the systems they claim to govern. Governance that lives in a document is decoration. What works is treating it as a system you build, document and hand off — in that order. This is the model I use, compressed to seven phases.
01Mandate
Before any register, control or committee, someone senior must own the outcome. With their name, not their department's. Governance without decision rights is advice, and advice loses every argument with a delivery deadline. I've watched strong frameworks evaporate the first time a flagship project asked for an exception and nobody in the room had the authority to say no.
Phase one is getting three things in writing: an accountable executive sponsor, a definition of what counts as an AI system in your organisation, and who can pause one. That second item sounds bureaucratic until you try to answer it. Is the copilot inside your CRM an AI system? The scoring model a vendor runs on your data? The agent someone wired up last month to triage tickets? If your definition doesn't cover models you build, agents you assemble and AI embedded in the software you buy, it will be obsolete before the ink dries. And if you cannot get the mandate at all — stop. Everything after it is theatre.
02Inventory
You cannot govern what you have not found, and there is always more than anyone admits. Build a register of every AI use case and every agent: owner, purpose, the data it touches, its autonomy level, the systems it can act on.
The uncomfortable part is shadow AI — the unofficial copilots and connectors nobody declared. Expect to find them; every tenant has some. Treat what you find as a demand signal rather than a crime scene. People built those things because something in their job was slow or painful, and the register is how that need gets a sanctioned path instead of a hidden one. Punish the first discovery and you guarantee you'll never make another.
03Classify
Risk-tier every entry: where it lands under the EU AI Act, what breaks when it fails, who gets hurt, whether the harm can be undone, how sensitive the data is. My favourite classification question is blunt: what happens if this is wrong and nobody notices for a week? The honest answers range from "nothing" to "we make the news", and that range is exactly what the tiers must capture.
Keep the tiers few — three or four, not nine — and predefine the obligations for each. Classification is what turns governance from an argument about opinions into a lookup. The tier tells you what is required, nobody negotiates controls case by case, and the review meeting takes twenty minutes instead of a quarter.
04Control
Controls should be proportional to tier and enforced where the traffic actually flows. Not in a document, not in a training slide. In practice that means one controlled front door for AI workloads: a gateway handling routing, quotas and content safety at the edge, identity on every call, hard data boundaries, and policy expressed as code wherever the platform allows it.
A control that depends on people remembering it is a suggestion. A control enforced by the platform is a fact.
You want as many facts and as few suggestions as your architecture can afford, because eighteen months from now nobody remembers the suggestions.
05Evidence
At audit time, a control without evidence does not exist. It doesn't matter that the guardrail fired; if nothing recorded it firing, you cannot prove it was ever there.
So every tier's obligations must produce artifacts continuously and automatically: evaluation pipelines on every release, red-team results, groundedness checks for anything that answers from enterprise content, logs that show the boundaries holding. The test is simple and slightly cruel: if assembling evidence for an audit takes a quarter of manual archaeology, phase five was skipped. No matter what the policy says.
06Document
Now write it down. Not the compliance novel — the operating model people will actually use: short policies, runbooks, a decision log, the risk register itself. My test for "done": a new engineer can find out what they are allowed to build, and how, without booking a meeting with the person who designed the framework.
This is also where aligning to ISO/IEC 42001 and NIST AI RMF earns its keep. It costs little while you are structuring the material anyway, and it turns every future audit from an excavation into a mapping exercise. Do it now, or pay for it annually.
07Hand off
Here is the part I have to argue for most often: the architect who built the framework is the wrong permanent owner for it.
Partly it is a conflict of interest — the person who built the system should not be the only one who can say no to it. Mostly it is a single point of failure: governance that lives in one person's head leaves in their notice period. And there is a quieter failure mode too, the flattering one. It is pleasant being the person everyone has to ask. Resist it.
Accountability transfers to named, permanent owners — risk, security, data, product — each holding the piece that matches their mandate. The architect stays close, as an advisor for the genuinely hard calls, and the framework keeps running on the days the architect is on a beach. Governance is an operating function, not a project. Projects end.
None of this makes AI governance easy. It makes it operable, which is the achievable kind of easy. The standards — ISO/IEC 42001, NIST AI RMF, the EU AI Act — give you the skeleton and the vocabulary; the seven phases give you the order of operations. Build, document, hand off. Then let go properly, on purpose, with your name off the approval chain. That is the only version of "done" that survives you.