大模型的数据泄漏面：训练记忆、上下文残留与 PII 防护

三条泄漏路径

大模型应用的数据泄漏不只有一个口子，按数据流经的位置至少分三段：

训练数据记忆：模型在训练时见过海量文本，其中可能混入敏感信息，并在特定提示下被「背」出来。模型不是数据库，但对高频、重复、独特的文本片段存在可复现的记忆。
上下文残留：多轮对话或共享会话环境里，前文信息渗入后续输出。用户前十轮交代的公司内部数据，可能在第十轮后被模型主动复述，或被组织进它对其他问题的回答。
供应链与日志：提示词本身就是要紧数据——里面常带着业务机密与个人信息。提示词日志、第三方 API 的数据留存策略、供应商「用你的数据改进服务」的默认条款，都是容易被忽略的出口。

路径一与路径二的分界值得强调：记忆写在权重里，随模型分发、删不掉；上下文残留在会话里，随上下文丢弃而消失。所以前者的缓解靠训练与选型，后者的缓解靠应用编排——会话结束即丢弃上下文、不跨用户复用上下文。若为了提速做 KV Cache 或提示缓存复用，要确认缓存的键带上租户与会话边界，否则等于把上一个用户的上下文借给了下一个用户。

记忆是怎么回事

机理一句话：模型对训练中重复出现的文本过拟合，记住了高频片段的延续方式。缓解主要在训练侧：对语料做去重与脱敏（识别并移除个人身份信息后再进训练集），以及差分隐私的思路——训练时给参数更新加噪声，让任何单条样本对模型的影响都有上限，压低「背出原文」的概率。这些手段能降低风险，但应用侧不应假设记忆为零。

应用侧 PII 防护流水线

PII（Personally Identifiable Information，个人身份信息）指人名、证件号、银行卡号、手机号这类能定位到自然人的数据。防护要在三个位置分别设闸：

输入侧检测与脱敏：请求到达模型前识别敏感字段，替换成占位符；在可信侧维护可逆映射，业务确需时再还原，模型从头到尾看不到真实值。
输出侧审查：对模型响应扫描敏感特征——占位符没替换干净的、模型自己「背」出来的——命中即拦截或二次脱敏。
日志侧最小化：不落原始提示词；确需留存时脱敏入库、缩短保留期、收紧访问权限。日志最常被遗忘，因为没人把日志当数据资产看。

一个输入脱敏的示意：

{
  "model_input": "请查询客户 {{NAME_1}} 的账单，回电 {{PHONE_1}}",
  "reversible_mapping": {
    "{{NAME_1}}": "王某（仅存于脱敏服务）",
    "{{PHONE_1}}": "138****0000（仅存于脱敏服务）"
  }
}

多租户隔离：检索越权这个隐蔽坑

多租户（多个客户共用同一套应用与模型）是 SaaS 的常态，隔离要做两层。一是会话隔离：上下文、缓存、历史互不可见。二是检索库权限边界——RAG 场景的坑特别隐蔽：向量检索默认「全库找相似」，检索时若不带租户过滤，A 租户的提问可能命中 B 租户的文档，模型再自然地把它组织进回答。越权发生在检索层，模型看起来完全无辜。对策是把租户 ID 做成检索的硬过滤条件，作为架构约束而不是提示词里一句「请勿提及他人数据」。

给产品经理的三个问题

技术设防之外，产品决策层要能答清三个问题：数据去了哪（发给哪些第三方、是否会用于对方训练）、留多久（日志与缓存的保留策略）、谁能看到（内部访问范围与授权流程）。三个问题答不清，功能再好也不该上线。

合规一句

按业务所在辖区的数据法规做数据分级：哪些数据可以直接进模型上下文、哪些脱敏后才能进、哪些根本不该进。分级结论要写进工程约束——存储、传输、模型调用各环节的控制要求都从分级导出，而不是各做各的。先分级，再接入。

小结

泄漏面横跨四段，各设一道闸：训练侧去重脱敏与隐私训练，输入侧 PII 识别与替换，输出侧审查拦截，日志侧最小化留存；多租户场景再加检索权限边界。数据安全的常识在这里依然成立——默认不信任，按最小必要流动。