NIST AI RMF in Practice: How to Run GOVERN, MAP, MEASURE, MANAGE in an Agile Team

The NIST AI Risk Management Framework is solid in theory and vague in practice. This guide shows how to actually implement it in a product team's sprint cadence, with concrete templates and ownership models.

Why the AI RMF Feels Vague

The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023) is intentionally framework-agnostic. It does not prescribe specific metrics, tools, or processes because these vary by organisation, domain, and system type. That design choice is sensible for a standards body. It is frustrating for a product team trying to run a sprint planning session.

The question that comes up repeatedly in practitioner communities is: 'This framework is interesting, but how do we actually do it on Monday morning?' This guide answers that question for teams running two-week sprint cycles with quarterly planning.

The Four Functions and Their Agile Equivalents

GOVERN is not a step you complete before the others. It is the organisational scaffolding that runs beneath all three other functions at all times. Think of it as your team's operating system, not a phase.

GOVERN: What Your Quarterly Review Looks Like

GOVERN activities establish who is responsible, what the policies are, and what the organisation's tolerance for AI risk is. For most product teams, GOVERN translates into three practical artefacts:

1. The AI Risk Ownership Matrix

Every AI system needs a named owner for each risk domain. Vagueness about ownership is the most common GOVERN failure. An effective matrix looks like this:

2. The AI System Inventory

You cannot govern what you cannot see. Maintain a living inventory of all AI systems in production (or in development). At minimum, each entry should record: system name, intended use, the AI RMF tier it sits in (see NIST AI RMF documentation), data sources, model or vendor used, and the name of the owner from your risk matrix.

3. Quarterly GOVERN Review Agenda

1. Review the AI system inventory for accuracy and completeness.
2. Review any risk incidents or near-misses from the prior quarter.
3. Assess whether organisational risk tolerance has changed (new markets, new regulations, new stakeholder concerns).
4. Update AI policies and the ownership matrix as needed.
5. Confirm AI literacy training completion rates meet the target.

MAP: Sprint 0 Risk Identification

MAP activities happen at project kickoff (or when scope significantly changes) to identify and categorise AI risks before development begins. This is the AI risk equivalent of threat modelling in security engineering.

A practical MAP session runs as a 2-3 hour workshop at the start of any AI project and produces four outputs:

1. Context statement: Who uses this system, in what context, and what decisions does it affect?
2. Stakeholder map: Who is impacted by the system's outputs — directly (users) and indirectly (third parties affected by decisions)?
3. Risk inventory: Identify potential harms — inaccurate outputs, biased outputs, privacy violations, adversarial manipulation, misuse. Use the AI RMF's risk taxonomy as a prompt list.
4. Risk tolerance statement: For each identified risk, what is the acceptable level? (Zero tolerance for privacy breaches; some tolerance for accuracy variation in low-stakes use cases.)

MAP should take no longer than half a day. If you find yourself writing multi-page risk registers during MAP, you are over-engineering it. The goal is a prioritised shortlist that informs your MEASURE and MANAGE activities, not an exhaustive audit.

MAP does not end at project kickoff. Re-run a lighter version of MAP whenever:

• The intended use of the system changes significantly.
• New data sources are added or existing ones change.
• The system is deployed in a new market, country, or user segment.
• A new regulatory obligation (like the EU AI Act) changes the risk landscape.

MEASURE: What Goes Into CI/CD

MEASURE is where AI risk management intersects most directly with engineering work. It is the function responsible for turning identified risks into metrics, then tracking those metrics continuously.

Integrating MEASURE into the Build Pipeline

Every sprint, the following automated checks should run as part of your CI/CD pipeline for AI-involved features:

• Model performance regression tests: Does the model still perform within the accepted accuracy thresholds on your evaluation set? Fail the build if it drops below threshold.
• Data quality checks: Does the training or inference data meet the expected schema, value ranges, and null-value rates? Log and alert on anomalies.
• Bias and fairness metrics: Measure performance disaggregated by demographic groups (where data is available). Alert if the disparity exceeds the threshold set in MAP.

Pre-Release Gate (every release)

Before every production release of an AI-involved feature, require sign-off on:

• Evaluation results on held-out test sets (including adversarial inputs where applicable).
• Human evaluation sample (a structured review of a random sample of model outputs by a human evaluator).
• Fairness report: disaggregated performance across user segments.
• Drift check: are production inputs similar to training data distributions?

Production Monitoring (continuous)

Post-deployment, the following signals should feed a dashboard reviewed at every sprint review:

• Input distribution shift: are live inputs drifting from the training distribution?
• Output distribution shift: are the model's outputs changing over time in unexpected ways?
• User feedback signals: correction rates, override rates, escalation rates.
• Error rate by user segment: is error rate uniform across groups, or are some segments disproportionately affected?

MANAGE: Sprint Review Risk Items

MANAGE converts the outputs of MEASURE into action. At every sprint review, the team reviews the MEASURE dashboard and processes any flagged items:

The Incident Response Runbook

Every AI system in Annex III (or any system where errors cause significant harm) needs a documented incident response runbook. It does not need to be complex. A one-page document covering these four questions is sufficient:

1. Who is notified when a threshold is breached? (Name, role, contact method.)
2. What is the mitigation timeline? (How quickly must a response be initiated?)
3. What is the rollback procedure? (How do we disable or revert the AI feature quickly?)
4. When and how are affected users notified?

Common Pitfalls

• Running MAP once and never revisiting it. Risk profiles change as systems evolve. Treat MAP as a living document, not a one-time checkbox.
• Treating MEASURE as only pre-deployment testing. Production monitoring is as important as pre-release evaluation. Many AI failures do not appear in test environments.
• Assigning GOVERN ownership to a single person. AI risk governance needs distributed ownership — ML engineers own model quality, product managers own use-case risk, legal owns regulatory exposure. One person cannot meaningfully own all of these.
• Setting MEASURE thresholds arbitrarily. Thresholds should come from the risk tolerance decisions made in MAP. If you set a 95% accuracy threshold because it sounds reasonable, it is not a risk-managed decision.
• Skipping MANAGE until something goes wrong. MANAGE should be a standing item in every sprint review, not a reactive fire drill.

One-Page Cadence Summary