Governance
AI Risk Management Framework (NIST AI RMF)
A four-function structure, Govern, Map, Measure, Manage, for boards and leadership teams to build AI oversight into existing governance rather than bolting it on as a technical afterthought.
Also known as NIST AI RMF, AI RMF 1.0, AI governance framework. First set out by U.S. National Institute of Standards and Technology (NIST) in 2023; the primary source is cited in full below.
Where this is contested
AI RMF is one of several credible reference points now in play, alongside ISO/IEC 42001, which is certifiable, and the EU AI Act, which is binding law in its jurisdiction. Unlike a long-settled framework, there isn't yet a single agreed standard for AI governance, and which one, or which combination, an organisation should anchor to is itself a live, unresolved question rather than a solved one.
- Format
- Structural model
- Level
- Corporate · Business unit
- Best for
- Assess risk · Plan execution
- Decision stage
- Diagnose · Plan · Execute · Review
- Difficulty
- Intermediate
- Time to apply
- An initial pass, setting up Govern and mapping your top two or three AI use cases, realistically takes a few weeks of leadership time, not a single meeting. Ongoing governance is then a standing quarterly commitment.
Plate · The model
The components
Govern
NIST describes Govern as a cross-cutting function that is infused throughout the other three, not a fourth sequential step tacked on at the end. It is the organisational plumbing: named accountability for AI risk decisions, a clear policy on acceptable use, and a route for AI risk to reach existing governance bodies, the audit committee, the risk committee, the board, rather than sitting quietly inside IT.
Signals of strength
A named individual or committee can be pointed to when someone asks who signed off on this AI use · AI risk appears as a standing item in existing governance reporting, not just when something has already gone wrong · Staff can find and understand an actual written policy on acceptable AI use, not just an intranet mention · Third-party and vendor AI tools get the same scrutiny as anything built in-house
Map
Builds a working understanding of a specific AI system or use case before anyone tries to judge it: what it's actually for, who it touches, what data feeds it, and what could plausibly go wrong for individuals or the business. NIST treats this as the context-setting function everything else depends on.
Signals of strength
Someone in the room can explain, in plain English, what the tool does without reaching for a vendor brochure · The people affected by the tool, staff, customers, candidates, are identified by name or group, not left as an abstraction · A short, specific list of what could go wrong exists for this use case, not a generic AI risk list copied from elsewhere · Data sources and known limitations of the tool are written down somewhere leadership can actually see them
Measure
Puts a defined check, quantitative or qualitative, against the risks surfaced in Map. NIST is explicit this doesn't require sophisticated technical testing, sampling and structured review count, but it does mean deciding in advance how you'll know a risk is materialising, rather than waiting for a complaint to arrive.
Signals of strength
At least one concrete metric or review process exists for each material risk identified, not just an intention to keep an eye on it · Someone actually reviews the measurement on a set schedule and can show evidence of having done so · Findings feed back into a decision, continue, adjust, or stop, rather than being filed and forgotten · Outcomes are broken down by relevant group where it matters, so an uneven impact isn't hidden inside a comfortable average
Manage
Turns mapped and measured risk into resourced action: what gets fixed, what gets monitored, what gets escalated, and what the organisation decides it simply won't tolerate. Includes the practical machinery for when something does go wrong, incident response, communication, recovery.
Signals of strength
Risks are prioritised, not just listed; leadership can name the two or three that matter most right now · There's an agreed answer to what happens if this AI tool gets something badly wrong in public, worked out before it happens · Budget or people-time has actually been allocated to the top risks, not just goodwill · A route exists for a member of staff or a customer to challenge an AI-influenced decision and get a human response
When it earns its keep
- A leadership team or board is about to approve, or has already approved, the organisation's first meaningful use of AI tools and wants a structured way to think through the oversight questions before rollout, not after something goes wrong.
- You need a shared vocabulary to bring legal, HR, IT, and operational leads into one AI governance conversation, rather than each function inventing its own ad hoc checklist.
- An organisation is drafting or refreshing an internal AI use policy, for staff use of generative AI tools, or for a vendor-supplied AI tool embedded in a core business process, and wants a recognised external reference point rather than a bespoke one-off.
- A board wants to be able to show a client, insurer, or regulator that AI-related risk is being managed through a recognised structure, rather than left to individual managers' judgement.
And when it doesn't
- An organisation with a formal legal or regulatory AI compliance obligation, for example under the EU AI Act, needs specific legal advice. This is a voluntary leadership framework, not a compliance substitute.
- You need a certifiable management system with an external audit trail. That is ISO/IEC 42001, not this; NIST AI RMF has no certification scheme attached to it.
- The organisation isn't using AI in any material way and has no near-term plan to. Applying a full governance framework to a hypothetical risk is process for its own sake.
- You want a ready-made, fill-in-the-boxes checklist you can hand to a junior manager and walk away from. The framework is deliberately open-ended and still needs senior judgement to turn into concrete controls.
How to run it
Before starting, gather the inputs the analysis depends on:
- A named senior owner, or small group, accountable for AI governance decisions, ideally with a genuine seat at the leadership table rather than a delegated IT sign-off
- A working inventory, even a rough one, of where AI is already used or being considered across the organisation, including vendor-supplied tools with AI embedded in them
- Access to someone who can explain, in plain terms, what a given AI tool actually does, what data feeds it, and what its known limitations are, so the leadership discussion isn't running on marketing claims
- Standing time on a leadership or board agenda, not a single meeting; this is meant to be an ongoing item, not a one-off exercise with a completion date
- 1
Establish Govern first
Before mapping any specific tool, agree who owns AI risk decisions, what 'acceptable use' means for your organisation, and how AI risk will be reported into existing governance, the risk committee, the audit committee, the board, whichever already exists. Do this before the first tool goes live, not retrospectively.
- 2
Map the specific use case
For each AI tool or use in scope, document in plain language what it does, who it affects, what data it touches, and what could plausibly go wrong. Name the affected people or groups specifically rather than describing risk in the abstract.
- 3
Measure what actually matters
For each risk identified in Map, decide how you will know if it's happening: an error rate, a complaint count, a sample audit, whatever is proportionate to the stakes. Don't settle for a one-off assurance from the vendor as your only evidence.
- 4
Manage and prioritise
Allocate real resource to the risks that matter most. Decide explicitly what you'll tolerate, what you'll mitigate, and what's a hard no. A short list of genuinely implemented controls beats a long list of intentions.
- 5
Loop back through Govern on a set cycle
Revisit at a defined interval, quarterly for anything client-facing or high-stakes, and treat the whole thing as a cycle rather than a project with an end date. AI tools, and the risks they carry, change faster than most governance calendars assume.
Reading the result
Not a certificate or a score. A working governance structure: a named owner, a live inventory of AI use and its risks, a defined set of things you're actually measuring, and a prioritised, resourced response, plus a paper trail showing the board took this on directly rather than delegating it silently to IT.
- An empty entry, no owner named, no metric tracked, is itself a finding; don't wait for a formal gap analysis to tell you what's obviously missing
- The four functions are meant to be revisited together on a cycle, not worked through once and filed away
- Depth should be proportionate to stakes: a low-impact internal tool needs a lighter touch than one screening job candidates or advising clients directly
- Treat early Govern outputs, the named owner, the written policy, as the precondition for the rest; weak Govern work tends to produce weak, invisible Map, Measure and Manage work downstream
A worked example
Hallcroft Associates: AI-assisted CV screening at a mid-size recruitment agency
Hallcroft Associates is a 140-person recruitment agency in Leeds, specialising in finance and professional services placements. Its largest client, a regional bank, has asked Hallcroft to handle the volume for its graduate scheme this year, several thousand applications for around 40 roles. Hallcroft's ops director has found an AI-powered CV screening and ranking tool from a well-regarded HR technology vendor, competitively priced, promising to cut screening time from weeks to days. The leadership team, the managing director, the ops director, and the head of compliance, is meeting to decide whether to adopt it before the graduate scheme opens in September. Nobody on the leadership team has direct AI expertise, and the vendor's sales material is confident but light on detail about how the ranking actually works underneath.
- Govern
- The head of compliance, not the ops director championing the tool, is named as accountable owner for the decision, and reports to the MD before go-live rather than after. Hallcroft drafts a one-page acceptable-use position: the tool ranks and shortlists, a human recruiter makes every reject decision, and any application can be manually reviewed on request. This becomes an actual written policy, not a verbal understanding between two directors.
- Map
- The team presses the vendor for a plain-English explanation of what the tool screens on and gets a useful answer: it's trained substantially on historic 'successful hire' data pooled from other clients. Hallcroft flags the obvious risk directly, if past successful hires elsewhere skew towards certain universities or backgrounds, the tool could learn to reproduce that pattern, which is an Equality Act 2010 indirect discrimination risk, not just a reputational one. The affected group is named specifically: graduate applicants, particularly those from non-target universities.
- Measure
- Before go-live, Hallcroft insists on trialling the tool against 300 real, anonymised historic applications with known outcomes, and asks the vendor for the demographic breakdown of who it would have shortlisted versus who human recruiters actually shortlisted. Compliance sets a threshold in advance: if the shortlist rate for any protected characteristic group drops materially against the human baseline, the tool doesn't go live as configured. Ongoing, 5% of the tool's rejections get sampled for human review each month.
- Manage
- The trial flags a meaningful skew against one tier of universities that correlates with a wider socioeconomic pattern. Rather than abandoning the tool outright, the client deadline is real and the volume genuinely can't be handled manually in time, leadership decides to run it as a first-pass volume filter only on the bottom third of applications by score, with every borderline case routed to human review, and commits to re-running the fairness check quarterly. They also agree, in writing, what would make them pull the tool entirely: any complaint escalating to a discrimination claim, or a repeat fairness-check failure.
The read. The framework didn't tell Hallcroft whether to buy the tool. It forced the conversation that made the eventual decision defensible: someone senior owned it, the specific risk was named rather than assumed away, it was tested against real data before rollout instead of taken on trust, and there's a clear written trigger for walking away. That's a materially stronger position than the ops director simply liking the demo, but it cost a full leadership meeting and an unbudgeted trial run. The framework doesn't do that work for you, it just makes it harder to skip.
Pitfalls
- Treating Govern as a one-off sign-off rather than an ongoing thread running through Map, Measure and Manage; a policy written once and never revisited is theatre, not governance.
- Skipping straight to a generic AI risk checklist instead of doing Map properly; a risk register copied from elsewhere misses the specific way a given tool touches your specific people and business.
- Accepting a vendor's fairness or accuracy claims at face value instead of insisting on your own trial against your own data; vendors have every incentive to present a tool favourably.
- Applying the full four-function weight to every AI use regardless of stakes; over-applying it to low-risk internal tools burns credibility and attention for when it genuinely matters.
- Assuming this framework, on its own, satisfies a specific legal obligation, UK GDPR or Equality Act considerations, or the EU AI Act where it applies. It's a governance scaffold, not legal sign-off.
What the critics say
As a voluntary, principles-based framework with no certification or enforcement mechanism attached, AI RMF relies entirely on organisations choosing to apply it seriously. Critics contrast this with a binding regime like the EU AI Act, which carries statutory penalties for non-compliance, and argue a framework with no teeth risks becoming a box to tick rather than a genuine control.
a recurring theme in comparative AI governance commentary, e.g. Trustible and Modulos, contrasting NIST AI RMF's voluntary status with the EU AI Act's binding obligations
AI RMF now sits alongside ISO/IEC 42001, a certifiable management-system standard, and the EU AI Act, binding law in its jurisdiction. Organisations operating across borders increasingly report duplicated effort or confusion trying to satisfy several overlapping AI governance regimes at once, rather than converging on one settled standard.
reflected in comparative guides mapping NIST AI RMF against ISO 42001 and the EU AI Act published by AI governance advisory firms
Built with substantial input from large, technically sophisticated organisations and federal agencies, the framework's full scope can read as disproportionate for a small or mid-size business with no dedicated risk or compliance function; some practitioners question whether smaller organisations need the whole structure or just its underlying discipline.
a recurring theme in small-business-oriented commentary on AI RMF adoption
Sources and further reading
- NIST, 'Artificial Intelligence Risk Management Framework (AI RMF 1.0)', NIST AI 100-1, January 2023 ↗
- NIST, 'Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile', NIST AI 600-1, July 2024 ↗
- NIST AI Risk Management Framework Playbook, NIST AI Resource Center ↗
- ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system ↗