合规风险点有哪些

风控同事最常卡在两件事上：一是风险点列不全，评审会上被问一句「还有吗」就答不上；二是列全了却不知道哪条归自己管、哪条该留证。这篇不给标准答案，给一套把风险点扫一遍的顺序和对照表，让你能自己收口，也能跟法务、内控说清边界。

风控同事最常卡在两件事上：一是风险点列不全，评审会上被问一句「还有吗」就答不上；二是列全了却不知道哪条归自己管、哪条该留证。这篇不给标准答案，给一套把风险点扫一遍的顺序和对照表，让你能自己收口，也能跟法务、内控说清边界。

先说明适用范围：下面这套流程针对的是「企业自己在用 AI、接外部模型、或者把数据交给第三方处理」这类场景。如果你们只是买了个封装好的行业软件、数据完全不出自己的机房、也没有自研调用，那么数据出境那条权重会低很多，但账号权限和供应商变更那两条反而要往上提。判断哪些适用、哪些不适用，本身就是风控该做的第一步。

先分清：哪些算合规风险点，哪些只是业务麻烦

很多清单一开始就写偏了，把业务亏损、口碑下滑、项目延期也算进去，结果清单长得没人看。合规风险的核心判断标准只有一条：这件事有没有可能被监管问询、被追责、被要求整改或赔偿。不会触发这些结果的，归到项目管理里去，别混在合规模块。

监管触发性

这件事如果被查到，有没有对应罚则、整改要求或问询函，有才算合规风险

主体可归责性

公司、负责人、经办人是否可能被单独追责，涉及个人的优先级更高

证据可证明性

出事后能不能拿出记录自证，拿不出就按风险处理，不管实际有没有做错

还有两点容易忽略。同一个事实往往同时命中多条线，比如把客户资料发给外部模型，既是数据合规，也牵出采购和供应商管理，别在一条线上找完就收工。另外，换个司法辖区，同一件事的定性会变，做跨境业务时要按目的地重扫一遍，不能照搬国内结论。

这一步的产出不是结论，是一份「事实清单」：谁、在什么系统里、对什么数据、做了什么动作。只有事实列对了，后面的定性才有意义。建议用一张表先把动作和载体记下来，先别急着判断合法与否。

扫描顺序：从数据流走一遍，比开会想更全

靠开会头脑风暴列风险，结果永远取决于谁在场。更稳的做法是固定一个扫描顺序，每次都按同一条路径走一遍，这样换人做也能得到差不多的覆盖度。推荐按数据流走：采集 → 存储 → 使用（含发给模型）→ 共享给第三方 → 出境 → 删除，每段单独问一遍风险。

• 采集段问：有没有超范围收集、有没有可用的同意路径、来源是否清楚
• 存储段问：存在哪、存多久、有谁能直接看到原始数据
• 使用段问：目的是否发生变化、有没有超出当初告知的范围
• 共享段问：接收方是谁、是否转手再给下游、有没有约定约束
• 出境段问：数据实际落到哪个区域、走的是什么路径
• 删除段问：主库删了备份还在不在、第三方是否同步删除

1. 按角色走一遍越权路径一线员工、外包、运维、管理员、离职人员，每类人能看到什么、能改什么，逐个确认；离职人员的账号回收时间是常见漏洞点，查最近几次离职的实际回收记录。
2. 按载体补漏网页端、内部系统、聊天工具、代码仓库、本地 AI 工具，各自最容易漏的地方不同；重点看那些「员工自己下载、公司没批准」的本地工具，这类往往不在 IT 台账里。
3. 标出不确定项走完一轮把「我不确定」的项单独标出来，这些才是真正要拉法务确认的，别在能自己判断的项上反复讨论。

数据与个人信息这条线：最常被监管点名的几块

这条线是绝大多数企业合规事件的高发区，但风险点其实集中在几个固定位置，按位置排查比按法条背更实用。每一块都要问两个问题：现在怎么做的、有没有留下能证明这样做的记录。

采集端看有没有超范围收集、有没有可用且可撤回的同意路径；未成年人和敏感个人信息另算一档，不能和普通信息用同一套流程。使用端看目的有没有变、有没有超出当初告知的范围，二次利用是最容易出问题的地方，尤其是「本来为 A 目的收的，后来拿去给模型训练」这种。

共享与出境端看接收方是谁、数据落到哪、有没有对应的评估或合同路径。路径怎么选、需要哪些材料，可以到 /ai-nav/category/ai-legal 里找对应工具和口径，别自己凭印象定。删除端看有没有真的删、日志和备份里还在不在，只删主库不删备份是常见陷阱，删完要能拿出删除记录。

供应商与外部模型：合同签了不等于风险转移

很多人以为签了数据处理协议，风险就转给供应商了，其实责任还在自己身上。合同能约定的是出了事谁赔，不能免除你选错供应商的责任。所以评估项要落到具体问题上，而不是「有没有签合同」。数据会不会被用于训练、留存多久、日志记什么，这些是站内已有文章讲过的，别在评审时只靠对方的口头承诺。

中转、聚合类平台要额外看转发链路和账号归属：请求经过了几跳、最终是哪个账号在调用、出问题能不能定位到具体某一跳。判断口径可以参考 /sites 目录里的分类方式和 /tools/verify 的实测思路，自己动手测一遍比看宣传页靠谱。供应商换域名、换主体、换条款时要重新过一遍，变更通知没看到就等于没评估。

什么情况下不适用：如果调用的是完全内网私有部署、数据不出机房，这条线的权重可以降，但内部权限风险会顶上来，别以为私有部署就没问题。反过来，如果只是短期试用、数据是公开信息，评估可以简化，但要在制度里写清简化的边界。

• 有没有书面约定数据用途、留存期限和删除机制
• 对方是否会把数据用于模型训练，能不能关掉
• 日志记录了哪些字段、保留多久、谁可以查
• 出现了几级转发，出问题能不能定位到具体环节
• 条款或主体变更后，多久内会通知你

内容与输出这条线：业务方最容易忽略

技术团队盯的是数据和接口，业务团队盯的是效率，中间这块「AI 生成后对外发布」常常没人管。对外发布的内容要管标识、版权来源、是否涉及人格权和商标，标注怎么做另有专文，这里只列检查项。

面向用户的对话和推荐要管输出审核规则：规则谁定、多久复核一次、误伤怎么申诉，都要有明确的主责人。没有主责人的规则等于没有规则。内部报告、投标材料、对客文档里用 AI 生成的部分，要能追溯是谁在什么时候生成的，否则出问题连从哪查起都不知道。

• 对外内容是否有必要的标识和来源说明
• 生成内容是否涉及第三方版权、商标或他人肖像
• 输出审核规则有没有书面化、有没有指定复核节奏
• 对客文档里 AI 生成部分能不能追溯到生成人和时间

不适用场景：纯内部头脑风暴、不落盘不外发的内容，可以按低风险处理，不需要走完整审核流程。但这个豁免边界要在制度里写清楚，比如「不落盘」怎么定义、「不外发」包括不包括截图转发，边界模糊的豁免最后一定会被滥用。

账号、权限与操作痕迹：出事时唯一能自证的地方

前面几条讲的是「有没有做错」，这条讲的是「出了事能不能查清楚」。监管问询时，你拿不出记录，和实际做错了，结果差别不大。所以要分清三张表：谁的账号、能干什么、干过什么。多数事故是在第二张表上找到缺口，也就是权限给多了。

管理员和审计角色不能是同一人，这个放在清单里当硬项，不能靠自觉。一人分饰两角，等于审计形同虚设。操作日志要能回答「谁在何时改了哪条配置」，只记登录成功失败是不够的。权限最小化的配置原则站内已有专文，这里只核一件事：最近一次权限复核是什么时候、有没有留下记录。

留证与上报：把「有没有风险」变成「能不能证明」

清单里每条风险旁边固定两栏：谁负责、证据存在哪。没有证据的项在评审时按未完成算，这样能避免「口头说做了但查无实据」的情况。证据不一定是文档，配置截图、审批记录、日志导出都算，关键是能拿出来、能被第三方看懂。

事件上报的时限、对象、模板先定好，别等出事再找流程。时限口径可到 /safety 分区对照当期要求，不同行业要求不同，别照搬别家做法。对外沟通的话术和内部复盘要分开存，混在一个文档里，举证时容易自伤，比如复盘里的推测被当成事实引用。

多久复核一次？按业务变化速度定，而不是固定等年度。接新模型、换供应商、上新地区、组织调整，这四件事任意一件发生就触发重扫。如果一年到头这些事都没发生，那倒是可以按年度走一次全量，说明业务确实稳定。

怎么让这张清单不变成一次性作业

清单最常见的结局是做完一次就锁进抽屉。要让它活下来，第一件事是把清单拆成三档：必须做、可以缓、先记录观察。全列成「必须」，最后一定没人执行。判断哪条进哪档，看的是后果严重程度和整改成本，不是看谁嗓门大。

• 必须做：涉及个人敏感信息、对外发布、监管明确要求的项
• 可以缓：内部流程优化、非敏感场景的规范化，排期做
• 先记录观察：新业务、新模型、还没定性的场景，先建台账跟踪

每季度只挑变化最大的两三条重扫，比全量重做更容易坚持下去。清单本身要标版本和依据来源，口径变了要能看出是哪一版改的，否则半年后没人说得清当前执行的是哪一版。判断类条目写清不适用条件，避免不同部门照同一句话得出相反的结论，这种分歧在评审会上最耗时间。

最后一个实用建议：把清单的归属写成人，不是写成部门。部门会换人、会重组，写在人头上至少要有个自然人知道这份清单当前在哪、上次更新是什么时候。这件事看起来小，但决定了这张清单是资产还是负担。