NIST AI Risk Management Framework (AI RMF): NIST AI Risk Management Framework – Tutorial (about 60 minutes)

The NIST AI Risk Management Framework (AI RMF) is a free, voluntary guide from the US National Institute of Standards and Technology (NIST) that helps organisations understand, assess and reduce the risks that artificial intelligence systems create for people, organisations and society. It is used by data scientists, engineers, product owners, risk, compliance and legal teams, auditors and executives, in every sector and far beyond the United States. After this tutorial you will be able to explain how the framework thinks about AI risk and trustworthiness, describe its four Core functions (Govern, Map, Measure and Manage), build simple Current and Target Profiles, and plan how to apply it to a real AI system alongside standards such as ISO/IEC 42001 and laws such as the EU AI Act.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The edition in force is Artificial Intelligence Risk Management Framework (AI RMF 1.0), published by NIST as document NIST AI 100-1 on 26 January 2023. It was developed in the open (a concept paper in December 2021, drafts in March and August 2022) under a mandate in the US National Artificial Intelligence Initiative Act of 2020. NIST maintains companion resources around it: the online AI RMF Playbook, a Roadmap, crosswalks to other documents and the Generative AI Profile (NIST AI 600-1, July 2024). NIST's AI RMF page states that version 1.0 is being revised as part of the White House AI Action Plan of July 2025, but as of the verification date no draft or new version has been published, so AI RMF 1.0 is the edition this course teaches. The framework itself says a formal review with community input is expected no later than 2028. In April 2026 NIST also released a concept note for an AI RMF Profile on trustworthy AI in critical infrastructure; that is a concept note, not a finished profile. Verified 2026-10-29.

Who this is for: engineers and data scientists who build or integrate AI models; product managers and architects who decide where AI is used; risk, compliance, privacy, security and internal audit professionals who are asked to "govern AI"; and managers who must explain to leadership, customers or regulators how their organisation keeps AI under control.

Prerequisites: none. A general idea of what machine learning does (a model learns patterns from data and then makes predictions or generates content) helps, as does basic familiarity with risk management. Every term is defined when it first appears.

By the end of this tutorial:

You will be able to explain why NIST created the AI RMF, what makes AI risk different from ordinary software risk and why the framework is voluntary and outcome-based.
You will be able to define the key vocabulary: AI actor, risk, impact, risk tolerance, residual risk, TEVV, context of use and Profile.
You will be able to name the seven characteristics of trustworthy AI and explain how they interact and trade off against each other.
You will be able to describe the four Core functions, what each one achieves and how they connect across the AI lifecycle.
You will be able to apply the framework to a real AI system using Current and Target Profiles and the Playbook.
You will be able to explain how alignment with the AI RMF is assessed when no certification scheme exists.
You will be able to position the AI RMF next to ISO/IEC 42001, ISO/IEC 23894, the EU AI Act and other NIST frameworks.

Lesson 1 – Origins, purpose and scope

Why a framework for AI risk?

Organisations have managed software risk for decades: they test code, patch vulnerabilities, control changes and recover from outages. AI systems bring all of those risks plus a new set that classic methods were not designed for. A machine learning model is not written line by line; it is trained on data, so its behaviour depends on how representative, accurate and current that data is. It can work well in testing and then degrade quietly when the world changes (this is called drift). It can produce outcomes that disadvantage some groups of people even though nobody intended it. It can be hard to explain why it produced a particular output. And it is often built from third-party parts – pre-trained models, public datasets, cloud APIs – whose inner workings the organisation using them cannot inspect.

These features matter because AI increasingly shapes decisions about loans, jobs, insurance claims and medical triage, at a scale and speed where damage can spread before anyone notices. Traditional software quality processes focus on the system working as specified, while many AI harms arise precisely when it works as specified but the data or the context of use is flawed.

The US Congress recognised this gap. The National Artificial Intelligence Initiative Act of 2020 directed NIST, the federal agency responsible for measurement science and technical standards, to develop a voluntary framework for managing AI risk. NIST did so through an unusually open process: a formal request for information, public workshops, a concept paper, two public drafts and many meetings with companies, researchers, civil-society groups and government bodies. The result, AI RMF 1.0, was released in January 2023.

What the framework is – and what it is not

NIST describes the AI RMF with four attributes worth remembering. It is voluntary: no law requires its use in general, although contracts, policies or sector rules may refer to it. It is rights-preserving: it aims to protect civil liberties and human rights while allowing beneficial uses of AI. It is non-sector-specific: banks, hospitals, manufacturers and public agencies can all use it. And it is use-case agnostic: it does not single out particular applications such as facial recognition or chatbots, but gives a method that can be applied to any of them.

Equally important is what the framework does not do. It is not a list of mandatory controls. It does not tell you how much risk is acceptable; each organisation decides that itself in light of laws, norms and its own priorities. It does not certify anyone. And it does not prescribe a single technique for testing fairness or robustness. Instead it describes outcomes – the results an organisation should achieve – and leaves the choice of methods to the people who know the context. This makes it flexible, but it also means that an organisation can only claim to have "used" the AI RMF meaningfully if it has made and documented real decisions.

Scope and audience

The framework is written for everyone who plays an active role in an AI system's life: those who design, develop, deploy, evaluate, buy, operate or use AI, plus those affected by it. NIST borrows the term AI actors from the Organisation for Economic Co-operation and Development (OECD) for this group. A small company that simply buys an AI-powered tool is in scope as much as a large lab that trains foundation models, because both make decisions that shape risk.

The framework also looks at risk broadly. It asks organisations to consider harm to individuals and groups (for example, discrimination or loss of privacy), harm to the organisation itself (for example, financial loss, disrupted operations or damaged reputation) and harm to wider ecosystems (for example, the financial system, supply chains or the natural environment). It also stresses that risk management is about enabling benefits, not only avoiding harm: a well-managed AI system is more likely to be trusted and used.

How the document is organised

AI RMF 1.0 is short – around 40 pages of main text – and has two parts. Part 1, "Foundational Information", explains how to frame AI risk, the challenges of managing it, who the audience is, and the characteristics of trustworthy AI. Part 2, "Core and Profiles", contains the four functions with their categories and subcategories and explains Profiles. Four appendices describe the tasks of different AI actors, how AI risks differ from traditional software risks, how human-AI interaction affects risk, and the design attributes NIST set for the framework. Around this document sits a family of companion resources hosted in NIST's Trustworthy and Responsible AI Resource Center (AIRC), launched in March 2023.

Figure 1 – The two parts and appendices of AI RMF 1.0 and the companion resources NIST maintains around it.

A useful way to read the framework is to treat Part 1 as the "why and what" (what kind of risk we are talking about and what good looks like) and Part 2 as the "how" (what outcomes an organisation should achieve to manage that risk). The Playbook then adds practical "how-to" suggestions for each outcome.

Lesson 2 – Key concepts and vocabulary

The AI RMF uses ordinary words in specific ways. Learning them precisely will make the rest of the framework much easier to read and will help you discuss AI risk consistently across technical and business teams.

AI system – an engineered or machine-based system that, for a given set of objectives, generates outputs such as predictions, recommendations, content or decisions that influence real or virtual environments. The framework adapts this definition from the OECD and ISO/IEC work.
AI actor – any person or organisation that plays an active role in the AI system lifecycle, including those that deploy or operate AI. Designers, data engineers, model developers, testers, deployers, operators, end users and even affected communities are all AI actors with different responsibilities.
Risk – a combination of how likely an event is and how large its consequences would be. The framework notes that consequences can be positive or negative, so risk management is also about seizing opportunities.
Impact and harm – an impact is any effect an AI system has; a harm is a negative impact on people, organisations or ecosystems. Harms may fall on people who never use the system directly, such as residents affected by a city's predictive model.
Risk tolerance – how much risk an organisation or AI actor is prepared to accept to achieve its objectives. The framework deliberately does not set tolerance; laws, sector rules and the organisation's own values do.
Residual risk – the risk that remains after treatment. The framework asks providers to document it so that deployers and end users understand what they are still exposed to.
Trustworthiness – the degree to which an AI system shows the seven characteristics described in Lesson 3 (validity, safety, security, accountability, explainability, privacy and fairness). It is not a yes-or-no property; it is a spectrum, and a system is only as trustworthy as its weakest characteristic.
Socio-technical system – a system whose behaviour depends on both technology and the people, organisations and society around it. The AI RMF insists that AI risk is socio-technical: you cannot judge it by looking at the model alone.
Context of use – the specific setting in which an AI system operates: its purpose, users, affected people, legal environment and operating conditions. The same model may be low risk in one context and high risk in another.
TEVV – test, evaluation, verification and validation: the set of activities used to check that an AI system works as intended and meets its requirements. NIST emphasises that TEVV happens throughout the lifecycle, not only before release.
Third-party risk – risk that comes from data, models, software or hardware supplied by others, including pre-trained models and cloud AI services. The organisation using them remains responsible for how they are used.
Profile – a tailored selection and implementation of the framework's functions, categories and subcategories for a particular setting, such as a hiring profile, or a description of the current or desired state of AI risk management.
Playbook – NIST's online companion that lists suggested actions, documentation prompts and references for each subcategory of the Core. Like the framework, it is voluntary and is not a checklist.

Three kinds of harm

Part 1 groups potential harms into three families. Harm to people covers individuals (for example, a wrongful denial of a benefit), groups and communities (for example, discrimination against a population) and society as a whole (for example, effects on democratic participation or access to education). Harm to an organisation covers its operations, security, finances and reputation. Harm to an ecosystem covers interconnected systems such as supply chains and financial markets, and natural resources and the environment. Thinking in these three families stops a team from focusing only on the most visible risk, which is usually the organisation's own.

Why AI risk is hard to manage

The framework is honest about the difficulties. Several challenges recur in practice:

Measurement is hard. There is no broad consensus yet on robust, verifiable metrics for many aspects of trustworthiness, and metrics can be gamed, oversimplified or blind to differences between groups. Not being able to measure a risk does not mean the risk is low – or high.
Risk changes over the lifecycle. A risk invisible at design time may appear once real users interact with the system, and risks found in a lab may look different in real-world operation.
Perspectives differ. A developer who publishes a pre-trained model sees risk differently from the company that deploys it for credit decisions; the deployer may not realise its specific use creates new risks.
Opacity complicates everything. When a system is hard to interpret, poorly documented or inherently uncertain, it becomes harder to tell whether it is fair, safe or accurate.
Comparing with humans is tricky. If AI replaces or supports a human decision, you need a baseline of human performance, but AI and humans often perform tasks differently.

Tolerance and prioritisation

Two further ideas shape every decision. First, trying to eliminate all risk is unrealistic and wastes resources; the goal is to recognise that not all AI risks are equal and to focus effort where potential impact is greatest. Systems that interact directly with people, use sensitive personal data or influence decisions about people generally deserve higher initial priority than, say, a model predicting machine vibration from sensor data – though even such systems can have downstream safety effects. Second, the framework is clear that when a system presents unacceptable risk – severe harm is occurring or imminent, or catastrophic risk is present – development or deployment should stop in a safe manner until the risk can be managed. This "stop" option is a key part of responsible AI governance and should be designed in from the beginning.

Finally, AI risk should not live in a silo. NIST recommends integrating it into enterprise risk management, so that AI risks sit alongside cybersecurity, privacy, safety and financial risks, are reported to the same leaders and are treated with comparable rigour.

Lesson 3 – Structure: trustworthiness, the Core and Profiles

The seven characteristics of trustworthy AI

Part 1 describes what "good" looks like through seven characteristics. They are not a checklist to tick independently; they influence each other, and improving one may weaken another. Here they are in plain language:

Valid and reliable – the system does what it is meant to do for its intended use (validity) and keeps doing so over time and under expected conditions (reliability). Accuracy and robustness (keeping performance in varied or unexpected conditions) feed into this. NIST treats it as the foundation: if a system does not work properly, nothing else about it can make it trustworthy.
Safe – under defined conditions the system does not lead to states that endanger human life, health, property or the environment. Safety is helped by careful design, clear instructions to deployers, simulation, monitoring and the ability to shut down or override the system.
Secure and resilient – the system protects confidentiality, integrity and availability against attacks such as data poisoning, adversarial inputs or model extraction (security), and can withstand or recover from unexpected events and degrade gracefully (resilience).
Accountable and transparent – appropriate information about the system and its outputs is available to the people who need it (transparency), and there are clear responsibilities for its outcomes (accountability). Transparency is often a precondition for people to obtain redress when something goes wrong.
Explainable and interpretable – people can understand how the system works (explainability) and what an output means in context (interpretability). A handy rule of thumb from the framework: transparency tells you what happened, explainability how, and interpretability why it matters for you.
Privacy-enhanced – the system respects norms that protect human autonomy, identity and dignity, for example through data minimisation, de-identification and privacy-enhancing technologies. AI can create new privacy risks by inferring sensitive facts that were never disclosed.
Fair – with harmful bias managed – the system addresses equality and equity concerns, including harmful bias and discrimination. Fairness is context- and culture-dependent, and balancing outcomes across demographic groups does not by itself make a system fair.

Figure 2 – Validity and reliability support every other characteristic, while accountability and transparency relate to all of them.

The framework's own figure shows validity and reliability as the base and accountability and transparency as a vertical bar touching all the others, which Figure 2 mirrors. Trade-offs are normal: making a model more interpretable may reduce accuracy; privacy techniques such as adding statistical noise can reduce accuracy for small groups, which in turn affects fairness. The framework does not resolve these tensions for you. It asks you to make the trade-off explicitly, in light of the context and values at stake, and to record a justification that others can examine.

On fairness, NIST points to three broad categories of bias drawn from its Special Publication 1270. Systemic bias lives in datasets, institutional practices and society. Computational and statistical bias arises from non-representative samples and algorithmic processes. Human-cognitive bias affects how people perceive and act on AI outputs – for example, over-trusting a confident recommendation. Each can occur without anyone intending to discriminate, which is why proactive measurement matters.

The Core: four functions

Part 2 organises risk management outcomes into four functions. Each function is divided into categories (broad outcome groups) and subcategories (specific outcomes), labelled with identifiers such as GOVERN 1.1 or MAP 2.3 so that teams can refer to them precisely. AI RMF 1.0 has 19 categories and 72 subcategories in total.

Function	Purpose in one sentence	Categories	Subcategories
GOVERN	Build the culture, policies, roles and oversight that make AI risk management possible across the organisation.	6	19
MAP	Understand the context of a specific AI system and identify its risks, benefits and impacts.	5	18
MEASURE	Analyse, test, benchmark and monitor the identified risks with suitable methods and metrics.	4	22
MANAGE	Prioritise risks and act on them: treat, accept, transfer or avoid, and respond to incidents.	4	13

GOVERN

GOVERN is cross-cutting: it applies to all stages and informs the other three functions. Its six categories cover, in paraphrase: policies, processes and practices for mapping, measuring and managing AI risk that are transparent and implemented effectively; accountability structures so that the right people are responsible, empowered and trained; workforce diversity, equity, inclusion and accessibility in AI risk work, so that a range of perspectives is brought to bear; a culture that thinks critically about AI risk and communicates it; processes for engaging with relevant AI actors, including people outside the team; and policies for risks from third-party software, data and supply chains. Senior leadership sets the tone here, including the organisation's risk tolerance.

Note on the revision: the AI Action Plan asked NIST to remove references to diversity, equity and inclusion, misinformation and climate change from the framework. When a revised version appears, the wording of some categories – particularly the third GOVERN category – may change. The underlying idea of bringing varied expertise to risk work is likely to remain useful whatever the wording.

MAP

MAP establishes the context for a particular AI system. Its five categories ask the organisation to establish and understand the context (purpose, users, laws, expectations); categorise the system (its tasks, methods and knowledge limits); understand capabilities, intended use, goals, and expected benefits and costs compared with suitable benchmarks; map risks and benefits for every component, including third-party ones; and characterise impacts on individuals, groups, communities, organisations and society. MAP ends with enough knowledge to make an initial go/no-go decision: should we design, build or deploy this system at all?

MEASURE

MEASURE turns mapped risks into evidence. Its four categories cover identifying and applying appropriate methods and metrics; evaluating the system against the trustworthiness characteristics; having mechanisms to track identified risks over time; and gathering feedback on whether the measurement itself is working. Measurement can be quantitative, qualitative or mixed. NIST encourages independent review to reduce internal bias and conflicts of interest, and testing both before deployment and regularly during operation.

MANAGE

MANAGE allocates resources to the mapped and measured risks. Its four categories cover prioritising and responding to risks based on what MAP and MEASURE found; planning strategies to maximise benefits and minimise negative impacts (including the ability to disengage or deactivate a system that behaves unacceptably); managing risks and benefits from third-party resources; and documenting and monitoring risk treatments, including response, recovery and communication when incidents happen.

The functions are not a strict sequence. Once governance is in place, NIST notes that most users start with MAP and continue to MEASURE or MANAGE, but they can be performed in any order and repeated as needed. In practice the loop never ends while the system is in use: new data, new users or new regulations send you back to MAP.

Profiles

The framework describes three kinds of Profile. A use-case profile applies the functions to a specific setting, such as hiring or fair housing. Temporal profiles describe either the current state of AI risk management (Current Profile) or the desired state (Target Profile); comparing the two reveals gaps that can be prioritised into an action plan. A cross-sectoral profile covers risks that appear in many sectors, such as the use of large language models or cloud services – the Generative AI Profile is an example. NIST deliberately does not prescribe a profile template. Note also a difference from the NIST Cybersecurity Framework: the AI RMF has no Implementation Tiers, so it does not rate maturity on a numbered scale.

Lesson 4 – How it works in practice

The AI lifecycle and its actors

To apply the Core, you need a shared picture of the lifecycle. The AI RMF adapts the OECD framework for classifying AI systems. It describes key dimensions – application context, data and input, AI model, and task and output – surrounded by lifecycle stages, with "people and planet" at the centre to represent human rights and the well-being of society and the environment. Each stage involves different AI actors, and NIST highlights that TEVV tasks should be woven through all of them.

Figure 4 – Lifecycle stages adapted from the OECD model: risk work starts at planning and continues through operation, with TEVV throughout.

Typical actors include system owners and product managers (plan and design), data engineers and data stewards (data), data scientists and model developers (build), independent testers, model risk teams and auditors (verify and validate), system integrators and deployers (deploy), operators and support staff (operate and monitor), and end users and affected individuals and communities. People outside the organisation – researchers, advocacy groups, standards bodies, trade associations – form a further audience that provides context, norms and boundaries for acceptable use. A key practical lesson is that each of these actors sees only part of the picture, so risk information must flow between them.

Implementation steps

The framework does not mandate a procedure, but organisations that use it successfully tend to follow a similar path:

Secure leadership commitment. Name an executive owner for AI risk, agree the scope (all AI, or a first set of systems) and decide how AI risk feeds into enterprise risk reporting.
Build an AI inventory. You cannot govern what you do not know about. List AI systems in use and in development, including AI features inside purchased software, with owners, purposes and data sources.
Set governance foundations (GOVERN). Write an AI policy, define roles (for example, system owner, model validator, AI risk committee), set risk tolerance and criteria for "high-impact" systems, train staff and add AI clauses to procurement.
Triage systems by risk. Use simple criteria – does it affect decisions about people, use sensitive data, operate autonomously, touch safety? – to decide how deep each system's assessment must go.
Map each priority system (MAP). Document purpose, context, users, affected groups, legal requirements, benefits, known limitations, third-party components and potential impacts. Make the initial go/no-go decision.
Measure (MEASURE). Choose metrics for the relevant trustworthiness characteristics, test before release with realistic data, arrange independent review proportionate to risk, and set up monitoring.
Manage (MANAGE). Decide treatments, document residual risk and who accepted it, prepare incident response and deactivation procedures, and manage vendor risks.
Build Profiles and improve. Record the Current Profile, define the Target Profile, close gaps through an action plan, and review periodically.

Using the Playbook

The Playbook is where many practitioners spend most of their time. For each subcategory it offers a short explanation, suggested actions, questions about transparency and documentation, and references to further resources. Teams should select from it, not try to do everything: NIST states plainly that users may choose among categories and subcategories based on their resources and needs. A sensible approach is to pick the subcategories most relevant to your highest risks, adapt the suggested actions into your own procedures, and record which ones you chose and why.

Typical artefacts

Because the framework is outcome-based, evidence matters. Common artefacts include an AI policy, an AI system inventory, impact assessments, model and dataset documentation (model cards, datasheets), TEVV reports with segmented metrics, records of go/no-go decisions and risk acceptance, monitoring thresholds, incident logs, vendor due-diligence records and Profiles. None is mandated by name.

Roles and culture

Tools alone do not change outcomes: accountability, incentives and culture must support risk management, and senior leaders must visibly back it. Multidisciplinary teams surface assumptions that homogeneous teams miss. A small start-up may combine several roles in one person but still needs clear ownership, documented decisions and a way to stop a harmful system.

Human-AI interaction

Appendix C draws attention to the human side. Human oversight only works when people have the time, information, authority and training to disagree with the system; otherwise they over-rely on its outputs (automation bias). Roles in human-AI configurations should be defined, and their effects evaluated rather than assumed.

Lesson 5 – Assessment, certification and compliance

There is no AI RMF certificate

The AI RMF is not a certifiable standard. NIST does not certify organisations, does not accredit auditors to the framework and does not maintain a register of "compliant" companies. Any badge or certificate claiming "NIST AI RMF certified" is a private product, not an official status. Organisations can say that their AI risk management is aligned with or informed by the AI RMF, and back that statement with evidence. If an organisation needs third-party certification of its AI governance, the usual route is a management system standard such as ISO/IEC 42001, certified by accredited certification bodies; the AI RMF can feed the risk work inside such a system.

How alignment is evaluated

Without a formal scheme, assessment relies on established assurance practice:

Self-assessment – teams compare their practices with the subcategories and record a Current Profile, often scoring each outcome as not addressed, partly addressed or achieved, using the organisation's own scale.
Gap analysis – the Current Profile is compared with a Target Profile chosen for the organisation's risk tolerance and obligations; gaps are prioritised by risk.
Internal audit – an independent internal function tests whether documented processes are actually followed, for example by sampling AI systems and checking their impact assessments, test reports and approvals.
Independent review of systems – the framework encourages independent evaluation of AI systems to counter internal bias and conflicts of interest; for high-impact systems this may involve separate model validation teams or external experts.
External assurance – customers, investors or boards may ask an outside firm to review alignment. Such reports are agreed between the parties; their scope and method should be stated clearly.

Evaluating the framework's effectiveness

NIST also asks users to judge periodically whether using the framework has actually improved their ability to manage AI risk – by looking at policies, processes, indicators and outcomes – and plans to develop shared methods for evaluating its effectiveness with the community. Expected benefits include clearer go/no-go decisions, better documentation, stronger accountability, better information sharing and greater TEVV capacity. If a programme produces documents but no better decisions, it is not achieving the framework's purpose.

Where the framework meets law and contracts

Although voluntary, the AI RMF often appears in regulatory and commercial contexts. Government policies, procurement requirements, sector guidance and some legislation in various jurisdictions refer to it as a recognised approach to AI risk, and large buyers increasingly ask suppliers to describe how their AI governance aligns with it. Using the framework does not by itself make you compliant with any law: obligations such as those under the EU AI Act or data protection law must be identified separately (MAP helps) and met in full. But a well-documented programme makes it much easier to demonstrate due care, because it shows how risks were identified, measured and managed.

What good evidence looks like

Assessors look for traceability – from policy, to the risk criteria applied to a system, to the tests, results, decision and decision-maker – plus currency (updated after material changes), proportionality and closure of actions. Generic policies with no system-level evidence are a warning sign, as is a perfect score on every subcategory.

Lesson 6 – Worked example: an insurer adopts the AI RMF

Harbourline Insurance is a fictional mid-sized insurer with around 3,000 employees. It plans to deploy a claims triage model bought from a vendor. The model scores each new motor claim: low scores are fast-tracked for payment, high scores are sent to the special investigations unit as possible fraud. The business case is strong – faster payment for honest customers and better use of investigators – but the board has asked for assurance that the system will be managed responsibly. The chief risk officer decides to use the AI RMF.

Step 1 – GOVERN: set the foundations

Harbourline already has an enterprise risk framework, so it extends it rather than creating a parallel structure. The board approves a short AI policy that defines what counts as an AI system, requires an inventory, and sets criteria for "high-impact" AI: any system that influences decisions about customers' money, access or treatment. An AI risk committee is formed with members from claims, data science, legal, compliance, privacy, IT security and customer experience. The claims director is named as system owner for the triage model; the model risk team, which reports separately from the data science team, is named as independent validator. Procurement adds AI clauses to vendor contracts: documentation of training data and testing, notification of model changes, cooperation in incident investigations, and audit rights. The risk appetite statement says that Harbourline will not accept automated decisions that deny or reduce a claim without human review.

Step 2 – MAP: understand the context

The team documents the system's purpose (prioritising claims for payment or investigation, not deciding outcomes), its users (claims handlers and investigators) and the people affected (claimants, including vulnerable customers). It notes legal requirements: insurance conduct rules, anti-discrimination law and data protection law. It records the expected benefits – an estimated reduction in average payment time – and the costs of errors. Two kinds of error matter: a false positive sends an honest customer into a fraud investigation, delaying payment and causing distress; a false negative lets a fraudulent claim through.

The mapping workshop, which includes two customer advocates, identifies several risks. The vendor trained the model on data from other insurers, whose customer mix differs from Harbourline's. Some input features, such as postcode and vehicle age, may act as proxies for income or ethnicity, creating a risk of unfair outcomes. Investigators may over-trust a high score. And the vendor can update the model, changing its behaviour without warning. The team also asks a basic question: is AI necessary? It concludes that the benefits justify proceeding, but only with the model in an advisory role. That is the go/no-go decision, recorded with the committee's approval.

Step 3 – MEASURE: gather evidence

The model risk team designs a test plan. It runs the model on two years of Harbourline's historical claims with known outcomes and measures precision and recall overall and for segments: regions, age bands, vehicle types and, where lawful and available, protected characteristics through a privacy-protective analysis. It finds that false-positive rates are almost twice as high in two postcode areas with lower average incomes. It tests robustness by simulating seasonal changes and a new claim channel. It checks whether the vendor's explanations of each score are understandable to investigators by running sessions with five of them. It also reviews security: who can access the scoring API, and whether claim data could be extracted through it. Metrics and thresholds for ongoing monitoring are agreed: weekly false-positive rate by segment, score distribution drift and investigator override rates.

Step 4 – MANAGE: decide and act

The committee prioritises the false-positive disparity as the highest risk because it directly harms customers. Treatments are agreed: the vendor removes one proxy feature and recalibrates; a higher threshold is used for referral in the affected segments until the gap falls below an agreed level; every referral must be reviewed by a human investigator who sees the main factors behind the score; and customers whose claims are delayed receive a clear explanation and a route to complain. Residual risk is documented and formally accepted by the claims director within the board's tolerance. An incident procedure defines what happens if monitoring breaches a threshold, including switching the model off and reverting to manual triage, which the team rehearses before go-live. The vendor contract is updated to require advance notice and joint testing for model changes.

Figure 5 – How Harbourline moved one AI system through the functions, from governance to monitored operation with a route back to mapping.

Step 5 – Profiles and improvement

After the first system, the AI risk committee builds a Current Profile for the whole organisation. It shows strong results in a few areas (independent validation, incident procedures for this one system) but gaps elsewhere: the AI inventory is incomplete because AI features inside purchased software were missed; there is no training for staff who use AI tools; and there is no process for gathering feedback from affected customers. The Target Profile, set for the next 12 months, focuses on GOVERN outcomes (inventory, training, third-party policy) and on extending MAP and MEASURE to the other two high-impact systems found by the inventory: a customer-service chatbot built on a generative AI service and a pricing model. For the chatbot, the team adds suggested actions from the Generative AI Profile, such as testing for confabulated answers about policy terms. Six months after go-live, monitoring shows the false-positive gap has narrowed and investigator overrides have stabilised; the committee reviews the results, updates the profile and reports to the board.

What the example shows

Harbourline did not attempt all 72 subcategories at once. It used GOVERN to make decisions possible, went deep on its highest-risk system, documented trade-offs and residual risk, integrated AI risk with existing processes and used Profiles to plan the next steps – proportionate, continuous risk management.

Lesson 7 – Relationship to other standards and frameworks

The AI RMF is one of several instruments that organisations combine. It is most useful to understand where it overlaps with others and where each has a distinct job: some are voluntary guidance, some are certifiable management system standards, and some are binding law.

Instrument	Type and owner	Focus	How it relates to the AI RMF
ISO/IEC 42001:2023	International management system standard (ISO/IEC), certifiable	Requirements for an AI management system: policy, roles, risk and impact assessment, controls, internal audit, improvement	Provides the certifiable management "container"; the AI RMF can supply detailed risk outcomes and practices. NIST's AI Resource Center hosts a crosswalk between them, contributed by Microsoft.
ISO/IEC 23894:2023	International guidance standard (ISO/IEC)	Applying ISO 31000 risk management principles and processes to AI	Similar purpose; both are guidance. Organisations aligned with ISO 31000 may find 23894 familiar and use the AI RMF for its trustworthiness model and Playbook.
EU AI Act (Regulation (EU) 2024/1689)	Binding EU law	Risk-based obligations for providers and deployers, with stricter rules for high-risk systems and bans on some practices	Legal obligations must be met in full; AI RMF practices (mapping, testing, documentation, monitoring) can help produce the evidence but do not equal compliance.
NIST AI 600-1 Generative AI Profile	NIST cross-sectoral profile of the AI RMF	Risks unique to or made worse by generative AI, with suggested actions organised by the four functions	A companion that applies the AI RMF to generative AI; used together with it, not instead of it.
NIST Cybersecurity Framework 2.0	Voluntary NIST framework	Cybersecurity risk outcomes in six functions, with Profiles and Tiers	Supports the "secure and resilient" characteristic; shares the Core-and-Profile design but uses different functions and has Tiers.
NIST Privacy Framework	Voluntary NIST framework	Privacy risk from data processing	Supports the "privacy-enhanced" characteristic; useful for AI systems that process personal data.
OECD AI Principles	Intergovernmental principles (OECD)	High-level values for trustworthy AI adopted by many governments	The AI RMF borrows OECD definitions and lifecycle model and turns principles into practical outcomes.

Combining them

A common pattern in multinational organisations is to build an AI management system aligned with ISO/IEC 42001 (and possibly certified), use the AI RMF and its Playbook for the detailed risk work inside it, apply the Generative AI Profile to generative AI systems, and map legal obligations such as the EU AI Act onto the same controls so that one set of evidence serves several purposes. Security and privacy teams continue to use the Cybersecurity Framework and Privacy Framework for their domains, with AI-specific risks added. The organisations that struggle are those that run each framework as a separate project with separate documents and owners.

Key differences to keep in mind

The AI RMF is outcome-based guidance with no certification and no maturity tiers, intended for global use. ISO/IEC 42001 contains auditable "shall" requirements. The EU AI Act imposes legal duties whose obligations phase in over several years, so check the current timetable. These differences explain why "we follow the AI RMF" is a good start but rarely the whole answer.

Common pitfalls and best practices

Pitfalls

Treating the Core as a checklist and trying to "complete" all 72 subcategories, producing paperwork instead of better decisions.
Assessing only the model in isolation and ignoring the socio-technical context: who uses the output, how much they trust it and who is affected.
Skipping the go/no-go question and assuming that an AI solution will be built; MAP should be able to conclude that AI is not appropriate.
Relying on a vendor's assurances without testing third-party models on your own data and context.
Measuring overall accuracy only, which hides poor performance for particular groups or conditions.
Doing a one-time assessment at launch and never monitoring for drift, misuse or changing context.
Claiming "NIST AI RMF certification", which does not exist, or equating framework alignment with legal compliance.
Running AI risk in a silo, separate from enterprise, security and privacy risk management.

Best practices

Start with GOVERN: an inventory, an owner for each system, a policy and an explicit risk tolerance.
Triage systems and apply effort in proportion to potential impact, going deepest on systems that affect people's rights, safety or money.
Involve diverse expertise and, for high-impact systems, the perspectives of affected people early, during MAP.
Break down test results by relevant segments and conditions, and use independent review for high-impact systems.
Design human oversight that works: reviewers with time, information and authority to override.
Document trade-offs, residual risk and who accepted it, so that decisions are traceable.
Build and rehearse a way to pause or switch off a system, with a fallback process.
Use Current and Target Profiles to plan improvement, and revisit them after incidents, model changes or new regulations.

Summary and key takeaways

The NIST AI RMF 1.0 (NIST AI 100-1, January 2023) is a voluntary, rights-preserving, non-sector-specific and use-case agnostic framework for managing AI risk; a revision has been announced but no new version had been published as of October 2026.
AI risk is socio-technical: it depends on data, models, people and context, and harms can affect individuals, organisations and wider ecosystems.
Seven characteristics describe trustworthy AI, with validity and reliability as the base and accountability and transparency relating to all; trade-offs between them must be made explicitly.
The Core has four functions – GOVERN (cross-cutting), MAP, MEASURE and MANAGE – with 19 categories and 72 subcategories, applied iteratively rather than as a checklist.
Profiles tailor the framework to a use case or sector and compare a Current with a Target state; there are no Implementation Tiers.
The Playbook offers suggested actions for each subcategory; organisations select what fits their risks and resources.
There is no certification; alignment is shown through evidence, self-assessment, internal audit and independent review, and certifiable assurance comes from standards such as ISO/IEC 42001.
The AI RMF works best combined with ISO/IEC 42001, the Generative AI Profile, NIST's security and privacy frameworks and the laws that apply to you.

Reflection questions

Pick an AI system your organisation uses or plans to use. Who are its AI actors across the lifecycle, and which of them currently have no visibility of its risks?
For the same system, which two trustworthiness characteristics are most likely to conflict, and how would you document the trade-off you choose?
What criteria would you use to decide that an AI system is "high impact" and needs the deepest MAP and MEASURE work?
If a vendor refuses to share information about how its model was trained and tested, what would you do under GOVERN, MAP and MANAGE?
Draft three outcomes you would put in a Target Profile for your organisation for the next year, and explain why each closes an important gap.