Who Accepts the Residual Risk?
Passing the mitigation checklist is not the same as making a release decision.
For an AI feature, someone still needs to decide whether the remaining risk is
acceptable—and be accountable for that decision.
The NIST AI RMF Playbook’s Manage guidance is useful here. It treats release as
a determination about whether the system achieves its intended purpose and
whether development or deployment should proceed, weighing negative risks
against benefits. It also identifies several possible treatments for a risk:
mitigate, transfer, avoid, or accept. The choice and the resources needed to
carry it out should be documented.
That suggests a small release record with five explicit fields:
- Remaining risk: what can still go wrong, for whom, and under what conditions?
- Authority: which accountable role can accept this risk, and what delegation
or escalation boundary applies? - Treatment: is the risk mitigated, transferred, avoided, or accepted? What
evidence and uncertainty support that choice? - Operating limits: what safe-use requirements, monitoring, or human review
must remain in place? - Communication: which downstream teams, acquirers, or end users need to know
the limitation before they rely on the feature?
This is not a universal approval template, and the playbook does not assign the
decision to one job title. Sector rules, legal obligations, and an
organization’s risk tolerance still matter. The practical test is simpler:
could a new reviewer understand what risk remains, who accepted it, why, and
what users must do differently?
Source: NIST AI RMF Playbook, Manage — Manage - AIRC