怎么给团队做 AI 风险清单How to Build an AI Risk List for Your Team

按用例拆，不按模型拆：同一个模型用来写周报和用来自动退款，风险面不一样，条目不能共用一行。

每条风险填五格：场景、触发条件、后果、现有控制、剩余缺口。只填前两格的清单没法驱动任何动作。

借现成分类打底再补自己的：NIST AI RMF 的 Govern / Map / Measure / Manage 与 OWASP 的 LLM 风险项可以当骨架，别从空白页开始想。

法规类条目单列一栏，注明依据条文与生效条件（EU AI Act 按用途分层，国内办法按服务类型定性），不要和体验问题混在同一张表里。

定更新触发线与负责人：接入新模型、接入新数据源、流程改动这三类事件要重跑一遍清单；没人认领的条目按没写处理。

举个例子（虚构情境）：输入是用例「AI 起草客户回复」→ 处理是按五格填表，触发条件写「涉及退款期限、赔付、法务口径」→ 结果判断是核对现有控制，发现出口没有期限字段核对，缺口成立 → 下一步是把该缺口列成待办，挂上负责人与验证方式（例如按周抽检回复样本，抽检数按你自己的量级定，不照抄别人的阈值）。

Break it down by use case, not by model: the same model drafting weekly reports and issuing automatic refunds carries different risks, so one row cannot cover both.

Fill five cells per entry: scenario, trigger condition, consequence, controls in place, remaining gap. A list with only the first two cells drives no action.

Borrow an existing taxonomy as the skeleton, then add yours: NIST AI RMF's Govern / Map / Measure / Manage and OWASP's LLM risk categories beat starting from a blank page.

Keep regulatory risks in their own column with the article and effective conditions noted (the EU AI Act tiers by use; China's Measures turn on service type); do not mix them with experience issues in one table.

Set update triggers and owners: connecting a new model, a new data source, or a process change should force another pass. Entries nobody owns count as not written.

Worked example (fictional scenario): input is the use case "AI drafts customer replies" -> processing fills the five cells with trigger conditions "refund deadlines, compensation, legal wording" -> the check reviews existing controls and finds no deadline-field validation at the exit, so the gap stands -> next step: turn the gap into a to-do with an owner and a verification method (for example a weekly sample audit of replies, sample size set by your own volume rather than copied from someone else's threshold).