The NIST AI Risk Management Framework gives organizations a durable vocabulary for trustworthy AI. Its four functions — Govern, Map, Measure, and Manage — are intentionally broad enough to apply across sectors and technologies. NIST's Generative AI Profile, released in July 2024, extends that foundation for risks specific to generative systems.
In April 2026, NIST also released a concept note for a profile focused on trustworthy AI in critical infrastructure. The details will evolve, but the direction is clear: AI risk management must connect policy to the operational environment in which a capability is deployed.
Govern: establish authority before selecting technology
Governance begins before model selection. A project needs an accountable business owner, a technical owner, a security decision-maker, and a clear path for accepting or escalating residual risk. Those roles should agree on the system's purpose, prohibited uses, data classes, and criteria for stopping the project.
A central AI policy can set organization-wide principles. The implementation record for each system should be more specific: what the system may do, whose data it may use, which environments it may reach, and who approves changes to models, prompts, tools, or retrieval sources.
Map: define the system, not only the model
Production AI is an assembly of components. A useful system map covers identity, application code, prompts, models, retrieval indexes, data stores, tool integrations, network paths, logging, and human approval points. It also identifies the people affected by the output and the conditions under which the system is expected to operate.
For private AI, the deployment boundary deserves special attention. Self-hosting a model does not automatically make the full workflow private. Telemetry, embeddings, support access, browser extensions, and downstream tools can still move sensitive information outside the intended boundary.
Measure: test behavior that matters to the workflow
Generic benchmarks are useful for screening models, but they do not prove that a system is ready for a particular workflow. Teams need a versioned evaluation set built from representative tasks, expected outcomes, known failure cases, and prohibited behavior.
Measurements should cover task quality and operational risk. Depending on the use case, that can include unsupported claims, prompt injection, sensitive-data disclosure, tool misuse, retrieval accuracy, latency, cost, and human override rates. Thresholds should be decided before release, not after a favorable result appears.
Manage: connect risk decisions to runtime controls
Risk treatment should be visible in the architecture. Least-privilege identities, scoped tools, input and output validation, approval gates, rate limits, network segmentation, immutable logs, rollback procedures, and incident playbooks are more persuasive than policy language alone.
The operating team also needs a change process. A new model version, prompt, retrieval corpus, tool permission, or context window can alter system behavior. Treat those changes as releases with impact assessment, testing, approval, and a recovery path.
A practical control checklist
- Document the intended decision or workflow, accountable owner, users, and affected parties.
- Map data classifications, identities, model endpoints, retrieval stores, tools, logs, and external dependencies.
- Define prohibited actions and identify where human approval is required.
- Build a versioned evaluation set with quality, security, privacy, and operational thresholds.
- Apply least privilege to every tool and service identity, not just the user-facing application.
- Record model, prompt, configuration, and source versions with each consequential output.
- Assign monitoring, incident response, access review, change approval, and retirement responsibilities.
The implementation question
The AI RMF is not a certification checklist, and NIST describes it as voluntary. Its value is that it helps organizations ask consistent questions across design, development, deployment, and evaluation. The practical next step is to choose one bounded workflow and produce evidence for each material risk decision.
That evidence may be modest at first: a system map, data-flow diagram, threat model, evaluation report, access matrix, approval record, and runbook. Together, those artifacts turn broad principles into something a technical team can build and an operating owner can defend.