人工智能风险记录怎么做：从系统用途到复核责任

引入人工智能系统时，风险清单如果只写“模型可能出错”，很难帮助项目成员判断要收集哪些资料、何时复查以及由谁处理。更有用的做法是把系统用途、使用边界、可观察的问题和待确认事项分别记录，并在系统或使用环境变化时回到记录中复核。

先描述系统实际承担的任务

在清单首页记录系统名称、提供方、版本或部署日期、使用部门、主要输入和输出，以及输出如何进入后续流程。明确哪些工作由人完成，哪些由系统提供辅助。信息无法确认时写“待核实”，不要根据产品宣传推断系统拥有某种能力或审批权限。

美国国家标准与技术研究院的人工智能风险管理框架介绍将框架作为帮助组织管理人工智能风险的资源。它并不是对某个具体产品的认证，也不自动确定一个系统在所有地区适用的法律义务。项目团队仍需结合自身用途和适用要求判断。

同一个系统在不同使用场景中可能面对不同输入、人员和后果。记录中可包括目标用户、使用频率、相关业务环节、输出接收方、可用的替代流程以及系统不可用时的处理方式。对涉及人员权益、敏感信息或重要业务的场景，应由相关负责人参与判断，而不是仅由技术人员填写一列“风险等级”。

假设一个团队使用系统整理公开设备资料。它可以先记录资料来源、生成内容的用途和复核者；若后来改为处理客户资料，输入和权限条件已发生变化，应重新评估。这个假设用于说明记录方法，不代表某个真实系统的能力或事件。

发现问题时，记录发生时间、使用条件、可复现的输入范围、实际输出和问题发现方式。若涉及敏感信息，应按组织要求限制保存和访问。可以记录潜在影响及其依据，但不应把尚未核实的原因写成确定结论，也不应仅凭一次结果推断系统整体表现。

NIST 的AI RMF 核心功能资料介绍了治理、情境映射、测量与管理等功能。团队可以参考这些概念检查记录是否覆盖用途、证据和处理责任；本文的表格建议并不是 NIST 对某个产品给出的测试结论。

每条待办至少写明问题描述、相关版本、负责人、当前状态、下一步需要的证据和复核时间。如果依赖供应商答复，记录提出问题的日期和具体问题。完成一项处理后，保留处理说明和验证结果；没有进行验证时，状态应保持待核实。

风险清单也应记录已知限制。例如，测试仅覆盖某类输入、资料仅来自供应商说明，或者尚未获得相关系统访问权限。不能把这些限制写成“全部场景已通过”。对超出团队能力范围的法律、行业或安全问题，应交由相应专业人员评估。

更换模型版本、扩大用户范围、增加数据来源或改变输出用途，都可能使旧记录不再完整。建议保留变更前后版本和实际生效时间，检查既有问题是否仍适用，并明确是否需要补充测试。若回滚，只记录已核实的操作和结果，不推断尚未检查的系统状态。

有关复核人员职责的组织方法，可阅读本站人工复核流程中的记录问题；行业资讯栏目提供相关背景。本文帮助整理治理资料，不替代正式风险评估、合规判断或具体系统的安全验证。