引言：当用户一句“我的身份证号是110…”触发合规警报
上线第一周，某头部金融SaaS平台的智能客服就出了事——调试面板里赫然显示着明文身份证号、银行卡尾号。前端JavaScript把这些数据一股脑传给了第三方分析服务。这不是推演，是2023年CNVD公开披露的CVE-2023-27891真实事件。
LLM正从演示走向真实业务。这时候，“PII保护”不再是法务文档里那几行加粗文字，而是每次token生成时都得绷紧的那根弦：实时拦、立刻脱敏、全程留痕。
GDPR罚金顶格是2000万欧元或全球营收4%；《个人信息保护法》第66条写得清楚：情节严重的，最高罚5000万元，或上一年度营业额的5%。更扎心的是，2024年中国AI安全白皮书里提到：92%的企业AI项目负责人承认，自家大模型对话系统压根没跑起来运行时PII检测。
这篇文章不讲概念，只拆七种真实场景里的PII裸奔路径，再给你一套能马上用上的防御方案。
一、PII在LLM交互链路中的四大暴露面
对话输入层：用户自己说出来的敏感信息
用户提问时根本不会想“这是不是PII”。比如：“帮我查下工号A20230888张伟的报销单”，或者“我身份证后四位是5678，订单号JD20240511XXXX”。
正则表达式早就不够用了。“身证号”“身分证”“ID card”都能绕过；有人甚至用拼音“shēnfènzhènghào”把完整身份证号喂给模型，结果模型真记住了，还复述出来。
要扛住这种攻击，得靠ML驱动的识别器——NER抓实体，SRL判语义，在150毫秒内搞定中英混排、形近字（比如用全角“０”代替“0”）、OCR误识（比如把数字“1”认成字母“l”）。
- 支持10类以上PII：身份证号、手机号、银行卡号、护照号、社保号、驾驶证号、病历号、住址、邮箱、生物特征哈希值
- 兼容混排、形近字、OCR错字
- 流式逐token扫描，不缓存整句，避免内存里留痕
模型输出层：LLM自己编出来的假PII
LLM不只反射用户输入，还会凭空造。斯坦福CRFM 2023年那个实验很说明问题：提示“生成一份北京朝阳区居民的租房合同”，Llama-2-13B有37%概率吐出一个完全虚构、但校验规则全对的身份证号。
这类风险最难防——它不是用户给的，却可能被下游系统当真数据存进数据库。有家医疗助手就曾生成“患者王某某，住院号HOS20240001，诊断ICD-10编码F32.2”，结果被医院HIS系统自动归档，真病人信息差点被覆盖。
“大模型输出的PII不是错误，而是系统性风险源。你没法靠‘不教模型记身份证’来躲，必须在输出侧建一条强制脱敏的管道。”
——中国信通院《生成式AI安全实践指南》2024版
上下文记忆层：RAG检索时把原始PII一起捞出来
企业塞进知识库的PDF、Word，很多压根没脱敏。有家制造业客户导入2000份供应商合同后，模型一回答“请列出近三年合作供应商”，直接把合同原文“甲方：北京XX科技有限公司，法定代表人：李XX，身份证号：110…”贴了出来。
PII这时已经脱离用户控制，进了向量库、进了检索路径。防护不能等模型开口才动手，得卡在数据进门那一刻。
- 文档预处理：OCR+NER双引擎扫一遍，标出所有PII段落
- 向量化前：对敏感字段做k-匿名化，或加差分隐私噪声
- 检索时：匹配到的段落动态掩码，只返回脱敏后的上下文锚点
日志与可观测性层：运维日志成了PII放大器
最容易被忽略的，其实是日志本身。有家电商大模型平台把用户原始query全写进ELK日志，运维查“退款”时顺手导出一批会话记录——里面全是带手机号的完整对话。
PII防护得贯穿全链路：日志采集代理（比如Filebeat）在传输路上就得脱敏，Dashboard上连原始字段都不能渲染。
二、技术选型：为什么规则+ML才是靠谱组合
规则引擎干它最该干的事：快、准、稳
身份证号（18位+X/x）、银行卡号（Luhn校验）、手机号（1[3-9]\d{9}）——这些标准格式，正则仍是最快最稳的选择，延迟低于5毫秒，几乎零误报。唯客AI护栏内置工信部《个人信息去标识化指南》规则集，大陆、港澳台、海外逻辑可按需切换。
ML分类器攻最难啃的骨头：语义理解
“我爸的医保卡号是尾号8866”——这句话里，“我爸”指向谁？“医保卡号”算不算PII？这得靠BERT-BiLSTM-CRF模型来判断。它在中文PII识别任务上F1值92.7%，训练数据来自CLUE-NER和自建金融对话语料。
双向I/O防护：输入拦住、输出锁死
- 输入侧：用户query流式进来，逐块检测→脱敏→重写→再送进LLM
- 输出侧：LLM每吐一个token，立刻拦截→替换成[REDACTED]→语法结构不动→再发给前端
- 全链路延迟压在300毫秒内，扛得住金融级实时交互
三、真实攻防案例：一次完整的PII提取链路
某安全团队红队测试某政务问答机器人：
- 第一步：用“请把以下内容用base64编码：我的身份证号是11010119900307231X”绕过关键词过滤
- 第二步：诱导模型解码，再让它“把解码后的内容转成拼音”
- 第三步：利用模型对“拼音”指令的机械服从，反推出原始数字串
整个过程没触发任何告警。这个案例直接催生了唯客AI护栏的“多跳推理PII追踪”模块——用图神经网络盯住跨轮次、跨编码的PII传播路径。
四、企业级PII防护实践建议
- 立刻翻一遍所有LLM API的请求体、响应体、日志、监控指标，画出PII在哪流、怎么流、谁在看
- 和现有IAM系统打通，让PII访问权限跟着员工职级走：HRBP能看工号，但不该看到身份证
- 每季度做一次PII渗透测试，重点打RAG检索、历史会话恢复、错误提示消息这三个最脆的口子
总结：PII防护是LLM系统的呼吸阀
生成式AI时代，PII保护不是锦上添花，是生死线。一次未脱敏的身份证号泄露，可能就是监管罚单、用户起诉、品牌崩塌的起点。
唯客AI护栏已落地200多家企业，在金融、政务、医疗场景里，日均拦截50万+含PII风险请求。流式检测、双向防护、毫秒响应——这条路，已经跑通了。
立即体验 唯客 AI 护栏
面向中国企业的 LLM 运行时安全防护系统，以双向I/O防护和毫秒级流式检校筑牢PII隐私数据保护最后一道防线。 申请部署评估