NIST AI RMF MANAGE Function: How to Prioritize, Treat, and Monitor AI Risks in Production

TL;DR

• MANAGE is the execution function: it turns risk findings from MAP and MEASURE into operational decisions, controls, and ongoing oversight.
• Four subcategories: prioritize risks (MG-1), implement strategies to minimize harm and maximize benefit (MG-2), manage third-party AI risks (MG-3), and document and monitor treatment plans (MG-4).
• MANAGE is not a one-time exercise — it runs as a continuous loop for every deployed AI system.
• Financial services teams need to connect MANAGE outputs to their AI risk register, incident response procedures, and model monitoring programs.

Most AI programs run the first three NIST AI RMF functions with some rigor and then stall out. GOVERN builds the governance infrastructure. MAP catalogs the risks. MEASURE runs the testing. Then the slide deck goes to the committee and the model goes to production. MANAGE is where the framework actually does its most important work — and where most teams have the thinnest coverage.

MANAGE is the function that answers: once you know what risks exist and how severe they are, what are you actually doing about them? It’s where risk assessment becomes operational decision-making, where treatment choices get documented, where third-party vendors get monitored, and where deployed AI systems get the ongoing oversight that regulators increasingly expect to see evidence of.

If MAP and MEASURE are the pre-deployment functions, MANAGE is the production function. And for AI systems already live in financial services environments — credit models, fraud detection, customer service automation — MANAGE is where the compliance work is happening right now.

The Four Subcategories of MANAGE

NIST AI 100-1 organizes the MANAGE function into four subcategories, each building on the prior.

MG-1: Prioritize Risks for Treatment

MG-1 is the triage step. It takes the risk catalog produced by MAP and the quantification work done by MEASURE and applies an organizational lens: which risks get resourced for treatment right now, which get accepted as within tolerance, and which require escalation?

Prioritization isn’t just about severity. It also factors in the risk appetite thresholds defined in GOVERN, the feasibility of available treatments, the deployment timeline, and the business value of the AI system. A high-severity risk on a low-value system might warrant decommissioning. The same risk on a system that processes 40% of the institution’s loan applications is a different conversation.

Practical MG-1 output: a documented risk register entry for each deployed AI system, with risks ranked by priority tier and assigned owners. If your AI risk register is a spreadsheet that was last updated at initial deployment and never touched since, that’s the first gap examiners will find.

MG-2: Plan and Implement Risk Treatment Strategies

MG-2 is about developing, planning, and implementing the strategies that minimize negative AI impacts and maximize benefits. It covers the full lifecycle of treatment — not just what controls exist at launch, but how those controls are maintained, updated, and documented as the system evolves.

Treatment options under MG-2 follow the standard enterprise risk management playbook:

MG-2 also covers how benefits are documented alongside risks. NIST’s framing is intentional — pure risk-reduction thinking misses the point. An AI system that’s 100% safe because it’s never deployed doesn’t help anyone. MG-2 requires articulating why the expected benefits justify the residual risk, and for what population, under what conditions.

MG-3: Manage Third-Party AI Risks

MG-3 is the third-party risk function within MANAGE — and it’s the subcategory most financial services teams underweight. Vendor-supplied AI models, third-party data, external APIs, and foundation models from providers like Anthropic, OpenAI, or Google don’t absolve the deploying institution of risk management responsibility. They create a new set of obligations.

MG-3 requires establishing ongoing monitoring processes for third-party AI components, with specific attention to:

• Trust but verify: Vendor representations about bias testing, model cards, and safety evaluations need to be independently assessed, not simply accepted. A SOC 2 report doesn’t tell you whether the vendor’s LLM is producing adverse outputs for protected class members.
• Ongoing surveillance: MG-3 isn’t satisfied by due diligence at onboarding. If a third-party model receives an update, if a vendor’s training data sourcing changes, or if a supplier announces a known vulnerability, your monitoring program needs to detect and respond to those changes.
• Decommissioning triggers: Third-party systems that exceed risk tolerances need documented exit criteria and procedures. “We’d just stop using them” is not a defensible answer in an exam.

For institutions deploying GenAI via API — embedding a foundation model into a customer service workflow or document review process — the MAP 4 vendor assessment and MG-3 monitoring requirements are where regulators are increasingly focused. The MAP function’s third-party component mapping feeds directly into MG-3 — you can’t monitor what you haven’t inventoried.

MG-4: Document, Monitor, Respond, and Recover

MG-4 is the ongoing production governance requirement. It covers two related activities: documenting risk treatment plans for all identified risks, and operating the post-deployment monitoring infrastructure that those plans require.

At the plan documentation level, MG-4 requires that every identified AI risk has a corresponding treatment decision, a rationale, an owner, a review cadence, and a set of monitoring indicators. The treatment plan should be a living document, not a one-time pre-deployment artifact.

At the operational monitoring level, MG-4 maps closely to what financial institutions already do for model risk under SR 11-7 — performance tracking, outcome analysis, drift detection, and re-validation triggers. Where MG-4 extends beyond traditional model monitoring is in its scope: it explicitly covers trustworthiness characteristics beyond accuracy, including fairness indicators, output quality for generative systems, and alignment with the system’s intended context. The continuous monitoring requirements for AI models — PSI thresholds, drift detection, recalibration cadences — are the operational implementation of MG-4.

Incident response is a core MG-4 requirement. Unlike traditional software failures, AI incidents often don’t look like outages. They look like subtle degradation — a credit model’s approval rates for one demographic group shifting by 3 percentage points over six months, or a GenAI assistant starting to produce outputs that create regulatory exposure. MG-4 requires:

• Documented procedures for responding to previously unknown risks when identified
• Communication protocols to relevant stakeholders, including affected communities in high-stakes cases
• Recovery plans to restore systems to acceptable operating parameters
• Change management processes for model updates, retraining, and version transitions

MANAGE as a Continuous Loop

The most important structural point in NIST AI 100-1’s MANAGE guidance is that MANAGE is not a project with a completion date. It’s a recurring operational cycle for every deployed AI system.

The loop runs: assess priority (MG-1) → implement or update treatment strategies (MG-2) → monitor third-party components (MG-3) → track, respond, and recover (MG-4) → feed findings back into MAP and MEASURE for the next cycle.

This matters for resourcing and governance. If your AI governance program treats MANAGE as a one-time pre-deployment checklist, you have a documentation program, not a risk management program. Deployed AI systems evolve — models drift, vendor products update, user behavior shifts, regulations change. MANAGE needs a defined review cadence: quarterly for high-risk systems, semi-annually for moderate-risk, annually at minimum for low-risk, plus event-driven reviews triggered by incidents or material changes.

The GOVERN function’s accountability structures should define who owns the MANAGE cycle for each system — who reviews the risk register, who approves treatment decisions, who escalates to the board. Without that accountability wiring, MANAGE degrades into a shelf artifact.

Financial Services Context: MANAGE and the SR 11-7 Transition

For banking institutions, MANAGE connects to a regulatory landscape that shifted significantly in 2026. OCC Bulletin 2011-12 and SR 11-7 — the 15-year cornerstone of model risk management — were rescinded and replaced with new interagency guidance that takes a more risk-proportionate, principles-based approach.

The new guidance doesn’t change the fundamental MANAGE obligation. High-risk AI systems still need documented treatment decisions, ongoing monitoring, and incident response procedures. What changed is that regulators are now more explicitly focused on AI-specific risks — bias drift, generative output quality, agentic system behaviors — that don’t fit neatly into the old model validation paradigm.

The Treasury’s Financial Services AI Risk Management Framework, released February 2026, provides 230 control objectives aligned with NIST AI RMF functions. For MANAGE-equivalent activities, it covers risk treatment documentation, third-party AI oversight, and production monitoring requirements in language tuned for financial services examiners. If you’re building evidence packages for exam readiness, the FS AI RMF control mapping is the most practical bridge from NIST principles to financial services exam expectations.

The MEASURE function’s TEVV and bias testing requirements feed directly into MANAGE’s monitoring protocols — the thresholds and metrics established in MEASURE become the tripwires that trigger MANAGE responses.

Building a Practical MANAGE Program

The gap between teams with defensible MANAGE coverage and those without usually comes down to a few concrete artifacts:

1. The AI Risk Register: A living document that maps each deployed system to its risk tier, treatment decisions, control inventory, monitoring cadence, and incident history. Not a spreadsheet from the initial deployment that hasn’t been touched since. An actively maintained register with dated review entries.

2. Monitoring Protocols by Risk Tier: Define what monitoring is required for each tier. High-risk: monthly performance review, quarterly comprehensive bias analysis, event-triggered re-validation. Moderate: quarterly review, semi-annual deep analysis. Low-risk: annual review plus trigger-based review. Document the protocols and the data that they’re producing.

3. Incident Response Procedures for AI: Standard IT incident response doesn’t cover AI-specific failure modes. An AI incident procedure should define: what constitutes an AI incident (drift beyond threshold, output generating consumer harm, unexpected behavior), escalation path, communication protocol, evidence preservation requirements, and post-incident review process.

4. Third-Party AI Vendor Oversight Program: A schedule for monitoring your vendor AI components, criteria for escalation and decommissioning, and a process for receiving and acting on vulnerability disclosures from suppliers.

So What?

If your AI governance program has GOVERN documentation, a MAP-derived risk catalog, and MEASURE-based testing results but no functioning MANAGE cycle, you have a compliance artifact, not a risk management program. Examiners in 2026 are asking to see the management evidence — the risk register with dated review entries, the incident log, the treatment decisions with rationale, the monitoring reports. Pre-deployment testing alone isn’t sufficient.

MANAGE is also where your AI governance program gets its credibility with the business. A risk register that shows clear treatment decisions — including explicit risk acceptance where appropriate — demonstrates that the program is making reasoned tradeoffs rather than applying blanket caution to everything. That’s a harder case to make without the MANAGE infrastructure.

Start with your highest-risk deployed systems. Build the MG-4 monitoring protocols and incident response procedures first — that’s where examiner attention is concentrated. Then work backward to formalize MG-1 prioritization and MG-2 treatment documentation for those systems. MG-3 third-party oversight should run in parallel as a gap assessment against your current vendor monitoring program.

The AI Risk Assessment Template & Guide includes model inventory templates, treatment decision frameworks, and monitoring protocol templates aligned with NIST AI RMF MANAGE requirements — built for financial services teams that need to operationalize these requirements without standing up a new department.

Sources:

• NIST AI Risk Management Framework (AI RMF 1.0) — NIST
• NIST AI RMF Playbook: MANAGE — NIST AI Resource Center
• AI RMF Core Functions — NIST AI Resource Center
• NIST AI 100-1: Artificial Intelligence Risk Management Framework (Full Text)
• Third-Party AI Risk Management — Mitratech