MANAGE: Where AI Risk Management Earns Its Keep

MANAGE is the function of the NIST AI Risk Management Framework¹ where analysis becomes action. GOVERN set the rules, MAP established context, MEASURE produced evidence; MANAGE is the function that prioritizes the risks, decides what ships, responds when something breaks, watches the vendors, and retires systems that have outlived their justification. It is the least glamorous function and the one whose absence is most visible, because an organization's MANAGE maturity is revealed in exactly one moment: the first bad day.

Everything upstream can be immaculate. If nobody holds go/no-go authority, if the incident plan is a future-tense sentence in a policy, if no one is watching the vendor's release notes, then the framework has produced a well-documented surprise.

Prioritization: not all risks get treated, and that is the point

MEASURE typically hands MANAGE more findings than any organization can act on. The function's first job is triage against the risk tolerance GOVERN wrote down: which risks get mitigated, which get accepted with sign-off, which get transferred contractually, and which are severe enough that the answer is not deploying at all.

The discipline is in the paper trail. An accepted risk with a named accepter, a date, and a rationale is risk management. The same risk accepted by default (because nobody decided anything) is negligence with better fonts. Mature programs can produce, per system, a short treatment record showing each material risk and what was decided about it. That artifact is what separates a defensible program from an optimistic one.

The deployment gate: someone says go

MANAGE formalizes the moment between "the model passed its tests" and "the model is in production." A functioning gate names the approval authority (scaled to risk tier: routine tools may need a manager; systems touching credit, care, or coverage may need an executive committee), states the criteria (validation evidence from MEASURE, security review, compliance check, documented human-oversight design), and (the part organizations skip) defines the way back out. Rollback procedures, a pilot or staged-launch plan for higher-risk systems, and explicit conditions that trigger retreat.

An AI system with no tested rollback path is a one-way door, and one-way doors deserve a much higher burden of proof than most deployments receive.

AI incident response: your IR plan has a gap

Every mature organization has an incident response plan. Many of those plans, as written, do not recognize an AI incident, because AI failures often do not look like incidents. Nothing is breached. No alarm fires. The system simply starts being confidently wrong: a model drifts into a demographic performance gap, a chatbot leaks fragments of retrieved context, a poisoned data pipeline nudges outputs, an agentic tool takes an action nobody anticipated authorizing.

Extending IR for AI means defining what counts as an AI incident (harmful or systematically erroneous output, suspected poisoning or prompt-injection compromise, unexplained drift past thresholds, unauthorized data exposure through model behavior); establishing detection sources beyond security telemetry, because the first detector is usually a user, an affected customer, or an employee who noticed something off, which makes reporting channels and escalation timelines part of the control; and pre-authorizing containment, starting with the unglamorous capability of turning the system off. Who can suspend a production model, on whose authority, with what business fallback? If that answer takes a meeting to determine, the meeting will happen during the incident.

Post-incident, the framework expects the familiar cycle (root cause, remediation, notification where required) plus a step unique to AI: feeding what was learned back into the map, the tests, and the policy, so the incident class gets retired rather than repeated.

Vendors do not stop being risks after procurement

GOVERN vets vendors at the gate; MANAGE watches them afterward. Third-party AI changes constantly and mostly silently: model versions swap, terms of service shift, sub-processors appear. Ongoing management means a re-assessment cadence for AI vendors, monitoring of update and release notices, contractual incident-notification terms you have actually tested against reality, and treating a vendor's model upgrade as a change event that can trigger your own re-validation. The organizations that skip this discover their risk posture changed months ago, by email they did not read.

Decommissioning: systems need an exit

Every AI system eventually stops earning its risk. MANAGE closes the lifecycle: criteria for retirement, secure disposition of models and data, notification of dependent processes and affected users, and an inventory record that shows the system is gone rather than merely forgotten. Orphaned models (still running, no owner, no monitoring) are a known risk, and they are pure MANAGE debt.

The cycle closes

MANAGE is where the framework loops. Incidents update the map. Monitoring findings drive new measurements. Treatment decisions reshape governance. Run once, the four functions produce a snapshot; run continuously, they produce something rarer: an organization that knows what its AI is doing and can prove it.

That is the whole argument of this series. The NIST AI RMF is not paperwork about AI. It is the operating discipline that lets an organization adopt AI at speed because it can see the risks, not despite them. Start with the inventory, name the owner, and let the cycle begin turning.

Frequently asked questions

What counts as an AI incident? Any event where an AI system causes or nearly causes harm through its behavior: systematically erroneous or harmful outputs, discriminatory performance drift, data leakage through model responses, suspected poisoning or prompt-injection compromise, or unauthorized autonomous actions. The defining feature is that many AI incidents involve no breach and trip no alarm; they surface through outputs.

Do we need a separate AI incident response plan? Usually not separate, but extended. Most organizations add an AI annex to their existing IR plan covering AI-specific incident definitions, detection sources, containment steps (including model suspension and rollback), and the roles authorized to act.

How do we decide when to retire an AI system? When its risk exceeds its value and remediation cannot close the gap: sustained performance below thresholds, an unsupported or opaque vendor dependency, a changed regulatory posture, or loss of a business owner. Decommissioning criteria should be defined at deployment, not invented at the end.