处理 PII 与敏感数据

把一张客服工单发给模型 API，就等于把工单里的所有内容——姓名、地址、账号、医疗细节——全都发给了第三方。

三条彼此不同的暴露路径，每一条需要不同的应对。

1 · 数据在发往服务商的途中

prompt 会离开你的基础设施。接下来发生什么，是合同问题，不是技术问题。

保留。 请求会被存多久？多数服务商会为滥用监测短暂保留；有些会对符合条件的账号提供零保留条款。

训练用途。 输入是否可能被用来训练未来的模型。商业版和企业版通常排除这一点；消费者版往往不排除。这是最要紧的一条术语，而且同一服务商的不同版本之间就不同。

子处理者与数据驻留。 还有谁会碰到这些数据，在哪些司法辖区内。这决定了在某些法规下你能不能使用这家服务商。

人工审查。 员工是否可以查看被标记的内容。

去读你实际所在版本的数据处理条款。不要凭服务商的整体名声去推断，也不要假定付费方案的条款适用于免费方案。

如果这些条件满足不了，替代方案是自托管一个开放权重模型——数据永远不离开你的基础设施，代价是要自己运维。

2 · 你自己的日志里的数据

这往往是更大的一处暴露，而且一直被低估。

良好的可观测性意味着要把完整的 prompt 记下来，也就意味着你的日志里现在装着用户发来的每一份敏感数据。这些日志会被复制、备份、长期保留，并且任何有日志访问权限的人都能读。

对很多系统来说，这造成的合规面比 API 调用本身还大，因为日志留存的时间长得多，能碰到它的人也多得多。

实际做法：写入前脱敏，而不是写入后再脱敏；把保留期设成符合你政策的值，而不是默认值；像管控数据库访问那样管控日志访问；能记标识符的时候就记标识符，而不是记内容。以很低的采样率抽取完整 prompt、同时对全部请求记录元数据，是一条合理的中间路线。

3 · 记忆与泄漏

两个常被混为一谈的独立问题。

训练时的记忆。 模型可以逐字复现训练数据里的序列，尤其是那些在文档间反复出现的罕见字符串——账号或 API key 恰好就长这样。这就是为什么用未脱敏的生产数据去训练，风险一旦发生就很难撤销。

上下文泄漏。 更直接：某次请求里的数据，出现在了一份本不该有它的回答里。如果你把另一个客户的记录放进了上下文，模型就可能把它说出来。这不是模型的缺陷——是检索和访问控制的缺陷。

后者的解法是按权限过滤的检索：在查询时按发起请求的那个用户的权限过滤，每一次都要。一套索引了各种访问级别文档、却不做逐用户过滤的 RAG 系统，会变成一种「让人读到本该读不到的东西」的通道。这是一个常见而严重的错误，而且完全可以避免。

减少你发出去的东西

调用前先脱敏。 把姓名、邮箱、账号替换成占位符，需要时再在回答里还原。当任务不依赖真实取值时效果很好——分类、摘要、情感分析。

局限在于检测并不完美。结构化的标识符能靠模式匹配抓到；姓名和上下文相关的标识符抓不到，而自由文本经常能让脱敏失效。

少发一点。 任务需要的常常是一个字段，不是一整条记录。把需要的部分抽出来，只发那个。

按敏感度分流。 不敏感的流量走托管 API，敏感的流量走自托管模型或人工。工程量更大，但干净地化解了这个张力。

干脆不发。 有些数据不管条款怎么写，都不该送到第三方 API。这件事要专门做决定，并写下来放在工程师能看到的地方。

对用户的义务

告知用户其数据由第三方模型处理。 在某些司法辖区是强制要求，在任何地方都算合理。

支持删除。 用户提出删除请求时，覆盖范围必须包括存储的记忆、日志和被检索的索引——不只是你的主数据库。要在需要之前就想好设计；事后给各种派生存储补上删除能力很痛苦。

用用户数据训练要谨慎。 拿客户内容去微调需要法律依据，通常还需要取得同意。用这些数据训出来的模型，没法有选择地「忘掉」它。

要点回顾

• 三条路径：发往服务商的途中、你自己的日志、记忆或上下文泄漏
• 服务商条款按版本不同——针对你实际使用的那一版，检查保留、训练用途、数据驻留和人工审查
• 日志往往是更大的暴露面：写入前脱敏、给保留期设上限、限制访问
• 按发起请求的用户的权限过滤检索，否则你的 RAG 系统就成了绕过访问控制的通道
• 自由文本上的脱敏并不完美；少发一点比多脱敏一点更可靠
• 删除请求必须能触达记忆、日志和索引——早点为此做设计

下一篇： 对 AI 系统做红队测试