AI 应用数据脱敏：喂给大模型之前先处理这些

把用户数据喂给大模型，等于把数据交给第三方（或至少进入你的日志和模型上下文）。如果这些数据含个人信息（手机号、身份证、地址），合规和隐私风险都很大。这篇文章讲数据脱敏的实践。

哪些数据要脱敏：

• PII（个人身份信息）：手机号、身份证、邮箱、地址、姓名
• 密钥凭证：API key、token、密码（这个绝对不该进模型）
• 内部信息：项目代号、内部 IP、未公开的业务数据
• 敏感财务：完整银行卡号

脱敏方式：

1. 替换。把敏感值替换成占位符：

替换后模型看到的是占位符，功能上（比如"帮我写一封给张三的邮件"）还是能理解"张三"这个称呼，但具体号码不会进模型。

2. 部分打码。保留部分信息供识别：138****1234。适合需要"识别但保护"的场景。

3. 生成替身。对需要模型处理的实体（人名、公司名），替换成假的但结构相同的数据，处理完再映射回去。这个最安全但实现复杂。

脱敏与功能平衡：

• 脱敏后模型可能"看不懂"某些上下文（比如"帮我查一下[手机号]的订单"），需要在 prompt 里说明占位符的含义
• 有些场景（代码调试、日志分析）数据是核心，脱敏会降低效果。这时候的决策：要么不喂（改为人工处理），要么脱敏后加规则提示

实现位置：

• 用户输入 → 模型：入口脱敏
• 模型输出 → 用户：出口检查（模型可能"记住"了脱敏前的数据并输出，比如日志里）
• 日志记录：一律脱敏后再写日志

坑：

1. 脱敏正则要覆盖全。漏一种格式（比如座机号、车牌号），等于没脱。

2. 模型可能反向推断。给了上下文（比如某人的订单记录），模型能猜出部分脱敏数据。高危场景（金融、医疗）不要存真实数据在上下文。

3. 脱敏映射表要安全。如果用了"替身映射"，映射表本身要加密存储，别和模型日志放一起。

总结：脱敏的核心是"敏感数据不进入模型上下文"。正则替换 + 占位符是最实用的起步方案，高危业务要更严格。