Every enterprise I work with has an AI governance framework. Some have two. A handful have three, inherited from previous consultants and living quietly on different intranets, contradicting each other in ways that no one has noticed because no one is actually reading them. The presence of a framework is not the issue. The issue is that almost none of these frameworks do what their authors intended.
When I ask leaders what their governance framework actually does — which models it has caused to be stopped, modified, or improved — the answers tend to be vague. “It’s raised awareness.” “It’s given us a policy we can point to.” “We haven’t had an incident.” These are real things, but they are not what governance is. Governance is a set of decisions that bind future behaviour, with the teeth to enforce them. A framework that has never stopped anything, modified anything, or provoked a difficult conversation is not governance; it is decoration.
Having watched perhaps forty organisations build these frameworks over the past five years, and having been responsible for building several myself, I’ve come to think there are four reasons they fail. The reasons compound. An organisation that falls into all four — which is most organisations — produces a framework that looks impressive in a slide deck and is invisible in practice.
The first reason: the framework is written before the process
The most common sequence is that a policy is drafted, approved, and then someone is asked to operationalise it. This is the wrong way round. Operational processes that pre-exist the policy get grandfathered in; processes that don’t yet exist get deferred because the policy doesn’t have teeth. The framework ends up describing an aspirational reality that no one is resourced to create.
The right sequence is the inverse: the process exists first, it is documented, and the policy is the codification of that documented process. This produces a framework that is genuinely enforceable because the mechanism of enforcement already exists and is already operating. The policy is not an ambition; it is a description.
A framework that has never stopped anything, modified anything, or provoked a difficult conversation is not governance — it is decoration.
Organisations that insist on policy-first governance usually do so because the policy is needed for a regulator, a board, or a compliance attestation. The policy therefore becomes the goal, and the process becomes a best-efforts afterthought. A better response, when the pressure is regulatory, is to draft the policy as provisional — explicitly linked to an operational build-out plan — and to treat the absence of a mature process as a documented risk rather than a pretended solution.
The second reason: there is no named accountable individual
Almost every failing framework I have seen is accountable to “the AI Ethics Board” or “the Risk & Ethics Committee” or some similar collective. Collective accountability is no accountability. When a model goes wrong, or when a difficult decision needs to be made, the collective defers to the individuals, and the individuals defer back to the collective. Nothing happens.
The fix is structurally unglamorous but operationally decisive. A named individual — typically the AI Ethics Officer, reporting to the AI-CoE Director — is accountable for the framework’s operation. That individual chairs the board, drafts the meeting papers, records the decisions, and owns the follow-up. The board exists to challenge and to grant legitimacy; it does not exist to be accountable. If the board disappeared, the framework should still function. If the named individual disappeared, it should not.
Where I have seen this rule broken, the pattern is always the same: an organisation fills the accountable role with someone whose main job is something else — a general counsel, a chief risk officer, a compliance director — and the AI work becomes the tenth priority on a list of ten. The framework then operates at tenth-priority speed, which is to say, not at all.
The third reason: the framework is decoupled from the model development lifecycle
In many organisations, the governance framework and the model development lifecycle are two separate documents owned by two separate functions. The data science team follows the MDLC. The governance team maintains the framework. The two meet only at formal review gates, and the formal review gates are the ones most often skipped under delivery pressure.
The right answer is that governance is embedded inside the lifecycle, not adjacent to it. The MDLC stage I describe in the AI-CoE guide as “Responsible AI Review” is not a separate process; it is the stage at which the governance framework’s requirements are expressed as concrete, executable tasks. A data scientist reading the MDLC sees exactly what they need to do: run these tests, produce this documentation, seek this sign-off. The governance framework is visible only as the policy rationale behind those tasks.
Collective accountability is no accountability. A framework accountable to “the committee” is a framework that nothing ever passes or fails.
Embedding governance this way has a second benefit: it makes the framework’s requirements legible to the people who have to implement them. A data scientist asked to “comply with the Responsible AI Policy” does not know where to start. A data scientist asked to “complete the bias analysis template, register it against the model card, and submit both to the Ethics Officer for sign-off” knows exactly what to do. The former is a framework; the latter is operational governance.
The fourth reason: the framework cannot say no
This is the deepest failure and the most common. The governance framework exists, it is well-staffed, it is embedded in the lifecycle, it has a named accountable individual — and in five years of operation, it has never stopped a model. Not one. Every model submitted to review has been approved, sometimes with conditions, but always approved.
This pattern has two possible explanations. Either the models being built are all genuinely acceptable, in which case the framework is redundant because the real quality control is happening upstream. Or the framework is pre-approving everything because it has never developed the authority — and the political cover — to exercise genuine refusal. In my experience, it is almost always the second.
A framework that cannot say no is producing theatre, not governance. The test is precise: has your framework, within the last twelve months, caused a model to be delayed, modified, or abandoned against the wishes of its sponsor? If the answer is no, the framework has not yet earned its existence, regardless of how many hours of board time it has consumed.
What a working framework looks like
A working governance framework has five characteristics. It was built second, after the operational process it describes. It has a single named individual who owns its operation. Its requirements are expressed as concrete tasks within the MDLC, not as standalone policy obligations. Its review body has demonstrated the authority to say no, and has done so at least once in the memory of the data science team. And — the easiest to assess from outside — the framework is visible in the work of the organisation, not only in its documentation.
Organisations that want to build such a framework should not start by drafting a policy. They should start by mapping the operational process: who decides which models are built, who reviews them before production, who monitors them once live, who decides when they retire. Where the map has gaps, fill the gaps with process. Where the process has weaknesses, strengthen them. Only then, once the operational reality is sound, write the framework that codifies it.
This is slower than the alternative. It produces a less polished document at the point the board asks to see it. It requires more organisational courage, because it forces honest conversation about the gaps that exist today. But it produces governance that works, in the sense that it actually governs.
Most organisations will not choose this path. They will produce the polished document, show it to the board, and then spend the following three years quietly discovering that it doesn’t govern anything. The cost of that discovery — in incidents, in regulatory exposure, in the dismantling and rebuilding of the framework — is substantial, and it is wholly avoidable. The only thing required to avoid it is to put the operational work first, and the documentation second.
This is an extract from thinking developed in EIS-001: AI Center of Excellence Guide, Chapter 11, and EIS-005: AI Governance with ISO 42001, both published in the Enterprise Intelligence Series.