AI合规管控重点防控的核心风险

做AI产品的，最怕不是功能做不出来，而是上线后被问「你怎么证明自己合规」。风险点散在数据、内容、账号、第三方依赖里，没人给你一张总表。这篇把合规管控里真正要重点防的几类核心风险摊开，配一份可以直接照着勾的上线自查项，并告诉你哪些情况这套清单不适用。

做AI产品的，最怕的不是功能做不出来，而是上线之后被人问一句「你怎么证明自己合规」。这个问题一旦答不上来，前面所有的迭代速度、用户体验都白搭。麻烦的地方在于，风险点不是集中在一个模块里，而是散在数据、内容、账号、第三方依赖这几摊事上，每摊各有各的说话人，没人给你一张总表。

这篇就干一件事：把合规管控里真正要重点防的几类核心风险摊开，配一份可以直接照着勾的上线自查项，最后说清楚哪些情况下这套清单不适用。清单不是万能的，但至少能让你在被人问起的时候，手里有东西。

先分清：哪些是合规风险，哪些只是技术故障

很多人把两件事混在一张表里管，结果重点全糊了。合规风险的本质是「触碰了外部规则」——会带来处罚、下架、封禁或者诉讼。接口超时、模型答错但不违法，那是质量风险，归技术侧管，别塞进合规表里。判断口径很简单：先问「这件事如果被监管或者平台方看到，我能不能拿出依据」，拿不出依据的，就是风险点。

数据来源与出境

用户输入和文件里有没有敏感信息，请求最终落在哪个区域，有没有明确答案

生成内容违规

输出里有没有违法违规信息、侵犯他人权利的内容、该标注没标注的合成内容

账号与资质不符

用个人身份跑商业业务、资质手续没配齐、调用方式本身不符合规则

第三方依赖不受控

中转站、聚合平台、插件改了条款或数据流向，你的合规结论跟着一起变

• 先给每件事贴标签：合规风险 or 质量风险，别混管；
• 合规风险再分四类：数据、内容、账号资质、第三方；
• 拿不出依据的项标红，能拿出依据的标绿；
• 红项按后面几节的自查动作逐个补，绿项留一份记录即可。

风险一：数据从哪来、发到哪去

输入端要盯住的是提示词、上传文件、附件里有没有掺进个人信息、客户机密、未公开的经营数据。这块的原则边界去看站内的 key-safety 页面，这篇只讲自查动作。输出端要盯住的是模型回传的内容有没有被落盘、有没有进日志、日志保留多久、谁能查。出境和第三方这块最容易含糊：调用的是哪家的接口、请求最终落在哪个区域，拿不出明确答案的，一律按「未知」处理，别默认按国内算。

1. 画链路图从用户输入到数据库，把每个节点画出来，节点之间连线标注数据流向；画不出来的地方就是盲区。
2. 逐节点标注每个节点写三栏——存不存、存多久、谁有权限；空着的栏就是待办。
3. 入口拦截在用户输入的第一落点检查敏感字段拦截有没有生效，用一条带测试标记的数据跑一遍验证。
4. 日志排查抽查日志样本，看有没有明文敏感信息；有的话先做脱敏再谈保留周期。

风险二：生成内容本身的合规红线

内容这块重点防三类：违法违规信息、侵犯他人权利的内容（人格权、版权）、需要标注而未标注的合成内容。产品形态直接决定防守重点。面向公众发布的内容平台，标注和审核压力最大；内部工具的重点反而在误用和二次传播上。深度合成类另有专门要求，具体条款和落地动作到 安全与合规（/safety） 分区对照现成的清单，别自己凭印象写。

自查动作的核心是找出所有「用户能一键发出去」的出口，每个出口确认拦截、留痕、可回溯这三条是否齐备。少一个出口没查，就等于留了一个后门。另外别忘了人工兜底通道——纯自动拦截一定会有误伤和漏网，得有人能接住。

• 列出所有对外发布出口：发布按钮、分享、导出、API 返回、定时任务；
• 每个出口确认三条：有没有拦截、有没有留痕、能不能回溯到具体请求；
• 需要标注的合成内容，确认标注位置和方式在产品里真的可见；
• 留一条人工兜底通道，写明谁在什么情况下介入；
• 上线后定期抽查被拦截样本，看拦截规则有没有失效。

风险三：账号、资质与调用方式

这一类的风险不在技术，在规则层面。用个人号跑商业业务、多人共享同一个账号或 Key、把额度转售给外部，这些做法一旦被平台方发现，后果是封禁而不是罚款，而且往往没有申诉通道。资质类要求（备案、算法相关手续、经营许可）取决于你的业务形态和面向地区，没有统一答案，按实际落地地区逐项确认。

自查动作就是填上面这张表。把每个对外提供的能力，对应到「谁在提供、用什么身份提供、有没有书面依据」三栏，空着的就是待补项。填表的过程本身就能暴露不少问题——很多时候你会发现某个能力根本说不清是谁在提供。

风险四：第三方依赖带来的连带责任

中转站、聚合平台、插件、SDK 这一类依赖，最大的问题是它们改了模型、改了域名、改了条款，你的合规结论就跟着一起变，而你可能根本不知道。重点看三件事：数据流向是否公开可查、服务条款里对数据使用怎么约定、出问题时的责任划分写没写。接第三方之前先做一轮真伪与稳定性核验，具体做法参考 中转站真假在线实测（/tools/verify）。

1. 建卡片给每个第三方建一张小卡片：用途、接触的数据类型、可替代方案、最近一次复核时间。
2. 查流向确认数据经它之后去了哪里，公开文档里查不到的直接列为未知。
3. 读条款重点看数据使用和留存条款，以及责任划分段落，划线存档。
4. 定预案判断有没有单点依赖，写清楚断供之后切到哪个备选、谁负责切。

• 卡片不全的第三方，先冻结新增调用；
• 出现单点依赖的，排一个替代方案验证计划；
• 条款更新的，重新过一遍前面的链路图；
• 复核时间超过一个迭代周期的，安排复查。

上线前自查：按这个顺序过一遍

顺序不要颠倒。数据没理清就去做内容标注，回头链路一变全部重做。下面这五步按依赖关系排的，前一步做完再动下一步。每一步的产出都是一份可复查的记录，不是口头结论。

1. 第一步 数据链路图是否完整、敏感字段是否已在入口拦截、日志里有没有明文敏感信息；验证方式是抽一条测试数据跑全链路。
2. 第二步 内容所有对外出口的拦截与标注是否就位、有没有人工兜底通道；验证方式是逐个出口做一次发布测试。
3. 第三步 账号与资质调用身份、书面依据、面向地区逐项对齐；验证方式是那张四列表填满没有空格。
4. 第四步 第三方卡片是否齐全、有没有单点依赖、断供预案写没写；验证方式是随机抽两张卡片核对内容是否过期。
5. 第五步 证据每项自查留一条可复查记录，写清谁在什么时候按什么口径确认的；空口无凭等于没做。

证据与报告：怎么留才算数

留证三要素：时间、口径、责任人。截图要带上下文，别只截一行结论——只截结论的截图，换个语境就说不清了。报告不必长，一页纸写清「查了什么、结论是什么、还差什么、谁跟进」就够用，长了反而没人看。复核节奏上，涉及第三方和数据链路的项变化最快，建议跟着版本走，每次发版复查一次。

具体到数字类信息，比如各家的接口成本变化，别写死在文档里，到 价格追踪（/price-watch） 核对当时的数字再引用，写死的数字过一阵就不准了，反而成了误导。

这套清单什么时候不适用

清单不是万能药，有几种情况下照着勾也没用。第一，业务模式本身处在灰色地带时，补自查项解决不了根本问题，得先调整模式本身。第二，面向的司法辖区不明确时，任何清单都是猜，先把落地地区定下来再谈条款。第三，只做技术验证、不对外提供服务的阶段，可以只保留数据与账号两项，其余延后。第四，团队里没人对合规结论负责时，清单会变成走过场，先指定一个人，再谈流程。

• 模式本身有问题的，先改模式，别指望清单兜底；
• 辖区没定的，先定地区，再对照当地要求；
• 纯技术验证阶段，砍到两项即可，别过度投入；
• 没人负责的，先点名，再启动流程。

合规自查的价值不在于查完就安全，而在于被问起时你能拿出东西——拿得出，就是合格；拿不出，补多少清单都是空的。