NIST AI Risk Management Framework: A Practical Business Guide

Start with a use case, not a framework score

A business does not become safer simply by marking four framework headings complete. The practical question is whether a specific AI use has an understood purpose, evidence about its risks, appropriate controls and someone accountable for the result.

NIST released AI Risk Management Framework 1.0 in January 2023 for voluntary use. Its current website says the framework is being revised; this guide uses the published 1.0 structure checked on October 1, 2026.¹ Do not treat a proposed revision or concept note as a final new requirement.

The framework can inform internal governance whether your organization builds AI or uses a supplier's system. It does not determine every law that applies or provide certification that an AI system is safe.

Understand the four connected functions

NIST's Core organizes outcomes under Govern, Map, Measure and Manage. These are interconnected functions rather than an ordered checklist that must be completed once.²

Governance runs across the other work. If measurement uncovers an unacceptable outcome, the team returns to context and decisions rather than hiding the issue in a completed assessment.

Original one-use-case worksheet

Complete this worksheet before asking leadership to approve a consequential use. It is a practical adaptation, not an official NIST assessment form.

1. Business purpose: What problem is being solved, and how will success be judged?
2. System boundary: Which model, application, configuration and connected services are included?
3. Affected people: Who receives outputs, is represented in data or may be disadvantaged by errors?
4. Information: Which data enters, where it goes, who can access it and what is retained?
5. Decision effect: Is the output a draft, a recommendation or an action? What human authority remains?
6. Risk scenarios: What could go wrong, under what conditions and with what consequences?
7. Evidence plan: Which tests or reviews would meaningfully challenge those scenarios?
8. Operating limits: What tasks, data and decisions are prohibited or require escalation?
9. Approval: Who accepts the remaining risk, and what conditions attach to approval?
10. Monitoring and exit: What change triggers review, and how can the use be suspended safely?

Record what is unknown. If the supplier does not explain a retention setting, the correct entry is an unresolved dependency, not “privacy verified.”

Worked example: drafting customer-support replies

Fictional scenario: A software company wants an AI system to draft replies from a reviewed knowledge base. It will not automatically send messages or change customer accounts.

Under Govern, the support director owns the use. Security and privacy reviewers consider data access, and a trained agent must approve each customer message. The team defines when agents must escalate billing, security or legal questions.

Under Map, the team describes the inputs, knowledge-base source and output destination. It identifies customers harmed by incorrect cancellation instructions, misleading security advice or exposure of another customer's information. It also maps a supplier dependency: the service may change model versions.

Under Measure, the team prepares original synthetic cases: a misspelled feature name, conflicting source articles, an unavailable refund policy and a prompt asking for another customer's account details. Reviewers record factual accuracy, prohibited disclosure, appropriate escalation and whether the agent can recognize uncertainty. Test cases must reflect the actual configuration being proposed.

Under Manage, leadership permits only the supported draft use after evaluating results. Unsupported answers go to a human; changed sources or models trigger focused retesting. The team retains a stop process if incidents or worsening results invalidate the approval.

The worksheet does not promise zero errors. It produces a bounded decision based on evidence, including the conditions under which the decision should change.

Choose measurements that match consequences

A single overall accuracy percentage can conceal the failure that matters. An incorrect adjective in a brochure and incorrect guidance about access revocation have different consequences.

Define a small set of relevant measures before testing. For the support example, these could include factual support in the source, recognition of unsupported questions, avoidance of cross-customer information and reviewer ability to reject unsafe drafts. Examine important subsets rather than averaging every result into one score.

Label the sample size, case selection, configuration and testing date. A supplier benchmark is contextual evidence, not proof that your application performs identically. Record qualitative observations where meaningful numeric measurement is not available.

Treat generative AI risks explicitly

NIST's Generative AI Profile is a companion resource addressing issues such as confidently incorrect content, privacy risks and human over-reliance.³ Use it to challenge assumptions about your chosen use rather than copying every risk into every register.

For example, ask whether a fabricated citation could mislead a reviewer, whether a connected document store could expose restricted records, and whether staff have time and expertise to review output. The controls for a public-copy assistant may differ substantially from those for a hiring or medical application.

Do not infer that an approved supplier model makes downstream use automatically appropriate. Changes in data, permissions, audience or decision authority can change the risk even when the model stays the same.

Turn findings into decisions

For each material issue, choose a clear response: change the use, add a safeguard, gather missing evidence, restrict deployment or stop the proposal. Assign a person and completion criteria.

An issue such as “hallucination risk” is too vague to close. A more useful record states: “The assistant invented a refund condition in two test cases. Remove unsupported refund responses, add an escalation rule and retest those cases with an accountable reviewer.” Do not declare the risk eliminated merely because the retest passed a small sample.

Approval should identify the reviewed version and scope. A general “AI approved” badge can erase the limits on which the decision depended. Preserve the decision history and link later changes to the original assumptions.

Questions about using the framework

Is NIST AI RMF mandatory?

NIST describes the framework as voluntary. A contract, sector rule or organizational policy may reference it, but that is a separate obligation to examine.

Is it the same as ISO 42001 or the EU AI Act?

No. A voluntary risk framework, a management-system standard and legislation have different purposes and requirements. Mapping can help organize work; it does not make them interchangeable.

Can a small team use it?

Yes. Begin with a limited use case and proportionate evidence. The AI acceptable-use policy template helps translate reviewed boundaries into staff instructions. The readiness assessment is a general starting point, not a NIST certification or authorization to deploy AI.

Sources and references

1. NIST. Artificial Intelligence Risk Management Framework 1.0 (2023-01-26). Voluntary framework; NIST reports a revision is in progress as checked October 2026. ↩

2. NIST. AI RMF Core (2023-01-26). Core functions are interconnected outcomes, not a fixed ordered checklist. ↩

3. NIST. AI 600-1: Generative Artificial Intelligence Profile (2024-07-26). Voluntary companion profile; supports discussion of privacy, unreliable outputs and acceptable-use governance. ↩