AI 风险登记簿：你的首席风险官在事故发生后的第二天会要求看什么

在发生第一起涉及六位数损失的智能体（agent）事故后的第二天早晨，董事们不会询问模型是否处于世界领先水平。他们会要求查看风险登记簿（risk register）中列出该场景的那一行、签字的负责人，以及董事会上次审阅该记录的日期。如果你的企业风险登记簿中包含了网络、供应商、监管和运营风险，但唯独没有“自主智能体在我们的凭证下采取了导致客户可见损失的操作”这一行，那么你即将在董事会上花时间解释，为什么其他每一类风险都有的应对方案，在刚刚让你赔钱的这一类风险上却偏偏缺失。

这不再是假设。Gartner 预测，到 2026 年底，企业将面临超过 1000 起因 AI 智能体造成损害而引发的法律诉讼。在短短一年内，AI 相关风险在安联风险指数（Allianz Risk Barometer）中的排名已从第十位跃升至第二位。保险公司现在在董监高责任险（D&O）续保调查问卷中询问：董事会如何将 AI 纳入公司风险登记簿，以及如何跟踪第三方智能体风险敞口。下文列出的项目代表了一个可靠的答案应具备的内容，以及 AI 功能负责人必须据此进行辩护的节奏。

对工程负责人来说，诚实的说法是：风险登记簿并不是一个让你委托给 GRC（治理、风险与合规）部门的合规产物。它是将你团队构建的东西转化为董事会可以治理的语言的文档。如果这一行不存在，董事们并不会因为漏掉它而失职——而是你因为没有编写它而失职。在事故发生后的诉讼中，原告不需要证明智能体是有缺陷的；他们只需要证明董事会未能对其进行治理。有记录的监管才是产品。缺乏记录则是负债。

自主等级：智能体在脱离人工的情况下能做什么？

每一行的第一列都是自主等级（autonomy class）。企业第一次常犯的错误是将其视为一种二元对立——“人工在环（human-in-the-loop）”或“自主”。董事会无法治理这种二元逻辑，因为你团队发布的每个智能体都处于一个至少包含四个有用等级的光谱中：只读检索（read-only retrieval）、带建议的读取（read-with-suggestion，模型提议，人工确认）、受限写入（bounded-write，智能体在不可逆的受限操作白名单内进行写入）以及无限制写入（unbounded-write，智能体可以调用凭证授权的任何工具）。风险登记簿的条目需要的是等级细分，而非二元分类，因为与审计委员会的对话核心在于：哪些智能体被允许处于哪个等级，依据是什么，以及有哪些补偿性控制措施。

陷阱在于，智能体“宣称的”自主等级与“实际的”自主等级会悄无声息地发生偏离。一个“带建议的读取”智能体，如果其生成的结构化输出被下游自动化系统直接消费且无需人工审核，那么它实际上就是一个“受限写入”智能体——从下游自动化系统发布之日起，登记簿上的那一行就是错误的。每个登记项都需要定期重新验证部署的覆盖面是否符合定义的等级，因为相邻系统的功能开发可能会在无人修改登记簿的情况下，提升智能体的实际自主权。

爆炸半径：最坏的可能行为会有多糟？

“爆炸半径”是将“草拟邮件的智能体”与“关闭账户的智能体”区分开来的那一列。一个有用的操作定义包含三个乘法因子：访问范围、运行速度和检测窗口。一个拥有广泛服务账号凭证、每小时处理数千次决策且没有操作级监控的智能体，实际上已将这三个因子最大化——最坏的可能行为就是通过访问面内的任何工具所能达到的最大损害，以工具的原生延迟执行，并乘以人工发现并停止它之前的时间。

这种纪律要求在登记行中强制填写“最坏情况”，而非“典型情况”。2026 年行业分析中记录的卖家账户关闭案例极具启发性：一个平台智能体根据其政策“正确地”关闭了一个账户，导致卖家丢失了 15 年的购买记录、之前授权的数字商品访问权以及店面收入。从政策上看，这一操作是可逆的；但从背景信息上看，这是无法恢复的。爆炸半径这一列必须捕捉到后者的数值，因为前者是团队在智能体获批时告诉自己的乐观谎言。

在成熟的风险登记簿中，一个正成为支柱的模式是：爆炸半径以 金额和客户影响时长 为单位，而非定性层级。“高达 X 美元的客户信用额度”和“长达 N 个客户小时的服务受损”是董事会可以用来与补偿性控制预算进行对比的数字。而“高”和“中”则不是。

评估覆盖率：我们到底测试了什么？

评估覆盖率（eval-coverage）是大多数团队的登记行退化最快的地方，因为评估（evals）是工程师们喜欢构建一次并永远信任的产物。董事会并不是在问是否存在评估集；董事会是在问：智能体 真实的生产环境行为面 有多少比例被评估覆盖，评估上次针对当前流量进行刷新是什么时候，以及谁验证了标注员和裁判模型（judge model）本身不是盲点的来源。

这一列的诚实版本至少包含三个子项：评估分布覆盖生产流量形态的百分比、上次针对实时流量刷新的日期，以及评估是否包含旨在触发爆炸半径列中所述失败模式的对抗性输入。如果一个评估在冻结的 2025 年分布上得分 92%，而生产环境已经漂移到评估构建时并不存在的提示词和工具中，那么它就在向董事会提供错误信号——此时风险登记簿中的这一行正处于最危险的状态：本该是黄色时却显示为绿色。

这一列的放大器在于：谁受评估约束这一元问题。如果评估是证明将智能体提升到更高自主等级合理的发布门槛信号，那么过时的评估就不只是数据质量问题；它是你治理链条中被悄悄断开的关键环节。季度性重新评估不是一种卫生习惯，而是保持风险登记行真实性的核心手段。

可逆性窗口：多久之后我们将无法回头？

可逆性是法务团队最关注的一列，因为它直接关系到一起事件是否会演变成客户退款、监管披露或集体诉讼。这一列的条目必须回答一个问题：从 Agent 采取行动的那一刻起，组织有多少分钟、小时或天的时间来检测、决策并撤销它，直到该行动变得不可恢复？

陷阱在于，可逆性不是行动本身的属性，而是行动加上下游上下文的属性。一个触发外部 Webhook 的“编辑记录”操作在内部是可逆的，但在外部是不可恢复的——第三方已经收到了数据，合作伙伴已经给客户开了发票，电子邮件已经离开了 SMTP 网关。编写记录的 Agent 的可逆性窗口受限于最慢的下游不可逆副作用的延迟，而登记册必须捕获的是这个延迟，而不是 Agent 自身撤销操作的延迟。

在 2026 年，欧盟《产品责任指令》（EU Product Liability Directive）对“缺陷”AI 系统的严格责任框架，以及加州的 AB 316 法案（该法案排除被告将 AI 系统的自主性作为辩护理由），都使得这一列成为了法律证据。一个带有文档化控制措施的短可逆性窗口是一种辩护手段；而一个没有检测机制的长可逆性窗口，则是原告律师会传唤调取的证据。

归属清晰度：谁负责这一行？

最后一列是最简单的，也是最具诊断意义的。每一行都必须指名一个负责该风险的自然人、一个运营该 Agent 的团队，以及一个签字确认该行内容为最新的高管。如果不能毫无争议地在这一行填上三个名字，那么这一行就不是一行——它是一个漏洞。

归属权是原告律师和监管机构最先阅读的内容。一项对 2026 年 AI 相关 D&O（董事及高管责任保险）诉讼的审查发现，原告的诉状中有一个共同点：缺乏记录在案的董事会监督，这里的“记录在案”意味着有具名的负责人、有记录的审查日期，以及显示董事会在风险演变为事件之前已审阅过该风险的审批日志。一个无人负责的行比缺失的行更糟糕，因为在证据开示阶段，它证明了组织知道风险存在却选择了不分配负责人。

组织失效模式是众所周知的：Agent 由应用 AI 团队构建，由产品团队部署，由平台团队监控，并由一个未被告知自主等级的证券团队管理。事件发生后的第二天早上，主管询问谁负责这个 Agent，四个团队互相指责。单人负责制正是为了弥补这一差距。董事会不需要理解 Agent；他们只需要知道下一次审查应该出现在谁的日程表上。

频率：董事会多久查看一次？

一份每年审查一次的登记册，在一年中的 11 个月里都是错误的。频率问题是将“可辩护的治理姿态”与“走形式的治理姿态”区分开来的关键，而 AI 风险行的答案要比传统风险行更短，因为底层系统变化得更快。

2026 年一种可行的节奏是：由 AI 功能负责人每月审查一次自主等级为“受限写入”或更高等级的每一行；由审计委员会每季度审查一次汇总报告，并标出重大变化；每当 Agent 的工具范围发生变化、底层模型升级，或更广泛的行业事件暗示威胁模型已发生转变时，立即进行基于触发器的审查。基于触发器的审查是大多数团队会跳过的，但它恰恰能捕捉到前文描述的“隐性自主权提升”——即当添加了一个下游系统，在没有人编辑该行的情况下，实际上提升了 Agent 的等级。

频率还必须包括一个“弃用”循环。停用的 Agent 必须干净利落地离开登记册，并附带证明凭证已轮换、工作流已清空、该行已注销并标明日期的记录。一个在工程追踪器中显示为“已弃用”但在登记册中仍有活跃凭证的 Agent，是“治理演戏”最糟糕的版本：它宣称风险已消失，但访问界面依然敞开。

现在该把什么列入日程

这五列背后的架构认知是：AI 风险登记册是一个运行时产物（runtime artifact），而不是一个文档产物。每一列都指向一个必须存在于生产环境中的控制措施：自主等级指向网关强制执行的工具白名单，爆炸半径指向预算和速率限制，评估覆盖率指向刷新流水线，可逆性窗口指向检测和回滚工具，归属权指向值班负责人。登记册是断言这些控制措施存在的文档；而控制措施才是使文档真实有效的原因。

如果一个团队走进事故后的董事会会议时，带着一份列出了每一列、每个负责人、每个审查日期和每个补偿性控制措施的登记册，他们谈论的是如何加固控制措施。而如果一个团队走进会议时，登记册上显示该 Agent 在上线三个月后仍处于“开发中”，他们谈论的将是另一件事——公司高管是否履行了受托责任，以及 D&O 保险承运人需要了解什么。

编写这一行的最佳时机是 Agent 上线的那天。次优时机是在 CRO（首席风险官）打电话来的那个早晨之前。

参考资料

• 97% 的企业预计年内会发生重大 AI Agent 安全事件 — Security Boulevard
• 2026 年 AI 风险：商业领袖需要了解的内容 — Aon
• 爆炸半径问题 — Kiteworks
• 《萨班斯-奥克斯利法案》与 AI 治理差距：董事及高级管理人员责任保险 (D&O) 的考量因素 — WTW
• 全球 AI 法规：董事及高级管理人员责任 (D&O) 的影响 — The D&O Diary
• 防御性 AI：董事会必须做对的事情 — Directors & Boards
• 企业级 AI 控制平面：可逆的自主性 — Medium
• AI 风险分类与分级工作流 — Agility at Scale
• AI 事件汇总：2025 年 11 月 – 2026 年 1 月 — AI Incident Database
• NIST AI 风险管理框架