From Shelf to Practice: Making the NIST AI Risk Framework Work for Your Business

Cover graphic for From Shelf to Practice: Making the NIST AI Risk Framework Work for Your Business
Fig. 1. NIST AI RMF Article Infographic, Jeremy Swenson, 11/14/2026.

AI GOVERNANCE · RISK MANAGEMENT

A leader’s playbook for turning voluntary AI guidance into a repeatable business discipline—without requiring a data science degree. As artificial intelligence becomes a board-level priority, business leaders are increasingly accountable for managing its risks, yet much of the available guidance is written by engineers for technical audiences. The NIST AI Risk Management Framework (AI RMF) offers a common, practical approach that helps organizations translate AI risk guidance into business practices, establish accountability, strengthen governance, and support responsible innovation. Here’s what the framework is, why it is increasingly becoming an expected standard, and how business leaders can begin putting it into practice today. This is based on my 29-page white paper, which has amassed almost 21,000 views!

Key takeaways

• It’s a cycle, not a project. Four functions (Govern, Map, Measure, Manage) run continuously across an AI system’s whole life.

• Voluntary in name only. Regulators, insurers, and enterprise customers increasingly treat it as the reference point.

• A credible program takes about a year. Start with governance and an inventory, not technical testing.

• The top failure mode is treating the framework as a checklist, or testing before anyone owns the results.

• Alignment ≠ compliance ≠ risk reduction. Frameworks give the work a defensible shape. They don’t do the work.

Why this belongs on the leadership agenda:

NIST published the AI RMF (NIST AI 100-1) in January 2023 as voluntary guidance for any organization that builds, buys, or simply uses AI. Its core is organized into four functions with roughly seventy specific outcomes, and it is explicitly meant to be tailored rather than adopted wholesale.

It is tempting to hand AI risk to IT. That instinct is wrong. The framework’s Govern function is about leadership, accountability, and culture: decisions only the business can make. And the pressure to act comes from every direction: regulators referencing “recognized frameworks,” procurement questionnaires asking whether vendors have adopted the AI RMF, insurers pricing in governance maturity, and the EU AI Act, whose high-risk requirements closely mirror the framework’s structure.

History is instructive. NIST’s Cybersecurity Framework launched as voluntary guidance in 2014 and became a de facto requirement long before most organizations treated it that way. The AI RMF is on the same path, even as the rules beneath it shift. Colorado’s first-in-the-nation AI law was repealed and replaced in May 2026 with a narrower disclosure law taking effect in 2027. At the federal level, OMB rewrote its AI memoranda in 2025, yet both new memos still point to NIST for the technical substance. The lesson: specific statutes change, so revisit any legal citation regularly. The framework is the stable anchor.

The four functions in plain language:

The NIST AI Risk Management Framework is organized around four core functions: Govern, Map, Measure, and Manage. Together, they provide organizations with a practical structure for establishing accountability, understanding AI-related risks, evaluating control effectiveness, and responding to identified issues.

Govern establishes the leadership, policies, and accountability structures that support everything else. It answers: Who is accountable, and what rules govern the organization’s use of AI? Map involves developing a comprehensive inventory of AI systems and understanding their business purpose, operating environment, and potential risks. It answers: What AI systems do we have, how are they being used, and where could things go wrong? Measure focuses on evaluating AI systems against defined metrics, including bias, accuracy, performance drift, and explainability. It answers: How do we know our controls are working, and can we demonstrate that the technology is performing as intended? Finally, Manage translates those findings into action through risk mitigation, ongoing monitoring, remediation, or retirement of systems when necessary. It answers: What do we do about the risks and weaknesses we’ve identified?

These four functions apply throughout an AI system’s lifecycle, from initial planning and procurement through development, deployment, ongoing monitoring, and eventual retirement. An AI model that passes testing at launch may perform very differently 18 months later as underlying data changes, operating conditions evolve, or a vendor quietly updates its model. Risk management cannot be treated as a one-time approval exercise; it requires continuous oversight. The framework also emphasizes clearly defined roles and responsibilities. Data providers, developers, testers, deployers, operators, and end users all contribute to AI risk management. In practice, many control gaps emerge not because organizations lack policies or technology, but because responsibility for a particular risk was never clearly assigned to anyone.

Step one: build governance, then know what you have:

The NIST AI RMF Operationalized infographic by Jeremy Swenson
Fig. 2. The NIST AI RMF Operationalized Infographic, Jeremy Swenson, 11/08/26.

Govern comes first because the other functions have nowhere to report without it. You need written answers to four questions: Who is accountable (a named person with budget and authority, not a committee name)? Which policies cover how AI is built, bought, and deployed? How does AI risk connect to enterprise risk management? And what is your risk tolerance? Many organizations borrow the familiar “three lines of defense”: the business owns the risk, a risk or compliance function sets policy and challenges it, and internal audit tests both.

Map starts with a complete inventory, and the most common mistake is scope. Organizations catalog what they built and forget what they bought: the HR resume screener, the marketing content generator, the AI feature switched on inside existing SaaS. Unsanctioned “shadow AI” use of consumer tools by staff belongs on the radar too. For each system, record what it does, what data it touches, who it affects, and which decisions it influences. Then assign a risk tier: high (credit, hiring, medical), medium (customer chatbots, scheduling), or low (email sorting, document search). Resist bringing everything to full compliance at once; that path leads to paralysis.

Step two: measure what matters, then act on it:

Measure turns qualitative concerns into numbers you define in advance: disparity across demographic groups, accuracy against ground truth and drift over time, whether users can understand and challenge outputs, and for generative AI, how often it confidently states things that are false. If accuracy slips from 94 to 87 percent, you want to know before your customers do. Internal testing is necessary but not sufficient. Independent audits and red-teaming catch blind spots and carry more weight with regulators and customers.

Manage is the response. Decide ahead of time whether to mitigate, accept, transfer, or avoid each risk, and document why. Define incident escalation paths, build monitoring into daily operations rather than an annual review, and keep a real process for retiring systems, including data retention and transition planning.

The risk areas leaders get asked about:

Leaders should pay particular attention to several emerging AI risk areas. For generative AI, organizations should use NIST’s Generative AI Profile (AI 600-1) to guide risk management. This includes monitoring for confabulation and information leakage and conducting ongoing red-team testing rather than limiting assessments to the pre-launch phase.

Third-party vendor risk requires additional scrutiny. Organizations should understand what data was used to train a model, whether their proprietary data will be used for retraining, and what happens when a vendor changes its underlying models. Audit rights and advance notification of material changes should be negotiated before signing agreements. Cybersecurity teams should also incorporate AI-specific threats, including prompt injection, model inversion, and data poisoning, into existing security programs. Frameworks such as NIST SP 800-218A and MITRE ATLAS can help identify, assess, and address these evolving threats.

Privacy and model risk management practices should extend to AI training and inference data. Organizations should maintain independent model validation and appropriate board visibility, even where newer banking guidance provides exceptions or different treatment for generative AI. Human oversight should reflect the level of risk involved: high-risk decisions warrant a human in the loop, medium-risk decisions require human oversight, and lower-risk applications can rely on periodic spot checks. Organizations should also test whether employees have the authority and ability to override AI decisions before an actual incident occurs.

Incident management is another critical consideration. Organizations should establish their own definitions of reportable AI incidents, identify who must be notified and within what timeframe, and ensure lessons learned translate into updated policies and controls.

Finally, don’t overlook your own engineers. As AI coding assistants generate more production code, organizations need current architecture documentation to serve as ground truth. AI-assisted code changes should be validated against established architecture and design requirements, not simply accepted because automated tests pass.

Proof it works at scale:

In February 2026, the Cyber Risk Institute released the Financial Services AI Risk Management Framework, built with more than 100 institutions and input from regulators including NIST. It doesn’t replace the AI RMF; it operationalizes it, expanding the four functions into 230 control objectives. A short questionnaire sorts each institution into an adoption stage, so a community bank piloting one chatbot isn’t held to the same bar as a global bank running dozens of models. Three lessons travel to any industry: translate the functions into auditable controls, integrate with frameworks you already run, and scope requirements to actual maturity.

Alignment, compliance, and risk reduction are three different things:

The AI RMF is designed to plug into what you already have, not to compete with it. It interoperates with NIST’s Cybersecurity and Privacy Frameworks, maps clause-by-clause to ISO/IEC 23894, pairs with certifiable ISO/IEC 42001, and fits naturally into COBIT governance and SOC 2 controls. A useful shorthand: NIST answers the what and why of AI risk, while ISO answers the how of proving you did it consistently.

But this is the most consequential misunderstanding in the space: adopting the AI RMF does not make you compliant with the EU AI Act, HIPAA, or a state automated-decision law, each of which carries its own requirements. Even an ISO 42001 certificate confirms that a management system exists and is followed, not that every decision inside it was right. The real risk management is the bias testing, red-teaming, monitoring, incident response, and human review. Frameworks make that work defensible. They are not a substitute for it.

How to know it’s working:

NIST’s own Implementation Tiers offer a built-in maturity model, from Tier 1 (Partial, reactive and informal) to Tier 4 (Adaptive, continuously improving). Most organizations start between Tiers 1 and 2, which is fine. The goal is not Tier 4 everywhere; high-risk systems should move toward Tiers 3 and 4, while a low-risk internal tool may never need more than Tier 2. Track movement over time, not a static score, and revisit the program at least semi-annually or whenever technology, threats, regulations, or risk appetite change.

Pair that with a short, decision-oriented report rather than dashboard theater. Useful monthly and quarterly measures include:

• Inventory coverage: share of known AI systems with a completed risk tier.

• Testing currency: share of high-risk systems tested within policy windows.

• Human override rate: a rate near zero can signal rubber-stamp review, not a perfect model.

• Overdue remediation, incidents by severity, and vendor attestations on file.

• Shadow AI discoveries: tools found in use that never entered the inventory.

Your next step:

Don’t try to implement all four functions at once. Name one accountable owner this week and give that person thirty days to produce a first-draft inventory of every AI system in use. Everything else (risk tiering, testing, response plans, framework mapping, metrics) has somewhere to attach once that exists.

The organizations that struggle are rarely the ones that started imperfectly. They are the ones that waited for a mandate that arrived quietly, as a lost contract, a denied insurance claim, or a regulator’s question they couldn’t answer with documentation. Momentum, not completeness, is what turns this framework from a document on a shelf into an operating discipline.

Where is your organization on this journey: still building the inventory, or already measuring? Share what’s working (and what isn’t) in the comments.

#AIGovernance #NISTAIRMF #RiskManagement #ResponsibleAI #Cybersecurity #AIRisk