Use Govern, Map, Measure, and Manage to organize GenAI risk.
Govern creates the organizational machinery that makes GenAI safety repeatable instead of heroic.
Govern creates the organizational machinery that makes GenAI safety repeatable instead of heroic.
Why this matters: Define who can approve, block, and revisit GenAI releases.
Problem anchor: a lesson-generation agent cites sources, drafts modules, stores traces, and can call tools. A prompt change improves fluency but increases unsupported claims. Without governance, everyone agrees it is concerning and nobody owns the release decision.
The Govern function names roles, risk appetite, policy stack, review cadence, escalation path, and evidence requirements. For GenAI, this includes content policy, privacy policy, tool-use policy, evaluation policy, vendor review, incident response, and change management.
Feature: automated lesson enrichment. Owner: learning product lead. Safety reviewer: trust and safety. Security reviewer: platform. Data owner: KB curator. Block authority: release manager when evals or data review fail. Evidence: risk register, eval report, source-citation audit, prompt version, model route, trace sampling plan, and incident playbook.
This is intentionally mundane. RMF value comes from making risk work durable enough that the next prompt, model, retrieval, or tool change reruns the right checks.
Map turns a broad GenAI feature into a concrete risk surface with boundaries and assumptions.
Map turns a broad GenAI feature into a concrete risk surface with boundaries and assumptions.
Why this matters: Map the use case, users, data, tools, and deployment context.
A GenAI system is not just a model endpoint. It includes prompts, retrieval sources, memory, user interface, tool permissions, logs, analytics, vendors, reviewers, and users who may misunderstand generated output. Mapping makes those pieces visible before measurement.
For a learning studio, mapped harms include unsupported teaching claims, biased feedback, privacy leakage, unsafe advice, prompt injection through sources, overreliance by learners, and tool actions outside the educational role.
A source note in the KB contains outdated legal language. The model faithfully summarizes it, cites it, and the lesson becomes wrong. A model-only map misses this; a system map includes source freshness, provenance, retrieval filters, citation checks, and curator ownership.
| Option | Dimension | Question | Example evidence | When to choose | Cost | Complexity |
|---|---|---|---|---|---|---|
| Context | Users and setting | Who uses it and what decisions could follow? | learner age range, teacher role, product copy, escalation path | Use during requirements. | Medium | Medium |
| Data | Prompts, KB, traces, evals | What sensitive or copyrighted material can enter? | data inventory, retention table, redaction policy | Use before ingestion. | Medium | Medium |
| Capabilities | Tools and outputs | Can the system act, publish, email, browse, or mutate data? | tool manifest, scopes, approval matrix | Use before tool enablement. | Medium | Medium |
Measure converts mapped risks into evidence about likelihood, severity, control effectiveness, and gaps.
Measure converts mapped risks into evidence about likelihood, severity, control effectiveness, and gaps.
Why this matters: Choose measurements for GenAI risks.
Decision this forces: Choose the right level of rigor for NIST AI RMF for GenAI: baseline, production design, or advanced optimization.
If the risk is hallucinated citations, measure citation faithfulness and unsupported-claim rate. If the risk is prompt injection from KB notes, test poisoned source chunks. If the risk is privacy leakage, inspect logs, traces, redaction, and vendor data settings. Generic chat quality scores are not enough.
Measurement includes offline evals, adversarial examples, human review, slice checks, telemetry, incident reports, and post-launch monitoring. The evidence should say what the control caught and what it missed.
Risk: lesson agent invents sources. Test set: 80 prompts across RAG, safety, and infra categories with known KB sources. Metrics: citation coverage, unsupported-claim rate, source freshness, render validation, and reviewer rejection. Red-team set: poisoned notes instructing the model to ignore citations. Pass rule: no critical unsupported claims and citation coverage above the release threshold by category.
Manage is where the team decides which controls reduce risk enough for the intended use.
Manage is where the team decides which controls reduce risk enough for the intended use.
Why this matters: Select controls for measured GenAI risks.
risk = {
"id": "GENAI-CITE-01",
"harm": "unsupported source claim in lesson",
"owner": "learning-quality",
"severity": "high",
"controls": ["citation_eval", "source_provenance", "human_review"],
"evidence": {"unsupported_claim_rate": 0.01, "critical_failures": 0},
"residual_risk_accepted_by": "release-manager",
}
assert risk["owner"]
assert risk["controls"]
assert risk["evidence"]["critical_failures"] == 0
assert risk["residual_risk_accepted_by"]No one is accountable for maintaining, reviewing, or changing those controls after release.
Check that an AI-generated RMF plan uses Govern, Map, Measure, and Manage as functions, not decorative headings. It should name system context, risks, owners, evals, controls, residual risk, monitoring, and update triggers for model, prompt, KB, route, or tool changes.
The RMF is a cycle; GenAI risk changes when models, prompts, tools, data, and users change.
The RMF is a cycle; GenAI risk changes when models, prompts, tools, data, and users change.
Why this matters: Recall the four-function loop.
Decision this forces: Choose the right level of rigor for NIST AI RMF for GenAI: baseline, production design, or advanced optimization.
Answer this from memory: "How do I apply NIST AI RMF to a GenAI feature?" Include Govern roles, Map context and misuse, Measure evals and monitoring, Manage controls and residual risk, then update after incidents or system changes.
Spaced recall: module 2 mapped retrieval and tools as part of the system. The final register must update when those non-model pieces change.
Pick a GenAI feature. Write one row with risk, affected users, severity, likelihood, context, measurement, controls, owner, residual risk, release gate, monitoring signal, and update trigger. Then explain which RMF function each field supports.
From memory, reconstruct the NIST GenAI risk loop: Govern roles and policy, Map context and harms, Measure with evals and evidence, Manage controls and residual risk, then update the register after incidents or changes.
Create a one-page release-ready plan for NIST AI RMF GenAI risk register mapped to govern, map, measure, and manage. Include: the user problem, realistic input, mechanism, design choice, runnable or reviewable check, metric (identified risks tied to owners and controls), failure case (risk work becomes a one-time checklist instead of a lifecycle practice), owner, and the next rung after this lesson.
A legal team flags a GenAI deployment risk after launch. Under NIST AI RMF Govern, who is responsible for deciding whether to continue, modify, or pull the system?
Govern requires a named risk owner — not a vendor or ad-hoc engineer — with documented authority to make go/no-go decisions and revisit them when new evidence arrives.
A team completes a model-only safety review — testing the base LLM in isolation — and declares the GenAI product safe to ship. What critical gap does NIST AI RMF highlight with this approach?
NIST AI RMF's Map function insists that risk lives in the full system context — users, data, tools, and environment — not just the model weights, so a model-only review is structurally too narrow.
Your GenAI system passes all offline evaluations before launch. Three weeks after deployment, users find a new jailbreak pattern. Which Measure-function practice would have given you the earliest signal?
Offline evals capture known risks before launch; production monitoring is what surfaces novel, real-world failure patterns — like new jailbreaks — after the system is live.
After controls are applied to a GenAI system, some risk always remains. What two things must be documented about that leftover risk before a system can be approved for launch under NIST AI RMF Manage?
Manage requires both a written record of residual risk and a named owner's acceptance signature — without both, there is no accountable decision trail if something goes wrong post-launch.
A team is choosing their level of rigor for the NIST AI RMF loop on a high-stakes GenAI system used in medical triage. Which choice best fits that context?
High-stakes, vulnerable-population deployments call for the advanced optimization tier, which demands deeper red-teaming, tighter monitoring, and more rigorous residual-risk acceptance — not a baseline checklist.