合规风险识别评估案例

很多团队不是不知道要做合规风险评估，而是坐到桌前不知道第一步写什么：从哪找风险？找到之后怎么判断严重程度？评估记录留成什么样才算数？这篇拿一个通用案例从头走一遍，每一步给出可照抄的动作和判断标准。看的时候记住：案例里的行业、规模都是虚构的，方法可以照搬，结论不能照搬。

很多团队不是不知道要做合规风险评估，而是坐到桌前不知道第一步写什么：从哪找风险？找到之后怎么判断严重程度？评估记录留成什么样才算数？下面拿一个通用案例从头走一遍，每一步给出可照抄的动作和判断标准。

案例里的行业、规模都是虚构的，方法可以照搬，结论不能照搬。你手上团队是三个人还是三十个人、做的是内容工具还是别的，风险清单和级别都会不一样，这点先记住。

先把案例的边界画出来，不然评估没法收口

范围不画清，评估就会越写越大，最后谁也不敢下结论。这个案例只圈「客户数据处理」一条线：客户上传的原始资料、调用过程中产生的请求与返回、以及我们本地留下的日志。前端展示、营销文案、员工报销这些都不在今天这轮里。

划范围的时候就写清三件事：涉及哪些数据、经手哪些系统、哪些角色能碰到。写的时候用具体字段和具体系统名，不要写「客户相关数据」这种含糊说法，不然后面根本没法判断谁能看到。

识别阶段只挖风险、不定性：先把可能出问题的点全列出来，判断放到下一节。很多人边找边否定自己，觉得这条不太可能就先不写，结果最后一轮下来只剩三五条不痛不痒的。

风险从哪找：五个固定入口，按顺序过一遍

与其坐在那儿想，不如按固定入口挨个过。下面五个入口每个都问一遍同样的问题，基本能把一条业务线上的显性风险捞干净。

1. 入口一：数据流从用户上传到模型调用到日志留存，逐段问「这段数据如果被看到会怎样」，落到具体字段上。别停在「用户数据」这种粒度，要落到「上传文件里的身份证号」「请求日志里的完整提示词」。
2. 入口二：合同与授权客户给的资料有没有授权我们处理、能不能传给第三方模型、用完要不要删。没有书面依据的，默认按高风险处理，先按高风险保护起来再谈降级。
3. 入口三：第三方依赖调用的外部接口、插件、中转服务，各自的数据留存放哪、能不能关闭、能不能换。到 模型数据留存期限（/model-data-retention-timeline） 这类页面核对当时的公开口径，别凭印象。
4. 入口四：内部行为谁能导出、谁能删、离职怎么交接、临时账号多久收回。多数事故出在这一层，问的时候直接问「谁能把整份数据拖走」。
5. 入口五：外部事件同行出过的事、监管点过名的场景，当成免费提示。这类信息拿来对照自己的业务，看有没有同样的口子。

五个入口过完，你手上应该有一张二十来条的风险草稿。草稿阶段不求准，只求全，宁可多写几条后面再划掉。

定级不用打分表，先把「谁受影响、影响多大」说清楚

很多人一定级就想找打分表，乘个系数得个数字，看起来很科学，其实吵起来更凶。更实用的做法是先描述后果，再根据可能性给级别。

后果描述要具体到人：数据泄露给谁、影响多少人、能不能撤回。同样是泄露，影响十个客户和影响几千个客户完全不是一档，级别不问清受众就没有意义。

• 判断维度一：发生可能性，看有没有现成防线，比如脱敏、权限控制、访问记录
• 判断维度二：后果严重度，看能不能补救，能撤回的和撤不回的要分开看
• 两项都高的，放进必须立刻动手的那一档，不要排期
• 写清什么情况下级别可以下调：比如已经有脱敏和留存上限，可以降一档，但要在记录里写明依据
• 级别别自己另起一套说法，到 安全与合规（/safety） 分区把同类风险的处理口径对齐

评估记录怎么留，才经得起后面回头查

记录的核心是「以后能看懂当时为什么这么判断」。下面是这个案例里一条风险的实际写法，照着这个格式填就行。

处理动作一定要写可验证的动词，比如「关闭该字段的落库」「把权限从全员改成两人」，不要写「加强管理」「提高意识」这种无法核对的表述。半年后回头查，只有前者能验证做没做。

复核节奏按级别分：高的一周一看，中低的一季度过一轮。每次复核只更新变化的部分，不重写整份，否则没人愿意维护。

判断依据和排除理由也要留：这条为什么不适用、哪条证据不足暂时挂起，半年后回头查全靠这段。没有这段，下次评估又得从头商量一遍同样的争论。

三个最容易翻车的地方

最后把三个最常见的坑摆出来，评的时候对着自查一遍，比自己重新想方法快。

• 把评估做成文档表演：列了一堆风险，没有一条写清责任人，等于没做
• 级别凭感觉：不问清影响受众就定级，同样一条风险在不同人嘴里差好几档
• 只评一次：业务一变、模型一换、人员一动，原来的结论就过期了，评估要有触发条件，不是年度打卡

触发的条件可以写得很具体：新增一类数据来源、换一个外部模型、单人权限范围扩大、出现一次未授权访问尝试，任何一条发生就重跑一遍这条线的评估。