4、数据泄露风险：Prompt中的数据泄露途径、敏感信息识别、数据脱敏技术
聊到Prompt安全，数据泄露是我最揪心的一块。
你想想看，我们辛辛苦苦训练出来的模型，喂进去的可能是客户名单、财务数据、甚至核心代码。一个不小心，这些信息就通过Prompt“溜”出去了。我在项目中遇到过不止一次，开发同学为了调试方便，直接把生产环境的SQL语句贴进Prompt里——嗯，这其实非常危险。
4.1 Prompt中的数据泄露途径
数据是怎么泄露的？说白了，就三条路。
- 直接泄露：用户或开发者主动把敏感信息写进Prompt。比如“帮我分析一下CEO张三的薪资结构，他年薪200万”。这是最直白的泄露方式。
- 间接泄露：Prompt本身不包含敏感词，但模型通过上下文推理出了敏感信息。举个例子，你问“我们公司去年营收最高的三个客户是谁？”，模型如果记住了训练数据中的客户名单，就可能间接输出。
- 侧信道泄露：通过模型的输出长度、响应时间、甚至错误信息来推断敏感数据。这个比较高级，但确实存在。我记得有一次，模型对某个特定ID的查询总是返回“无法处理”，而对其他ID正常——这本身就是一种信息泄露。
⚠️ 注意： 很多团队只关注直接泄露，忽略了间接泄露和侧信道泄露。实际上，后两者更难防范。
4.2 敏感信息识别
要防泄露，首先得知道什么是敏感信息。我个人的习惯是，把敏感信息分成三类。
| 类别 | 示例 | 识别难度 |
|---|---|---|
| 个人身份信息（PII） | 姓名、身份证号、手机号、邮箱、家庭住址 | 低（有固定格式） |
| 商业机密 | 财务报表、客户名单、源代码、产品定价策略 | 中（依赖上下文） |
| 系统凭证 | API Key、数据库密码、SSH密钥、Token | 低（有固定格式） |
识别方法上，我推荐组合拳：
- 正则表达式：适合识别有固定格式的信息，比如身份证号（18位数字+字母X）、手机号（1开头的11位数字）。
- 命名实体识别（NER）：适合识别人名、地名、组织名等。比如“张三”这种，正则搞不定，但NER模型可以。
- 关键词匹配：适合识别商业机密。比如“客户名单”、“财务报表”这类关键词，直接命中就报警。
- 上下文分析：这是最难的一环。比如“我们那个姓张的副总，年薪大概多少？”——这里没有直接出现人名，但结合上下文，模型可能推断出是“张副总”。
💡 小技巧： 我曾经在项目中用了一个简单的规则：如果Prompt中同时出现“公司名+金额+人名”，就自动触发二次确认。效果还不错。
4.3 数据脱敏技术
识别出敏感信息之后，就得处理它。脱敏，说白了就是把敏感信息“伪装”起来，让模型无法识别，但又不影响业务逻辑。
常用的脱敏技术有这几种：
- 替换：把敏感信息替换成假数据。比如把“张三”替换成“用户A”，把“13800138000”替换成“138****0000”。这是最常用的方法。
- 掩码：只保留部分信息，其余用星号或X代替。比如身份证号“110101199001011234”变成“110101********1234”。
- 泛化：把精确信息变成模糊信息。比如“北京市海淀区中关村大街1号”变成“北京市海淀区”。
- 加密：对敏感信息进行加密，模型只能看到密文。但要注意，如果模型需要理解语义，加密就不太合适了。
- 差分隐私：在数据中加入噪声，让模型无法精确推断单个用户的信息。这个技术比较高级，适合大规模数据场景。
下面是一个简单的脱敏代码示例，用Python实现：
import re
def desensitize_prompt(prompt):
# 替换手机号
prompt = re.sub(r'1[3-9]\d{9}', '138****0000', prompt)
# 替换身份证号
prompt = re.sub(r'\d{17}[\dXx]', '110101********1234', prompt)
# 替换邮箱
prompt = re.sub(r'\w+@\w+\.\w+', 'user@example.com', prompt)
# 替换人名（假设用NER模型识别过，这里用占位符）
prompt = prompt.replace('张三', '用户A')
prompt = prompt.replace('李四', '用户B')
return prompt
# 测试
test_prompt = "帮我查一下张三的手机号13800138000和身份证110101199001011234"
print(desensitize_prompt(test_prompt))
# 输出：帮我查一下用户A的手机号138****0000和身份证110101********1234
⚠️ 重要提醒： 脱敏不是万能的。如果脱敏后的数据仍然保留了足够的上下文信息，攻击者可能通过推理还原出原始数据。比如把“张三”替换成“用户A”，但上下文里还有“销售总监”、“年薪200万”等信息，那“用户A”是谁其实很容易猜出来。
4.4 实战中的避坑指南
最后，分享几个我踩过的坑。
- 不要只依赖正则：正则只能识别固定格式，但敏感信息往往没有固定格式。比如“我们CEO的邮箱是zhangsan@company.com”，正则能识别邮箱，但“CEO”这个身份信息它识别不了。
- 脱敏要彻底：我曾经遇到一个案例，脱敏了手机号，但忘了脱敏邮箱。结果攻击者通过邮箱反查到了手机号——因为邮箱里包含了姓名拼音。
- 注意上下文关联：脱敏不是简单的替换，要考虑上下文。比如把“张三”替换成“用户A”，但后面又出现了“张总”，那这两个应该统一替换。
- 日志也要脱敏：很多团队只脱敏Prompt，但忘了脱敏日志。结果日志里明文记录了敏感信息，这等于白忙活。
我曾经在一个金融项目中，因为日志没脱敏，导致客户名单泄露。从那以后，我养成了一个习惯：所有涉及敏感信息的系统，日志输出前必须过一遍脱敏函数。
嗯，数据泄露这事儿，防不胜防。但只要我们做好识别和脱敏，至少能把风险降到最低。记住，安全不是一劳永逸的，而是一个持续迭代的过程。