清川小区换了一位物业经理老周。上任之前,巡检队已经报上来几十条隐患:AI 门禁偶尔不响应、地库积水、楼道堆放杂物。老周翻完报告说,问题写得再细、再准,不变成维修工单就等于没管。他要做的事是给隐患排优先级、批预算、派师傅、定工期,修完之后还要复查,月底再把账本摊开给业委会看。这套动作,就是 NIST AI RMF 里 Manage 功能的缩影。NIST AI RMF 是美国国家标准与技术研究院发布的 AI 风险管理框架;在这个框架里,Govern 管规则、Map 摸清场景、Measure 量化风险,而 Manage 负责把风险变成可执行的安全行动,并持续盯住没处理完的隐患。可以说,Manage 是 AI 风险管理从“知道问题”走向“解决问题”的执行落地环节。

岗位关联

理解 Manage 功能,能帮你把一份风险评估报告变成真正的治理行动,是 AI 合规、风险与安全岗位从业者的核心能力之一。

目录
  1. 可视化演示
  2. 功能定位
  3. 风险登记
  4. 资源保障
  5. 缓解措施
  6. 残余监控
  7. 文档沟通
  8. 治理闭环
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示二叉搜索树的节点插入过程与中序遍历,观察BST的左小右大特性及遍历产生有序序列的过程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

二叉搜索树插入与遍历 蓝色节点为已插入,橙色为当前操作节点 绿色为遍历已访问节点 左 < 根 < 右 中序遍历产生有序序列。

功能定位

老周上任第一件事不是急着修东西,而是先把物业的管理架构搭起来。他说,巡检能发现楼道堆物,但发现之后如果没有责任人、没有限期、没有预算,问题依然会躺在纸上。Manage 在 NIST AI RMF 里的定位,就像老周的这套管理架构:它不负责发现风险,而负责把发现变成处置。

在 NIST AI RMF 中,Govern 管规则,Map 摸清使用场景,Measure 量化风险,Manage 则把前面发现的隐患转成行动项。一个 AI 系统上线后,风险不会自动消失,而是进入一个“决定怎么处理、投入多少资源、持续盯到最后”的管理通道。这里的责任主体包括模型负责人、安全团队、法务合规和业务方,大家都要在 Manage 阶段认领动作。

从预期产出看,Manage 要输出风险响应策略、资源分配结果、缓解措施执行记录、残余风险水平和监控证据。如果只拿到一份风险评估报告,却没有看到处置计划,那只是跑了一半流程;Manage 补齐了后半程。

老周把这句话贴在物业管理处:决策再好,师傅没去、复查不做,等于白干。Manage 的意义,就是让风险治理从会议室走进机房和业务现场。

风险管控成效=处置决策×执行到位率×持续监控\displaystyle \text{风险管控成效}=\text{处置决策}\times\text{执行到位率}\times\text{持续监控}
这三个变量只要有一个为 0,整体管理效果就是 0。就像物业没人执行、不持续检查,再好的决策也会失效。
  1. 风险管控成效衡量 Manage 功能总体效果的结果变量,代表风险处置是否真正落地。
    风险管控成效\text{风险管控成效}
  2. 处置决策指对每项风险选择什么策略、定什么优先级,是管理动作的开端。
    处置决策\text{处置决策}
  3. 执行到位率资源、责任人、工期是否真正落实,决定决策能不能变成现实。
    执行到位率\text{执行到位率}
  4. 持续监控处置后残余风险是否超阈值、告警是否被升级,决定闭环能否长期运转。
    持续监控\text{持续监控}

风险登记

老周要求每一条隐患都要有唯一的“报修编号”,贴在楼道,登记在册。没有编号的问题,维修师傅不知道要不要去;有了编号,责任才算挂到人头上。这就是 Manage 的第一个基本动作:登记。

Manage 的起点同样是风险台账。Map 和 Measure 阶段形成的风险发现,不能只停留在某次模型测试报告里,而要进入可跟踪的登记表。现实中的 AI 团队常有几十条待处理风险,如果没有统一台账,很快就会被遗忘或重复讨论。

一条风险条目至少应包含编号、场景描述、影响、可能性、责任人和处置时限。影响和可能性可以合成风险等级,决定后续优先级;责任人和处置时限保证有具体的人、在具体时间前完成。台账不是纸面文章,而是后续资源分配和缓解动作的索引。

老周常说,台账不是库存,是作战地图。风险登记不是行政手续,而是决定后面资源分配和管理动作是否有序的地基。

风险条目=(编号,描述,影响,可能性,责任人,处置时限)\displaystyle \text{风险条目}=(\text{编号},\text{描述},\text{影响},\text{可能性},\text{责任人},\text{处置时限})
就像报修单必须写清房号、问题、紧急程度、师傅和截止时间,否则就是一张没人认领的纸。
  1. 编号为每条风险分配唯一标识,方便追踪、检索和审计。
    编号\text{编号}
  2. 描述说明风险发生在什么场景、会带来什么后果,让不同角色都能理解。
    描述\text{描述}
  3. 影响与可能性影响表示危害大小,可能性表示发生概率,两者是后续计算优先级的输入。
    影响,可能性\text{影响},\text{可能性}
  4. 责任人与处置时限责任人解决“谁来管”,处置时限解决“什么时候必须处理完”。
    责任人,处置时限\text{责任人},\text{处置时限}

资源保障

清川小区只有一支维修队,积水要抽、门禁要换、堆物要清。老周没有平均用力,而是把预算和师傅优先派给“可能出事且出事很严重”的位置。在 AI 风险管理里,资源保障也一样:人力、预算、工具和工期都要根据风险等级来配置。

管理资源永远有限,不能因为某条风险在报告里写得长就多给预算,也不能因为某个团队嗓门大就优先处理。更合理的做法,是用风险等级作为权重来分配。假设总预算为 B,第 i 项风险权重为 W_i,那么第 i 项风险分到的预算就是总预算乘以该风险权重在全部权重中的占比。

老周会在月度会上把预算表摊开:哪栋楼分了多少、为什么,一目了然。资源分配一旦可解释,风险处置就不再是拍脑袋。

第i项预算=总预算×第i项风险权重∑j=1n第j项风险权重\displaystyle \text{第}i\text{项预算}=\text{总预算}\times\frac{\text{第}i\text{项风险权重}}{\sum_{j=1}^{n}\text{第}j\text{项风险权重}}
这相当于物业开会时问:哪个隐患最可能让人受伤、影响最大,预算就向哪里倾斜。
  1. 总预算组织愿意投入风险处置的总体资源,可以是资金、时间或人力包。
    总预算\text{总预算}
  2. 第 i 项风险权重该项风险的综合评分,通常由影响和可能性相乘得到。
    第i项风险权重\text{第}i\text{项风险权重}
  3. 所有权重之和分母把所有风险权重加总,让分配结果变成相对比例。
    ∑j=1n第j项风险权重\sum_{j=1}^{n}\text{第}j\text{项风险权重}
  4. 预算占比用该项权重除以总权重,得到它在全部风险中应占的资源份额。
    第i项风险权重∑j=1n第j项风险权重\frac{\text{第}i\text{项风险权重}}{\sum_{j=1}^{n}\text{第}j\text{项风险权重}}

缓解措施

楼道堆物可以清,地库积水可以抽,但有些隐患短时间修不完。老周有三种办法:直接修、转给别人、或者先立警示牌并定期检查。NIST AI RMF 的风险应对也类似:规避、转移、降低,或者接受残余风险。选择取决于风险等级、处置成本和组织的风险容忍度。

当选择“降低”时,需要评估控制措施是否真的有效。设原风险为 R0,措施有效性为 E,其中 0 到 1 之间,则缓解后风险等于原风险乘以未缓解的部分。E=0 表示措施完全没起作用,E=1 表示风险被完全消除。

老周提醒,不是所有问题都能一次修到完美。接受风险也不是放弃,而是清楚知道剩下多少风险、由谁在看着它。

缓解后风险=原风险×(1−缓解有效性)\displaystyle \text{缓解后风险}=\text{原风险}\times(1-\text{缓解有效性})
就像堵漏后还要看水还漏不漏,有效性不是写在方案里的口号,而是算出来的数字。
  1. 原风险尚未实施缓解措施时的风险水平,是计算起点。
    原风险\text{原风险}
  2. 缓解有效性控制措施能降低风险的比率,取值范围在 0 到 1。
    缓解有效性\text{缓解有效性}
  3. 未缓解比例1 减去有效性,代表剩余风险占原风险的比例。
    1−缓解有效性1-\text{缓解有效性}
  4. 缓解后风险原风险乘以上一步比例,得到处置后仍然存在的风险水平。
    原风险×(1−缓解有效性)\text{原风险}\times(1-\text{缓解有效性})

残余监控

修好门禁不等于永远没事。老周安排保安每周复查,把“之前叫不响”“现在偶尔叫不响”都记下来。Manage 对残余风险也一样:处置之后必须有监控指标和复查节奏,否则风险会在无人注意时悄悄反弹。

残余风险是缓解后仍然存在的风险。组织需要为它设定阈值,再配置相应的监控指标、巡查频率和告警路径。用 1 表示触发告警,0 表示暂不告警,这个判断可以用一个分段表达式表示。

监控不是走过场。老周会看保安的复查记录,没记录等于没查;残余风险超阈值不升级,等于管理链条在最后一环断了。

告警={1,残余风险≥阈值0,其他\displaystyle \text{告警}=\begin{cases}1,& \text{残余风险}\ge\text{阈值}\\0,& \text{其他}\end{cases}
阈值就像物业定的“积水超过 5 厘米必须响警报”,低于这条线可以观察,超过就必须马上处理。
  1. 残余风险缓解措施实施后仍然存在的风险水平。
    残余风险\text{残余风险}
  2. 阈值组织能接受的最大残余风险水平,由管理者和业务方共同确定。
    阈值\text{阈值}
  3. 比较判断将残余风险与阈值比较,决定是否进入告警状态。
    残余风险≥阈值\text{残余风险}\ge\text{阈值}
  4. 输出告警满足条件时输出 1,表示需要升级;不满足时输出 0,表示继续观察。
    告警={1,成立0,其他\text{告警}=\begin{cases}1,& \text{成立}\\0,& \text{其他}\end{cases}

文档沟通

老周要求每次维修都留底单:谁报修、谁处理、用了多少钱、为什么这么修。月底他还会把这些底单整理成简报,向业委会汇报。AI 风险处置同样需要完整记录。没有审计痕迹,事后就说不清当时为什么选这个方案、责任人是谁、残余风险还剩多少。

在 Manage 阶段,文档沟通贯穿始终。除了记录处置动作,还要明确上报渠道,让一线团队发现异常时知道往哪一层报;对外也要与监管、客户、合作伙伴同步残余风险。一条审计记录至少应包含风险条目、处置动作、时间戳和决策理由。

老周说,业委会最在意的不是每笔预算都花完,而是每笔钱都讲得清楚。文档沟通就是 AI 治理的账本,让外部相关方愿意继续信任这套系统。

审计记录=(风险条目,处置动作,时间戳,决策理由)\displaystyle \text{审计记录}=(\text{风险条目},\text{处置动作},\text{时间戳},\text{决策理由})
就像维修底单不仅证明“修过”,还要能回答“为什么这样修”“是谁决定修的”。
  1. 风险条目指向最初登记的风险编号,把记录与具体风险连接起来。
    风险条目\text{风险条目}
  2. 处置动作记录实际采取的措施,例如增加测试、回滚模型、调整阈值。
    处置动作\text{处置动作}
  3. 时间戳记录动作发生的具体时间,让整个过程可排序、可追溯。
    时间戳\text{时间戳}
  4. 决策理由说明为什么选择该方案,这是审计和复盘时最重要的依据。
    决策理由\text{决策理由}

治理闭环

到了月底,老周把物业、安保、业委会叫到一起复盘:哪些问题修完不再出现,哪些修完又复发,下个月资源要不要调整。Manage 不是一个“处置完就结束”的动作,而是一个周而复始的闭环。每次复盘都要把新增风险、措施降低量和残余风险重新算一遍,更新下一轮基线。

业务场景在变、数据分布会漂移,上一轮评估的风险可能发生变化,同时也会冒出新风险。因此,Manage 阶段的下一个周期不能简单复制旧计划,而要基于新基线重新登记、重新分配、重新监控。

老周最喜欢说,管理没有终点,只有下一轮更聪明的重启。治理闭环的意义,就是让 Manage 永远跟得上 AI 系统和外部环境的变化。

新风险基线=原残余风险+新增风险−措施降低量\displaystyle \text{新风险基线}=\text{原残余风险}+\text{新增风险}-\text{措施降低量}
这就像物业下个月的巡检计划,是根据这个月哪些地方又积水、哪些新隐患冒出来重新排出来的。
  1. 原残余风险上一轮缓解后仍未消除的风险,是下一轮继续关注的存量。
    原残余风险\text{原残余风险}
  2. 新增风险本轮新识别的风险,例如新功能上线、数据源变化带来的隐患。
    新增风险\text{新增风险}
  3. 措施降低量本轮缓解措施实际降低的风险量,代表治理工作的成效。
    措施降低量\text{措施降低量}
  4. 新风险基线把原残余风险加上新增风险、减去措施降低量,得到下一轮的管理起点。
    原残余风险+新增风险−措施降低量\text{原残余风险}+\text{新增风险}-\text{措施降低量}

AI 应用场景

金融信贷 AI 模型上线

阶段:风险登记、资源分配与缓解执行

解决的问题:传统方式下,模型风险评估报告常常停留在文档里,出现问题后不知道找谁、预算和排期也没有着落。AI Manage 把风险变成带编号的台账,按风险权重分资源,并明确处置时限。

具体案例:某银行上线信用评分模型时发现对长尾客群存在偏见风险。风险管理团队在 Manage 阶段给这条风险分配了数据复核预算,指定模型负责人,并要求两周内完成训练数据修正;上线后继续监控偏见指标,残余风险超标时自动告警。

医疗影像 AI 的残余风险监控

阶段:残余监控与告警升级

解决的问题:医疗场景对误判容忍度极低,模型部署后不能一劳永逸。Manage 要求对残余风险设置阈值,通过监控指标发现性能下降并升级处理。

具体案例:一家医院部署肺结节筛查 AI 后,运营团队设定“低危结节漏检率超过 2% 必须告警”。某月监控指标达到 2.3%,系统自动通知影像科负责人,团队随即暂停低置信度场景使用并重新校准模型。

第三方大模型采购的文档沟通

阶段:文档沟通与治理闭环

解决的问题:采购外部大模型时,数据隐私与输出合规风险往往难以由技术团队单独判断。Manage 的文档记录和上报机制,能帮助组织在供应商风险出现时快速追溯决策过程。

具体案例:某企业采购一款客服大模型,法务、安全和业务部门共同登记了“训练数据跨境”“回复内容违规”等风险,记录处置方案和残余风险;每季度向管理层同步一次供应商审计报告,作为下季度是否续约的依据。

Python 演示

python65 行
# -*- coding: utf-8 -*-# NIST AI RMF Manage 功能的最小演示from dataclasses import dataclass  @dataclassclass RiskItem:    risk_id: str    description: str    likelihood: float    impact: float    owner: str = ""    residual: float = 0.0  class RiskManage:    def __init__(self, budget: float):        self.budget = budget        self.register = []        self.logs = []     def add_risk(self, item: RiskItem):        item.residual = item.likelihood * item.impact        self.register.append(item)        self.logs.append("登记:" + item.risk_id)     def priority(self, item: RiskItem):        return item.likelihood * item.impact     def allocate(self):        total = sum(self.priority(r) for r in self.register)        plan = {}        for r in self.register:            plan[r.risk_id] = self.budget * self.priority(r) / total if total else 0.0        self.logs.append("分配预算")        return plan     def mitigate(self, item: RiskItem, effectiveness: float):        item.residual = self.priority(item) * (1 - effectiveness)        self.logs.append("缓解:" + item.risk_id)        return item.residual     def monitor(self, threshold: float):        alerts = []        for item in self.register:            if item.residual > threshold:                alerts.append(item.risk_id)        self.logs.append("监控完成")        return alerts  if __name__ == "__main__":    mgr = RiskManage(budget=100000)    r1 = RiskItem("R1", "客服误判", 0.6, 8)    r2 = RiskItem("R2", "数据泄露", 0.3, 10)    r3 = RiskItem("R3", "模型漂移", 0.7, 5)    mgr.add_risk(r1)    mgr.add_risk(r2)    mgr.add_risk(r3)    print("预算分配:", mgr.allocate())     for r, effect in [(r1, 0.8), (r2, 0.6), (r3, 0.7)]:        mgr.mitigate(r, effect)    print("监控告警:", mgr.monitor(3))    print("流程记录:", mgr.logs)
目的:用一个最小风险台账类,模拟 Manage 闭环中的登记、分配预算、缓解和监控四个动作。
  1. item.residual = item.likelihood * item.impact登记时先计算风险分数,作为后续优先级依据。
  2. total = sum(self.priority(r) for r in self.register)汇总全部风险权重,为归一化分配做准备。
  3. plan[r.risk_id] = self.budget * self.priority(r) / total if total else 0.0按风险权重占总权重比例分配预算。
  4. item.residual = self.priority(item) * (1 - effectiveness)缓解后更新残余风险,不再使用原始风险值。
  5. if item.residual > threshold:残余风险超过阈值时,进入告警列表并触发后续处置。

常见误区

误区我总觉得,做完 Manage 之后风险应该清零,如果还有残余风险,说明治理失败了。

正解AI 风险管理不可能把风险全部消灭,成本、技术和业务价值都不允许。Manage 的目标是把风险控制在可接受范围内,让残余风险有监控、有责任人。就像物业不可能让小区永远零积水,但可以做到“积水不超阈值,超标就派人处理”。

为何常见:很多人把“管理”误解为“解决”,忽略了 AI 系统本身就带有不确定性和局限。

误区我认为把风险一条条写进表里,标好负责人和紧急程度,Manage 就结束了。

正解台账只是起点。真正重要的是后续的资源分配、缓解执行、监控和复盘。老周如果只填报修单却从不派师傅,问题不会自己好。风险台账必须持续驱动行动,才算真正进入 Manage。

为何常见:文档工作最容易在流程上被看见,但行动是否落地、残余风险是否下降,往往需要更长时间检验。

误区AI 出问题交给安全部门就行,业务方和模型团队不需要参与 Manage。

正解AI 风险往往横跨数据、模型、业务场景和用户影响。模型负责人要判断技术处置方案,业务方要决定是否接受残余风险,合规团队要确认沟通和记录是否到位。就像小区积水不能只靠保安,还要工程队、业委会和财务一起配合。

为何常见:安全团队名称里带“安全”,容易让人误以为所有与风险相关的动作都归他们。

误区我觉得这条风险这次修好了,以后就不会再出现了。

正解AI 模型会随数据分布、业务策略和外部环境变化而变化。今天有效缓解措施,明天可能失效。Manage 需要通过定期评估和残余监控来确认风险没有反弹,再根据新基线调整计划。老周修完门禁后还要每周复查,就是这个道理。

为何常见:人天然偏好“一次解决”的确定性,但 AI 系统的环境是动态的。

面试题

Q1. Manage 功能的首要目标是什么?

单选题 · easy

  • A.管理并监控风险← 正确答案
  • B.彻底消除风险
  • C.提升模型精度
  • D.增加更多数据

答案:A。Manage 的核心是让风险处于受控状态,而不是追求绝对清零。彻底消除风险既不现实,也不是 AI 治理的目标;提升模型精度和增加数据属于模型训练范畴。

Q2. NIST AI RMF 中 Manage 属于哪个环节?

单选题 · easy

  • A.风险处置落地← 正确答案
  • B.数据采集存储
  • C.算法训练调参
  • D.用户界面设计

答案:A。Manage 负责把风险转化为行动,是风险处置的执行环节。数据采集、算法训练和用户界面设计都不属于 Manage 的职责范围。

Q3. 风险台账中最关键的要素是什么?

单选题 · mid

  • A.编号和责任人← 正确答案
  • B.字体和颜色
  • C.会议记录时间
  • D.文件存储位置

答案:A。唯一编号让风险可被追踪,责任人让处置动作有人推动。字体、会议时间和文件位置都不是风险管理的核心要素。

Q4. 分配风险处置资源时,主要依据是什么?

单选题 · mid

  • A.风险等级权重← 正确答案
  • B.提出先后顺序
  • C.部门人数多少
  • D.模型参数数量

答案:A。资源分配应按风险等级权重进行,高风险高投入。先后顺序、部门人数和模型参数数量都不能代表风险本身的大小。

Q5. 残余风险指的是什么?

单选题 · mid

  • A.处置后仍留存的← 正确答案
  • B.尚未被识别的
  • C.已被彻底消除的
  • D.完全无法量化的

答案:A。残余风险是缓解措施实施后仍然存在的风险。它不一定无法量化,也不等于未被识别,更不是已经被消除的风险。

Q6. “接受风险”策略适合什么场景?

单选题 · hard

  • A.残余在容忍线内← 正确答案
  • B.风险完全不可见
  • C.资源无法统计
  • D.风险必然不发生

答案:A。只有残余风险在组织可接受阈值内,才适合接受风险。接受不等于假装风险不存在,也不是只适用于完全不可见或必然不发生的风险。

Q7. 当监控发现残余风险超过阈值时,第一动作是什么?

单选题 · extreme

  • A.通知责任人处置← 正确答案
  • B.降低监控阈值
  • C.删除历史日志
  • D.停止风险登记

答案:A。超阈值意味着风险超过容忍线,首要任务是让相关责任人介入处置。降低阈值或删除日志属于掩盖问题,停止登记更会破坏治理闭环。

Q8. Manage 功能包含哪些活动?

多选题 · easy

  • A.资源分配调度← 正确答案
  • B.残余风险监控← 正确答案
  • C.纯模型调参
  • D.处置过程留痕← 正确答案

答案:ABD。Manage 包含资源分配、残余监控和文档记录;纯模型调参属于开发环节,而不是 Manage 的管理动作。

Q9. 残余风险监控应配置哪些内容?

多选题 · mid

  • A.监控指标阈值← 正确答案
  • B.告警升级路径← 正确答案
  • C.无限处置预算
  • D.定期复查周期← 正确答案

答案:ABD。监控需要阈值判断是否告警,需要升级路径明确谁来处理,也需要定期复查周期保证持续关注。无限预算既不现实,也不是监控本身的目标。

Q10. 文档沟通环节的正确做法有哪些?

多选题 · hard

  • A.记录处置过程← 正确答案
  • B.只向开发组汇报
  • C.同步相关干系人← 正确答案
  • D.删除历史日志

答案:AC。好的文档沟通要留痕、可追溯,并向业务、安全、法务等干系人同步。只向开发组汇报会导致信息孤岛,删除日志则破坏审计链路。