Security leaders who already use the NIST Cybersecurity Framework often assume it covers AI, but it doesn't. The Cybersecurity Framework (CSF) protects the confidentiality, integrity, and availability of the systems around a model. Outcome risk from model decisions is a different job.
The NIST AI Risk Management Framework (AI RMF 1.0) helps you govern AI use and test model risk, with clear ownership before systems create harm. NIST published it as NIST.AI.100-1 on January 26, 2023, as voluntary guidance built on four functions: Govern, Map, Measure, and Manage. Because it's voluntary guidance rather than a certification program, it doesn't produce a compliance badge, and a team that "already does NIST" via CSF has not implemented this framework for AI risk.
The official designation is NIST.AI.100-1, voluntary guidance designed to improve trustworthiness across an AI system's lifecycle. NIST published it along with several companion materials to help teams apply the framework in practice: the AI RMF hub and the full NIST.AI.100-1 document, the AI RMF Playbook, the Roadmap, the Crosswalk, and the Generative AI Profile (NIST.AI.600-1, released in July 2024).
The framework organizes AI risk work into four functions that run throughout the AI lifecycle; here's what each one means:
These functions are interconnected and iterative across the AI lifecycle. They aren't a one-time checklist or a numbered vendor roster. NIST organizes the framework's details into a structure called the Core, which breaks each function into categories and subcategories you can tailor by system risk.
The official AI RMF Playbook offers voluntary action suggestions mapped to those subcategories. It's neither a full checklist nor a mandate to complete every item. Teams use it after they know which systems are in scope and who owns the risk decisions.
NIST also publishes an AI RMF Roadmap for research and measurement priorities and AI RMF Crosswalks that align the Core with other standards and frameworks. Use those companions after the four functions are clear; they do not replace Govern, Map, Measure, or Manage.
Govern comes first for a reason. Without an owner, documented risk tolerance, and accountability, Map inventories remain incomplete, and Measure tests become optional theater. Tooling helps after policy exists, but it doesn't replace the four functions.
Lean security teams often forward the table above as the working artifact because it captures the essential actions without requiring deep familiarity with NIST's full Core structure. The rest of the Core, NIST's detailed breakdown of categories and subcategories within each function, adds specificity after you know who owns what, which matches how questions actually arrive from auditors and boards. First comes "who owns AI risk," then "show the inventory and evidence."
The AI RMF addresses AI risks by iterating through Govern, Map, Measure, and Manage to mitigate potential harm to people, organizations, and ecosystems. It steers design toward NIST's trustworthiness characteristics. That path goes beyond security controls alone.
Those three harm categories stay concrete in practice. For people, harm can include impacts on rights, safety, economic opportunity, and discrimination. For organizations, harm can include operational and financial harm, as well as reputational damage when model outputs fail or leak sensitive data. At the ecosystem level, harm can include failures that cascade across interdependent systems and the shared infrastructure across supply chains.
The seven trustworthiness characteristics from NIST are the design and evaluation targets for that work:
"Trustworthy" here is an engineering and governance target, not a marketing label. A model can sit behind strong access control and still fail fairness, privacy, or reliability tests. The CSF alone doesn't force you to run those tests.
For generative systems, NIST later extended AI RMF 1.0 with a Generative AI Profile covering prompt- and model-specific risks. That profile maps generative-specific risks onto the same four functions. It doesn't replace the base framework. Use it when prompts, foundation models, or retrieval pipelines change the harm surface, and don't treat it as a second parallel program.
CSF-fluent teams protect the model's environment. They rarely have a parallel motion for the model's decisions. For a deeper walkthrough of CSF itself, see the NIST Cybersecurity Framework guide.
CSF isn't obsolete, and the AI RMF isn't a replacement. You still need CSF-class controls protecting model endpoints and training data. You need the AI RMF to decide go or no-go, with evidence and ongoing monitoring behind it.
In practice, CSF-fluent teams already know how to protect a model endpoint. The gap shows up when a customer questionnaire or board pack asks whether the company "does NIST AI RMF." Access reviews and vulnerability scans answer the environment question. They do not answer whether anyone owns the model's harm scenarios or its evaluation evidence.
Fairness and explainability gaps clearly show the split. Securing an API doesn't tell you whether a scoring model disadvantages a group or whether operators can justify a high-stakes decision. Outcome risk needs its own owner and tests.
You can implement the framework in three phases:
Start with accountability, not software. Put someone, or a small body, in charge of AI risk tolerance. That body should approve high-impact use cases and halt deployments lacking evidence.
Publish a written AI policy covering acceptable use, data handling, and who approves exceptions. Define roles with a RACI matrix spanning security, legal, and the business. Integrate AI risk into your existing GRC rhythms so it doesn't become a parallel silo.
Do not start by buying a tool. Platforms and questionnaires help later, but they cannot invent ownership or risk appetite for you. A purchase without Govern leaves you with dashboards and no decision rights when a use case fails its evidence gate.
When teams eventually evaluate AI governance platforms, those tools should support the four functions you already defined rather than stand in for them.
Create an inventory that includes every AI system your organization owns, procures, or integrates. Document each system's intended purpose, the sensitivity of the data it processes, and the impact of its decisions. Third-party vendor models and hosted APIs belong in Map too: accountability for how external model outputs are applied remains with your organization, regardless of who trained the underlying weights.
For each system in scope, document its context and the potential harms it could cause. Record what the system is intended to do and what falls outside that scope. Poor mapping creates dashboards that appear thorough but overlook the decision paths where harm actually occurs.
Before go-live, insist on a minimum evidence pack. Include the relevant fairness and security tests, documented limitations, and the human oversight model. Treat evaluation as a gate, not a slide in a design review.
Unsanctioned tools still belong in Map when they process company data or influence decisions. Shadow AI creates the same outcome risk as approved systems when no one has mapped data flows or failure modes. That exposure is why teams track shadow AI data leaks as inventory and measurement problems, not just acceptable-use violations.
Assign a system owner for every in-scope AI system, with an escalation path for changes and incidents. Prioritize residual risk against your published tolerance and fund mitigations on a standing cadence rather than a one-time sign-off.
Monitor for drift, including unexpected outputs and vendor control failures. Incorporate lessons into Govern to keep policies, RACI, and risk tolerance up to date. Manage is where the framework becomes operational. Without owners and feedback, Map and Measure decay into static documents.
If you need external visibility into exposed assets and unsanctioned AI-related exposure on your attack surface, UpGuard's Breach Risk provides that view.
To operationalize vendor questionnaires against the same four functions, use the NIST AI RMF security questionnaire.
AI RMF 1.0 is voluntary guidance, meaning NIST frames it as a way to build trustworthiness into AI systems rather than as a compliance mandate. The full AI RMF 1.0 document (NIST.AI.100-1) serves as the primary reference text for teams implementing the framework.
It doesn't make your organization "NIST AI compliant." It also doesn't replace CSF or broader NIST compliance program work.
Legal regimes such as the European Union AI Act impose different, binding obligations. The AI RMF isn't a substitute for them. Similarly, ISO/IEC 42001 is a separate, certifiable AI management system standard—another instrument, not a renaming of AI RMF 1.0.
Use it to structure ownership, evidence, and outcome risk, not to earn a badge.