把用户数据喂给 AI 之前：一份工程师视角的合规自查清单（2026 版）

上个月帮一家客户做内部 AI 助手上线评审，技术方案很漂亮，但问到「用户的聊天记录会被如何处理」时，架构师沉默了半天，说「应该……不会存吧」。这就是典型状态：技术跑在前面，合规还停在 PPT 里。

本文不谈法律条文，只讲工程师能直接动手做的部分。

一、先分清两种数据流

AI 应用的数据流向有两个，很多团队把它们混在一起，导致过度设计或者漏掉关键环节。

训练流：你的数据被用来改进模型。一旦进入训练集，几乎无法撤回——模型权重里已经包含了你的数据信息，删不掉。这是最危险的一条路。

推理流：数据只用于生成这一次的回复。理论上可以处理完即丢弃，但实际情况取决于供应商是否记录日志。

工程上的第一原则：默认切断训练流。对企业应用来说，几乎所有场景都不需要用自己的用户数据去训练基础模型。

二、供应商合同必查的四个条款

这是最容易被「还没细看」跳过的部分，但经济风险最大。

1. 数据是否用于模型训练 必须是明确禁止（opt-out 不够，要 opt-out 默认生效或合同明确禁止）。很多 API 的默认政策是「不用于训练」，但企业版和个人版条款不同，要看清账户类型。

2. 日志保留期限 默认保留 30 天的很常见，用于滥用检测。如果你的数据含敏感信息，应争取零保留（zero data retention），通常需要企业合同。

3. 数据驻留与子处理商 模型请求可能被路由到其他区域的机房。要看清楚子处理商（sub-processors）列表，以及变更时是否提前通知。

4. 泄露责任与 SLA 模型供应商泄露数据时的赔偿责任上限，往往等于你付的月费。这意味着风险基本由你承担，需要在内部保险和加密方案上另做安排。

三、PII 脱敏：别信「正则够用了」

我们做过测试，纯正则的脱敏方案在真实业务文本上的漏检率约 18%。漏掉的包括：中文姓名（正则很难）、地址（格式太多样）、身份证号的变体写法、以及最麻烦的上下文推断出的信息（「我们公司在杭州西溪园区 3 号楼」）。

可用的分层方案：

1. 强规则层：身份证、手机号、银行卡、邮箱用正则+校验位，这一层准确率高，必须做
2. NER 模型层：用轻量 NER 模型识别姓名、地址、机构名，召回率能提到 95% 以上，成本可接受（本地小模型，延迟 < 50ms）
3. 网关层兜底：在出口网关做一次最终扫描，检测到疑似 PII 直接拦截并告警，比事后追责有用
4. 格式保护：脱敏时必须保留必要结构，否则模型看不懂上下文。用「[姓名]」而不是「███」

重要细节：脱敏必须在客户端或你自建的网关完成，不能依赖模型供应商。因为数据已经出门了，再脱敏无意义。

四、跨境传输的真实风险

这是 2026 年监管最活跃的方向。要点：

• 中国大陆的数据出境需要走安全评估或标准合同备案，调用境外 API 传输个人信息属于数据出境
• 欧盟的 Schrems II 后续判决持续收紧，依赖标准合同条款不足以覆盖美国情报机构接入风险，实际合规需要补充传输影响评估
• 多数企业的最优解不是硬扛，而是区域化部署：中国用户走国内模型，欧洲用户走欧洲节点

这一点在设计阶段就要考虑。事后把一个已上线的系统做区域拆分，成本是设计时做好的 5 倍。

五、可直接用于评审的 20 项清单

数据分类

1. 是否列出所有进入 AI 系统的数据字段及敏感等级
2. 是否包含未成年人数据（若有，需单独流程）
3. 是否包含生物识别信息（声纹、人脸需单独同意）

最小化 4. 输入是否只包含必要字段，能否去掉用户 ID 5. 是否在调用前完成 PII 脱敏 6. 是否避免把整份文档塞进上下文而只取相关段落

模型侧 7. 供应商是否合同禁止训练使用 8. 日志保留期限是多少，能否为零 9. 是否配置了区域路由 10. 是否记录了每次调用的数据流向审计日志

输出侧 11. 模型输出是否可能复述其他用户的敏感信息（多租户场景） 12. 输出是否经过一次敏感词与 PII 扫描 13. 是否限制输出被写入公开可访问的存储

用户权利 14. 用户能否查询「我的哪些数据被用于 AI」 15. 用户能否要求删除对话历史 16. 删除请求是否真正传导到了日志和向量库 17. 是否提供了不使用 AI 的人工替代路径

组织 18. 是否有 AI 使用登记表（含影子 AI 检测） 19. 事故响应流程是否覆盖 AI 数据泄露场景 20. 是否每季度复核一次供应商条款变更

六、最后一句

合规不是上线前的一次性检查，而是持续的数据流治理。把上面 20 项做成一个季度评审表，比写一份漂亮的合规文档有用得多。真正的风险从来不在于「不知道规则」，而在于「不知道数据去了哪里」。