风险登记册为何失效及如何修复

在项目启动周，团队精心编写了一份风险登记册，覆盖了当时能想象到的各种风险。几个月后，这份文档描述的系统早已不存在，但没有人注意到，因为整个流程中没有任何环节要求重新打开它。这不是登记册的失败，而是把风险管理当作文档而非流程的典型错误。

EU AI Act第9条：风险管理必须持续迭代

EU AI Act第9条明确要求，高风险AI系统的风险管理应当是持续、迭代的，贯穿整个生命周期。具体包括：识别和分析已知及可预见的风险，估计和评估残余风险，采取适当的控制措施，并记录和测试所有内容，包括预期目的和合理可预见的误用带来的风险。一次性填写的电子表格远远达不到这一要求。

启动登记册的先天不足

启动时的风险登记册擅长识别上线前能想象的风险，但难以应对上线后出现的新情况：新的数据源接入、模型更新、无人预见的用例、安全事故、用户使用方式的漂移等。第9条期望在系统和环境变化时重新审视分析，并记录残余风险的推理过程，而不仅仅是初始风险清单。作者坦言：“我只有初始风险，没有触发机制。”

缺失的触发机制：登记册为何会“变绿”

作者发现，自己缺少一个“现在重新打开登记册”的触发条件。没有触发，重新评估只能靠记忆，而记忆往往不会发生。登记册保持绿色，是因为没有添加新内容，而不是因为系统没有变化。这是一个关键洞察：一个长期不更新的登记册，其“绿色”状态是虚假的安全感。

缺失的残余风险：控制与结果之间的连接

作者还缺少对残余风险的明确表述。团队列出了危险和控制措施，但很少写出连接句：“采取这项控制后，剩余的风险是什么？为什么我们认为它可以接受？”这正是评估测试关注的部分，也是最容易过时的部分——启动时足够的控制，可能因输入分布变化而失效。

重写风险项：把登记册变成循环

作者重写了每个风险项，使其包含五个要素：危险、可能性和严重性估计、控制措施、明确的残余风险陈述、重新评估触发条件。其中，触发字段是点睛之笔，它把静态的登记册变成了动态的循环。“模型版本变化时重新评估”“严重事故后重新评估”——这些看似平淡的句子，恰恰是让风险管理真正持续的关键。

RmsForge：从描述到框架的工具

作者构建了RmsForge，用于起草上述框架。使用时，你粘贴自己如何运行AI系统的描述，工具会返回一个Article 9风险管理起点：风险主题、残余风险缺口、生命周期触发条件、证据缺口。工具并不了解你的具体危险，不测试控制措施，也不运行评估。它只生成草稿框架，真正的风险识别、估计、控制和残余风险判断，必须来自熟悉系统的人。

实用解读：这个工具对谁有价值

RmsForge是决策支持工具，不是法律建议、认证或实时审计。它不观察你的系统、不验证控制措施、也不决定Article 9是否适用——这取决于高风险分类和你的角色。如果系统不属于高风险类别，大部分工作并不适用。作者强调，他引用的是真实义务，而不是截止日期、罚款或合规保证。对于开发者和AI使用者来说，这个工具的价值在于：它提供了一个可争论的框架，让你在启动后依然能持续审视风险，而不是让登记册在角落里积灰。

结论

如果风险登记册是启动时的电子表格，自上线后从未被打开，RmsForge的粘贴优先起点能给你一个可争论的框架。但记住：它输出的是风险管理系统的起点，不是系统本身。真正的风险管理，需要你持续维护、更新和重新评估。