NIST’s AI Risk Management Framework gives organizations a shared way to describe AI risk. Its Generative AI Profile narrows that work to risks that generative systems create or intensify. Neither document certifies a product, and neither replaces sector rules. They are tools for deciding what to document, test and control before and after deployment.
The useful starting point is not a model name. It is the intended use, the people affected, the data and services the system depends on, and the harm that could follow when the system behaves outside its limits.
Start with the four functions
NIST AI RMF 1.0 organizes risk work into four functions: Govern, Map, Measure and Manage. Govern sits across the other three rather than at the end of a checklist.
Govern assigns authority, policies and accountability. A team needs to know who can approve an AI use, who owns monitoring, who can stop it, and which legal or business requirements apply.
Map defines the context. That includes the intended purpose, users, affected groups, expected benefits, foreseeable misuse, outside dependencies and conditions in which the system should not operate.
Measure turns those concerns into tests and evidence. Accuracy may matter, but so can privacy, security, bias, reliability, human oversight and the ability to detect a change after deployment.
Manage uses the evidence to prioritize risks, choose controls and decide whether to proceed, limit the use or stop it. The NIST AI RMF Playbook explicitly says its suggested actions are not a checklist that every organization must follow in full.
What the Generative AI Profile adds
NIST published the Generative AI Profile as a cross-sector companion to AI RMF 1.0. It applies the same four functions to generative AI and describes risks that are novel or amplified by the technology.
The profile groups 13 risk areas and supplies more than 400 suggested actions. The list includes confabulation, data privacy, harmful bias, information integrity, information security, intellectual property, human-AI configuration and risks introduced through the value chain. That breadth matters because a system can fail even when its model produces fluent text.
A fintech product team, for example, may depend on a hosted model, a retrieval database, account data, a third-party identity service and an employee approval step. Mapping only the model misses the components that decide what data enters the system and whether an output becomes an action. Our guide to third-party AI risk in financial services covers the separate vendor-governance questions around that chain.
Turn a use case into a risk record
A practical risk record can fit on one page before it grows into a larger assessment. Start with six questions.
- What is the system allowed to do? Separate generating text from making a decision or sending an instruction.
- Who relies on the output? An employee reviewing a draft faces a different risk from a customer receiving an automated denial.
- Which data and services feed it? Record model providers, retrieval sources, personal data, plugins and external APIs.
- What would failure look like? Name concrete outcomes such as a wrong balance explanation, disclosure of personal data or an unsupported compliance statement.
- How will the team detect it? Set tests, review samples, incident signals and thresholds before release.
- Who can intervene? Identify the person or role that can pause the feature, change a control or notify affected users.
This is the Map function made operational. It also prevents a common governance gap: a general policy that says AI must be “responsible” without identifying the system, decision or owner.
Measure the deployment, not only the model
NIST treats AI risk as sociotechnical. A model benchmark cannot show whether staff understand when to override an output, whether a user interface encourages over-trust, or whether a retrieval source has gone stale.
Testing should match the deployment. For a document assistant, that can mean measuring whether citations support the answer, whether access controls prevent cross-customer retrieval, and whether unsupported statements are flagged. For a customer-service system, the team may also test escalation, complaint handling and whether the system gives the same quality of response across user groups.
Keep the test set and acceptance rule. “Reviewed by the team” is not reproducible evidence. A useful record says what was tested, which version and data were used, what counted as a failure, who reviewed the result and when the test must be repeated.
Treat monitoring as part of the design
The profile covers the whole AI lifecycle. A system that passed before launch can change because the provider updates a model, the retrieval corpus changes, a new integration is added or users discover a different way to prompt it.
The risk plan should therefore name change triggers. A model-version switch, a new data source, a material rise in escalation rates or a security incident should cause a fresh review. Logs need enough detail to investigate an event without collecting data the team does not need.
Monitoring also needs an exit route. If the system must be disabled, the organization should know which workflow replaces it, which decisions need human review and what happens to in-progress cases.
What the framework does not prove
Using the AI RMF does not mean a product is safe, compliant or endorsed by NIST. The framework is voluntary guidance. A profile is an implementation of the framework for a technology or use case, shaped by the organization’s requirements, risk tolerance and resources.
The AI RMF is also being revised. NIST’s AI RMF resource page notes that version 1.0 is under revision, while the current Generative AI Profile remains a companion to that version. Teams should preserve the version of the framework used in an assessment and review updates rather than silently treating the documents as static.
A workable first pass
For a new generative AI feature, the minimum useful output is not a policy statement. It is a documented use case, component map, named risk owners, deployment-specific tests, acceptance thresholds, monitoring triggers and a stop procedure.
That package will not answer every risk question. It does make the next decision inspectable: the team can see what it knows, what it has not tested and who is responsible for the remaining uncertainty.
