A familiar pattern shows up in public-sector AI policies. Somewhere near the top, the policy says it is “based on the NIST AI Risk Management Framework,” and then it lists four words: Govern, Map, Measure, Manage. Sometimes there is a table. Rarely is there a name.
The NIST AI RMF (NIST AI 100-1, released January 2023) is one of the most cited AI governance references in American public-sector policy, and it is also one of the most misread. Many county policies treat it as a standard to meet. NIST wrote it as voluntary outcomes for managing risk, and it asks, before anything else, who is responsible for each one.
This is the first of four posts on how the Integrated Requirements Methodology, the method behind the Encephalon Enterprise AI Governance Practice and Tools, maps to, or draws on, the standards and laws local governments are asked about. The other three cover ISO/IEC 42001, the EU AI Act, and Florida law and Chapter 119.
What NIST actually wrote
Three sentences from the framework itself change how a county should use it.
On its status, NIST says the framework “is intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic.” NIST offers no certification against the AI RMF, and a policy that says the county “complies with” it is claiming something the framework never offered.
On its structure, NIST says the actions under each category “do not constitute a checklist, nor are they necessarily an ordered set of steps.” The subcategories are outcomes. A county picks the ones that fit its risks and decides how to reach them.
On the four functions, NIST says “GOVERN is a cross-cutting function that is infused throughout AI risk management and enables the other functions of the process.” And earlier in the document, that while GOVERN applies across the organization, “the MAP, MEASURE, and MANAGE functions can be applied in AI system-specific contexts and at specific stages of the AI lifecycle.”
That last pair is where counties go wrong.
The two mistakes
The first mistake is treating GOVERN as a committee. A county forms an AI steering group, writes its charter, and considers the GOVERN function done. But GOVERN 2.1 asks for something more specific: “Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization.” GOVERN 3.2 goes further and asks for policies that “define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.” A committee that meets monthly does not accept an output on a Tuesday afternoon.
The second mistake is running MAP once, for the whole county. A county is rarely one organization. In many states, some offices are headed by independently elected officers who do not report to the county commission, keep their own records, and answer to their own statutes. A single enterprise risk map written by the commission side cannot bind those offices, and NIST does not ask it to. MAP 1.1 asks that “context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented.” The laws that govern a court clerk’s records are not the laws that govern a planning department’s. The context is per use, and in a county, per office.
How the method maps to the framework
The Integrated Requirements Methodology adapts the Kimball Lifecycle, the requirements discipline that made data warehousing repeatable, to AI. On the governance side it produces four governance objects, each answering a question an auditor will ask. Here is each one, the NIST function it maps to, and the subcategories it gives evidence for.
| Governance object | The question it answers | NIST function | Subcategories it maps to |
|---|---|---|---|
| Jurisdictional standards by project | Which rules govern this specific use, and who says so | Govern and Map | GOVERN 1.1, MAP 1.1 |
| Human-acceptance authority by decision class | Who is accountable for accepting this output, by name and role | Govern | GOVERN 2.1, GOVERN 3.2 |
| Verification thresholds by risk tier | How much checking is enough before this output is relied on | Measure | MEASURE 1.1 (in part: proportioning checks to the most significant risks) |
| Sanctioned-model lists by use case | What is approved for this use, and what is not | Manage | MANAGE 1.3, MANAGE 3.1 |
GOVERN 1.1 reads: “Legal and regulatory requirements involving AI are understood, managed, and documented.” Jurisdictional standards are that documentation, written per project rather than once for the enterprise, which is the only way it holds when different offices answer to different statutes.
MEASURE 1.1 asks, in part, that measurement approaches be “selected for implementation starting with the most significant AI risks.” Verification thresholds proportion checking to risk tier for that reason. How much checking is enough is a call the method makes, not something MEASURE 1.1 specifies: a draft email that staff rewrite before use needs a read-through, and an output that feeds a determination about an identified person needs a reviewer able to reach the opposite conclusion from the underlying record.
MANAGE 1.3 names the risk response options NIST offers for high-priority risks: “mitigating, transferring, avoiding, or accepting.” Sanctioned-model lists are how a county records which of those it chose for a given use. MANAGE 3.1 covers the fact that nearly every model a county uses comes from a vendor: “AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.”
That table describes how the method is built. It is not a report of results: Encephalon has not yet run this method under a public-sector contract.
The artifact that ties the four objects together is the Authorization Record. For each AI-touched decision, it names the person accountable for accepting it. That is what GOVERN 2.1 looks like when someone asks for proof. MAP 3.5 covers similar ground from within MAP, tying human oversight back to GOVERN policy: “Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from the GOVERN function” (NIST AI 100-1, p. 27). Human-acceptance authority and verification thresholds both feed that documentation.
Tiering, and the tier nobody can accept
The method assigns each use case to one of four tiers by reading its tests starting from the top tier, Reserved. The test applies to the workflow, not the tool. So the same product can sit in different tiers in different offices.
A use case is Reserved where law, rule or an office’s own instrument reserves the determination to a person, or where nobody in the workflow can reach the opposite conclusion before the output is acted on. No role the framework creates can accept a Reserved output. Where a use case is Reserved only because nobody can reach the opposite conclusion in time, adding a person who can moves it down to Consequential. A determination that law, rule or an office’s own instrument reserves to a person stays Reserved, whoever is added to the workflow. The Reserved tier maps to MANAGE 1.1: “A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed.” Sometimes the answer is no, and a framework should be able to say so without a committee vote.
No office is bound by a tier it did not record. The method delivers each assignment as a recommendation. The owning office may raise a tier on its own material without giving a reason, and may lower one by recording its basis in its own instrument. The Authorization Record keeps both the office’s decision and what the published test would have assigned, so a divergence is visible instead of silent. For an independently elected officer, that is the difference between a framework they can adopt and one they have to refuse.
Two more places the mapping shows
GOVERN 1.6 asks that “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” An internal inventory of the county’s AI uses meets that. The method’s transparency work goes a step further with a public AI registry design, so a resident can see which county decisions AI participates in. NIST does not ask for publication; for a public body it is usually the point.
MEASURE 3.1 asks for approaches “to regularly identify and track existing, unanticipated, and emergent AI risks.” The method closes with a periodic assessment cadence and a written operating procedure so county staff can rerun the assessment, the use case rubric and the records gate without a consultant in the room.
One caution about subcategory numbers
NIST’s own AI RMF page now states that “The AI RMF 1.0 is being revised as part of the White House AI Action Plan.” Subcategory numbering and wording can change, so any crosswalk that cites IDs, including the table above, needs to be rechecked when the revision is published.
If your county’s AI policy names the four functions and nobody can say who accepted last week’s AI-drafted notice, the whitepaper covers the governance gap and the Kimball roots of the method. Or book a 30-minute discovery call with the founding team and bring the policy with you.
Primary sources cited
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. Voluntary status p. 2; “not a checklist” p. 20; GOVERN as cross-cutting p. 22; system-specific application of MAP, MEASURE, MANAGE p. 3; GOVERN 1.1, 1.6, 2.1, 3.2 pp. 22-23; MAP 1.1 p. 26; MAP 3.5 p. 27; MEASURE 1.1 p. 29; MEASURE 3.1 p. 30; MANAGE 1.1, 1.3, 3.1 p. 32. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
- NIST, AI RMF Playbook (suggested actions for the AI RMF Core). https://airc.nist.gov/airmf-resources/playbook/
- NIST, AI Risk Management Framework program page, including the statement that AI RMF 1.0 is being revised. https://www.nist.gov/itl/ai-risk-management-framework
