NobleCloak
Governance Watch

NIST AI RMF for compliance officers who dont build models

Author

Audrey

NobleCloak's AI Correspondent · AI-drafted, fact-checked against our sourced evidence before publishing.

Date Published

What happened

This one isn't news in the "a rule just dropped" sense — it's a resource that's been sitting in plain sight, and most compliance owners have been told (wrongly) that it's for engineers. So consider this the practitioner's read on why it belongs on your desk.

The NIST AI Risk Management Framework (AI RMF 1.0) was released in January 2023. It is explicitly voluntary — NIST publishes standards, not regulations — and it's organized around four plain-language functions: Govern, Map, Measure, and Manage. In July 2024, NIST added a companion, the Generative AI Profile (NIST AI 600-1), which applies those same functions to the specific risks of generative AI.

The framing that trips people up: the AI RMF was written with AI developers prominently in mind, and the GenAI Profile catalogs a long list of technical actions a builder can take. If you read it as a build spec, it looks like homework you're not qualified to do. That's the wrong lens. Read as a vocabulary and a crosswalk, it's the most useful thing a non-engineer compliance officer can put between their AI exposure and their examiner.

Why it matters

Here's the problem the AI RMF quietly solves. You own AI risk at your institution, but you don't speak the language your vendors' security teams speak, and — more importantly — there's no single regulatory rulebook that tells you what "good AI governance" looks like. The Fed carved generative AI out of its model-risk guidance. The NCUA can't even examine your tech vendors. Reg S-P gives you an oversight obligation but no AI-specific structure. You're standing in a vacuum with a duty and no map.

The AI RMF is the map. Not because it's mandatory — it isn't — but because it's the common reference the whole field has converged on. When a vendor describes its AI controls, it increasingly maps them to NIST functions. When an examiner reaches for a way to evaluate whether your AI governance is real, NIST is the neutral yardstick they'll recognize. Adopting its vocabulary means you and everyone assessing you are finally using the same words. Govern, Map, Measure, Manage translates directly to what an examiner actually wants: Do you have a policy? Do you know where AI is? Do you check it? Do you do something about what you find?

That's the whole trick. You're not implementing NIST. You're borrowing its four verbs so that your existing compliance work becomes legible to people who assess AI for a living.

What it means for you

If you're a credit union or community bank: you already run a third-party risk management program on a proportional basis — the NCUA's own 07-CU-13 framework tells you to scale diligence to the vendor's risk. NIST doesn't replace that; it organizes it for the AI dimension. Do-this-Monday:

  • Take your existing AI inventory and sort each entry under Map. Map is just "know where your AI is and what it touches." If you've run an AI data call, you've already done the hard part — you're just relabeling it in a vocabulary the examiner recognizes.
  • Point your existing vendor-management policy at Govern. You don't write a new policy; you show that your AI oversight lives inside the governance you already have.
  • Use the GenAI Profile's risk list as a question bank, not a to-do list. It names real generative-AI risks (data leakage, provenance, harmful outputs). You're not mitigating them as an engineer — you're asking your vendors how they mitigate them. That's diligence, in NIST's words.

If you're an RIA or broker-dealer: your driver is Reg S-P service-provider oversight, which demands written policies and ongoing monitoring but doesn't tell you what to write. NIST fills the blank. Structure your service-provider oversight file under Govern/Map/Measure/Manage and you've turned a vague obligation into a defensible framework — and you've done it using a reference the SEC's examiners already know. That's also your defense against an "AI washing" finding: NIST-shaped evidence is harder to wave away than a marketing sentence in your ADV.

For everyone: the single highest-value move is the crosswalk. One column is your regulator's language (07-CU-13, Reg S-P 248.30, FFIEC third-party risk). The next is the NIST function. The next is the specific evidence you hold. That table is the most examiner-friendly artifact you can build, because it answers "how do you govern AI?" in the questioner's own vocabulary.

How to get ahead of it

The prepared team builds the crosswalk once and reuses it at every exam and in every vendor conversation. Keep it deliberately small: the four NIST functions down one axis, your live obligations across the top, and a real piece of evidence in each cell — a dated inventory, a signed policy, a vendor questionnaire response, a monitoring log. When it's empty in a cell, that's your roadmap; when it's full, that's your binder.

Two disciplines keep it honest. Don't claim a function you can't evidence — writing "Measure: yes" with nothing behind it is worse than an honest gap, because it reads as AI washing the moment someone asks to see it. And treat the GenAI Profile as your vendor-question source rather than your engineering backlog: its value to you is the questions it makes you smart enough to ask, not the mitigations it expects a developer to implement.

If you want the ready-made version, this is the same spine behind a 07-CU-13 / NIST AI RMF crosswalk and an examiner-ready AI evidence binder.

What to watch out for

The overreaction is to treat the AI RMF as a certification. There is no "NIST AI RMF certified." It's a voluntary framework; nobody hands you a badge, and any vendor implying they can "certify you to NIST AI RMF" is selling a fiction. What you can honestly say is that you use the framework to organize your AI governance — that's true, useful, and examiner-credible.

The second trap is scope-creep in the wrong direction — a small compliance team trying to implement the 400-plus developer actions in the GenAI Profile. You are not the developer. Almost none of those actions are yours to perform; they're your vendors'. Your job is to know the risks well enough to ask, and to record the answers. Mistaking the developer's checklist for your own is how a two-person program drowns in someone else's homework.

And the honest boundary: NIST gives you structure, not facts about your specific vendors. The framework can tell you that provenance and data-retention are risks worth governing; it can't tell you what OpenAI, your CRM, or your custodian actually does with your customer data. That part is diligence you (or someone) still has to perform. NIST is the shape of the answer, not the answer.

The bottom line

The NIST AI Risk Management Framework isn't an engineering mandate and it isn't a rule — it's the shared vocabulary that makes your AI governance legible to the examiner standing in the same regulatory vacuum you are. Use its four verbs to organize what you already do, build the crosswalk once, and evidence every cell honestly. Turning that structure into a filled binder — the vendor facts NIST can't give you, mapped to the functions it can — is exactly what a Discover scan is designed to produce.

See what a Discover scan finds.