前提：能不喂就不喂
脱敏的第一原则不是"怎么处理"，而是是否真的需要：很多功能并不需要原始的用户数据，
只需要统计特征、类别标签或已抽取的结构化字段。最小必要能省掉绝大部分风险。
数据进入模型前的四道处理
一、识别
- 显式标识（身份证、手机号、邮箱、银行卡、订单号）；
- 准标识（姓名 + 生日 + 地址组合起来能定位到人）；
- 自由文本里的隐性信息（"我是 XX 公司唯一的女 CTO"）。
二、替换（假名化）
把标识替换成占位符（<PHONE_1>、<PERSON_A>），并在文内保持一致（同一人始终是同一个占位符），
否则模型会读不懂指代关系。需要还原时，映射表单独加密保存，与模型输入分离。
三、裁剪
- 只发送需要的那一段（不要整封邮件都为了一句话）；
- 去掉签名档、页脚、附件名等无关内容（它们常含联系方式）。
四、记录
- 记下"这次调用用了哪些字段"；
- 谁在什么时候因为什么原因调用了它（审计留痕）。
三个容易忽略的点
- 日志也是数据：请求日志、错误日志、评测样本里同样会有原始数据，要一并脱敏；
- 向量库是长期存储：把带标识的原文嵌入并长期保存，等于把脱敏绕过去了；应嵌脱敏后文本；
- 提示词回显：有些界面会把完整提示词展示给用户或写在错误信息里，注意别把映射表带出来。
与合规的三条对应
- 最小必要：只收集与处理完成目的所需的最少数据；
- 可撤回：用户撤回同意后，能定位到并删除相关数据（包括派生数据如向量）；
- 可解释：能说明数据流向（发给了谁、保存多久）。
一个可执行的检查清单
- 列出该功能真正需要的字段（多数能砍掉一半）；
- 为每个字段定脱敏规则，并写成可测试的规则（用样例自动比对）；
- 日志与评测样本走同一套脱敏；
- 建立字段级调用审计；
- 演练一次"撤回同意 → 删除数据 → 确认派生数据也删除"。