NIST AI Risk Management Framework, Explained for Small Teams

The NIST AI Risk Management Framework (AI RMF 1.0, published as NIST AI 100-1) is voluntary guidance from the US National Institute of Standards and Technology for managing the risks of designing, building, deploying or using AI. Its core is four functions: Govern sets the rules and owners, Map works out the context and what could go wrong, Measure checks it, and Manage acts on what you find. It is not a law or a certification, and nothing in it forces you to do all of it. A small team can use its shape as a checklist of questions, answer each one in a sentence or two, and have something a customer or investor will recognize.

What the AI RMF is, and what it is not

NIST’s AI Risk Management Framework page↗ (opens in a new tab) says the framework was released on January 26, 2023, and is intended for voluntary use. The document itself describes it as “voluntary, rights-preserving, non-sector-specific, and use-case agnostic,” meant for organizations of every size. It speaks to anyone who designs, develops, deploys or uses AI systems, which includes a team whose only AI is an assistant connected to its tools.

• It is guidance, not regulation. No agency audits you against it and no one certifies you to it.
• It is organized as outcomes, not steps. NIST says the actions “do not constitute a checklist, nor are they necessarily an ordered set of steps.”
• It is being revised. NIST’s page says AI RMF 1.0 is under revision as part of the White House AI Action Plan, so check that page before you quote category numbers in a contract.

The AI RMF 1.0 document↗ (opens in a new tab) has two parts. Part 1 frames AI risk and lists the characteristics of a trustworthy AI system: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Part 2 is the Core, the four functions, and profiles.

The four functions

Each function breaks into categories and subcategories, labeled like GOVERN 1.6 or MANAGE 2.4. NIST says that once governance is in place most users start with Map and continue to Measure or Manage, and that the process should be iterative.

Govern

Govern is the cross-cutting function: policies, roles, accountability and culture, applied throughout the other three. Several of its subcategories read like a small team’s to-do list. GOVERN 1.6 asks for an inventory of AI systems. GOVERN 2.1 asks that roles and responsibilities be documented and clear. GOVERN 3.2 asks for policies that define roles for human-AI configurations and oversight. GOVERN 6.1 covers risks from third parties, which is every AI vendor you use.

Map

Map establishes context: what the system is for, who uses it, where it runs, and what could go wrong for people inside and outside the organization. MAP 1.1 asks that intended purposes, the setting and the relevant laws be understood and documented. NIST describes Map’s output as the basis for Measure and Manage; without the context, the risks are hard to judge.

Measure

Measure uses quantitative, qualitative or mixed methods to analyze, assess and monitor the risks Map identified. The framework says AI systems should be tested before deployment and regularly while in operation, and that the measurements themselves should be documented.

Manage

Manage puts resources on the risks you mapped and measured: decide what to treat, how to respond, and how to recover. MANAGE 2.4 asks for a way to supersede, disengage or deactivate a system that behaves outside its intended use, with the responsibility assigned. MANAGE 4.3 asks that incidents and errors be tracked, responded to and communicated.

The Playbook

The AI RMF Playbook↗ (opens in a new tab) is NIST’s companion resource: suggested actions, aligned to each subcategory of the four functions, for reaching the framework’s outcomes. NIST is plain that it “is neither a checklist nor set of steps to be followed in its entirety,” and that organizations may borrow as many or as few suggestions as apply. It downloads as PDF, CSV, Excel or JSON, and NIST says updates come out about twice a year. For a small team, the CSV is the useful form: filter it to the subcategories you chose and ignore the rest.

The Generative AI Profile (NIST AI 600-1)

NIST released the Generative AI Profile↗ (opens in a new tab), NIST AI 600-1, on July 26, 2024. It names twelve risks that are new with, or made worse by, generative AI, and maps suggested actions to the AI RMF’s functions. For a team using AI assistants, a handful of them do most of the work:

• Confabulation: confidently stated but false output. The case for a person checking what an assistant marks as done.
• Information security: including prompt injection, which the profile describes in both direct and indirect forms. Indirect prompt injection covers how it reaches agents.
• Data privacy: personal or sensitive data leaking through prompts, outputs or logs.
• Human-AI configuration: over-reliance and automation bias, where people stop reading what the AI produced.
• Value chain and component integration: third-party models, tools and data you cannot fully see into.

The others, such as CBRN information, obscene content and environmental impact, matter mostly to teams building or hosting models. Profiles are a general idea in the AI RMF too: a current profile against a target profile shows the gap to close.

A light version for a team of five

Here is the framework cut down to what a five-person team whose AI is mostly assistants such as Claude, ChatGPT or Cursor connected to its tools can actually keep up. One sentence per line is enough. The one-page policy that sits under Govern is written out in AI agent governance for small teams; this is the risk view around it.

GOVERN
  Owner of this page:        <person>; reviewed quarterly
  Inventory (GOVERN 1.6):    <assistant> - <what it connects to> - <owner>
  Oversight (GOVERN 3.2):    AI may draft, file, comment; a person approves
                             anything customer-facing, irreversible or paid
  Vendors (GOVERN 6.1):      <model provider>, <tools> - where data goes
MAP (per assistant)
  Purpose:                   <what it is for, and not for>
  Data it can reach:         <open / careful / never>
  What could go wrong:       wrong output shipped; data leaked; injected
                             instructions acted on; over-reliance
MEASURE
  Checks:                    a person reviews every AI-completed task;
                             monthly look at what each assistant changed
MANAGE
  Switch-off (MANAGE 2.4):   <who> revokes <which token>, same day
  Incidents (MANAGE 4.3):    logged as a task, cause and fix recorded

1. Govern first, in one meeting: name an owner, list every assistant and what it reaches, and write down what a person must approve.
2. Map each assistant in five minutes: its purpose, the data it can reach, and the two or three ways it could hurt you or a customer.
3. Measure with habits rather than metrics: a person checks AI-completed work, and once a month someone reads what each assistant changed. The routine is in how to audit AI agents.
4. Manage by knowing how to switch each assistant off, who does it, and where an incident gets written down. AI agent incident response has the runbook.
5. Revisit the page every quarter, and whenever you connect something new.

How it relates to the EU AI Act

They are different kinds of thing. The AI RMF is voluntary US guidance you adopt as far as it helps. The EU AI Act is a law with obligations that depend on what an AI system is used for, and it can apply to a US company whose system is used in the EU. Doing the AI RMF well does not make you compliant with the Act, but the work overlaps: an inventory, documented purposes, human oversight, testing and incident handling are what both ask about first. If you sell into the EU, read human oversight under the EU AI Act alongside this.

Recording AI rules where the work happens

The AI RMF keeps asking for things to be documented: roles, oversight, decisions about risk. A policy file nobody opens fails that quietly. On fenbs, the Decisions and rules page holds that record. A decision says the question, what was decided, why, the options turned down, and who decided; a rule is a decision that holds from now on, such as “a person approves anything customer-facing.” The decider is always a person, never an AI assistant. Rules are shown in full at the top of every connected assistant’s AI context, so the assistants read them before they start, and changing a rule means recording a new decision that supersedes the old one, which keeps the history. Incidents and fixes go on the board as tasks, and the board’s history records who changed what, with an assistant’s changes named as the assistant acting for its person. fenbs does not score risks or produce a risk register for you; the page above is yours to keep.