LLM数据防泄漏（DLP）实战：三层语义防御架构-尧图网络科技

1. 项目概述：这本“黑皮书”不是讲黑客技术，而是讲怎么守住AI时代最后一道门

你有没有遇到过这样的场景：团队刚上线一个内部知识库问答机器人，员工用它查报销流程、问IT故障、甚至输入客户合同片段确认条款——结果某天审计部门发来一封邮件，说在第三方日志平台里发现了明文存储的身份证号和银行卡尾号？又或者，市场部同事把一份含脱敏客户画像的Excel表拖进大模型做文案润色，三天后竞对发布的推广话术，结构、数据粒度、甚至错误用词都和你们内部草稿惊人一致？这些不是虚构剧情，而是我过去18个月在6家不同行业客户现场亲眼记录的23起真实事件。The LLM DLP Black Book这个标题里的“Black Book”，指的从来不是暗网手册或渗透指南，而是企业安全团队在AI落地过程中被迫写下的“血泪操作日志”——它不教你怎么攻破系统，而是手把手告诉你，当大模型像一台永不疲倦的复印机，把所有喂给它的数据都刻进权重、缓存、日志、中间件时，你该在哪几个关键卡口上焊死螺丝、加装指纹锁、设置数据熔断阀。这本书的核心关键词是LLM数据防泄漏（DLP）、PII识别与阻断、AI工作流隐私加固、提示词工程防御层、模型输出净化。它适合三类人：正在把RAG系统接入生产环境的算法工程师、需要向董事会解释“为什么不能让销售用ChatGPT改PPT”的CISO、以及每天被业务部门追着问“这个API能不能传客户手机号”的一线安全运维。它解决的不是“要不要用AI”的哲学问题，而是“怎么让AI在不偷走你命脉数据的前提下，老老实实干活”的生存问题。

2. 内容整体设计与思路拆解：为什么传统DLP在LLM面前集体失能？

2.1 传统DLP的三大失效点，必须先戳破幻觉

很多企业安全负责人第一反应是：“我们已有Symantec DLP/Forcepoint，直接开规则就行”。我亲手帮两家金融客户做过对照测试：把同一份含身份证号的测试文档，分别通过邮件附件、U盘拷贝、以及“上传至内部Copilot插件提问”三种方式触发。结果很残酷：前两种方式100%被拦截并告警，第三种方式——也就是经由LLM处理链路——0告警，且原始身份证号完整出现在模型返回的JSON格式响应体中。原因不在工具不好，而在架构逻辑根本错位。传统DLP基于三个假设构建，而LLM全部击穿：

假设一：数据流动有明确边界。传统DLP监控网络出口、终端USB、邮件网关等“咽喉要道”。但LLM的输入流是API调用，输出流是HTTP响应，它不经过防火墙策略链，不触发DLP的文件扫描引擎。就像你在家门口装了十道防盗门，却忘了小偷能从空调外机管道钻进来。
假设二：敏感数据以静态形式存在。DLP规则依赖正则匹配、字典扫描、机器学习分类器识别文档中的结构化字段。但LLM处理的是动态语义流：一段“张三，31011519900307251X，上海浦东新区XX路XX号”的文本，在进入模型前可能被用户口语化改写成“我们那个90年出生、身份证最后四位251X、住浦东的朋友”，传统规则根本无法关联识别。
假设三：数据生命周期可控。DLP默认数据离开终端即结束监控。但LLM会把输入数据切片、嵌入、缓存、生成中间token、拼接输出，整个过程跨越GPU显存、Redis缓存、LangChain内存对象、前端浏览器localStorage等多个非标准存储点。你永远不知道哪一行日志里藏着未脱敏的PII。

提示：别急着买新工具。先做一次“LLM数据流测绘”：从用户输入框开始，画出数据经过的所有组件（前端JS、API网关、认证服务、向量数据库、LLM推理服务、缓存层、日志收集器、监控告警系统），标出每个环节是否具备数据内容检查能力。这张图比任何采购清单都重要。

2.2 “黑皮书”的三层防御架构：不依赖单点神器，靠组合拳打穿盲区

这本书的设计逻辑，是把防御能力像洋葱一样层层嵌套，每层解决特定维度的失效：

第一层：输入端语义级过滤（Input Semantic Sanitization）
不再用正则找“18位数字”，而是用轻量级NER模型实时识别“身份证号实体”，结合上下文判断是否为真实PII（比如“我的身份证号是123456789012345678”要拦，“身份证号字段长度为18位”则放行）。这一层部署在API网关或前端SDK，延迟控制在15ms内，避免拖慢用户体验。
第二层：模型交互层协议加固（Model Interaction Protocol Hardening）
这是最容易被忽视的战场。我们发现73%的PII泄露发生在提示词（prompt）构造阶段：业务系统把用户原始输入+数据库查询结果+知识库摘要，一股脑拼进system prompt发送给LLM。解决方案是强制推行“提示词沙盒”：所有外部数据必须经由专用服务做脱敏/泛化处理（如将“张三”转为“用户A”，“上海浦东”转为“华东某市”），再注入模型。这个服务本身不接触原始数据，只返回处理后的token流。
第三层：输出端意图驱动净化（Output Intent-Driven Purification）
模型返回的文本，不能简单用正则清洗。比如用户问“帮我总结客户王五的投诉记录”，模型回复中若出现“王五，电话138****5678，地址XX小区3栋”，直接删号码会破坏语义连贯性。我们采用“意图-实体-动作”三元组分析：识别用户提问意图（总结投诉）、提取模型输出中所有PII实体、根据意图决定净化动作（此处应泛化为“客户联系方式已隐去”，而非删除）。这需要微调一个小型分类器，但准确率比规则引擎高42%。

这种分层不是炫技，而是对应真实故障点。我在某电商客户实施时，第一层拦截了81%的恶意测试输入（员工故意输身份证号测系统），第二层堵住了63%的业务系统误传（订单服务把用户手机号当备注字段传入），第三层则解决了剩余16%的“合理但危险”场景（客服用LLM生成回访话术时，模型自发引用了历史对话中的地址信息）。

2.3 为什么拒绝“LLM专属DLP盒子”？成本、延迟与误报的三角困局

市面上已出现标榜“LLM原生DLP”的商业方案，宣称一键集成、零改造。我带队做过深度POC：在同等硬件配置下，对比自建三层架构与某头部厂商的SaaS方案。结果如下表：

维度	自建三层架构	商业SaaS方案	关键差异说明
平均请求延迟	47ms（含所有过滤）	218ms	商业方案需将完整prompt+response往返云端检测，增加TCP握手与序列化开销
PII漏报率	0.8%（测试集10万条）	3.2%	商业方案依赖通用NER模型，对金融/医疗等垂直领域实体识别弱；自建层可针对业务字段微调
误报率	2.1%	18.7%	商业方案将“身份证号字段”“银行卡号格式”等开发文档术语全误判为PII，导致大量合法API调用被阻断
年授权成本（500并发）	￥12.6万（含人力维护）	￥89万（基础版）	商业方案按API调用量计费，高峰期成本飙升；自建架构资源可复用现有K8s集群

更致命的是扩展性。当客户要求新增“检测港股代码泄露”（如“00700.HK”）或“识别内部项目代号”（如“Project Phoenix”）时，商业方案需等待厂商排期更新模型，而我们的输入过滤层只需在NER训练数据中加入200条标注样本，2小时完成热更新。这印证了一个残酷事实：在AI安全领域，没有银弹，只有持续迭代的肌肉记忆。这本书不提供“买来即用”的幻觉，而是给你一套可生长、可验证、可审计的防御基因。

3. 核心细节解析与实操要点：从理论到落地的七处生死关

3.1 输入过滤层：轻量NER模型如何做到15ms内完成语义识别？

很多人以为NER必须用BERT-large，实际完全不必。我们在生产环境用的是DistilBERT-base + CRF头的精简架构，参数量仅135M（BERT-large为340M），在T4 GPU上单次推理耗时9.2ms（P99）。关键在于训练数据的构造逻辑：

不追求全量实体覆盖：聚焦企业最敏感的5类PII（身份证号、手机号、银行卡号、邮箱、住址），放弃“姓名”“公司名”等高误报实体。因为姓名在业务场景中天然高频，强行识别会导致大量误拦。
引入对抗样本增强：在训练集中注入三类扰动样本：
1. 格式变形：31011519900307251X→310115 19900307 251X（加空格）、310115-19900307-251X（加横线）
2. 语义遮蔽：“请查询张三的身份证号”→“请查询用户A的唯一身份标识符”
3. 上下文混淆：“身份证号123456789012345678无效”（需识别为无效但仍是PII）、“身份证号字段长度为18位”（需识别为非PII）

训练时采用Focal Loss替代交叉熵，重点惩罚难分样本。最终在测试集上，身份证号识别F1达99.3%，误报率压至0.4%。部署时采用TensorRT优化，模型序列化为.plan文件，通过共享内存与API网关进程通信，彻底规避HTTP序列化开销。

注意：不要在前端JS中运行NER模型！曾有客户为“降低延迟”将模型编译为WebAssembly，结果被逆向工程师5分钟提取出全部权重和词表。所有敏感计算必须在服务端完成。

3.2 提示词沙盒：如何让业务系统“无感”接入脱敏服务？

最大的落地阻力从来不是技术，而是业务部门的抵触：“加个中间层会影响我们QPS！” 我们的解法是协议兼容+异步兜底：

协议层面：沙盒服务完全模拟原有LLM API的OpenAI兼容接口。业务系统无需修改一行代码，只需将https://llm-api.company.com/v1/chat/completions指向沙盒服务地址。沙盒收到请求后，先解析messages数组，对所有user角色消息执行脱敏，再将处理后的消息体转发至真实LLM，最后将响应原样返回。
性能保障：沙盒内置两级缓存：
- L1缓存（内存）：对相同原始输入的脱敏结果缓存5秒，命中率超68%；
- L2缓存（Redis）：对高频PII模式（如“手机号”“身份证号”）建立泛化规则库，例如将所有11位数字串统一替换为<PHONE>，此规则可预加载，脱敏耗时降至0.3ms。
兜底机制：当沙盒服务异常时，自动降级为“直通模式”，但会在响应头中插入X-Sandbox-Status: degraded，并触发告警。运维团队可在5分钟内收到通知，而非等到审计发现泄露。

实操中，我们为某保险公司的保全系统接入时，QPS从1200降至1185（-1.25%），完全在业务容忍范围内。关键是让业务方看到：安全不是加锁，而是换一把更智能的钥匙。

3.3 输出净化层：为什么“正则替换”在LLM时代是自杀行为？

这是踩坑最深的一环。初期我们用re.sub(r'\d{17}[\dXx]', '<ID_NUMBER>', response)处理输出，结果引发严重事故：某银行客户用LLM生成贷款审批意见，模型回复中有一句“参考《个人信用信息基础数据库管理暂行办法》（银发〔2005〕12号）”，其中200512被正则误判为身份证号，替换成<ID_NUMBER>，导致法律文书引用失效，监管检查时被定性为“重大合规缺陷”。

根本问题在于：正则无法理解语义边界。解决方案是构建“意图-实体-动作”决策引擎：

意图识别：用小型BERT分类器判断用户原始提问类型（共12类：如“总结投诉”“生成合同”“分析数据”“编写代码”）。模型输入为[CLS] + prompt + [SEP] + response[:128]，输出12维概率向量。
实体抽取：对response全文运行轻量NER，获取所有PII实体及其位置。
动作决策：查表匹配意图与实体组合，确定净化动作：
- 意图=“生成合同”，实体=“手机号” → 动作=“泛化为<CONTACT_PHONE>”
- 意图=“分析数据”，实体=“身份证号” → 动作=“删除整段含PII的句子，并添加注释‘此处涉及个人身份信息，已按合规要求省略’”
- 意图=“编写代码”，实体=“邮箱” → 动作=“保留，但添加注释‘示例邮箱，非真实地址’”

这个引擎的决策表是业务安全团队与法务共同制定的，每季度更新。它让净化不再是技术判断，而是合规意志的代码化表达。

3.4 日志与监控：如何从万亿级LLM日志中揪出那0.001%的泄露？

LLM服务的日志量是传统API的5-8倍：除常规access log外，还有token级debug log、embedding向量采样、prompt版本追踪。某客户单日产生12TB日志，传统SIEM工具直接崩溃。我们的方案是分级采样+语义索引：

Level 0（全量）：仅保留request_id,timestamp,status_code,response_time，存于低成本对象存储，保留180天。
Level 1（采样）：对1%的请求，额外记录prompt_truncated(前200字符),response_truncated(前200字符),piis_detected(NER识别出的PII类型列表)。使用Elasticsearch的ingest pipeline实时解析，建立piis_detected.keyword字段用于聚合分析。
Level 2（深度）：对所有status_code=200且response_time>5000ms的请求，强制记录完整prompt+response（加密后存于独立冷备库），供事后审计。

关键创新是PII指纹索引：对每个识别出的PII实体，生成SHA-256哈希（如31011519900307251X→a1b2c3...），在ES中建立pii_fingerprint字段。当审计发现某身份证号泄露时，无需全文检索，直接查哈希即可定位所有相关请求，响应时间从小时级降至秒级。

3.5 模型选型陷阱：开源vs商用，谁在偷偷记下你的数据？

这是企业最易忽略的“信任盲区”。我们曾审计某客户使用的商用LLM SaaS服务，发现其Terms of Service第7.2条写着：“客户输入数据将用于模型持续优化，客户不可撤回同意”。而该客户是三级等保单位，此条款直接违反《个人信息保护法》第十三条。

我们的核查清单（必须逐条确认）：

数据主权：合同是否明确约定“客户数据所有权归属客户，服务商仅获有限使用权”？注意“用于改进服务质量”这类模糊表述，必须限定为“匿名化、聚合化、不可逆的统计分析”。
退出机制：终止服务后，服务商能否提供书面证明，说明所有客户数据（含备份、日志、缓存）已物理销毁？是否有第三方审计报告？
本地化能力：是否支持纯私有化部署（包括向量数据库、Embedding模型、LLM推理引擎）？注意“混合云”常意味着敏感数据仍需过公网。
审计日志：能否提供细粒度日志，证明无未授权数据访问？日志需包含who（操作者）、what（数据范围）、when（时间戳）、how（访问方式）四要素。

实操建议：优先选择Llama 3、Qwen2等Apache 2.0协议模型，配合vLLM推理框架，所有组件可控。商用模型如Claude、GPT-4，必须签订Data Processing Agreement（DPA），并启用企业版提供的“数据不用于训练”开关（注意：此开关仅对新输入生效，历史数据仍可能被使用）。

3.6 RAG系统的特洛伊木马：知识库不是保险箱，而是泄露放大器

RAG（检索增强生成）被广泛认为“更安全”，因为它不把原始数据喂给模型。但我们在某政务客户发现，其RAG系统将市民信访记录作为知识库，检索时返回的chunk中包含完整身份证号，LLM在生成回答时直接复述。问题根源在于检索粒度失控。

标准RAG流程：Query → Embedding → 向量检索 → Top-K chunks → Prompt拼接 → LLM生成。当K=5时，若某chunk含PII，模型极可能复述。我们的加固方案：

检索前过滤：在向量数据库（如Milvus）中，为每个chunk添加has_pii: bool元数据字段。检索时强制filter="has_pii == false"，确保PII chunk永不进入检索结果。
检索后净化：对返回的每个chunk，运行轻量NER，若含PII则触发“动态泛化”：将张三，31011519900307251X替换为市民A，身份证号已脱敏，再拼入prompt。
生成后校验：LLM输出后，用规则引擎快速扫描是否含原始PII（因泛化可能失败），若发现则触发重试机制，强制模型重新生成。

这套组合拳将RAG系统的PII泄露率从12.7%降至0.3%。记住：知识库的安全等级，永远等于其中最脆弱的那个chunk。

3.7 人员与流程：为什么90%的泄露源于“好心办坏事”？

技术再强，挡不住员工的好奇心。我们统计过23起泄露事件，19起源于内部测试：员工为验证系统能力，主动输入真实客户数据。某科技公司CTO甚至用自己护照号测试OCR模块，结果该图片被缓存至CDN，暴露长达72小时。

我们的“人防”三板斧：

沙箱环境强制隔离：所有开发、测试环境必须使用合成数据平台（如Synthea）生成的假数据。生产环境API网关对X-Environment: dev/test请求头自动拦截含PII的输入，并返回400 Bad Request: PII not allowed in non-prod env。
权限最小化：LLM服务的API Key按角色分级。客服人员Key只能调用/summarize-complaint接口，且该接口后端强制启用输出净化；而算法工程师Key可调用/debug-prompt，但此接口返回的完整日志仅限安全团队查看。
安全左移培训：每月一次“红蓝对抗演练”：蓝军（业务方）用真实业务场景设计测试用例，红军（安全团队）现场演示如何在不泄露数据的前提下达成目标。例如“如何用LLM分析客户投诉趋势？”——答案是：先由数据团队提供脱敏后的投诉主题分布CSV，再喂给LLM分析。

最有效的改变，是把安全从“守门员”变成“教练员”。当业务方自己能说出“这个prompt里有客户手机号，得先过沙盒”，防御才算真正扎根。

4. 实操过程与核心环节实现：手把手搭建你的第一道防线

4.1 从零部署输入过滤层：15分钟跑通语义识别流水线

以下是在Ubuntu 22.04 + Python 3.10环境下，用不到50行代码实现可运行的输入过滤服务。重点不是代码多酷，而是每一步都直击生产痛点。

# requirements.txt transformers==4.41.2 torch==2.3.0 scikit-learn==1.4.2 fastapi==0.111.0 uvicorn==0.29.0 # main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from transformers import AutoTokenizer, AutoModelForTokenClassification from transformers import pipeline import torch app = FastAPI() # 加载轻量NER模型（已量化，仅128MB） tokenizer = AutoTokenizer.from_pretrained("distilbert-base-ner-finetuned") model = AutoModelForTokenClassification.from_pretrained("distilbert-base-ner-finetuned") ner_pipeline = pipeline( "ner", model=model, tokenizer=tokenizer, device=0 if torch.cuda.is_available() else -1, aggregation_strategy="simple" # 避免实体碎片化 ) class FilterRequest(BaseModel): text: str @app.post("/filter") def filter_pii(request: FilterRequest): try: # 关键：限制输入长度，防OOM truncated_text = request.text[:512] # 执行NER，仅关注5类高危实体 results = ner_pipeline(truncated_text) pii_entities = [ r for r in results if r['entity_group'] in ['ID_NUMBER', 'PHONE', 'BANK_CARD', 'EMAIL', 'ADDRESS'] ] # 构建脱敏后文本（保留非PII部分） filtered_text = request.text for ent in sorted(pii_entities, key=lambda x: x['start'], reverse=True): # 从后往前替换，避免位置偏移 placeholder = f"<{ent['entity_group']}>" filtered_text = filtered_text[:ent['start']] + placeholder + filtered_text[ent['end']:] return { "original": request.text, "filtered": filtered_text, "piis_found": len(pii_entities), "entities": [{"type": e['entity_group'], "text": e['word']} for e in pii_entities] } except Exception as e: raise HTTPException(status_code=500, detail=f"Filter failed: {str(e)}") # 启动命令：uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4

部署要点说明：

模型选择：distilbert-base-ner-finetuned是我们公开的微调模型（Hugging Face ID:company/llm-dlp-ner-distil），已在金融、政务数据集上训练，F1达99.1%。你可用自己的数据微调，只需200条标注样本。
长度截断：LLM输入通常很长，但NER只需看上下文片段。截断至512字符既保证精度，又将GPU显存占用从2.1GB压至0.8GB。
反向替换：reverse=True确保长文本中多个PII替换时不互相干扰。实测显示，正向替换在含10+PII的文本中错误率达37%。
轻量启动：--workers 4利用多核CPU，单节点QPS可达1800+，满足中小规模需求。

实操心得：第一次部署后，务必用真实业务日志做压力测试。我们曾发现某客户日志中大量<br>标签导致NER分词错乱，解决方案是在pipeline前加text.replace('<br>', ' ')。生产环境的脏数据，永远比测试数据集更野蛮。

4.2 构建提示词沙盒：用NGINX+Lua实现零代码协议兼容

为避免业务系统改造，我们采用NGINX作为沙盒入口，用Lua脚本实现协议转换。此方案无需Python服务，延迟更低（实测P99=3.2ms），且可与现有K8s Ingress无缝集成。

# nginx.conf 中的沙盒server块 upstream llm_backend { server 10.0.1.10:8000; # 真实LLM服务 } server { listen 8001; server_name sandbox.llm; location /v1/chat/completions { # 步骤1：解析JSON body，提取user messages access_by_lua_block { local cjson = require "cjson" local ngx_req = require "ngx.req" ngx.req.read_body() local data = ngx.req.get_body_data() if not data then ngx.exit(400) end local json = cjson.decode(data) local user_msgs = {} for _, msg in ipairs(json.messages) do if msg.role == "user" then table.insert(user_msgs, msg.content) end end -- 步骤2：调用过滤服务（此处简化为curl，生产用lua-resty-http） local filter_url = "http://127.0.0.1:8000/filter" local http = require "resty.http" local httpc = http:new() local res, err = httpc:request_uri(filter_url, { method = "POST", body = cjson.encode({text = table.concat(user_msgs, " ")}), headers = {"Content-Type": "application/json"} }) if not res or res.status ~= 200 then ngx.exit(500) end local filter_res = cjson.decode(res.body) if filter_res.piis_found > 0 then -- 步骤3：修改原始JSON，替换user content for i, msg in ipairs(json.messages) do if msg.role == "user" then msg.content = filter_res.filtered break -- 简化：只处理第一个user消息 end end end -- 步骤4：重写body并继续转发 ngx.req.set_body_data(cjson.encode(json)) } proxy_pass http://llm_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

关键优势：

零业务侵入：业务系统仍调用/v1/chat/completions，完全无感。
极致低延迟：Lua在NGINX worker进程中执行，无进程间通信开销。
弹性扩展：NGINX可水平扩展，过滤服务可独立扩缩容。

注意事项：生产环境必须用lua-resty-http替代os.execute(curl)，后者会创建子进程，QPS超过500时CPU飙升。我们实测lua-resty-http在1000并发下CPU占用稳定在35%。

4.3 输出净化引擎：用规则引擎实现意图驱动的精准动作

我们不推荐用复杂ML模型做输出净化（成本高、难调试），而是用YAML定义的规则引擎，兼顾灵活性与可审计性。

# purification_rules.yaml rules: - intent: "generate_contract" entities: - type: "PHONE" action: "replace_with_placeholder" placeholder: "<CONTACT_PHONE>" - type: "ID_NUMBER" action: "remove_sentence" comment: "PII removed per contract compliance policy v3.1" - intent: "analyze_customer_feedback" entities: - type: "EMAIL" action: "anonymize_local_part" # 将 name@domain.com → xxx@domain.com - type: "ADDRESS" action: "generalize_to_city" # 将 "上海市浦东新区XX路XX号" → "上海市某区" - intent: "write_code" entities: - type: "ALL" action: "allow" comment: "Code generation requires real examples for accuracy"

Python解析引擎核心逻辑：

def apply_purification(response: str, intent: str, entities: List[Dict]) -> str: rules = load_yaml("purification_rules.yaml") rule = next((r for r in rules['rules'] if r['intent'] == intent), None) if not rule: return response # 无匹配规则，放行 for entity in entities: entity_rule = next((er for er in rule['entities'] if er['type'] == entity['type']), None) if not entity_rule: continue if entity_rule['action'] == 'replace_with_placeholder': response = response.replace(entity['text'], entity_rule['placeholder']) elif entity_rule['action'] == 'remove_sentence': # 找到含entity的整句，用正则删除 sentence_pattern = r'[^。！？\n]*' + re.escape(entity['text']) + r'[^。！？\n]*[。！？\n]' response = re.sub(sentence_pattern, entity_rule.get('comment', ''), response) elif entity_rule['action'] == 'anonymize_local_part': # 邮箱脱敏逻辑 response = re.sub(r'(\w+)@([\w.-]+)', r'xxx@\2', response) return response

为什么用YAML不用代码？因为法务和合规团队需要直接审阅规则。当监管问询“为何允许代码生成中使用真实邮箱”，他们能指着YAML文件第12行# Code generation requires real examples给出明确答复。可审计性，是安全方案的生命线。

4.4 全链路监控看板：用Grafana构建LLM数据安全仪表盘

没有监控的安全是纸糊的。我们用Prometheus+Grafana构建实时看板，核心指标必须包含：

输入侧：llm_input_pii_rate（含PII请求占比）、llm_input_filter_bypass_count（绕过过滤的请求量）
处理侧：llm_sandbox_latency_ms（沙盒P95延迟）、llm_sandbox_cache_hit_rate
输出侧：llm_output_pii_leak_count（净化后仍含PII的响应数）、llm_output_regen_count（因泄露触发重试次数）
日志侧：llm_log_pii_fingerprint_count（按PII指纹聚合的泄露事件）

Grafana看板关键面板配置：

面板名称	数据源	查询语句	业务意义
实时PII流入热力图	Prometheus	`sum(rate(llm_input_pii_count{job="filter"}[5m])) by (entity_type)`	监控哪类PII最常被输入，指导员工培训重点
沙盒服务健康度	Prometheus	`100 - (rate(llm_sandbox_error_count{job="sandbox"}[5m]) / rate(llm_sandbox_request_count[5m])) * 100`	低于99.5%触发P1告警
泄露溯源矩阵	Elasticsearch	`GET /llm-logs/_search { "aggs": { "by_pii": { "terms": { "field": "pii_fingerprint.keyword" } } } }`	点击任一指纹，下钻查看所有相关请求详情

部署捷径：用prometheus-operator一键部署Prometheus，Grafana Dashboard JSON模板已开源（GitHub:llm-dlp-monitoring）。导入后，5分钟内获得可运行看板。

实操提醒：必须开启llm_output_pii_leak_count的告警。我们某客户首次部署后，告警显示每小时有3次泄露，排查发现是客服系统将“客户说他身份证丢了”这类描述性文本误判为PII。这暴露了业务语义理解盲区，推动我们增加了“否定语境识别”模块。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪经验

5.1 “为什么我的NER模型在测试集上F1=99%，上线后漏报率飙升？”

这是最高频问题。根本原因不是模型差，而是数据漂移（Data Drift）。我们跟踪过12个生产模型，上线30天后平均F1下降11.2%。罪魁祸首有三：

业务语言进化：初期训练数据中“手机号”多为138****5678格式，但业务方很快开始用138-****-5678、138 **** 5678，甚至138*5678（星号数量不固定）。
跨域迁移：在金融数据上训练的模型，用于政务场景时，对“港澳居民来往内地通行证号”（9位数字+字母）识别率为0。
对抗性输入：员工为绕过检测，发明新写法：“身份证：三一零一壹伍壹玖玖零零叁零柒贰伍壹X”（中文数字）。

解决方案不是重训模型，而是动态反馈闭环：