数据脱敏与最小必要：把用户数据喂给模型前该做什么

把用户数据送进模型前，应先做最小必要判断，再走识别、假名化、裁剪、记录四道处理。本文给出具体做法、三个容易忽略的点（日志/向量库/提示词回显）与一份可执行检查清单。

前提：能不喂就不喂

脱敏的第一原则不是"怎么处理"，而是**是否真的需要**：很多功能并不需要原始的用户数据，

只需要统计特征、类别标签或已抽取的结构化字段。**最小必要**能省掉绝大部分风险。

**一、识别**

显式标识（身份证、手机号、邮箱、银行卡、订单号）；

准标识（姓名 + 生日 + 地址组合起来能定位到人）；

自由文本里的隐性信息（"我是 XX 公司唯一的女 CTO"）。

**二、替换（假名化）**

把标识替换成占位符（`<PHONE_1>`、`<PERSON_A>`），并在文内**保持一致**（同一人始终是同一个占位符），

否则模型会读不懂指代关系。需要还原时，映射表**单独加密保存**，与模型输入分离。

**三、裁剪**

只发送需要的那一段（不要整封邮件都为了一句话）；

去掉签名档、页脚、附件名等无关内容（它们常含联系方式）。

**四、记录**

记下"这次调用用了哪些字段"；

谁在什么时候因为什么原因调用了它（审计留痕）。

**日志也是数据**：请求日志、错误日志、评测样本里同样会有原始数据，要一并脱敏；

**向量库是长期存储**：把带标识的原文嵌入并长期保存，等于把脱敏绕过去了；应嵌**脱敏后**文本；

**提示词回显**：有些界面会把完整提示词展示给用户或写在错误信息里，注意别把映射表带出来。

1. **最小必要**：只收集与处理完成目的所需的最少数据；

2. **可撤回**：用户撤回同意后，能定位到并删除相关数据（包括派生数据如向量）；

3. **可解释**：能说明数据流向（发给了谁、保存多久）。

1. 列出该功能真正需要的字段（多数能砍掉一半）；

2. 为每个字段定脱敏规则，并写成**可测试**的规则（用样例自动比对）；

3. 日志与评测样本走同一套脱敏；

4. 建立字段级调用审计；

5. 演练一次"撤回同意 → 删除数据 → 确认派生数据也删除"。