What is an AI governance framework?
An AI governance framework is the set of decisions your organisation has already made about AI, written down, so that individual projects do not have to make them again badly and under time pressure. Most published frameworks are principles documents, and a principles document governs nothing. The part that does the work is much smaller and much more boring: a register of what exists, named owners, a gate that some things must pass through, and a route for reporting when something goes wrong.
Do you actually need a formal framework?
If you use a handful of vendor AI features, employ nobody who trains models, and make no automated decisions about people, then a two-page policy and an accurate list of tools is sufficient governance and anything more is theatre. The obligation that scales fastest is not the number of AI tools you use, it is whether any of them affects a person's access to employment, credit, education, housing, healthcare or a public service.
The threshold worth watching is closer to that than to headcount. A fifteen-person company running an automated CV screen has a governance problem. A thousand-person company using AI only to draft internal documents largely does not, whatever its auditors say.
The honest reason organisations build frameworks earlier than that is procurement. Enterprise buyers and public bodies now ask for evidence of AI governance in supplier questionnaires, and the cheapest time to be able to answer is before the question arrives. That is a legitimate reason. It is not the same as a risk reason, and confusing the two produces documents optimised to be shown rather than used.
What does an AI governance framework actually contain?
Six components, and the order matters because each one is useless without the one before it. An inventory of AI systems in use, with an owner named for each. A risk classification method that sorts those systems into tiers. A set of controls that attach to each tier. A decision gate where a system cannot go live without passing the controls for its tier. A monitoring arrangement that watches systems after launch. And an incident route that says who is told, how quickly, when a system behaves in a way it should not.
Everything else in a typical framework document is either a restatement of principles, which changes no behaviour, or a mapping table showing how your controls satisfy some external regime, which is evidence rather than governance. Both are worth having. Neither is the framework.
The single component most often missing is the gate. Organisations write the tiers and the controls, publish them, and then never place a step in any real workflow where the controls are checked. The result is a framework that describes a company nobody works at.
How do the published frameworks differ?
They answer different questions, which is why organisations end up using two or three at once rather than choosing. The EU AI Act tells you what you must do. NIST tells you how to think about it. ISO 42001 tells you how to prove it. OECD and UNESCO tell you what to aim at. None of them tells you what your own risk appetite is, and that is the part you cannot outsource.
A common and workable combination is to use the AI Act or an equivalent local regime to set the tiers because they carry legal consequences, NIST AI RMF to structure the internal process because it is free and detailed, and ISO 42001 only if a customer or regulator has asked for a certificate.
| Framework | What it is | Binding | Gives you | Does not give you |
|---|---|---|---|---|
| EU AI Act (2024/1689) | Product-safety style regulation with risk tiers | Yes, in scope of the EU | Prohibitions, high-risk obligations, penalties, deadlines | Any method for meeting them |
| NIST AI RMF 1.0 | Voluntary risk management structure, four functions | No | A process vocabulary and a detailed playbook of practices | Thresholds, or any answer on what is acceptable |
| ISO/IEC 42001:2023 | Certifiable AI management system standard | By contract only | An auditable structure and a certificate buyers recognise | Assurance that the AI itself is any good |
| OECD AI Principles | Intergovernmental principles, basis for much later law | No | Shared vocabulary and a definition of an AI system | Anything operational |
| Sector rules (finance, medical, employment) | Existing regulation applied to AI | Yes, where they apply | Specific, enforceable duties that often predate AI law | Coverage of anything outside that sector |
Who should own AI governance?
One named person with the authority to stop a launch. If nobody in the structure can stop a launch, there is no governance, only advice. This is the fastest test to run on any framework, including one you have already built: identify who said no most recently, and what happened next.
In practice ownership tends to land in one of three places, each with a predictable weakness. Legal and compliance ownership produces frameworks that are accurate about regulation and disconnected from how systems are built. Engineering ownership produces frameworks that are technically sound and blind to duties that arrive from employment law or consumer protection. A standalone AI office produces good documents and struggles to get anything adopted because it owns no delivery.
The arrangement that tends to survive is a small cross-functional group with a single accountable owner, meeting on a fixed cadence, with the authority to approve tiers and block deployments, and with the engineering lead in the room rather than consulted afterwards. Committees without an accountable individual produce minutes rather than decisions.
What makes a governance framework fail?
Four failure modes, and only one of them is a lack of rigour. The first is that the framework governs projects rather than systems: it reviews things at the point they are commissioned and never again, so a model that has drifted for eighteen months remains formally approved. Governance has to attach to the running system, not to the project that built it.
The second is scope defined by technology instead of by effect. A framework covering machine learning will not cover the spreadsheet of hard-coded rules that decides who gets an interview, even though the harm and the legal exposure are identical. Define scope by what the system decides or influences about people, and the coverage stops moving every time the technology changes.
The third is a tiering scheme with too many levels. Anything beyond three or four tiers means the classification argument costs more than the controls. The fourth is treating vendor AI as out of scope. Most AI in most organisations is a feature inside software someone else wrote, and a framework that only covers models you build yourself governs the smallest part of your estate.
How do you tell whether yours is working?
Run this test this afternoon. Pick one AI-enabled system that is live and being used by real people. Ask, without warning, for four things: who owns it, what tier it was classified as and by whom, what evidence exists that it was tested before launch, and what would happen if it started producing wrong output at nine tomorrow morning.
If those four answers exist and can be produced in a day, the framework functions regardless of how thin the documentation looks. If they take a week of asking around, the documentation is not the problem and adding more of it will not help.
A second test is the inventory count. Ask your framework owner how many AI systems the organisation uses, then ask finance how many suppliers with AI in the product description were paid last quarter. When the two numbers differ by a factor of several, which is common, the framework is governing a subset it chose rather than the estate that exists.
Common questions
- What is an AI governance framework?
- The set of decisions an organisation has already made about how AI may be used, written down so individual projects do not remake them under time pressure. A working one contains six things: an inventory of AI systems with named owners, a risk classification method, controls attached to each risk tier, a gate a system must pass before going live, monitoring after launch, and a route for reporting failures. Principles statements are not frameworks.
- What is the difference between the EU AI Act and NIST AI RMF?
- The EU AI Act is binding regulation that says what is prohibited, which uses count as high risk, what obligations attach to them and what the penalties are. It does not say how to satisfy those obligations. The NIST AI Risk Management Framework is voluntary and does the opposite: it supplies a detailed process vocabulary and playbook but sets no thresholds and creates no duties. Many organisations use the first to set scope and the second to structure the work.
- Do small companies need AI governance?
- Only in proportion to what their AI decides. A small company running automated CV screening or credit decisions carries real legal exposure and needs a genuine control. A larger company using AI only for internal drafting mostly needs an accurate tool list and a short acceptable-use policy. The trigger is whether a system affects a person's access to employment, credit, education, housing, healthcare or public services, not organisational headcount.
- Who should be responsible for AI governance in an organisation?
- One named individual with authority to stop a deployment, supported by a small cross-functional group that includes engineering rather than consulting it afterwards. If no one in the structure can block a launch, what exists is advice rather than governance. The quickest diagnostic is to ask who last said no to an AI deployment and what happened after they did.
- Why do AI governance frameworks fail?
- Commonly for four reasons: they govern projects rather than running systems, so approval is never revisited as models drift; they define scope by technology rather than by effect, missing rule-based systems that cause identical harm; they use too many risk tiers, so classification costs more than the controls; and they exclude vendor AI, which is where most AI in most organisations actually sits.
- Is ISO 42001 certification worth getting?
- It is worth getting when a customer, regulator or tender has asked for it, and rarely otherwise. ISO/IEC 42001:2023 certifies that a management system for AI exists and is followed. It says nothing about whether any particular model is accurate, fair or safe, so it answers a procurement question rather than a risk question. Building the underlying management system has value independently of paying to certify it.
