给AI应用做风险评估，先落一份能执行的风险清单配置
AI风险评估配置的核心不是找一份模板填完存档，而是把“这个AI应用可能出什么问题、出了谁负责、多久复查一次”变成可检查、可追踪的条目。
适用于准备上线或已上线AI应用的团队；
如果只是内部试验、没有真实用户数据，评估范围可以相应收窄。
先界定评估对象，别一上来就列风险
配置之前必须先写清楚三件事，否则后面的条目会互相打架：
- 系统边界：这个AI应用包含哪些部分，是只有模型推理接口，还是含知识库、插件调用、人工复核环节。
- 使用场景：面向内部员工还是外部用户，输出是否直接影响用户决策（如客服答复、内容审核、辅助诊断）。
- 数据范围：输入里是否包含个人信息、商业秘密或敏感业务数据，数据是否出境、是否用于训练。
这三项确定后，风险清单才有比较基准。
同一套模型，用在内部文档检索和用在对外客服，风险等级不应该一样。
风险条目的字段怎么设计
一份能执行的清单，每个条目至少包含以下字段，建议直接用表格或工单系统管理：
| 字段 | 说明 |
| --- | --- |
| 风险描述 | 一句话写清“什么情况下会出什么问题” |
| 影响对象 | 用户、企业、第三方或数据主体 |
| 可能性 | 高/中/低，附判断依据 |
| 影响程度 | 高/中/低，说明最坏结果 |
| 现有控制措施 | 已做的过滤、鉴权、人工复核等 |
| 剩余风险 | 控制后仍存在的风险等级 |
| 负责人 | 具体到岗位或人名，不能写“团队” |
| 复核周期 | 按月、按季度或触发式复核 |
字段不必求多，但负责人和复核周期不能缺。
缺了这两项，清单就退化成一次性文档。
分级规则要能落到判断条件上
常见做法是按“可能性 × 影响程度”得到风险等级，但真正难的是给每个维度写出可判断的条件，而不是凭感觉打分。
可以参考这样的写法：
- 影响程度为高：输出错误会导致用户财产损失、人身安全风险、大规模个人信息泄露，或被用于对外正式决策。
- 影响程度为中：输出错误需要人工返工，或造成局部业务中断但不涉及上述后果。
- 可能性为高：同类问题在测试或试运行中已出现过，或缺乏任何输出过滤。
- 可能性为低：有明确的技术约束和人工复核双重拦截，且历史未出现。
分级结果决定后续动作：高风险条目必须有上线前控制措施和更短的复核周期；
中风险可以带条件上线；
低风险按常规周期抽查。分级规则一旦确定，同一批评估要使用同一套标准，避免不同人评出不同结论。
把配置落到实际操作上
如果团队用表格管理，可以按以下顺序执行：
- 建一张清单表，按上面的字段建列，另加“评估日期”和“状态”两列。
- 组织一次评估会，参与人至少包括业务负责人、技术负责人和了解合规要求的人。
- 逐条填写风险描述，每条只写一个风险，避免“模型可能不准或泄露数据”这种混合条目。
- 现场确定影响程度和可能性，有争议的条目记录下来，由业务负责人拍板。
- 为每条指定负责人和复核周期，高风险条目建议按月复核，中低风险按季度。
- 把清单状态与上线流程挂钩：高风险条目未关闭控制措施的，不进入正式发布。
如果使用工单或项目管理工具，可以把每个风险条目建为独立任务，用标签区分风险等级，用到期提醒代替人工记忆复核时间。
容易踩的坑
- 只评模型不评链路：提示词注入、知识库污染、插件越权往往比模型本身输出错误更现实，评估范围要覆盖整条调用链。
- 负责人写成部门名：出问题时找不到具体人，复核也会流于形式。
- 分级标准每次重定：不同批次评估用不同口径，结果无法比较，也无法向管理层说明风险是否下降。
- 清单和变更脱节：模型换版本、接入新数据源、开放新场景后没有触发重新评估，旧清单会失效。建议把“重大变更触发复核”写进流程。
- 把评估当成一次性合规动作：AI系统的风险随数据和用法变化，复核周期是清单能持续有效的前提。
怎么验证清单真的可用
配置完成后做一次自检：随机抽三条高风险条目，看能否回答“谁负责、上次复核是什么时候、现有控制措施是什么、剩余风险是否可接受”。
如果任何一项答不上来，说明清单还没落到可执行状态。
另一个有效方法是模拟一次输出事故，按清单追溯责任人和控制措施，检验流程是否走得通。
AI风险评估配置的价值在于让风险可见、可追、可复查。
先把评估对象和分级规则定清楚，再逐条补齐负责人和复核周期，比追求清单条目数量更重要。
