An AI-generated discussion of this article, created with NotebookLM. It paraphrases rather than reads the text, so the wording is the model’s rather than mine.
The NIST AI Risk Management Framework is voluntary guidance for managing the risks that artificial intelligence creates, organized around four functions: Govern, Map, Measure, and Manage. For a business with substantial operations and no dedicated risk department, the useful portion reduces to four questions: who owns each system’s outcomes, where is AI actually being used, how would you know if it stopped working correctly, and what happens when output is uncertain.
Background
The National Institute of Standards and Technology (NIST) is a United States government agency responsible for developing technical standards across a wide range of industries. Its cybersecurity framework has become an important reference point for corporate security policy and risk management.
In January 2023, NIST published the Artificial Intelligence Risk Management Framework, commonly referred to as AI RMF 1.0. The framework is voluntary guidance rather than regulation, and it establishes no certification. Its stated purpose is to help organizations manage the risks that artificial intelligence presents to individuals, organizations, and society, and to incorporate considerations of trustworthiness into the design, development, use, and evaluation of AI systems.
The framework has become significant for practical rather than regulatory reasons. It provides a common vocabulary for organizations evaluating their AI practices across areas such as risk, compliance, and procurement. A related standard, ISO/IEC 42001, establishes requirements for an AI management system and can be used as the basis for third-party certification. NIST has also published a companion document addressing generative AI specifically, recognizing that generative AI introduces or intensifies risks that require additional consideration.
The Four Core Functions
AI RMF 1.0 is organized around four functions intended to operate continuously rather than as a simple sequence: Govern, Map, Measure, and Manage. Each function addresses a distinct question, and for organizations without a dedicated risk or compliance department, each can be implemented at a scale appropriate to the business.
Govern concerns accountability. The relevant question is not who built a system, but who owns its outcomes. This distinction matters more for AI than for conventional software because AI failures can be less visible. A broken integration produces an error message; a model that has begun misreading a new document format may continue producing plausible but incorrect output. For a smaller organization, adequate governance may consist of a single documented paragraph per system stating its purpose, its owner, the criteria by which it is judged to be functioning correctly, and the response when it is not.
Map concerns context. The framework asks organizations to establish what a system does, whom it affects, and what the consequences of failure would be. In practice, the initial task is an inventory. Many organizations have more AI in active use than they are aware of, much of it introduced without a formal decision: features added by existing software vendors, transcription tools adopted by individual teams, and general-purpose chatbots used informally with business data. A system that has not been identified cannot be managed.
Measure concerns ongoing evaluation, and it is a function that can easily be neglected. An accuracy figure established at deployment has limited value. A document extraction process operating at ninety-five percent accuracy may be entirely acceptable if its errors are randomly distributed across low-consequence fields, and unacceptable if those errors are concentrated in the fields that determine pricing or in documents originating from a single major customer. Meaningful measurement therefore requires scheduled sampling of live output rather than a one-time assessment. This is particularly relevant in trade and logistics environments, where document formats change continuously as suppliers change systems, jurisdictions revise forms, and partners alter their submission methods. Degradation of this kind can be gradual and may produce no obvious alert.
Manage concerns response. The framework calls for prioritizing identified risks, responding to incidents, and maintaining the cycle over time. For operations-intensive businesses, one of the most consequential elements is the design of the fallback path. When output is flagged as uncertain by confidence thresholds, validation rules, or other controls, it should be routed to a person, and the reason for that uncertainty should be visible. Systems that present questionable output identically to validated output allow errors to propagate downstream unchallenged. This is an architectural decision made at design time and cannot be adequately addressed through policy afterward.
The four functions reduce to four questions: who owns the outcomes, where is AI in use, how would degradation become visible, and what happens when output is uncertain.
Generative AI Considerations
The risks associated with large language models differ in important ways from those of earlier statistical models, which is one reason NIST published a separate generative AI profile. That document identifies risks including model confabulation, commonly called hallucination, and intellectual property concerns. A system that fabricates a plausible invoice number represents a category of failure that conventional software controls were not generally designed to address.
The appropriate response is generally architectural rather than procedural. Grounding a system in the organization’s own data, constraining output to defined formats, and validating results against an authoritative source can all reduce the likelihood that fluent output will be mistaken for correct output.
It should be noted that the framework itself continues to develop. NIST has indicated that AI RMF 1.0 is under revision, and in April 2026 released a concept note for a framework profile addressing trustworthy AI in critical infrastructure. Organizations should therefore treat the framework as a current reference rather than a fixed standard.
A Minimum Viable Implementation
For an organization with substantial operations and no dedicated AI governance function, a reduced implementation can be sketched in a single working session and can address several common areas of exposure:
A worked example of the resulting register, for a mid-sized freight and distribution business, shows what this produces in practice.
- Compile an inventory of all locations where AI is currently in use, including capabilities introduced through existing software vendors.
- Assign a single named owner to each identified system.
- For any system affecting financial transactions, customer outcomes, or regulatory compliance, document the criteria that define correct operation and establish a regular review against those criteria.
- Define the handling procedure for outputs flagged as low confidence, uncertain, or inconsistent with validation rules.
- Review the inventory quarterly, as its contents are likely to change more rapidly than expected.
This does not constitute full adoption of the framework. It does, however, address a common and avoidable failure pattern: organizations that deploy AI capably but establish no mechanism by which degradation or error will be detected.
Where to Start
Most organizations do not need a governance program on the scale the framework describes. What they need first is to know what they already have running, who is responsible for it, and how failure would become visible. That is a smaller exercise than the framework suggests, and it is usually the difference between an AI deployment that holds up and one that quietly stops working.
If you would like to talk through where your organization stands, I am glad to have that conversation. You can reach me at mike@redtreelabs.com, or through the contact form.