NIST AI RMF in Depth — Govern & Map

Maintain an obligation register that links each AI system to every law and regulation that touches it — EU AI Act risk tier, GDPR status, sector rules (HIPAA, FERPA, DORA), state privacy laws. Assign an owner and a review cadence tied to regulatory change velocity. For the EU AI Act, this includes documenting whether the system is prohibited, high-risk, limited-risk, or minimal-risk — and which provider or deployer obligations apply.

• Obligation register with regulation name, applicability determination, owner, and last-reviewed date
• Sign-off from Legal on each AI system's classification
• Process for updating when new regulations take effect

The seven NIST trustworthiness characteristics (valid & reliable, safe, secure & resilient, accountable & transparent, explainable & interpretable, privacy-enhanced, fair) must appear in your AI policy — not just as listed values, but as design constraints. For example: the AI AUP clause prohibiting black-box models for consequential individual decisions implements the "explainable" characteristic. The bias-testing requirement in the development checklist implements "fair."

• AI policy document that references each trustworthiness characteristic with operational definition
• Development checklist items traceable to specific characteristics
• Documented tradeoffs where characteristics conflict (e.g., explainability vs. accuracy)

Risk tolerance is not a feeling — it is a documented, board-approved statement that drives tiering decisions. Higher-impact AI systems get deeper MAP, MEASURE, and MANAGE work; lower-impact systems use a lighter process. Without a risk tolerance statement, every system gets either too much scrutiny (inefficient) or too little (dangerous). The tolerance statement should define at minimum: what constitutes "high risk" for this organization, what governance controls apply at each tier, and who can approve exceptions.

Risk tolerance: "AI systems that influence student academic outcomes or employment decisions are High Tier. AI systems used for administrative productivity are Low Tier. High-Tier systems require MAP worksheet, bias testing, and Governance Board approval. Low-Tier systems require self-registration and annual review."

Each team that builds, deploys, or uses AI must understand their specific risk management responsibilities. This is not the same as having a central AI governance team — it means every relevant team (IT, HR, Finance, Academic Affairs) has named individuals who own AI risk for their scope. The central governance function sets the standard; business units execute it.

The AI Use Case Register (AI system inventory) is the operational artifact here. Every approved AI deployment is recorded with: system name, owner, intended purpose, data inputs, EU AI Act risk tier (where applicable), human oversight model, deployment date, and next-review date. This register is the "asset inventory" for AI — you cannot manage what you haven't counted. Shadow AI detection becomes a gap analysis against this register.

• System name and version
• Business owner and technical owner
• Intended purpose (one sentence)
• Data inputs (classification level)
• EU AI Act tier / organizational risk tier
• Human oversight model (HITL / HOTL / HOOL)
• Deployment date and next review date

AI systems cannot simply be "turned off" — they must be retired safely. Data must be deleted or archived appropriately; users must be notified; dependent downstream systems must be migrated. Decommissioning policies prevent the scenario where a deprecated model continues running in production because nobody knows it's there or how to stop it. Required elements: notification lead time, data disposition procedure, downstream system inventory, and user communication plan.

The organization defines how risks are identified — not for a specific system, but as a repeatable methodology. This includes: intake process for new AI proposals, red-team and adversarial evaluation standards, bias testing requirements, and triggers for re-evaluation (significant model update, change in deployment scope, new regulatory requirement, incident). GV-1.7 is the policy; MAP is the execution.

Define and document at minimum: AI Governance Lead (chairs the steering committee, owns the use-case register), AI Risk Owner (assesses and treats AI risk per the taxonomy), AI Security Lead (owns technical controls and threat response), Model Owner (accountable for a specific AI system's behavior), Data Steward for AI (data provenance and quality). Larger organizations may add a Responsible AI Officer. Each role needs a written description, a named person, and a backup.

Calling the CISO "the AI risk owner" with no additional resources or authority — then wondering why AI governance doesn't happen. The CISO is already accountable for everything else. AI governance requires dedicated roles or dedicated allocation of existing capacity.

Training is role-differentiated — not everyone needs the same depth. Three tiers: Awareness (all staff — what is AI risk, what's in the AUP, what to report), Practitioner (AI product teams, business analysts — MAP worksheet completion, bias evaluation, prompt engineering security), Expert (AI Governance Lead, Risk Owner — full NIST AI RMF, EU AI Act compliance, red-teaming, advanced risk assessment). EU AI Act Article 4 mandates AI literacy for all staff involved in AI — this is no longer optional.

AI risk that exceeds defined thresholds must escalate to executive leadership — not just as an FYI but as a decision requiring executive action. This means: the AI Steering Committee has a defined executive sponsor, escalation thresholds are documented, and board-level AI risk reporting is on the agenda at least annually. GV-2.3 is the safeguard against "the governance team flagged the problem but leadership didn't know" failure scenarios.

Homogeneous teams produce AI systems that fail on demographic groups the team didn't represent. A facial recognition system built by a team with no women performs worse on women. A medical AI trained primarily on male patient data misdiagnoses conditions in female patients. These are security and liability failures, not just fairness concerns. GV-3 requires diversity in the teams doing risk work — MAP stakeholder identification, bias evaluation, and harm assessment — not just in the teams building the product.

Ask any engineer on the team: "If you discovered that this AI system was producing biased outputs for a protected demographic group, what would you do?" If the answer is anything other than "I'd raise it immediately through [named process]" — and if they don't know the named process — GV-4 is not implemented. Culture is not a mission statement. It's the answer to that question. GV-4.3 is especially critical: incentive structures (ship fast, hit metrics) must be compatible with the risk management behaviors the governance program requires. They often aren't, and the incentive wins.

NIST's definition of "AI actors" is broad — it includes not just the build team but operators, users, affected third parties, and the broader public where relevant. GV-5 requires the organization to have systematic processes for hearing from these groups — not just an email address. Examples: student advisory panel for EdTech AI, patient advocates for healthcare AI, community review for AI in public-sector decisions. GV-5 often feels like governance overhead; in practice it catches harms the build team cannot see from inside the organization.

• GV-6.1 — Policies for third-party AI risk: vendor assessment requirements, contractual AI obligations, data-handling standards for inputs to external AI services
• GV-6.2 — Contingency processes for supply chain failures: what happens if a foundation model provider changes their API, deprecates the model, or raises prices 4×? Who owns that decision? What's the fallback?

GV-6 establishes the organizational policy and contingency process that apply to all third-party AI use. The specific vendor assessment for a specific system happens at MAP. You define the standard once (GOVERN) and apply it many times (MAP).

If you can't write three clear sentences — what the system does, who uses it, and what context it operates in — MAP 1.1 is not complete. This statement anchors everything: the EU AI Act classification, the trustworthiness characteristics that apply, the stakeholder identification in MAP 1.2, and the harm scenarios in MAP 5. A weak intended-purpose statement produces a weak MAP and a weak risk register.

"AI chatbot for customer service." Not specific enough. Better: "A generative AI assistant that answers questions about enrollment, financial aid, and course scheduling for prospective and current MVCC students, accessed through the public website and the student portal, operating under FERPA and MVCC's data governance policy, with no access to live student records in its first deployment phase."

The MAP 1 context-setting exercise should not be done by the AI product team alone. Include: domain SME (academic affairs, finance, HR — whoever owns the business process), user representative (a student, a faculty member, a patient — someone who actually uses the system), legal/privacy (FERPA, GDPR, AUP compliance), and security (threat model for this specific deployment). Document who was in the room. Homogeneous context-setting produces blind spots that become liability later.

This subcategory is where MAP connects to GOVERN. The risk tolerance defined at the organizational level (GV-1.3) is applied to this specific system in MAP 1.5. The question answered here is: given this system's intended purpose and deployment context, what organizational risk tier does it fall into — and therefore, what depth of Measure and Manage work is required? This is the gate that determines whether a system gets a full red-team exercise or a lighter evaluation process.

For each stakeholder group identified in MAP 1, map: (1) intended positive impact, (2) unintended positive impact, (3) intended risk (accepted and managed), (4) unintended negative impact. The fourth quadrant is where AI harm lives — and it's the one teams most consistently fail to populate, because it requires imagining outcomes the team doesn't want to see. Forcing teams to complete MP-3.1 systematically surfaces assumptions that would otherwise remain implicit until they become incidents.

Traditional likelihood × impact math assumes normal distributions. AI risks often have heavy tails: the model works correctly 99% of the time, and the 1% failure is catastrophic. MP-3.5 requires documentation of these tail risks — not just the expected-value risks. A hiring AI that is biased in 2% of cases produces a manageable expected-value harm but a class-action lawsuit risk that is extreme. Both numbers belong in the document.

• Harm scenario description
• Affected population
• Estimated frequency (with confidence interval)
• Severity rating (1–5, with definition of each level)
• Detectability (how quickly would we know?)
• Existing mitigations
• Residual risk determination

MAP 5.1 requires explicitly naming marginalized or vulnerable groups who may be disproportionately affected by the AI system. For a community college: first-generation students, English language learners, students with disabilities, students from low-income backgrounds. For a healthcare AI: elderly patients, patients with limited English proficiency, patients in rural areas with limited follow-up access. This is not soft ethics — disproportionate impact is precisely what the EU AI Act's FRIA (Fundamental Rights Impact Assessment) examines for high-risk systems.

MP-5.2 is a pre-deployment gate: the practices, personnel, and transparency measures for addressing negative impacts must be in place before the system goes live — not planned for later. This means: the escalation path for bias reports is defined, the affected-population notification procedure is written, the redress mechanism for impacted individuals exists, and the transparency disclosure is prepared. MAP 5.2 is what converts a well-documented risk into an actually managed one.