引言：当用户一句“我的身份证号是110…”触发合规警报
某头部银行的智能客服上线第一周，就出了事——用户随口说的“我的身份证号是110…”，被原样记进了没加密的日志系统，还同步到了第三方分析平台。37条含完整身份证号、银行卡号、手机号的对话记录，就这样裸奔了出去。结果，《个人信息保护法》第66条直接被触发，企业面临千万元级罚款和监管专项检查。这不是演练，是2023年第四季度真实发生的事。
LLM正从演示快速走向柜台、热线、审批流。这时候，“PII防护”早不是合规部PPT里的一页纸，而是系统每秒都在跑的硬逻辑。中国信通院《2024大模型安全治理白皮书》里有个刺眼的数字：83.6%的LLM生产事故，根子在PII泄露或误用；其中超六成，发生在提示词进来的那一瞬，和模型答回来的那一秒之间。本文不讲大道理，只聊三件事：怎么识别真PII（不是正则能抓全的）、哪些地方最容易漏（你以为防住了，其实没）、以及一线团队真正能落地的防护动作。
一、PII防护不是脱敏，是流式拦截
PII不是字段，是语义——得听懂上下文
传统数据库脱敏靠字段名匹配：看到id_card就打码。可人在跟AI说话时，不会写{"id_card": "110..."}。他们会说：“建行95533刚发来验证码123456”“我爸医保卡后四位是8899”。这里，“95533”是银行短号，不是手机号；“8899”只有连着“医保卡号”才构成敏感信息。纯靠正则？漏得厉害。我们实测过，金融场景下，NER+上下文分析对信用卡CVV的召回率是99.2%，而纯正则只有61.4%。
防护不能等——得在模型吐字时就动手
老办法是：请求进来→模型算完→返回结果→再扫一遍日志。平均耗时2.3秒，等发现有PII，话已经说完了。新做法必须卡在token流里：当模型输出到“您的订单号是：123456789”的第9个字符“9”时，系统就得立刻把整串替换成“*********”，全程压在300毫秒内。这要求防护层和推理框架绑在一起，SSE流式响应、OpenAI兼容接口，都得原生支持。
真实改造：一个政务热线是怎么堵住漏洞的
某省12345热线接入大模型后，日均处理12万通语音转文字咨询。最初没加实时防护，市民投诉里写的“家庭住址：XX市XX区XX路X号”“社保卡号：123456199001011234”，原封不动弹到坐席屏幕上，还进了档案库。后来上了唯客AI护栏，双向拦：输入端自动掩掉身份证、住址、病历号；输出端掐住模型可能编出来的“根据您2023年就诊记录……”。三个月后，相关投诉少了92%，也顺利通过了省级网信办的安全验收。
二、四个最危险的时刻
危险时刻1：用户自己说漏了
- 提问里直接甩身份证号、护照号、驾驶证号
- 分三次说：第一轮“我在北京朝阳区”，第二轮“住国贸三期”，第三轮“楼号是8”——拼起来就是完整地址
- 上传身份证照片，OCR完直接喂给模型，连“机读区”都没过滤
危险时刻2：模型自己编出来
- 凭空造记录：“您2022年在北京协和医院的就诊记录显示……”（用户根本没去过）
- 过度补全：“怎么查医保余额？” → “请登录国家医保APP，输入您的身份证号110101199003072315”
- 写代码示例时手滑：
phone = "13800138000"直接写死在Python里
《2023全球大模型安全报告》里有一组数据：开源模型在医疗问答中，17.3%的回答会幻觉出PII；商用闭源模型低一些，4.8%。但只要输出层没防护，那4.8%就是实打实的风险。
危险时刻3：RAG检索时翻出旧账
- 向量库里存着没脱敏的合同、病历、工单原文
- 检索返回一个chunk：“根据您签署的《劳动合同》第3.2条……”，模型照搬
- 连文件名都泄密：
张三_身份证_扫描件.pdf被当成关键词检索
危险时刻4：调试时忘了关闸
- 开发者为查问题，开了全量日志，用户原始输入全在里头
- Prometheus指标标签里塞手机号：
llm_request_total{user_id="139****1234"} - A/B测试用邮箱哈希做分流键，结果被人逆向扒出明文
三、五步落地，不画饼
- 摸清家底：扫一遍所有LLM入口——API网关、Dify流程、LangChain Agent、前端SDK，标清楚数据从哪来、往哪去
- 分级定级：按《GB/T 35273-2020》，把PII分三级：身份证号是L3（最高危），设备ID是L1（低风险）
- 策略分治：L3必须打码+告警；L1只记日志，不干预
- 插进推理链：在OpenAI接口、Ollama、vLLM这些推理层前面，加一道防护中间件
- 看得见才算数：Dashboard上盯着——每天拦了多少类PII？脱敏准不准？误报多不多？目标：误报率压到0.3%以下
四、别选边站队：规则+模型，才是现实解法
纯靠规则？金融场景漏报率超40%。纯靠BERT-NER？遇到港澳居民来往内地通行证这种长尾PII，F1值只有0.52。唯客AI护栏走的是混合路：规则引擎盯牢18位身份证、16–19位银行卡这类高确定性模式；ML分类器负责“我的快递收货电话是……”后面那个号码——它得结合前文判断。保险理赔对话实测：混合方案F1值0.987，比单一路线强3.2倍。
五、踩过的坑，帮你绕开
- 只防输入，不管输出？错。58%的泄露，就出在模型自己答出来的那句话里
- 指望system prompt管用？“不要输出身份证号”——实测绕过率92%以上
- 私有化部署时，把脱敏密钥和模型权重塞进同一个容器？等于把锁芯和钥匙挂在一起
实践建议：今天就能做的三件事
- 把客服、政务、医疗这三类高敏场景的LLM API，先加上双向I/O防护
- 把PII检测延迟写进SLA：别超300毫秒
- 每月红队一次：拿对抗样本去撞，比如“我的ID是110101199003072315，但最后一位是X”，看它能不能识破
记住：PII防护不是加个功能模块，是让整个LLM应用跑在一条干净的数据管道上。
总结：PII是AI安全的锚点
所有防线，最终都得落在PII上。从用户敲下第一个字，到模型吐出最后一个token，再到日志落盘的每一字节——防护必须贯穿始终。这不是为了应付检查，而是让用户敢对你说话。
立即体验 唯客 AI 护栏
面向中国企业的 LLM 运行时安全防护系统，提供双向防护与毫秒级响应的 PII 隐私数据保护能力，已在200+企业生产环境稳定运行。 申请部署评估