很多人一到合规专项检查就发懵：平时也没少做安全动作，真被问起来却说不清风险点在哪、证据在哪。这篇不讲空泛概念，直接给一张按发生概率和后果排布的风险清单，每项都配一个可立刻执行的自查动作和取证要求。适合被抽查的技术负责人、合规对接人，以及自己给自己做体检的中小团队；如果你所在行业已有更细的监管口径，请以本行业规定为准，本文只做通用底稿。
一到合规专项检查就发懵，多半是因为平时做的是零散的「安全动作」，而不是一套能对着答的「风险清单」。检查方问的其实很朴素：哪几类风险是你自己认定的、先查了哪条、证据放在哪。这三问答不上来，做了多少动作都显得心虚。
下面按发生概率和后果不可逆程度给一张底稿，每类风险都有触发场景、先查什么、留什么证据。适合被抽查的技术负责人和合规对接人，也适合中小团队自己先体检一遍。前提是：你所在行业已有更细的监管口径时，以本行业规定为准，本文只当通用底稿用。
先分清四类风险，别一锅端
把风险按来源切成四类，不是为了做分类学，而是因为排查动作完全不同。输入侧靠翻历史记录，输出侧靠抽样复核，链路侧靠读协议和配置，账号侧靠比对改动记录。混在一起查，通常查到最后只摸清了最容易被看见的那一类。
| 风险来源 | 典型表现 | 先查什么 | 不适用情形 |
|---|---|---|---|
| 输入侧 | 提示词或附件里带了不该外发的信息 | 抽样近期会话与上传文件 | 全员内网、数据不出域时可降优先级 |
| 输出侧 | 对外内容缺标识、侵权或明显失实 | 抽检已发布内容 | 纯内部草稿未对外发布不在此列 |
| 链路侧 | 调用了外部服务、数据落点不明 | 读协议与配置、看留存 | 私有化部署基本不涉及跨境，但仍要查访问控制 |
| 账号侧 | Key 共享、临时账号未回收 | 比对变更记录而非当前名单 | 单人单账号的极小团队可简化，但仍有交接问题 |
还有一点要提前想清楚：分类是排查地图，不是结论。把四类风险都写进文档、却没有对应证据位置，检查方反而会顺着问「那你这一类是怎么控的」，答不上来比没写更被动。
排优先级：先盯后果不可逆的
优先级不要按「技术难度」排，要按两个维度排：后果能不能挽回，以及检查方能不能一眼看到。数据发出去了、内容已经公开了，这类几乎不可逆，先处理；日志、对外页面、公开接口这些对方扫一眼就能发现，也要往前放。
- 敏感数据外发：一旦出去就收不回，且最容易被对方从流量或记录里看出来，排最前
- 内容标识缺失：公开页面可见，抽查成本低，容易被顺手指出
- 权限过大与账号共享：涉及人和流程，解释成本高，越晚查越难补
- 记录不全：单独看后果不重，但会连带放大前三项的严重程度
这个顺序在一种情况下不适用：已经被举报、或已进入调查流程的场景。那时不要再按自己的优先级推进，改成按对方问到的顺序逐条答复、逐条给证据，主动铺开反而打乱节奏。每完成一项就更新台账状态，别等检查当天现补，补出来的时间和内容往往对不上。
一次可跑完的自查动作
- 查输入面抽样近期会话与上传附件，确认有没有把不该发的内容发出去。原则层面先看站内 /safety 的说明，具体边界判断可对照 /ai-dict/category/safety 的分类口径。产出：一张抽样表，写清样本范围、抽查条数、命中情况。
- 查输出面抽检对外发布的 AI 相关内容，看有没有标识、有没有明显侵权或失实表述。版权相关的判断单独走一条线，别和内容安全混在一次抽样里。产出：抽检记录加截图。
- 查权限与账号谁持有 Key、谁在共享、有没有临时账号该回收没回收。重点看变更记录，不是看当前名单——名单只能说明现状，说明不了过程。产出：变更对照表。
- 查链路列出调用了哪些外部服务、数据落在哪、留存多久。能拿到书面说明的优先拿书面说明，口头确认在检查时基本不算数。产出：协议截图或往来邮件。
四步不必一天跑完，但每一步都要有产物。没有产物的自查等于没做——检查方不看你做了多少事，只看你留下了什么。想先摸清各类服务的可信度底细，可以到 /sites 看站点判断口径，再决定哪些链路需要优先补书面说明。
记录怎么留，检查时才拿得出手
记录分三类，缺一类就容易被认定为「制度有、执行无」：决策记录说明为什么这么配，执行记录说明谁在什么时候改的，结果记录说明改完之后抽样验证过。三类凑齐，一条链路才算闭环。
| 记录类型 | 回答什么问题 | 优先形式 | 证明力偏弱的形式 |
|---|---|---|---|
| 决策记录 | 为什么这样配置 | 评审纪要、工单结论 | 口头共识 |
| 执行记录 | 谁在何时改的 | 带时间的工单、邮件 | 个人笔记 |
| 结果记录 | 改完有没有验证 | 抽样表、复核截图 | 聊天窗口自述 |
留存形式优先选不容易被随手改的：工单系统、邮件、带时间的截图。个人笔记和聊天记录证明力最弱，因为它们既没有时间锚点，也无法证明没被事后编辑。留存时长和范围按你所在行业与数据类型定，别凭印象设一个数字，具体口径到 /safety 和相关法规解读页核对当时要求。
一个容易忽略的不适用情形：如果检查方明确只问某一项，不要主动铺开讲全部记录。信息过载会让对方顺着你提供的新线索，问出别的缺口。答完被问的那一项就够了，其余留在台账里备查。
几个最常见的踩坑
- 把买了工具当成风险已控：工具解决的是检测能力，不解决你有没有按检测结果处置，处置记录才是答案
- 把清单当一次性任务：风险是持续状态，至少按季度重跑输入面和权限面
- 只盯技术不盯人：离职交接、外包临时权限、多人共用一个账号，是专项检查最常问也最难解释的三类
- 为了显得重视而临时大改配置：改动本身会留下新的解释成本，反而多出几个要回答的问题
最后一条误判值得单独说：如果近期业务形态没变、调用方式没变，风险面通常也不会突然变大。专项检查要的是把已有的东西讲清楚，不是现场表演一次整改。临时改动的记录会立刻被追问，而你往往来不及准备配套的决策与结果记录。
检查问的从来不是「你做了多少」，而是「你能不能指到证据所在的那一行」。下一步先按四类风险列一张自己的台账，再拿这张台账去 /sites 对照各站点的可信度判断口径，把需要补书面说明的链路挑出来。想持续跟踪判断标准的变化，到 /rankings 和 /price-watch 核对当时的数字与排序，别用记忆里的印象做决策。→
常见问题
专项检查到底会问哪些问题？
通常绕不开四句：哪些数据发给了外部、谁有权限、内容发出去前有没有把关、出问题能不能还原。把这四个问题各准备一份带时间戳的材料，基本能应付绝大多数问询；行业监管另有清单的，以那份为准。具体判断口径可以在站内安全与合规分区先过一遍。
小团队没专人做合规，最低限度要做什么？
保三样：一份调用与数据流清单、一份权限名单及改动记录、一份内容发布前的抽检记录。这三样不需要专门岗位，一个人每季度花半天就能维护，但检查时比任何制度文档都管用。等团队规模上去再补制度和流程。
自查发现有问题，是先改还是先上报？
涉及数据已经外发或内容已经公开发布的，先做止损动作再同步给上级或合规对接人，同时把处置过程记下来；纯粹配置类问题可以改完再汇报。拿不准严重程度的，倾向先报告，处置晚一点比事后被问「为什么不报」要好解释得多。
