Why NIST AI RMF Matters (Even Though It Says Voluntary)
The NIST AI Risk Management Framework (AI RMF) arrived in January 2023 with a clear disclaimer: it's for voluntary use.
That qualifier matters if you’re operating in a vacuum. It doesn’t matter if you have customers in the EU, Colorado, New York, or California. It doesn’t matter if you’re a federal contractor or work in healthcare, finance, or payments. It doesn’t matter if your board is asking how you’re managing AI risk.
In those cases, the compliance requirement is already here. You just haven’t formatted it to match NIST’s structure yet.
The Voluntary/Mandatory Gap
Here’s what’s happening in real time:
The EU AI Act (effective now in phases) mandates risk management for high-risk AI systems. Violations carry scaled administrative fines: up to €35 million or 7% of global revenue for prohibited AI practices, up to €15 million or 3% of global revenue for high-risk system non-compliance, and up to €7.5 million or 1.5% of global revenue for providing incorrect information to regulators.
Colorado’s SB 24-205 (Colorado AI Act), passed in May 2024, requires algorithmic accountability for AI systems in consequential decisions, including loan approvals, housing, and employment. Main compliance obligations take effect May 1, 2026, giving organizations an active runway to implement controls now.
New York’s AI bias audit law (effective now) requires documented bias testing for any automated employment decision system.
California’s CCPA amendments (effective January 2025) treat AI-generated inferences about personal characteristics as personal information requiring disclosure and consumer control.
Federal contractor requirements - if you have a federal contract and use AI anywhere in your operations or supply chain, NIST guidance is moving from “suggested” to “expected.”
Industry specific rules don’t wait for NIST frameworks. HIPAA covered entities are already being audited on how they’re implementing guardrails for AI assisted diagnosis. Payment processors are implementing SOC2 Type II controls specifically for AI data handling. Mortgage lenders are documenting Fair Lending compliance for AI-assisted underwriting.
NIST’s “voluntary” framing is legally accurate. It’s also practically misleading.
Why Traditional Security Frameworks Miss AI Risk
Your existing risk management process probably looks like this:
Asset → Threat → Vulnerability → Control → Measure effectiveness
That works for infrastructure. A server has a known vulnerability. You patch it. You confirm the patch. Risk goes down.
AI breaks this model in three ways:
First, the asset is probabilistic. A machine learning model doesn’t have a fixed behavior. It makes decisions based on training data, weights, and sometimes randomness. The same input can produce different outputs depending on model-versioning, quantization, or how you weighted your training set. You can’t patch uncertainty.
Second, the threat landscape includes your own model. Traditional security threats come from outside (attackers, malware, misconfiguration). AI risk includes model drift (your model gets worse over time as real-world data shifts), data poisoning (your training data was compromised or biased), and emergent behavior (your model started doing something you didn’t design it to do). The threat is inside your own decision system.
Third, the control feedback loop is broken. In security, you measure control effectiveness by seeing if the threat was stopped. With AI, you need to measure trustworthiness: accuracy, fairness, robustness, explainability, safety. These don’t always align. A more accurate model might be less fair. A more explainable model might be less accurate. You need to decide which tradeoff is acceptable before deployment. Traditional frameworks don’t have a structured way to think about those tradeoffs.
NIST AI RMF does.
The Four Functions: Govern, Manage, Map, Measure
The framework organizes risk management into four sequential functions:
Govern: Establish the policies, roles, and accountability structures for AI risk management. Who decides if an AI system is safe to deploy? Who owns the risk if it fails? What’s your organization’s risk appetite for AI decisions? What training do your teams need?
Manage: Implement the controls and processes that mitigate risk. This is where the concrete work happens: testing for bias, documenting training data provenance, building human-in-the-loop workflows for high-stakes decisions, creating audit trails.
Map: Document your AI systems and their risk profiles. Which AI tools are you using? What data do they process? Who built them? How are they integrated into your business processes? Where do third-party AI vendors touch customer data?
Measure: Assess the effectiveness of your controls and the ongoing performance of your AI systems. Does your bias test actually catch the harms you’re trying to prevent? Is your model still accurate six months after deployment? Do your audit logs show what you expected?
These aren’t separate projects. They feed each other. You can’t measure effectiveness if you didn’t govern what “effective” means. You can’t manage risk if you haven’t mapped where the risk exists.
The Gotchas Nobody Talks About
As companies start implementing this, patterns emerge:
Human-in-the-loop is harder than it looks. Everyone agrees: high-stakes AI decisions (credit denials, employment screening, medical recommendations) need human review. The gotcha: when regulators audit you, they’ll ask “how many decisions actually got human review?” If the answer is “most of them, but not all,” they’ll ask “how did you decide which ones skip human review?” If you don’t have a documented, auditable answer, you’re exposed.
Data flow documentation creates liability. The moment you map where your data flows through AI systems, you’ve documented that you know it’s happening. That’s good for governance. It’s also evidence if something goes wrong. Companies are realizing they need to document not just what data goes into AI, but what the AI does with it, who has access to the outputs, and how long it’s retained. That level of transparency is new.
Vendor AI use is your blind spot. Most companies know their own AI use cases. Fewer know that their email vendor uses AI to filter spam, their CRM vendor uses AI to score leads, their recruiting software uses AI to rank candidates, and their cloud provider uses AI to detect anomalies. Each of those is an AI system processing your data or your company’s decisions. If regulators ask “what AI systems process customer data in your ecosystem,” the honest answer for most companies is “we’re not entirely sure.”
Audit trails for contested decisions are non-negotiable. EU AI Act, Colorado SB 24-205, and others are converging on one requirement: if a person challenges an AI-rendered decision, you need to be able to explain it. Not generally. Specifically. For that person. For that decision. In that moment. That means you need to log: what data went in, what the model output was, how confident the model was, whether a human overrode it, and what the reasoning was. Most companies logging AI decisions today aren’t logging that level of detail.
Compliance is industry-specific. A financial services company implementing AI for underwriting has different requirements than a retailer using AI for inventory prediction. A healthcare provider using AI for triage has different requirements than a logistics company using AI for routing. Generic “AI governance” doesn’t exist. You need a framework flexible enough to address your specific regulatory environment.
That’s where NIST’s approach is useful. It’s not prescriptive (it doesn’t tell you exactly what controls to implement). It’s structured (it gives you a way to think about the problem and prove you’ve thought about it).
Why This Matters Now
Three reasons companies should start moving on this:
First, regulators are looking. The EU is actively investigating AI use cases. Colorado’s law is signed and enforcement runway is active now. New York’s bias audit law is live. Federal agencies are auditing contractors. This isn’t coming. It’s here.
Second, first-movers have an advantage. Companies implementing RMF-style governance now are building muscle memory. They’re identifying problems while they’re still manageable. They’re creating documentation that regulators expect to see. By the time compliance becomes mandatory in their specific context, they’re already ahead.
Third, the cost of starting increases monthly. AI systems are more mature now. They’re more embedded in business processes. The more AI systems you deploy without governance, the harder it is to retrofit controls. Auditing and remediating ten AI systems is easier than remediating fifty.
What Comes Next
This is the beginning of a series. The next articles will walk through each function:
Govern: Building the policies and accountability structures
Map: Documenting your AI ecosystem (the one you know about and the one you don’t)
Manage: The specific controls that matter (testing, human-in-the-loop, audit trails)
Measure: How to know if your controls are actually working
Each function has specific gaps that companies hit. Each gap has practical ways to close it.
If you’re building AI, deploying AI, or using vendors who build AI, this series is for you.
The voluntary part is optional. The compliance part isn’t.