TL;DR
The NIST AI Risk Management Framework is voluntary guidance from the US National Institute of Standards and Technology for identifying and managing risk across the life of an AI system. It is organized as four functions: Govern, Map, Measure, and Manage. It is not a law, a certification, or a checklist, so nobody can be “NIST compliant.” What a team can do is show that each function has an owner, an artifact, and evidence that it ran.
Key Takeaways: Govern sets accountability and runs through the other three. Map documents each system and its context. Measure defines how you will know it is working. Manage is what you do when it is not. The framework is easier to evidence for systems whose behavior is reproducible and whose decisions leave a readable record, because Measure and Manage depend on being able to reconstruct what happened.
What the NIST AI RMF is
The AI Risk Management Framework, published by NIST as AI RMF 1.0 (document NIST AI 100-1) in January 2023, is a voluntary framework for managing the risks of AI systems to people, organizations, and the wider environment. NIST developed it in consultation with industry, government, and academia, and a companion Playbook suggests actions for each part of the framework.
Three things about its status are worth stating plainly, because they are routinely misrepresented.
It is voluntary. No regulator requires it by name. That does not make it irrelevant: examiners, auditors, customers, and some state AI laws treat it as a recognized reference, so a documented alignment to it is useful evidence.
It is not a certification. There is no audit that results in a NIST AI RMF badge. Vendors who claim otherwise are describing their own mapping.
It is about risk, not about a technology. The framework applies equally to a machine-learning model, a generative AI assistant, and an automation that executes business processes. What matters is what the system does, to whom, and what happens when it is wrong.
For a finance or operations team, the practical question is rarely “what does the framework say” and usually “what would we have to be able to show if someone asked.” The rest of this guide is organized around that question.
The four functions in operations terms
The framework’s core is four functions. Govern is cross-cutting: it sets the culture, policy, and accountability that the other three operate inside. Map, Measure, and Manage are applied to each AI system.
| Function | The question it answers | What it looks like for a process that executes work |
|---|---|---|
| Govern | Who is accountable, and under what policy? | A named owner for each AI system, a written risk tolerance, an approval path for new use cases, and a rule for who may change what |
| Map | What is this system, where does it act, and what could go wrong? | An inventory entry per system: the process it touches, the data it reads, the decisions it makes, the people affected, and the failure modes |
| Measure | How would we know it is working or drifting? | Defined metrics per system, such as error rate, exception rate, override rate, and reproducibility, tested on real inputs and tracked over time |
| Manage | What do we do when it is not? | Thresholds that trigger action, an incident path, a change process, a way to pause the system, and a record that shows what happened |
Govern is where most programs start and stall. The work is unglamorous: deciding who may approve a new AI use case, who owns each system after it goes live, and what level of error is tolerable for each process. A system with no named owner has no one to receive an alert.
Map is an inventory with context. A list of tools is not enough. The entry has to say what process the system touches, what it is allowed to decide, what it reads and writes, and who is affected when it is wrong. Systems embedded in vendor software are the usual gap, because nobody on the finance team thinks of the ERP’s new assistant as an AI deployment.
Measure turns “it seems fine” into numbers. Pick metrics that match the failure modes found in Map, and test them on your own inputs rather than vendor samples. For an automation that approves, posts, or pays, the useful measures are error rate, exception rate, how often a person overrides it, and whether the same input produces the same output.
Manage is the response. It covers thresholds that trigger action, an incident path, change control for the system’s logic, and the ability to pause it. It also requires a record of what the system did, because an incident cannot be investigated from a log that says only that a model returned a score.
The seven trustworthiness characteristics
Alongside the functions, the framework defines what a trustworthy AI system looks like. These are not controls. They are a lens for review, and each can be turned into a question you can ask of a live process.
| Characteristic | The question for an operations process |
|---|---|
| Valid and reliable | Does it produce correct outputs on your inputs, and the same output when the input is the same? |
| Safe | Can it cause harm to people or the business, and what stops it when it should not act? |
| Secure and resilient | Who can read its data, change its logic, or push it off course, and how does it behave when something upstream fails? |
| Accountable and transparent | Can you show who owns it, what it was authorized to do, and what it did on a given day? |
| Explainable and interpretable | Can a reviewer see why this transaction was treated this way, in terms they understand? |
| Privacy-enhanced | Does it touch only the personal data it needs, and where does that data go? |
| Fair, with harmful bias managed | Does it treat comparable cases comparably, and would you notice if it did not? |
Two of these tend to decide how hard the rest is. Valid and reliable, and explainable and interpretable, determine whether Measure and Manage can be done at all. If the same invoice can be treated differently on different days, you cannot measure reliability. If the reasoning behind a decision cannot be read, you cannot manage the failure when it appears.
How it relates to SR 11-7, the EU AI Act, and ISO 42001
Teams rarely adopt the NIST framework alone. It sits among several others, and they differ mainly in whether they bind you.
| Framework | Status | What it asks of you |
|---|---|---|
| NIST AI RMF | Voluntary guidance from a US standards agency | A risk management process across the AI lifecycle, expressed as four functions |
| SR 11-7 | Supervisory guidance applied by US bank examiners | Model development, validation, and governance for models used in decisions |
| EU AI Act | Binding regulation, phased in, with obligations that scale by risk tier | Record keeping, human oversight, and documentation for higher-risk systems |
| ISO/IEC 42001 | International standard for an AI management system, certifiable by audit | A documented management system, with evidence that you followed it |
They are compatible. The RMF is the broadest and least prescriptive, which makes it a good organizing structure: Govern broadly maps to the management-system requirements of ISO 42001, Measure and Manage to the validation and monitoring expectations of SR 11-7, and Map supports the documentation the EU AI Act asks for. For banks, our guide to AI model risk management under SR 11-7 covers that supervisory expectation in detail, and our piece on AI governance sets out how the frameworks reward the same underlying property: decisions that can be reconstructed after the fact.
The Generative AI Profile
In July 2024 NIST published a companion document, the Generative AI Profile (NIST AI 600-1). A profile applies the framework to a specific technology or use. This one identifies risks that are unique to or made worse by generative AI, with suggested actions for each.
The risk most relevant to business processes is confabulation: a generative model producing confident output that is wrong. The profile’s relevance to operations teams is the question it forces about placement. A generative model that drafts an email carries a different risk from one that decides whether an invoice is paid, and the profile expects the controls to differ accordingly. Where generative AI is used to read documents, the sensible split is the one we describe in our guide to intelligent document processing: probabilistic reading, deterministic deciding.
A 90-day path
A team starting from nothing can produce credible evidence in a quarter without a large program. The order below follows the functions.
Days 1 to 30: Govern and Map. Name an accountable executive and a working group. Write a one-page risk tolerance for AI in finance and operations: which decisions AI may make alone, which need a person, and which it may not touch. Build the inventory, including AI embedded in software you already own. For each entry, record the process, the data, the decision rights, the owner, and the known failure modes.
Days 31 to 60: Measure. For the three or four highest-risk systems, define metrics tied to their failure modes and set a baseline from real transactions. Include a reproducibility test: run the same inputs twice and compare. Decide the reporting cadence and who receives it.
Days 61 to 90: Manage. Write the response for each system: the thresholds that trigger action, who is called, how the system is paused, and how a change to its logic is approved and recorded. Run one tabletop exercise on a plausible failure, such as a wrong value posted to the ledger, and check that the record you hold would let you reconstruct what happened.
The output is a short evidence pack: policy, inventory, metric baselines, and a response plan, each with an owner and a date. That is what an examiner, auditor, or customer reviewing your alignment to the framework will ask to see.
Where Kognitos fits
The framework does not prescribe an architecture, and no platform makes an organization aligned to it. Policy, inventory, ownership, and tolerance are decisions your organization makes. Kognitos is not a governance, risk, and compliance tool and does not replace an AI inventory or a risk register.
What architecture changes is how much of Measure and Manage you can evidence rather than assert. Kognitos is neurosymbolic: the reasoning that decides what happens to a transaction is deterministic, so the same input under the same rules produces the same outcome and can be reperformed. Processes are written and read in plain English, so a reviewer can see the rule that was applied. Every decision produces a record of what was determined and on what basis, which turns the question “what did it do on March 3” into a lookup.
Those properties line up with the characteristics that make the rest of the framework tractable: valid and reliable, accountable and transparent, explainable and interpretable. For the audit-trail detail, see our checklist of AI audit trail requirements.
For related material, see our guides on AI governance, AI model risk management under SR 11-7, AI audit trail requirements, the top risks in AI, and neurosymbolic AI. To see deterministic execution with a full record of every decision, book a demo or try the platform.
