Skip to main content
SecureAI Guard

NIST AI RMF for LLM applications

What the NIST AI Risk Management Framework (AI 100-1) and its Generative AI Profile (AI 600-1) ask of an LLM deployment, and what a control layer can evidence.

Published ·4 min read·SecureAI Guard
NIST AI RMF
governance
compliance
risk management

The NIST AI Risk Management Framework is voluntary, not certifiable, and that is the first thing to be clear about — there is no NIST AI RMF audit, no NIST AI RMF certificate and nobody who can issue you one. Any vendor claiming to be "NIST AI RMF certified" is describing something that does not exist.

What it is instead is the framework most large organisations have adopted as the structure of their AI governance programme, because it is free, sector-neutral and written in language a risk function already speaks. It is also increasingly the shape into which regulatory obligations get mapped: a team that has implemented the AI RMF has, incidentally, produced most of the artefacts the EU AI Act asks a provider to keep.

Source and currency. Document numbers and dates below are from NIST's own publication pages, checked on 12 August 2026.

The two documents you need

*NIST AI 100-1, AI Risk Management Framework 1.0* — released 26 January 2023**. The core framework. Sector-neutral and technology-neutral; it does not mention large language models because it predates their enterprise adoption.

*NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile* — published 26 July 2024**. A cross-sectoral companion profile to AI RMF 1.0 for generative AI, issued pursuant to Executive Order 14110. This is the document that carries the generative-AI-specific risks and the suggested actions against them, and it is the one to work from for an LLM application. Cite both numbers together in a questionnaire response; citing only 100-1 signals you have not read the profile.

The four functions, and where an LLM deployment usually fails

The framework organises everything into four functions: GOVERN, MAP, MEASURE and MANAGE. GOVERN is the cross-cutting one that the other three sit inside.

GOVERN — policies, accountability, roles, culture. The failure mode specific to LLM work is that governance was written for models a data-science team trained and reviewed, and nobody updated it when the models started arriving through an API key that any engineer could obtain in ninety seconds. The practical GOVERN test for an LLM programme is whether you can name, today, every model your organisation is calling and who approved each one.

MAP — context, intended purpose, and the risks that follow. This is where the LLM-specific attack surface enters: the classes catalogued in the OWASP LLM Top 10, plus your own deployment's particulars — what the model can reach, which corpus it retrieves from, which tools it can call, and who the users are. Doing MAP well for a RAG application means mapping the retrieval corpus as an asset, which most first attempts skip.

MEASURE — quantify and track. The hardest function for generative AI and the one where programmes stall, because the obvious metrics are unstable: a detection rate against a fixed adversarial corpus decays as attacks evolve, and an evaluation benchmark measures the model rather than your system. What is stable enough to measure is your traffic: how many requests were blocked and why, how many detector verdicts were reviewed and how many were false, how long a fix took to reach production, and whether coverage extends to every model call or only to the ones through the official path.

MANAGE — prioritise, respond, recover, and monitor over time. For an LLM application this means incident response that treats a prompt injection as a security incident, and a route from a detection to a change in policy that does not require a release.

What a runtime control layer contributes

Named plainly, so it can be checked. The AI RMF is a governance framework; a control layer is not a governance programme and cannot become one. What it does is make three of the four functions evidenceable instead of assertional:

  • MAP. An enforced allow-list of models and providers on every call produces a system inventory derived from traffic rather than from a spreadsheet. That is a MAP artefact that stays true between reviews.
  • MEASURE. Per-request policy decisions, recorded with the context that produced them, are the raw material for every metric above. Without a control on the request path there is nothing to count.
  • MANAGE. Policy that can change without a release is the difference between a MANAGE function that responds and one that files a ticket.

GOVERN it does not touch at all. Accountability, roles, escalation and tolerance for risk are decisions people make and sign. No product supplies them, and a vendor implying otherwise is selling you a spreadsheet.

Using the AI RMF alongside a certifiable standard

Because the AI RMF cannot be certified, organisations that need an external attestation generally run it alongside ISO/IEC 42001, which can be. The two are complementary rather than competing: the AI RMF gives you the risk taxonomy and the actions, and 42001 gives you the auditable management system to hang them on. The common pattern is to run the programme by the AI RMF and present it to auditors through 42001's structure.

For adversary techniques when you are building a MEASURE test set, use MITRE ATLAS rather than inventing one; and see AI red teaming for LLM applications for how the model-level and application-level exercises differ.

Primary sources