The NIST Generative AI Risk Profile is a companion to the agency’s voluntary AI Risk Management Framework. It does not certify a model or prescribe one universal checklist. It gives teams a common way to identify risks, decide which controls fit a use case and assign work across the AI lifecycle.

NIST published the final profile, NIST AI 600-1, on July 26, 2024. The document remains the agency’s current cross-sector profile for generative AI as of October 14, 2026. NIST is revising AI RMF 1.0, so teams should record which edition they use instead of treating the framework as static.

Start with the four AI RMF functions

The profile keeps the parent framework’s four functions: Govern, Map, Measure and Manage. They are not a sequence that ends at launch.

Govern covers accountability, policies, roles and third-party oversight. Map defines the system, the people affected, the context of use and the possible harms. Measure turns those risks into evaluations, thresholds and evidence. Manage applies controls, monitors results and changes or retires a system when it falls outside accepted limits.

A workable first pass is a one-page register with five fields: the use case, the model or service, the accountable owner, the evidence required before release and the condition that triggers escalation. Link every test result and incident to the same record. This makes the framework easier to use than a separate policy document that no one consults during a release.

What NIST means by generative AI risk

NIST separates risks by lifecycle stage, scope and source. A problem can appear during design, deployment, operation or decommissioning. It may affect one model, an application that wraps the model or a wider group of people. The profile also warns that some risks remain hard to scope because evidence is limited.

One named risk is confabulation, NIST’s term for false or erroneous content presented with confidence. The definition includes answers that contradict the prompt or an earlier answer. Other risk areas include data privacy, information security, harmful bias, intellectual property, content integrity, human overreliance, environmental effects and failures introduced through suppliers or model components.

The categories overlap. A fabricated citation can be a confabulation problem, an information-integrity problem and a human-factors problem if staff trust it without checking. Teams should avoid assigning one owner to each label and then losing the connection between them.

Our guide to RAG for financial documents shows why retrieval does not remove the need to verify sources, dates and calculations. For regulated deployment questions, the NYDFS AI cybersecurity guidance adds a sector-specific view.

Turn broad risks into release tests

NIST’s suggested actions are organized under AI RMF subcategories. The profile says applicability depends on the system, lifecycle stage and actors involved. A small internal summarizer and a customer-facing agent that can move money should not share the same test plan.

For an internal summarizer, the evidence might include:

  1. A test set drawn from the documents staff actually use.
  2. Sentence-level checks that cited passages support the output.
  3. A privacy review covering prompts, logs and retention.
  4. A record of the base model, retrieval source and prompt version.
  5. A clear refusal when the source material does not answer the question.

For an agent with tools, add authorization tests, transaction limits, separation between reading and writing, recovery after a failed call and a human approval step for high-impact actions. Our function-calling explainer describes why model output should be treated as a request to a controlled application, not as permission by itself.

NIST specifically recommends reviewing sources and citations during pre-deployment measurement and ongoing monitoring. It also warns against extrapolating broad capability from narrow or anecdotal tests. A successful demo is useful evidence about one path through the system, not proof that neighboring tasks are safe.

Test the whole system, not only the model

A hosted model is one component. The deployed system also includes the user interface, retrieval index, filters, tools, identity controls, logging and human review. A failure in any of those layers can defeat a strong model evaluation.

Record every third party with access to organizational content. Document what changed when a provider, model, prompt, retrieval index or policy was updated. NIST’s profile calls for supplier assessments, contracts that address security and content provenance, and records of changes made by third parties.

Pre-deployment testing should match the context of use. A chatbot for public FAQs needs tests for incorrect answers and abusive prompts. A credit workflow needs evidence about adverse impacts, data provenance and human override. An assistant that writes code needs security review of the code it generates, not only a score on natural-language questions.

Build incident handling before release

The profile treats incident disclosure as part of risk management, not a communications task added after something goes wrong. Decide in advance what counts as an incident, who receives the report, what evidence must be preserved and who can suspend the system.

Useful incident records include the input, output, model and prompt versions, retrieved sources, tool calls, permissions, human decisions and downstream effect. Preserve sensitive data carefully, with access rules and retention limits. The goal is to reconstruct what happened without creating a second privacy problem.

Monitoring also needs decision points. Set limits for error rates, unsupported citations, policy violations and security alerts. When a limit is crossed, name the action: restrict the use case, switch off a tool, roll back a version, require manual review or decommission the system. A dashboard without a response rule is observation, not control.

A practical adoption order

Start with one real use case. Map the people, data and decisions it touches. Choose the risks that could cause a material harm, then define evidence for each one. Test before release, keep the evidence with the system record and repeat the tests after material changes.

The NIST profile is most useful as a vocabulary and evidence structure. It does not remove legal duties, sector rules or the need for expert judgment. It helps a product, security, legal and operations team discuss the same system without assuming that one benchmark score settles the decision.

Sources

Sources reviewed October 14, 2026.