An AI governance framework sets out how an organisation develops, purchases, deploys and monitors AI. Most teams should start with the voluntary NIST AI Risk Management Framework, then add binding legal duties such as GDPR and CCPA.
Picture a team that has approved its first AI pilot. The model works, a vendor tool is already in use, and then someone asks who signs off changes, who watches performance and what happens if a regulator calls. A governance framework answers those questions, and it sits inside the wider discipline of enterprise ai, where enterprise ai adoption challenges often begin as ownership gaps rather than technical faults.
| Key fact | Detail |
|---|---|
| OECD principles are non-binding | Non-binding, rights-based approach |
| NIST AI RMF core functions | Four functions: Govern, Map, Measure, Manage |
| NIST AI RMF is not certifiable | Guidance; not subject to formal certification schemes |
| AI governance definition | Governs how an organisation develops, purchases, deploys and monitors AI |
| GDPR and CCPA rules for personal data in AI | Binding rules on personal data entering AI systems |
| Explainability techniques | SHAP and LIME local explanation methods |
Figures from www.bradley.com and www.qa.com; they can change, so check the source before you rely on them.
When nobody owns AI decisions
QA describes AI governance as the way an organisation establishes how it develops, purchases, deploys and monitors AI. That wording is useful because it names every stage where a decision can go unowned, including the purchase of tools that someone else built.
- Develop: in-house models need a documented purpose, a record of the data used and agreed testing standards before build work begins.
- Purchase: a vendor tool brings its risks with it, so procurement should ask for the same kind of evidence expected from an internal build.
- Deploy: release needs a named approver who can say no, rather than a launch that happens because the pilot looked good.
- Monitor: a system that was acceptable at launch can drift, so someone must own the review of how it behaves in use.
A framework is therefore less a document than a set of agreed answers: who approves, who reviews, who can stop a system, and what evidence is kept. Without named owners, even a well-written policy leaves the pilot team improvising. Once owners exist, the next decision is which reference structure to organise their work around.
Choosing a starting reference
The most practical starting point is the NIST AI Risk Management Framework. According to Bradley’s overview of global AI governance frameworks, NIST released it in January 2023 and it is voluntary. It breaks AI management into four core functions: Govern, Map, Measure and Manage.
Each function answers a different organisational problem. Govern suits the ownership gap described above, because it concerns the policies, roles and culture that surround every other activity. Map is where a team records what a system is for and who it affects. Measure turns concerns into tests and ongoing monitoring. Manage covers acting on what those tests show, including the decision to change or retire a system.
Because the framework is voluntary, nothing forces adoption, which is both its weakness and its appeal. Teams can adopt it in part, starting with Govern and Map for a single system, and extend it as the practice matures. Treat it as the internal spine of a programme and let legal requirements set the minimum controls on top.
Separating principles from legal duties
A recurring mistake is treating every named framework as equally binding. The OECD principles are described as non-binding but influential, with a rights-based approach. They help set the values behind a policy, but they do not create obligations. Personal data is different: GDPR and CCPA set binding rules for how personal data enters an AI system. If a use case touches personal data, bring privacy counsel in before training or prompting begins rather than after the pilot.
| Reader problem | Instrument | What the evidence says | Planning use |
|---|---|---|---|
| Need a structure for internal AI risk work | NIST AI RMF | Voluntary guidance with the functions Govern, Map, Measure and Manage | Use as the organising spine for roles, reviews and records |
| Need shared values for responsible AI | OECD principles | Non-binding, rights-based approach | Use to shape policy language, not as a compliance checklist |
| Personal data will feed an AI system | GDPR and CCPA | Binding rules on how personal data enters an AI system | Involve legal and privacy teams before data is collected or used |
| A system may count as high-risk | High-risk non-compliance penalties | Up to 15 million euros or 3% of global annual turnover | Treat as a ceiling that tells you where to concentrate review |
Figures and descriptions in the table come from Bradley’s framework overview and Trinetix’s governance guide.
Penalty ceilings show how seriously the EU AI Act is meant to be taken. Superblocks reports that fines for prohibited practices reach €35 million or 7% of worldwide annual turnover, whichever is higher. These are ceilings, not predictions of what any organisation will pay. Their practical value is in ranking systems: the closer a use case sits to a prohibited or high-risk category, the earlier and more carefully it deserves review.
Explaining model decisions
Governance often stalls when a customer, auditor or colleague asks why a model produced a particular result. Trinetix lists feature importance scoring and local explanation techniques such as SHAP and LIME among the ways to make model behaviour understandable. Feature importance points to which inputs matter most across a model, while local methods look at the reasons behind an individual output.
Choose the technique by who is asking. A regulator, a customer challenging a decision and an internal reviewer need different depth, and a single method rarely suits all of them. Record which method was used and who reviewed the result, so the explanation can be repeated later rather than reconstructed from memory.
An explanation is evidence for a decision, not the decision itself. A technique can describe a model accurately and still reveal that the model should not be used for that purpose, and governance should give someone the authority to act on that finding.
Troubleshooting a framework that exists only on paper
Many programmes fail after the policy is written. These are the common symptoms and the fix that usually addresses each.
- The policy has no owner. If nobody can name who approves a deployment, assign an accountable role before refining the text. A policy without an approver is advice, not governance.
- Nobody knows which AI is in use. Teams adopt tools faster than central functions hear about them. Build a list of systems, built and bought, and treat it as a living record. An ai readiness assessment is a sensible way to check whether data, skills and processes can support the controls you are about to write.
- Legal review arrives after the pilot. Redesigning a working system is expensive and demoralising. Ask counsel which binding rules apply at the idea stage, particularly where personal data is involved.
- Controls stop at launch. If the Measure and Manage activities have no schedule or owner, monitoring quietly lapses. Put review dates and escalation routes in writing for every live system.
- The framework is too heavy for small projects. Scale the controls to the risk. A low-impact internal tool needs lighter checks than a system that influences decisions about people, and a proportionate approach keeps teams from working around the process.
Matching the approach to your situation
No single arrangement suits every organisation. The right first move depends on what you already have and what exposes you most.
- No AI policy yet: begin with the Govern and Map functions of the NIST framework. They create owners and an inventory, which every later control depends on.
- Personal data in scope: start with legal mapping of GDPR, CCPA and any other binding rules, then fit the NIST structure around those requirements.
- Mostly buying vendor tools: concentrate on purchase and monitoring. Ask suppliers for evidence of testing and explanation methods, and keep your own records of how each tool is used.
- Possible high-risk or prohibited uses: escalate these first. The penalty ceilings quoted above are a reason to give such systems senior review and documented sign-off before any wider rollout.
- Strong technical teams, weak process: add the governance roles and review dates rather than more tooling. Technical quality rarely fails first; unowned decisions do.
Frequently asked questions
Can an organisation be certified against the NIST AI RMF?
Show answer
No. Bradley’s overview describes it as guidance that is not subject to formal certification schemes, so it works as a structure for internal practice rather than a badge to display.
Is there NIST guidance specific to generative AI?
Show answer
Yes. Superblocks cites NIST’s Generative AI Profile, NIST AI 600-1, dated July 2024. Teams using generative tools can read it alongside the core framework.
Should a voluntary framework or legal review come first?
Show answer
Run them side by side. The voluntary NIST framework organises internal practice, while binding rules such as GDPR and CCPA set the minimum for personal data. Early counsel input avoids redesign later.
Who should own AI governance?
Show answer
Give it to a named role with authority to pause a deployment, supported by legal, security, data and business representatives. A committee that can only advise tends to leave decisions unowned.
