The NIST AI Risk Management Framework, Translated for Engineers

If you build AI systems in a regulated company, someone has probably told you the work needs to "align with the NIST AI RMF." It is worth reading the framework yourself, because it is more practical than its reputation, and knowing it lets you have a better conversation with your risk and compliance partners.

What it is

The AI Risk Management Framework, AI RMF 1.0, was published by the U.S. National Institute of Standards and Technology in January 2023. It is voluntary. It is not a regulation, a certification, or a checklist you pass. It is a structured way to think about the risks of an AI system across its whole life, from design to retirement.

NIST published a companion Playbook with suggested actions for each part of the framework. In July 2024, it added a Generative AI Profile (NIST AI 600-1), which applies the framework to generative models specifically.

What "trustworthy" means here

The framework describes characteristics of trustworthy AI. A system should be valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair, with harmful bias managed.

NIST is explicit that these involve trade-offs. Making a model more interpretable might cost some accuracy. Stronger privacy protections might limit the data you can use to test for bias. The framework does not pretend you can maximize all of them. It asks you to make those trade-offs deliberately and write them down.

The four functions

The core of the framework is organized into four functions. This is the part engineers will spend most of their time on.

Govern is about the organization, not any single system. Who is accountable for AI risk? What policies exist? How are people trained? Do teams have a way to raise concerns? Govern is meant to run through all the other functions. For an engineer, this usually shows up as the approval process, the inventory of AI systems you are asked to register in, and the policy that says which data can go to which models.

Map is about understanding context before you build. What is the system for, who uses it, who is affected by it, and what could go wrong? What are the limits of what the model knows? This is design review work: documenting intended use and, just as important, uses you are not supporting.

Measure is about testing and tracking risk with real methods. Evaluate the system for the characteristics above, using test sets, red teaming, and monitoring. If you already have an evaluation pipeline for an LLM feature, much of it belongs here. The framework also asks you to measure whether your measurements are any good, which is a fair challenge to any test suite.

Manage is about acting on what you found. Prioritize the risks, decide which to fix, which to accept, and which mean the system should not ship. Plan for incidents and for how to roll back or retire a system. On-call runbooks, kill switches, and rollback plans for a model change all live here.

The generative AI profile

The Generative AI Profile lists twelve risks that are unique to generative AI or made worse by it. They include confabulation (the framework's term for confidently stated false content), information security, data privacy, harmful bias, intellectual property, information integrity, and risks from the value chain of third-party models and components. For each, it suggests actions mapped back to the four functions.

For platform engineers, the value chain risk deserves attention. Most companies are not training foundation models. They are integrating models, APIs, and tools from vendors. The profile treats that dependency chain as a risk to be governed, which supports the case for things like a central gateway, vendor review, and an inventory of which applications use which models.

How to use it without drowning

You do not need to implement every suggested action in the Playbook. A practical approach:

1. Keep an inventory of AI systems and their owners. Govern starts here.
2. For each system, write a short document covering intended use, users, data involved, and known limitations. That is your Map.
3. Attach an evaluation suite and monitoring to it. That is Measure.
4. Record the risks you accepted, the mitigations in place, and how to turn the system off. That is Manage.

Do that consistently and you will be able to answer most of the questions an auditor or risk team will ask, in language they recognize. That is the real benefit of the framework: it gives engineering and governance a shared vocabulary, so the conversation is about the system and not about definitions.