The NIST AI framework maps directly to infrastructure you already run. Learn how its four functions translate to gateway controls, monitoring, and access policies.
If you run AI workloads through an API gateway, you are already doing risk management. Access controls decide who can call which model. Logging captures every request and response. PII redaction strips sensitive data before it hits a third-party endpoint. Rate limits prevent runaway spend and abuse.
What you probably lack is the vocabulary to describe these controls in a governance context, and a structure that connects them to organizational accountability. That is what the NIST AI framework provides. Not a compliance checklist. An operational blueprint that maps to infrastructure decisions you have already made or need to make soon.
Software risk frameworks assume deterministic systems. You write code, test it, deploy it, and barring bugs, it behaves the same way tomorrow as it does today.
AI systems break that assumption. They may require more frequent maintenance due to data, model, or concept drift that has no parallel in traditional software. A model that performs well on Monday can degrade by Friday if the distribution of inputs shifts. Outputs are non-deterministic. Reproducibility is difficult.
And the threat surface is different. Existing frameworks cannot adequately handle generative AI risks, evasion and model extraction attacks, or risks from fine-tuned transfer learning where a model trained in one domain gets repurposed in another, outside your security controls.
The organizational numbers reflect this gap. About 77% of employees use GenAI at work, but only 28% of organizations have clear usage policies. Corporate data flowing into AI tools jumped 485% between 2023 and 2024, with the share of sensitive data in those inputs nearly tripling from 10.7% to 27.4%. IBM reports that one in five organizations had a breach from Shadow AI, costing USD 670,000 more than regular data breaches.
Meanwhile, 96% of leaders think using generative AI makes security breaches more likely, yet only 24% of current generative AI projects include security measures. Traditional risk frameworks were not designed for any of this. The NIST AI framework was.
Published on January 26, 2023, as directed by the National Artificial Intelligence Initiative Act of 2020, the AI Risk Management Framework (AI RMF 1.0) gives organizations a structured approach to identifying, assessing, and mitigating AI-specific risks.
Three properties matter for developers:
It also provides crosswalks to the NIST Cybersecurity Framework (CSF) and ISO standards, so if your organization already uses those, the mapping is built in.
Before getting to the operational functions, the framework defines what "trustworthy" means. These seven characteristics are your design targets:
| Characteristic | What it means for developers |
|---|---|
| Valid and reliable | The system performs as intended across expected conditions. Validation follows ISO 9000:2015: confirmation, through objective evidence, that requirements for a specific intended use have been fulfilled |
| Safe | The system does not create unacceptable risk of harm |
| Secure and resilient | Resistant to adversarial attacks, model extraction, and prompt injection |
| Accountable and transparent | Decisions are traceable; stakeholders can inspect the process |
| Explainable and interpretable | Outputs can be understood by their intended audience |
| Privacy-enhanced | User data is protected throughout the pipeline |
| Fair with harmful bias managed | Outputs do not systematically disadvantage groups |
These characteristics are not independent toggles. Tradeoffs emerge between them: optimizing for interpretability can conflict with privacy, and predictive accuracy can conflict with interpretability. The framework does not pretend otherwise. It asks you to make those tradeoffs deliberately, with documentation.
For teams running AI through a gateway layer, several of these characteristics map directly to infrastructure: PII redaction handles privacy-enhanced. Access logging handles accountable and transparent. Guardrail policies handle safe and fair.
The operational heart of the NIST AI framework is four functions: Govern, Map, Measure, and Manage. Each breaks down into categories and subcategories with specific outcomes.
Governance is designed to be cross-cutting, meaning it does not sit alongside the other three. It flows through and informs all of them. After instituting Govern, most users start with Map, then proceed to Measure or Manage, but the process should be iterative.
Without clear roles, policies, and accountability, Map and Measure activities lack authority, and Manage decisions have no home. GOVERN is where most teams fail. Not because they lack technical controls, but because no one owns them.
The GOVERN function cultivates a culture of risk management, outlines processes and organizational schemes that anticipate and identify risks, incorporates processes to assess potential impacts, and addresses the full product lifecycle including legal and other issues concerning use of third-party software or hardware systems and data.
For a development team, GOVERN answers these questions:
An AI gateway enforces several GOVERN outcomes by design. Access control policies define who can use which models. Usage logging creates an audit trail. Rate limits and spend caps enforce organizational boundaries on AI consumption. If you already run a gateway, you have GOVERN artifacts. You just need to connect them to written policy.
For teams dealing with shadow AI, the gateway becomes the enforcement point: route all AI traffic through a single control plane, and shadow usage becomes visible and governable.
MAP is about understanding what you are building and what can go wrong. Where is the AI system deployed? Who uses it? What decisions does it inform? What data does it consume?
AI Development actors are specifically responsible for model building, interpretation, creation, selection, calibration, training, and testing. Even if you did not train the model, you selected it. You decided which prompts to use. You chose what context to inject via RAG. MAP says: document those decisions and their risk implications.
Concrete MAP activities for a developer team:
MAP identifies risks. MEASURE quantifies them.
The framework emphasizes TEVV (Test, Evaluation, Verification, and Validation) as the primary measurement mechanism. Critically, TEVV tasks run throughout the entire AI lifecycle, not just at deployment. And ideally, AI actors carrying out verification and validation tasks are distinct from those who perform test and evaluation actions.
What MEASURE looks like in practice:
MANAGE is where the lifecycle nature of AI risk becomes most visible. Because AI systems may require more frequent maintenance due to data, model, or concept drift, MANAGE is not a phase you complete. It runs as long as the system runs.
The AI RMF Playbook provides suggested actions for each subcategory of MANAGE (and every other function). It is neither a checklist nor set of steps to be followed in its entirety; organizations may utilize as many or as few suggestions as apply to their use case.
MANAGE activities that map to gateway infrastructure:
The base framework covers AI broadly. For teams working specifically with large language models, NIST released additional guidance.
On July 26, 2024, NIST released NIST-AI-600-1, the Generative Artificial Intelligence Profile, designed to help organizations identify unique risks posed by generative AI and propose actions for risk management aligned with their goals and priorities. If you are building on LLMs, this profile addresses risks the base framework treats at a higher level: hallucination, training data provenance, generated content attribution, and more.
The framework continues to evolve. On April 7, 2026, NIST released a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure, which will guide critical infrastructure operators toward specific risk management practices for AI-enabled capabilities.
The full NIST AI framework contains dozens of subcategories and hundreds of suggested actions. You do not need all of them. Here is a practical starting sequence for a development team running AI workloads through API infrastructure.
No. The framework is voluntary, rights-preserving, non-sector specific, and use-case agnostic. No regulation currently requires its adoption. However, its structure aligns with emerging AI regulations, making future compliance easier.
It applies to any organisation that develops, deploys, or uses AI systems, including software teams integrating LLMs, ML engineers, and platform teams building AI infrastructure.
The AI RMF 1.0 covers AI systems broadly. The Generative AI Profile (NIST-AI-600-1), released July 26, 2024, addresses risks specific to generative AI, such as hallucination, content provenance, and training data issues.
No. The Playbook is neither a checklist nor set of steps to be followed in its entirety. Select the subcategories and suggested actions that match your organization's risk profile and use cases.