The AI Risk Management Framework, mapped for the classroom.
A voluntary, non-sector-specific framework for identifying, measuring, and responding to the risks of designing, developing, deploying, and using AI systems — built around four functions and seven characteristics of trustworthy AI.
Govern is the outer, always-on function. Map → Measure → Manage form the inner, iterative cycle applied to a given AI system, use case, or lifecycle stage.
Purpose & Origin
Why the framework exists, who it's for, and what problem it's solving.
What it is
The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, consensus-driven framework, published by the U.S. National Institute of Standards and Technology in January 2023, that gives organizations a common vocabulary and structured process for managing risks introduced by AI systems — across their entire lifecycle, from design through decommissioning.
Why it was created
AI systems introduce risks that traditional software risk management wasn't built for: statistical and data-driven uncertainty, opacity in how models reach conclusions, third-party and supply-chain dependencies (pretrained models, datasets, APIs), and impacts that are harder to test for and can surface long after deployment. The framework was directed by the National AI Initiative Act of 2020 and built with broad public and private-sector input.
Who it's for
Any organization designing, developing, deploying, evaluating, or procuring AI systems — regardless of sector, size, or stage of AI adoption. It is intentionally sector- and use-case-agnostic, meant to be adapted rather than applied as a fixed checklist.
What it is not
It is not a compliance checklist, not a certification standard, and not a technical standard for any specific AI technique. It does not assign legal liability or define a pass/fail test. It's a flexible process for reasoning about risk, meant to be tailored to context.
How to Use This Guide
This tool is built for a course session, not a policy office. Suggested path through the material:
- Read the seven characteristics first. Before the functions make sense, you need the target: what does "trustworthy" actually mean here? Start at the Characteristics section below.
- Walk the ring, not a checklist. Govern, Map, Measure, Manage are not steps 1–4 you complete once. Govern runs the whole time; Map → Measure → Manage repeat every time context changes — new use case, new data, new deployment.
- Open each function's categories. Click into Govern, Map, Measure, and Manage below. Each accordion holds the categories NIST defines under that function, with a plain-language summary of the intent — use these as discussion prompts, not verbatim policy text.
- Apply it to one real or hypothetical AI system. The framework is only useful in the applying. Pick a system (an admissions chatbot, a proctoring tool, a hiring screener) and ask, function by function: who governs this, what's been mapped, what's being measured, and what happens when it fails?
- Go to the primary source for anything graded. This guide is a teaching scaffold summarizing NIST AI 100-1 and its companion Playbook. For assignments, quote and cite the original NIST text — see Sources below.
Characteristics of Trustworthy AI
NIST frames these seven characteristics as the outcome the four functions are managing toward. An AI system is not trustworthy because one characteristic is strong — trade-offs between them are expected and must be documented, not hidden.
Valid & Reliable
Performs as intended, accurately, and consistently under expected conditions, with ongoing testing rather than one-time validation.
Safe
Does not endanger human life, health, property, or the environment under defined conditions of use, including foreseeable misuse.
Secure & Resilient
Withstands adversarial manipulation (data poisoning, evasion, model extraction) and recovers from unexpected adverse events.
Accountable & Transparent
Roles, responsibilities, and decisions are documented and traceable; information about the system is available to those who need it.
Explainable & Interpretable
Explainable: can describe the mechanism behind an output. Interpretable: the output has meaning in context for the person using it — two related but distinct properties.
Privacy-Enhanced
Safeguards human autonomy, identity, and dignity — anonymity, confidentiality, and control over data are actively engineered in.
Fair, with Harmful Bias Managed
Addresses systemic, statistical, and human/cognitive bias; fairness includes equity concerns and disparate impact, not just a single metric.
Govern
Cultivates and implements a culture of risk management across the organization. Govern is the only function that runs continuously and touches every other function — it's the policies, structures, and accountability that make Map, Measure, and Manage possible and consistent.
"Who is responsible when this AI system causes harm, and how would we know?"
- Legal & regulatory landscape. The organization understands which laws, regulations, and standards apply to its AI systems before deployment, not after.
- Trade-offs documented. When trustworthy characteristics conflict (e.g., more explainability can reduce accuracy), the trade-off and rationale are written down, not left implicit.
- Risk tolerance defined. The organization has articulated what level of AI risk it is and isn't willing to accept, tied to its broader risk appetite.
- Roles & responsibilities. Specific people or teams are named as accountable for AI risk decisions — not diffused across "the team."
- Human oversight. Mechanisms exist for humans to intervene in, override, or halt an AI system's outputs when needed.
- Diverse perspectives. Teams building and reviewing AI systems include a range of disciplines and lived experiences, reducing blind spots in what risks get noticed.
- Training. Staff who interact with AI systems — not just engineers — are trained to recognize and escalate risk.
- Communicated commitment. The organization's stance on trustworthy AI is documented and communicated internally and to its supply chain.
- External input. Processes exist for people outside the organization (users, affected communities, auditors) to raise concerns.
- Third-party risk. Policies extend to vendors, pretrained models, and third-party datasets — risk doesn't stop at the organization's own code.
Map
Establishes the context in which risk will be framed. Before you can measure or manage a risk, you have to know what the system is, what it's for, who it touches, and what could plausibly go wrong.
"What is this system actually being used for, and by whom, and who else does it affect?"
- Intended purpose. The specific use case, users, and setting are documented — an AI system's risk profile changes entirely with context.
- Business/mission value. Why the organization is deploying this system, so risk decisions can be weighed against actual benefit, not assumed benefit.
- Type of system. Whether it's generative, predictive, a recommender, biometric, etc. — different categories carry different characteristic risks.
- Lifecycle stage. Whether it's being designed, piloted, deployed at scale, or nearing retirement, since risk-management needs differ by stage.
- Capabilities vs. claims. What the system can actually do is documented separately from what it's marketed or assumed to do.
- Costs and benefits. Weighed across affected groups, not only the deploying organization — a benefit to the business can be a cost to an end user.
- Component-level risk. Risks are traced to specific components — training data, model architecture, integration points — not treated as one undifferentiated "AI risk."
- Impacts to people. Effects on individuals, groups, communities, organizations, society, and the environment are identified, including impacts on those who never directly use the system.
Measure
Employs quantitative, qualitative, or mixed methods to analyze, assess, benchmark, and monitor AI risk and its impacts. If Map defines what could go wrong, Measure is how you'd actually know whether it is.
"What evidence do we have that this system is behaving the way we mapped it to — and is anyone watching for drift?"
- Fit-for-purpose metrics. Chosen metrics actually reflect the risks mapped earlier, rather than defaulting to whatever is easiest to compute (e.g., aggregate accuracy hiding subgroup failure).
- Testing against the seven characteristics. The system is evaluated for validity/reliability, safety, security, fairness, and the others — not just overall performance.
- Red-teaming & adversarial testing. Deliberate attempts to find failure modes before adversaries or end users do.
- Mechanisms for tracking risk over time. Since models drift and contexts change, measurement is repeated, not a one-time gate before launch.
- Feedback on the measurement itself. The organization checks whether its own metrics and methods are actually working, and revises them when they aren't.
Manage
Allocates resources to mapped and measured risks on a regular basis, and treats them: mitigate, transfer, avoid, or accept. Manage is where risk analysis turns into an actual decision and an actual action.
"Given what we've mapped and measured, what are we doing about it — and who finds out if it happens anyway?"
- Prioritization. Risks are ranked by severity and likelihood, given finite time and budget — not treated as equally urgent.
- Treatment decision. For each significant risk: mitigate it, transfer it (e.g., insurance, contract terms), avoid it (don't deploy), or accept it explicitly and document why.
- Ongoing optimization. Strategies are implemented and revisited, not set once at launch.
- Vendor & supply-chain accountability. Risks introduced by third-party models, data, or services are actively managed, not assumed to be someone else's problem.
- Response plans. Documented plans exist for when an AI system fails or causes harm — not improvised after the fact.
- Communication. Affected parties are told what happened, in plain language, as part of the plan rather than an afterthought.
Classroom Uses
Ways instructors have used this structure with students.
Case study walk-through
Give students a real or fictional AI deployment (a hiring tool, a chatbot, a proctoring system). Have them fill in one sentence per category — Govern through Manage — using only what's known, and flag what's missing.
Trade-off debate
Pick two trustworthy characteristics that pull against each other for a given system (e.g., Explainability vs. Valid & Reliable) and have students argue both sides before proposing a documented trade-off.
Govern audit exercise
Have students draft a one-page "who's accountable" chart for an AI system at their own institution — a low-stakes way to make GOVERN concrete before touching the more technical MAP/MEASURE work.
Playbook comparison
Assign students a single subcategory from the official NIST AI RMF Playbook and have them present the suggested actions in their own words — building comfort with primary-source policy language.
Sources & Further Reading
This guide is a teaching summary. For anything graded, cite NIST directly.
NIST AI RMF 1.0 (AI 100-1)
The primary publication: full text of all four functions, categories, and subcategories.nvlpubs.nist.gov — search "NIST AI 100-1."
NIST AI RMF Playbook
A companion resource with suggested actions, references, and documentation for every subcategory — the practical "how" to this guide's "what."airc.nist.gov/AI_RMF_Knowledge_Base/Playbook
NIST AI Resource Center
Ongoing NIST guidance, crosswalks to other frameworks (ISO/IEC 42001, EU AI Act), and generative-AI-specific profile documents.airc.nist.gov