What an AI Governance Framework Actually Contains

An AI governance framework is the standing arrangement by which an organisation decides what AI it will run, on what terms, and how it knows those terms are being met. In working form it has five parts: named ownership, a system inventory, a rule for tiering risk, evidence requirements attached to each tier, and a review cycle that actually runs.

It is not a policy document. A policy is one output of a framework, and the least load-bearing one — organisations with excellent AI policies and no framework are common, and the policy is generally the reason nobody noticed.

1. Ownership, with a name and a veto

One person, named, with the authority to stop a deployment.

The most common arrangement is distributed: legal handles the regulatory reading, security handles the model, data handles provenance, product handles the roadmap. Each of those is doing real work and none of them can stop a launch, so nothing is ever stopped. When a launch date and an unresolved question collide, the question loses by default.

The test is not who is on the committee. It is who signs, and whether they have ever said no. If the answer is nobody and never, the framework has not been exercised and you do not yet know whether it works.

2. An inventory that changes

A list of every AI system the organisation runs or relies on, with an owner against each, that is updated when the estate changes rather than annually.

Two failure modes. The first is under-counting: the AI features inside SaaS tools the organisation already licenses — summarisation in a CRM, ranking in a hiring product, suggested replies in a support desk — are AI systems the organisation is answerable for, and they enter the estate without a procurement decision. The second is staleness. An inventory whose last modification date is nine months old is describing a different company.

The date of last change is the single most diagnostic fact about a governance framework, and it takes ten seconds to check.

3. A tiering rule you can apply without a meeting

A written rule that sorts systems by consequence, applied at the point a system enters the inventory.

Tiering is what stops the framework applying the same weight to a meeting-notes summariser and a model that prices insurance. The rule does not need to be elaborate — consequence to a person, reversibility, autonomy and data sensitivity carry most of it — but it does need to be written down, because a tiering decision made in conversation is a tiering decision nobody can reconstruct later.

Two anchors are worth building the rule against rather than inventing from scratch. The EU AI Act defines a high-risk category with specific triggers, and if any of your AI touches EU users, that categorisation is not optional — it is narrower and stranger than most summaries suggest. The NIST AI Risk Management Framework's Map function gives a structured way to characterise context and impact for everything else; we set out its four functions in plain English separately.

4. Evidence requirements, attached to the tier

What each tier must be able to produce, decided once, so that the question at launch is "is the evidence here" rather than "how much diligence does this deserve".

For a low-tier system that might be a one-paragraph description and an owner. For a high-tier system it is a documented evaluation with dates and populations, a data-provenance record, the human-oversight design, a monitoring plan and an incident route. The specific list matters less than the fact that it is fixed in advance: a diligence standard negotiated per launch is negotiated by whoever is under the most schedule pressure.

This is also the part that makes an external audit cheap rather than expensive. An organisation whose framework already requires the evidence has already assembled most of what an audit asks for — which is most of what preparing for an audit involves.

5. A review cycle that runs on a date

A recurring review of the high-tier systems, on a schedule, whether or not anything has gone wrong.

AI systems change without anyone deploying anything. Traffic shifts, the population changes, an upstream vendor updates a model behind an unchanged API, a retrieval corpus goes stale. A framework that only reviews on change will miss all four, because none of them is a change anyone made.

The review does not have to be heavy. It has to be dated, to produce a record, and to be capable of the outcome "this needs to stop."

Where the standards fit

ISO/IEC 42001 is the closest thing to a blueprint for the five parts above — it is the management-system standard for AI, and it describes the machinery rather than any individual model. Most organisations get more from building against it than from certifying to it early; certification becomes worth its cost when counterparties start asking for it by name. What it actually requires is a separate read.

NIST AI RMF is the vocabulary a great many US enterprise and public-sector buyers now use in their questionnaires. It is voluntary, and answering it well is largely a function of whether the framework above exists.

The EU AI Act is law, and it does not care whether you have a framework — it cares whether specific systems meet specific obligations. What a framework gives you is the ability to know which of your systems are in scope before somebody else tells you.

What a framework does not do

It does not produce compliance. This is worth being blunt about, because it is the claim a governance programme is most tempted to make internally once it has cost enough.

A framework is machinery for producing and checking evidence. Whether a particular system is accurate enough, fair enough, secure enough and explainable enough is a question about that system, and it is answered by testing it. What a good framework changes is that the testing is routine rather than exceptional, and that somebody notices when it has not happened.

It also does not survive being run by the team that builds the systems. Self-assessment has an honest place — it catches a great deal cheaply — but it cannot produce the record a third party is asking for, and it has a known blind spot around the claims the team already believes. What "independent" means and why self-assessment is not it covers the distinction.

Three questions for your own framework

If you want to know where yours stands without commissioning anything, ask these in order.

When did the inventory last change? If the answer is more than a quarter ago in an organisation that is actively deploying AI, the inventory is describing a past state.

Name the most recent system the framework stopped, delayed or altered. If there is no example, the framework has never been tested against a deadline, which is the only condition under which it matters.

What would you hand over if a regulator, a partner bank or an enterprise buyer asked tomorrow? Not what exists in principle — what could be produced this week, by whom.

An organisation that can answer all three has a framework. One that cannot answer the second has a document. iDharma's own standard for what verification means, and what our reports are measured against, is published in full at the verification methodology.