如何利用 AI 创建风险登记册：完整指南
风险登记册是一张列出可能出现的问题及其发生概率的表格。它还记录了会造成什么损失、负责人是谁以及您决定采取什么措施。大多数团队都是在发生了一些没人记录过的状况之后，才开始建立第一份风险登记册。本指南将介绍手动创建的途径，以及利用您已有的导出数据进行快速创建的更高效途径。
什么是风险登记册
最清晰的定义来自 NIST 的词汇表，它将其称为“风险信息的存储库，包括随着时间的推移对风险所了解的数据”。
同一页面上的第二个条目对实际工作更有用。它将其描述为针对特定范围或组织的当前风险的中央记录。
该条目随后做出了大多数模板都忽略的区分。当前的风险既包括您已经接受的风险，也包括具有计划缓解路径的风险。
这就是核心理念。风险登记册不是等待解决的问题清单。它是一份决策记录，而“我们评估了这个问题并决定接受它”也是一个合理的条目。
这种区分具有实际意义。如果遗漏了已接受的风险，就没人能分清一个风险是经过权衡后被否决的，还是根本就没有被发现。六个月后，这两者看起来一模一样，而其中只有一个属于失职。
在构建之前，请注意一个范围说明。NIST 的材料处于联邦和网络安全背景下。其词汇表条目指向了 OMB Circular A-11，规定了联邦登记册必须包含的内容。这里接下来介绍的是大多数团队实际需要的管理版本，而不是按照合规标准构建的登记册。如果您是根据特定框架进行申报，请使用该框架的字段列表。
不过，该文献中的一个理念确实可以借鉴。NIST 的 IR 8286 是围绕登记册构建的。其摘要解释了“将通常在较低系统和组织层面处理的风险衡量标准汇总到更广泛的企业层面的价值”。
这在设计第一个版本时就值得考虑。一个评分基于可比数据的登记册可以与另一个团队的登记册合并；而一个基于个人主观判断构建的登记册则无法做到这一点。
开始前您需要准备什么
三个输入要素，且它们很少存在于同一个地方。
- 危险源清单。 无论记录得多么非正式，只要是您团队已经在担心的事情。
- 风险暴露数据。 供应商支出、合同条款、各站点员工人数、系统库存、事件历史记录。
- 负责人关系图。 谁能真正做出决定，而不是谁报告了问题。
您还需要提前确定一个数字。即影响阈值，只有超过该阈值的事项才属于风险登记册的范畴。如果没有它，表格就会塞满没人会去处理的项目。
将其设置为与您的风险暴露数据相同的单位。以年支出表示的阈值是可核查的；而以“重大”表示的阈值则会在每次评审时重新引发争论。
如何手动构建风险登记册
方案 1：电子表格中的单张表格
每个风险占一行，发生概率和影响程度作为列。这几乎是所有登记册的起点，对于小团队来说已经足够了。
代价是维护成本。每一行都需要手动输入，而在产出该登记册的研讨会结束后的第二周，登记册就会开始过时。
方案 2：对风险进行评分并排序
为发生概率 and 影响程度分别评分，将它们相乘，然后进行排序。现在表格有了顺序，这是使其在会议中发挥作用的首要条件。
难点在于一致性。两个人相隔一个月对同一个风险进行评分，结果会产生分歧，而电子表格中没有任何机制可以发现这一点。
方案 3：将评分建立在您自己的数据基础上
这是一个经得起质疑的版本。您无需凭记忆对供应商风险进行评分，而是提取真实的数据。年支出、合同通知期以及有多少个团队依赖该供应商，这些因素共同决定了影响评级。
FEMA 的 Ready.gov 指南在物理风险方面也指出了相同的方向。其风险评估页面告诉企业要“寻找可能使您的企业更容易受到灾害破坏的漏洞或薄弱环节”。指南指出，这些薄弱环节“在事件发生时会加剧破坏的严重程度”。
同一页面还从投资的角度阐述了应对措施。影响“可以通过投资于缓解措施来减轻”。在潜在影响重大的情况下，制定缓解策略“应该是当务之急”。
这是正确的方法，但也是缓慢的方法。每个风险都意味着要重新查看不同的导出数据。
如何利用 AI 创建风险登记册
步骤 1：上传描述您的风险暴露的导出数据
打开 Powerdrill Bloom and 上传您拥有的数据：供应商支出导出、合同列表、系统库存、过去的事件日志。请将它们一起上传，而不是逐个上传。
然后用自然语言描述您的范围。说明该登记册覆盖业务的哪一部分、您的影响阈值是多少，以及您采用什么分值体系进行评分。
步骤 2：要求提供每个风险的暴露数据，而不是评级
要求生成一个表格，每个候选风险占一行，其中包含决定评分的数据。例如年支出、依赖该供应商的团队数量、通知期以及过去一年的事件数量。
要求提供每个数字的来源。平台会返回一个有据可查的答案，指出每个数字背后的具体页码和行数。在风险登记册中，这种可追溯性决定了您的评分是理据充分还是站不住脚。
根据这些数据自己进行评分。判断是应该由人类来完成的部分。
步骤 3：添加您的决策并导出
针对每一行，记录决策：接受、缓解、转移或规避。如果决策是缓解，请添加计划采取的行动、负责人和评审日期。
然后导出按评分排序的表格。保留风险暴露数据列，不要将其删除。下季度的评审将从这些数字是否发生变化开始。
如果该登记册成为一项定期交付的工作，每个方案中都列出了计划任务，其中 Free 方案包含 1 个，Pro 及以上方案包含 20 个。每季度更新一次适合大多数团队。
每一行应该包含什么
| 列 | 为什么它占有一席之地 |
|---|---|
| 风险描述 | 写成原因和结果，而不是一个主题 |
| 发生概率 | 占评分的一半，且是人们凭空猜测的那一半 |
| 影响程度 | 应该可以追溯到真实的数字 |
| 风险暴露数据 | 影响评级所依据的数字 |
| 决策 | 接受、缓解、转移或规避 |
| 缓解措施与负责人 | 只有指定到具体个人才有意义 |
| 评审日期 | 如果没有它，登记册就会在无形中失效 |
风险暴露数据列是大多数模板都会遗漏的一列。保留它可以将主观评级转化为下一位评审人员可以核查的内容。
最佳实践与常见错误
同时记录已接受的风险。 一个只包含未解决项目的登记册只是一张任务清单。已接受的条目是当以后有人询问是否有人考虑过某个风险时，能够为您提供保护的依据。
将风险写成原因和结果。 “供应商集中度”是一个主题。而“我们的计费依赖于一家通知期为 90 天的供应商”则是一个您可以进行评分的风险。
将影响与数字挂钩。 即使是一个粗略的数字，也比凭空捏造的评级要好，而且它能让下一次评审变成对比，而不是重新引发争论。
为每一行指定一位负责人。 共同承担风险往往意味着根本没人去评审它，而负责人应该是能够批准缓解措施的人。
按行而不是按登记册设置评审日期。 供应商风险和监管风险的变化周期不同，而单一的季度全面排查则将它们一视同仁，这显然是不合理的。
将其与供应商绩效分开。 它们使用重叠的导出数据，并回答不同的问题。根据交付和质量对供应商进行评估属于我们关于供应商计分卡的指南内容；而登记册关注的是如果该供应商倒闭会发生什么。
统一术语定义。 发生概率区间和影响层级对每个评分人员来说应该具有相同的含义。这与我们在构建数据字典的演练中所涵盖的原则相同。如果输出结果成为一份常设文档，AI 报告生成器页面展示了其具体形态。
结论
风险登记册的价值在于将零散的担忧转化为决策记录，包括接受某事并继续前进的决策。难点从来不在于表格的布局，而在于将每个影响评级建立在数字而非感觉的基础上。
利用您已有的导出数据构建风险登记册，并在评分旁保持风险暴露数据可见。为每一行指定负责人和评审日期。
已经拥有供应商和事件导出数据了吗？立即体验 Powerdrill Bloom，并在本周构建您的第一个版本。
常见问题解答
什么是风险登记册？
NIST 的词汇表将其描述为风险信息的存储库，涵盖了随着时间的推移对风险所了解的数据。在实践中，它是一张记录每个风险、其评级、其负责人以及针对其所做决策的表格。
风险登记册应该包含哪些列？
至少包括：写成原因和结果的风险、发生概率、影响程度以及影响评级背后的数据。然后是决策、缓解措施及其负责人，以及评审日期。
已接受的风险应该保留在登记册中吗？
是的。NIST 的定义将当前风险视为既包括已接受的风险，也包括具有计划缓解路径的风险。删除已接受的项目会丢失该决策的记录。
应该多长时间评审一次？
按行而不是针对整个文档设置评审日期，因为不同类别的风险在不同的时间尺度上发生变化。对评分最高的行进行季度排查适合大多数团队。
这与风险评估是一回事吗？
不是。Ready.gov 将风险评估描述为识别危险源并分析可能发生的情况的过程。而登记册则是记录结果和决策的载体。