Assess one AI system by documenting its purpose and context, categorizing it, listing risks and impacts with likelihood and magnitude, testing the risks you can measure, choosing a treatment, and recording residual risk and who accepted it. The AI RMF Map, Measure and Manage functions give the structure.
Step 1: context (MAP 1)
Write down the intended purpose, users, deployment setting, and relevant laws and norms. Note assumptions and limitations. NIST also asks that the business value be defined and that organizational risk tolerance be on record.
Step 2: categorize the system (MAP 2)
State what the system does: classifier, generative model, recommender, agent. Document knowledge limits and how humans oversee output. Write the limits plainly: what it should not be asked to do.
Step 3: map components and third parties (MAP 4)
List models, data sources, libraries and vendors the system depends on, and the controls you have for each. The generative AI profile treats untraceable upstream components as a risk in its own right.
Step 4: characterize impacts (MAP 5)
For each identified impact, beneficial or harmful, record likelihood and magnitude. NIST suggests using expected use, past uses in similar contexts, public incident reports, and feedback from people outside the team.
For generative systems, walk the twelve risks in the profile and mark which apply, such as confabulation, data privacy, information security, and over-reliance.
Step 5: measure what you can (MEASURE)
Pick tests tied to the risks: accuracy against a test set, security testing, privacy checks, bias evaluation where relevant. Document test sets, metrics and tools. Test again in production, since MEASURE 2.4 asks for monitoring of behavior when deployed.
Step 6: treat and decide (MANAGE 1)
Prioritize by impact, likelihood and available resources. For high-priority risks, plan and document a response: mitigate, transfer, avoid or accept. Decide whether the system should proceed at all.
Step 7: record residual risk
Write down what remains, and who accepted it. NIST asks that negative residual risks to downstream acquirers and end users be documented.
Step 8: schedule the reassessment
Set triggers: model version change, new data source, new use case, incident, or a calendar date.
A short worked outline
For an internal code-review assistant, context is a developer-facing tool seeing private source code. Categorization is a generative model with read access to repositories. Third parties are the hosted model and a plugin. Impacts include leaking code to a provider, incorrect review comments, and over-reliance. Tests include a seeded set of known bugs and a check that secrets in code are not retained. Treatment might be a contract term on retention plus a rule that humans approve merges. Residual risk is recorded and accepted by the engineering lead.
Quick check
How long should this take?
For a low-tier system, an afternoon. For a high-impact system, expect weeks, since testing and independent review take time.
Who should be in the room?
The system owner, security, privacy, legal, and someone who represents the affected users.
Sources
Last reviewed: 19 October 2026.
