AI 项目风险登记表模板：让15组字段支持真正的决策

下载模板，并先确定哪些内容应该进入风险表

下载15组可编辑风险记录，以及六条案例与证据说明。下载文件是纯文本 Markdown，可以将其中的部分复制到获准使用的文档、项目管理系统或电子表格中。它们不是 Excel 工作簿，没有自动评分宏。这里的15组是逻辑分组；每组可以拆成多个数据库字段，不应把证据、负责人和截止日期挤在一个单元格里。

录入第一条风险前，先写清登记表的共同约定：试点边界、允许执行的动作、受影响用户、评估周期、证据存放位置、评分规则版本、接受权限和复查触发条件。本文的虚构案例是一个内部客服助手试点，评估周期截至2026年1月31日，统计快照为1月15日00:00 UTC。这些日期用于演示前后一致的记录，不代表 OpenMax 的真实部署。

如果风险、问题、假设和任务混在一起，负责人往往会把“做完任务”误认为“风险已消除”。先用下面的区分确定下一步应由谁处理。

一个事件可能暴露多项未来风险，一项风险也可能对应多项措施。保留这些关联，不要每增加一个任务就复制一条相同风险。风险登记表应持续保存历史，而不是每周重建一份没有来历的汇报表。NIST 的风险登记表术语条目也包含持续记录和保留已接受风险的含义。

15组字段分别怎么填写

1. 稳定编号与明确的业务流程

为每项风险设置长期不变的编号、简短标题和适用流程。系统或配置版本会影响判断时，也应写明。例如“R03：客服试点 v0.4 的提示输入包含机密信息”比“数据风险”更有用。之后更换模型或连接器，应能看到同一风险在新条件下的评估，而不是某个颜色无缘无故改变。

同时记录不在范围内的能力。只能生成草稿的只读助手，与有权执行退款的代理，所面对的风险不同。对草稿回复的评估不能被解释为批准交易执行。扩大操作权限之前，先明确扩大后的边界和重新评估要求。

2. 原因、不确定事件与后果

使用完整陈述：“由于过期价格文档仍可被检索，助手可能起草过时报价，导致客服向客户承诺企业无法履行的条款。”原因帮助确定措施，事件帮助确定检测对象，后果帮助识别谁可能受到影响。

不要把所有后果统一写成“声誉损失”。误导性答复、个人信息披露和未经授权退款，可能使用同一个模型，但需要不同证据、负责人和处置方式。是否拆分记录应取决于决策是否不同，而不是为了让表格看起来更丰富。

3. 分类与受影响人群

选用数量有限、定义清晰的分类，例如信息质量、保密性、越权操作、可用性、人员与流程、项目交付；需要时增加辅助分类。分类用于筛选，不能代替风险陈述。“保密性”并没有说明哪些资料可能通过什么路径被谁看到。

写出受影响群体及其可能承受的后果。同一次延误，对内部分析人员可能只是短暂不便，对等待紧急处理的客户却可能造成明显损害。不能因为企业自身修复成本较低，就忽略项目团队之外的人承担的影响。

4. 证据与可定位来源

记录带日期的测试结果、配置检查、事件记录或依赖说明，并注明版本和相关段落、结果位置。审核人无法查看某份来源时，应明确写出访问缺口，不能把无法核查的摘要包装成已验证事实。

敏感原始内容应留在获准使用的受限资料库。风险表通常只需要必要说明和受控证据编号，不需要复制含个人信息、密钥或内部机密的完整提示。证据链接失效应触发补查，而不是被当成风险已不存在的理由。

5. 评估周期与关键假设

说明评估覆盖的时间、业务量、用户和运行条件。“1月有限试点，内部客服逐条审阅草稿”与“不受限制的客户直连生产环境”不是同一个情景。知识库保持更新、人工备用流程可用等依赖条件，应单独列出。

对重要假设指定核实负责人，并写出何时需要重新评估。“供应商不会变更模型”不能永久当作事实。如果无法确认，就保留不确定性，并考虑更受限的使用决定。信息缺失不能悄悄变成最低的发生可能性。

6. 假设无相关控制时的固有风险

如果组织的方法要求评估固有风险，应明确该假设情景排除了哪些相关控制。尽量与当前评估使用相同后果和时间范围，否则说明差异。当权限限制和人工审阅已经存在时，仅标注“采取措施前”会产生歧义。

固有风险是分析情景，不意味着为了测分就移除真实保护措施。不要在生产环境中关闭控制来获取一个数字。组织不要求这种基准时，可以说明原因并标记未评估，不应刻意编造较高分数来证明后续措施效果显著。

7. 目前实际运行的控制措施

列明已经生效的控制、责任人、覆盖范围和证据日期。配置中的权限边界，与要求员工谨慎操作的制度，可能都有作用，但失效方式不同。不要把已发布的制度、已配置的限制和已验证的效果混成一个“有控制”标签。

对于重要控制，记录它在什么条件下可能失效。例如强制审批，如果审核人看不到来源，或另一条操作路径可以绕过审批，就不能提供预期的保护。“人在回路中”不是充分说明；必须有真实的判断节点以及停止动作的能力。

8. 当前可能性、影响与优先级

依据目前实际运行的控制评估风险，记录发生可能性、影响等级、最终优先级、理由、评估人、日期和规则版本。证据可信度与后果严重性是两个问题：证据薄弱不意味着影响轻微，影响严重也不意味着已经知道准确概率。

本文后面提供一个演示用的小型查表规则，它不是概率模型，也不是 NIST 指定的量表。缺少评估就使用“待评估”。在调查期间，仍可能需要暂停受影响能力；没有分数，不能成为忽视潜在严重事件的理由。

9. 应对策略与范围

说明准备采取什么方式，以及业务流程将如何改变。规避某项风险可能意味着移除交易能力；缓解可能意味着限制该能力，并验证审批边界。合同责任安排或保险可能改变某些费用由谁承担，但不必然消除用户受到的损害。

接受风险需要独立的授权决定，不是“研发没时间处理”的另一种说法。写出仍然存在的风险和可选方案。如果措施引入新风险，例如备用流程导致客服负荷过高，应新增或关联记录，而不是只汇报没有条件的改善。

10. 对风险负责的人

指定一个承担问责的人，或一个已明确当前任职人的角色，并附升级路径。“IT 部门”这类集体名称，不能说明复查逾期时到底由谁响应。应确认对方知道自己承担责任，并能够取得相关证据。

风险负责人不必亲自执行所有措施，也未必有权限接受风险。这几种责任应分开记录。如果负责人未指定，应形成待分派异常，而不是因为不属于任何人的“我的风险”视图而从关注范围里消失。

11. 措施、执行人和截止时间

每项措施都有独立编号、交付物、负责人、截止日期及时区约定、状态和完成证据。“提升安全性”无法检验；“移除过期价格集合并提交检索测试结果”则能被审核。多项措施不要合并成一句没有责任边界的描述。

将完成状态和有效性验证分开。一项工作可能按时完成，但随后测试发现保护措施仍可被绕过。即使风险优先级只是中等，措施逾期也应可见。调整原截止时间时，保留修改理由和批准记录，不要覆盖掉逾期历史。

12. 计划实施后的目标评估

写明希望达到的风险水平，以及实现该目标的条件。必须标注“目标”，不能标成“当前”或“已验证”。这能帮助审核人判断拟议工作是否足够，以及直接收紧功能范围是否更合适。

目标依赖成功实施与验证，不能被当作安全保证，也不应进入当前风险汇总。如果为了取得上线批准而把目标调低，记录隐藏的正是最应该讨论的决策。目标没有实现时，需要重新考虑措施，而不是改写已经观察到的结果。

13. 控制验证与剩余风险重评

记录测试条件、结果、局限、证据位置和审核人。可使用“未运行”“在说明范围内通过”“失败”“无法确定”等明确状态，再依据这些信息记录带日期的重评。单项测试通过，也不一定足以调低整体风险等级。

本文的 R03 案例中，提示过滤修改已经完成，但虚构机密标记仍能通过另一条输入路径，验证结果为失败。因此，较低的计划值仍然只是目标，当前“高”风险保持不变。证据支持的是重新处理措施，而不是宣布控制已有效。

14. 接受权限与附带条件

接受风险时，应记录决策人、权限依据、接受范围、理由、限制、开始时间及到期时间或复查条件，并关联决策记录。风险负责人提出“建议接受”，不等于具备权限的人已经批准。

被接受的风险仍可能具有实质影响。保留当前评估和监控要求。接受决定到期时，应按组织规定重新取得决定；不能因为没有人发表新意见，就默认为使用权限自动续期。负责人离职或条件改变，也可能要求提前复查。

15. 生命周期、历史与下次复查

状态说明的是生命周期，而非严重程度，例如“处理中”“附条件接受”“针对明确风险范围关闭”。保留下次复查日期、事件触发条件、历史评估和每次变化的原因。已经发生的事件可以在问题表处理，同时保留再次发生的风险。

关闭需要理由、证据和有权限的审核人。移除一个过时导出任务，可以关闭与该任务有关的特定风险，但不能证明企业整体的数据披露风险为零。写出重新打开的条件，例如任务恢复、增加新的导出路径或原关闭证据失效。

用五个步骤让风险表真正运转

1. 先约定决策边界，再开始评分。 明确试点范围、评估周期、规则版本和权限，确认谁可以限制、暂停或恢复能力。不同团队评分定义不一致时，先解决口径冲突，不要直接合并颜色。
2. 从少量有证据的风险开始。 检查预期行为、权限、依赖、已知事件和受影响用户的顾虑。AI 生成的建议只能作为候选；删去无关套话，来源不足时保留待评估。
3. 评估当前风险并分派工作。 由风险负责人及相关专业人员检查假设和后果，定义独立措施、责任人、截止时间和验证条件。未来目标不进入当前风险汇总。
4. 验证措施并记录人工决定。 分清实施了什么，以及证据实际证明了什么。失败和无法确定的结果不能隐藏。接受、例外和放行决定遵循既定权限，并保留理由。
5. 按日期和事件两种方式复查。 模型、权限、来源数据或流程改变，控制失败，发生事件，负责人变更或接受到期，都可能触发重评。常规复查间隔应与组织风险匹配，而不是套用统一的每周或每季度承诺。

NIST AI RMF 核心内容的 MEASURE 1.2 涉及现有控制有效性评估，MANAGE 涉及应对及剩余风险记录。它并不规定本文模板或查表矩阵。应由组织中具备相应能力的风险和业务专业人员审核具体流程，而不是把引用框架当成批准。

六条案例：填完、做完和验证通过并不是一回事

下列记录、证据编号和角色均为虚构。试点采用演示规则 v1，没有真实客户数据，也不代表 OpenMax 性能或适用于所有企业的风险结论。完整下载资料包给出了假设、证据说明和决策历史，便于按同一口径复核。

发生可能性使用定性描述：“不太可能”表示在当前说明的控制下需要非常规条件；“有现实可能”表示试点条件下存在可信路径；“预期会发生”表示在评估周期内应为其发生做好安排。“未知”表示证据不足，不能选择上述等级。这些词没有被赋予百分比。影响分为可局部恢复的不便、明显客户或运营损害、以及按虚构规则必须专业升级处理的严重后果。正式使用时，组织应自行明确适合本场景的边界。

这里采用明确查表，不把序数标签相乘。任何输入未知，都返回“待评估”，不能返回零。严重后果即使发生可能性证据不足，也需要升级关注。这些优先级用于组织注意力，不授予使用权限；“低”不等于自动放行，“高”也不能只靠换一个标签就变成“中”。

在1月15日00:00 UTC 的快照中，六条记录全部保留。R01 至 R05 是五条仍有当前风险的记录，其中四条完成当前评估，所以评估覆盖率为 4/5＝80%。这表示记录完整度，不表示“80%安全”。R06 是保留的历史记录，不进入这个当前风险分母。

示例有两项未完成措施：负责人分派 A01 和来源纠正 A02。其中一项逾期，所以未完成措施中的逾期比例为 1/2＝50%。A03 已完成，不进入这个分母；但它进入另一项统计：需要验证的已完成处理措施共一项，通过的为零，即 0/1。只统计已完成数量，会掩盖保护措施验证失败的事实。

R04 是接受而非关闭，当前评估仍为中等，接受决定有时间限制。R05 关联问题，是因为退款事件已经发生；问题解决本身不代表不会再次发生。R06 则演示有范围限制的关闭：已记录的特定风险来源被移除，但其他位置可能仍有相关数据风险。

选择人工、规则检查还是代理辅助

小型试点可以从获准使用的共享记录和明确审核人开始。来源少、变化不频繁时，这往往更容易管理。主要弱点是漏跟进，因此需要指定复查责任人，并单独查看未分派、措施逾期和接受即将到期的记录。增加软件不会自动解决权限争议。

如果现有项目管理系统支持必填字段、权限、修改历史和提醒，可以围绕已约定的流程进行配置，并用测试记录验证。检查父风险被接受以后，其逾期措施是否仍能看到；修改截止日期以后，旧值是否保留。不要仅凭功能名称就认定这些行为已经满足要求。

规则或脚本适合机械检查：负责人缺失、日期无效、接受过期、编号冲突、目标值误填当前列等。评分规则版本必须明确。程序能发现证据缺失，却不能证明无法检查的控制有效。遇到不确定情况，送交审核，不要默认填写“低”。

当资料分散在多个获准来源时，代理辅助整理候选更新更有评估价值。先使用只读访问，要求每条建议保留来源，替换正式记录前必须审核。特别检查虚构证据编号、推断负责人、擅自改变评级等问题。扩大规模后，还需分离接受和放行权限，保留修改日志、访问限制以及经过测试的停止更新方式。这些是实施验收条件，不代表某个产品已经提供全部能力。

OpenMax 可以放在哪一环，哪些能力必须先验证

本文由 OpenMax 内容团队撰写。OpenMax 官网以人和代理协作为产品定位。对风险登记流程，一个值得评估的用途是让代理准备带来源的更新建议，由人保留评估与接受决定。这是拟议应用，不代表已经验证 OpenMax 具有原生风险登记表、认证评分、项目工具自动同步或合规保障。

连接真实项目资料前，可先要求使用上述六条虚构记录演示：R01 应保持待评估，A02 应显示逾期，R03 的失败验证不能被覆盖，R04 保留接受到期日，R05 关联问题，R06 不应在没有相关变化时被自动重新打开。同时确认谁能查看受限证据、修改评级、批准接受、恢复旧版本。应检查具体配置中的行为，而不是从一般产品定位推断功能。

如果团队只有少量风险、无法确定来源权限，或没有人有权审阅更新，先采用简单共享记录更合适。下一步可以携带虚构资料与 OpenMax 讨论有限的人机协作流程，而不是直接授权代理接受风险。接受理由放进决策日志，已发生事件关联事件复盘，项目状态报告只汇总核实后的记录，不取代原始依据。

使用边界、敏感资料与专业审阅

风险登记表是协作工具，不是完整安全评估，也不能单独证明法律合规。它的价值取决于每条记录背后的范围、证据、专业判断和决定。即使维护得很整齐，也可能遗漏重大风险。对后果重大的部署，应由相关业务、安全、隐私和法律专业人员参与；本文没有经过具名独立专业审阅。

不要为了填表就上传机密提示、个人信息、凭证或事件细节。与负责团队确定允许的存储位置、访问范围和保留规则。只分享决策所需的最少证据，并用实际审核人角色检查访问情况。广泛共享的风险表可以描述受限证据记录，而不公开其中的原始内容。

示例矩阵、日期、阈值和状态是教学设计，不是行业统一要求。NIST AI RMF 概览说明框架为自愿采用；截至2026年9月4日查阅时，页面注明1.0版本正在修订。将模板纳入正式流程前，应确认所用框架版本，以及适用的组织制度和当地要求。

常见问题

下载的是 Excel 风险登记表吗？

不是。下载内容是可编辑 Markdown 记录和案例资料包，不是 XLSX 工作簿。可以将15组逻辑字段复制进电子表格，但应把负责人、日期、评估类型和验证状态分成独立列，不能为了简化表格就将目标评估标成当前风险。

每个 AI 项目都应该使用五乘五风险矩阵吗？

没有一个矩阵适用于所有项目。应使用组织认可、适合具体决策和后果的方法。本文三乘三示例是明确查表，不是概率估计。证据未知仍为待评估；即使无法确定发生可能性，也要关注潜在严重后果。

什么时候可以把剩余风险调得比当前风险低？

需要已实施变化及有记录的重新评估，支持在相关范围内得出这一结论。完成任务或通过一项有限测试，不会自动使风险下降。当前风险也可能已经是现有控制后的剩余风险，因此必须写清评估日期和基准。

已经接受的风险是否可以从表中删除？

只要被接受的风险仍然相关，就不应删除。保留当前评估、授权决定、条件、复查日期和到期安排。接受属于治理决定，不等于消除风险；关闭需要独立理由和证据。

AI 代理可以不经人工审阅维护风险表吗？

可以评估代理是否适合准备带来源的候选更新等有限工作，但不能假定它具备判断后果、接受风险或批准部署的能力和权限。先建立并测试审核边界。本文没有验证 OpenMax 或其他产品已经具备这些具体能力。

来源与证据边界

来源查阅日期为2026年9月4日：NIST 固有风险、剩余风险、风险登记表、AI RMF 核心内容和框架概览。它们支持相邻段落中的特定概念，不证明本文表格有效，也不构成对 OpenMax 的认可。OpenMax 官网属于第一方定位来源，不是独立产品验证。

15组结构、六条记录、证据说明、查表规则及计算均为原创教学材料，不是客户成果、实证研究、NIST 官方模板或经过测试的 OpenMax 自动化。投入实际使用前，应由承担责任的专业人员批准范围、评级方法、证据规则和决策权限。