提示词隐私Prompt Privacy在很多 LLM 应用里仍然被当成“用户输入加密”来对待这是一个普遍的误解。实际上提示词进入大模型前后的每一层都可能被记录、缓存、转发或用于后续统计单靠 TLS 和登录态并不能保证敏感信息不出现在不该出现的地方。要在项目中真正落地提示词隐私保护必须从敏感信息识别、脱敏替换、模型调用、结果还原、日志审计这条完整链路入手而不是只在前端把输入包一层加密。接下来这篇文章会沿着一条可复现的主线展开先梳理 LLM 场景下的隐私风险面再实现一个最小可运行的提示词脱敏与还原模块最后给出生产环境需要的配置、排错链路和最佳实践。适合正在开发对话机器人、智能客服、文档分析、企业知识库等场景的后端工程师也适合刚开始把大模型接入业务系统的技术负责人。1. 先理解 LLM 应用中的提示词隐私风险面1.1 LLM 提示词隐私不只是“用户输入”的隐私传统服务端应用通常只需要保证输入数据在存储时不泄露、在传输时不被截获。LLM 应用多了一层特殊之处原始提示词会被组合成请求发送给模型服务模型输出又可能引用或推断出输入中的敏感内容。也就是说隐私风险不只存在于用户输入那一刻而是覆盖从输入采集、组装 prompt、调用模型、接收响应、记录日志到缓存结果的整个生命周期。日常开发中常见的风险有两种。第一种是“不知道敏感信息在哪个环节被落盘”。应用日志、网关日志、链路追踪系统、消息队列、Redis 缓存都可能保存完整请求体只要其中任何一个环节记录了原始 prompt隐私保护就已经失效。第二种是“把脱敏和加密混为一谈”。对 prompt 做全量加密后再发给模型模型无法理解内容业务上用不了只做网络加密服务端记录明文日志又等于白做。提示词隐私保护的核心目标不是让所有敏感信息永远不出现而是让敏感信息只出现在被允许出现的地方。允许出现的位置包括业务处理内存、用户授权范围内的存储、明确的模型调用出口不允许出现的位置包括无关联的日志、缓存、监控采样、调试输出和第三方非授权系统。1.2 典型风险面应该按请求链路逐层排查在设计保护方案之前先把一条 LLM 请求可能经过的环节列出来更容易确定该在哪里加控制。实际项目中典型的风险面如下表。风险面说明常见触发场景客户端采集页面或客户端把用户输入原样保存到本地前端埋点、浏览器本地缓存、剪贴板记录传输链路prompt 在网络传输过程中被中继设备记录未开启 TLS、经过调试代理、内网网关转发应用日志服务端打印请求参数用于排错logger.info(prompt%s, prompt)第三方模型服务请求体发送到外部模型服务可能被服务端记录或保留使用公网大模型 API未确认数据处理策略模型输出模型可能复述或推导出敏感信息提示词包含 key模型在回复中重复该 key中间件缓存缓存层保存完整 prompt 或完整响应Redis 缓存命中结果缓存 key 或 value 含原文监控与审计APM、链路追踪采集 HTTP body采样器默认采集请求和响应体从表格可以看出即使只保护“用户输入”这一端中间经过的组件仍然可能泄露数据。因此提示词隐私保护方案要按请求链路设计而不仅是按某一个函数设计。1.3 隐私保护与模型效果之间存在取舍一个让很多团队困惑的问题是脱敏之后模型效果变差了。原因在于大模型依赖上下文理解实体之间的关系把“张三”替换成“A”把“zhangsanexample.com”替换成[EMAIL_0]模型仍然可能理解这是某个人的邮箱。但如果把整句话删除或完全 mask模型丢失了必要语义生成结果自然不可控。正确思路不是追求把所有敏感字段全部替换掉而是根据业务场景选择“最小必须可见”原则。对于模型回答不需要知道明文的内容直接脱敏或删除对于模型回答需要引用或操作的内容使用可还原的 token 替换对于模型只需要知道大类的字段使用泛化标签例如[EMAIL]、[PHONE]、[DATE]。所以提示词隐私保护方案必须可配置不能写死一套规则。不同业务、不同阶段、不同模型能力下需要调整的通常不是“是否保护”而是“保护到什么程度”。2. 提示词隐私保护的整体链路与方案选型2.1 推荐主链路识别、替换、调用、还原、审计一个可落地的提示词隐私保护模块可以按照下面的链路设计。在进入业务逻辑之前扫描原始 prompt识别其中的敏感信息。对识别出的敏感信息执行脱敏策略默认使用 token 替换生成脱敏后的 prompt。将 token 与原始值的映射关系保存在短期、受控的内存存储中。把脱敏后的 prompt 发送给大模型服务。对模型返回结果再次做敏感信息扫描防止模型在回复中编造或泄露新的敏感字段。根据业务需要决定是否还原 token或者只保留脱敏结果。记录审计日志但日志中只保存脱敏后的 prompt、模型响应摘要和脱敏数量。这个链路的关键点是“先识别再替换后调用”。如果顺序颠倒先调用再脱敏敏感信息已经到达了模型服务端风险已经扩张到外部。2.2 脱敏策略选型token、泛化、删除、加密不同敏感字段适合不同的处理方式。不要对全部字段使用同一种策略。策略示例适用场景注意事项Token 替换zhangsanexample.com-[EMAIL_0]模型输出需要引用原值业务允许临时保存映射映射关系要短期保存并及时销毁泛化标签13800138000-[PHONE]模型只需要知道字段类型不需要具体值无法还原但安全性高固定替换username-user测试环境、调试环境容易丢失多条数据的区分度删除sk-123456...- API Key、Token、密码删除后模型输出不会引用但可能影响语义加密映射表用 AES 加密后持久化需要跨请求还原或需要临时落盘密钥要放入 KMS不要写死在代码里Token 替换是最推荐的默认策略因为它既保留了“这段内容是一个实体”的结构又让模型无法直接看到真实值。但 token 不是加密token 与原始值的映射关系一旦泄露同样会暴露数据。因此映射关系的生命周期要尽量短并且不能写入普通日志。2.3 需要重点保护的数据类型与检测规则需要保护的数据类型需要结合业务场景界定。常见类型至少有这些。数据类型示例推荐策略说明邮箱zhangsanexample.comtoken 替换正则规则简单但容易误收ab手机号86 13800138000token 替换或泛化不同国家格式不同需要按区域配置证件号110101199001011234删除或泛化结构复杂建议只保留区段API Keysk-abcdefghijklmn...删除绝不能发送给无关模型IP 地址10.20.30.40泛化或删除内网 IP 也要保护用户名zhangsan泛化需要借助词表或 NER正则难以覆盖内部系统名order-db-prod泛化可能需要业务词典参与识别日期时间2025-06-18 12:00:00按需脱敏有些业务需要日期有些不需要正则适合处理格式固定的字段比如邮箱、手机号、常见密钥前缀。人名、地名、公司名这类实体则需要借助命名实体识别NER模型或自定义业务词典。实际生产项目通常采用“正则规则 NER 模型 业务词表”三层结合才能控制漏报和误报。3. 环境准备与项目结构3.1 开发环境要求下面实现一个最小可运行的提示词脱敏与还原模块使用 Python 3.9 以上版本。示例采用标准库re、dataclasses外部 HTTP 调用使用requests。如果只跑本地 mock 演示连requests都可以不装。依赖版本建议用途Python3.9运行环境requests2.31调用兼容 OpenAI 协议的模型服务cryptography41.0可选用于映射关系加密pytest7.x可选运行测试这里没有写死某个大模型 SDK 的版本因为不同项目接入的模型服务不同。落地前需要确认你使用的模型服务地址、协议版本和 SDK 版本不要盲目使用最新版优先使用项目中已经锁定的版本。3.2 项目目录设计建议把脱敏模块作为独立的 Python 包放在项目中避免把检测和脱敏逻辑散落在业务代码里。privacy-guard/ ├── requirements.txt ├── config.yaml ├── guard/ │ ├── __init__.py │ ├── detector.py │ ├── masker.py │ ├── llm_client.py │ ├── pipeline.py │ └── audit.py ├── scripts/ │ └── run_demo.py └── tests/ ├── test_detector.py ├── test_masker.py └── test_pipeline.py目录设计的主要目的是让“检测器、脱敏器、模型客户端、审计日志”相互独立。这样在切换检测规则、更换模型服务、调整日志策略时不需要重写整套调用流程。4. 实现一个最小可运行的提示词脱敏模块4.1 定义敏感信息类型和检测器第一步是定义可扩展的敏感信息类型。为避免不同省份、不同运营商、不同业务系统的差异示例只保留通用规则。# guard/detector.py from dataclasses import dataclass from typing import List, Dict, Pattern import re dataclass class SensitiveSpan: type_name: str value: str start: int end: int SENSITIVE_RULES: Dict[str, str] { email: r[\w.-][\w-]\.[\w.-], phone: r(?!\d)\?[1-9]\d{7,14}(?!\d), api_key: r(?i)(sk-[A-Za-z0-9_\-]{20,}), ipv4: r\b(?:\d{1,3}\.){3}\d{1,3}\b, } class SensitiveInfoDetector: def __init__(self, rules: Dict[str, str] | None None): rules rules or SENSITIVE_RULES self._patterns: Dict[str, Pattern] { name: re.compile(pattern) for name, pattern in rules.items() } def detect(self, text: str) - List[SensitiveSpan]: spans: List[SensitiveSpan] [] for type_name, pattern in self._patterns.items(): for match in pattern.finditer(text): spans.append( SensitiveSpan( type_nametype_name, valuematch.group(0), startmatch.start(), endmatch.end(), ) ) return spans这里把规则以字典形式传入方便后续从config.yaml加载。需要注意多个规则可能匹配同一个字符串片段。例如 email 可能包含一段看起来像 IP 的内容两个规则都命中。生产环境要做重叠区间的去重处理最简单的方式是优先保留更敏感的类型。4.2 提示词脱敏处理器脱敏处理器的职责只有两个把原始 prompt 中的敏感内容替换成 token并维护 token 与原值的映射。# guard/masker.py from typing import Dict, List, Tuple from .detector import SensitiveInfoDetector, SensitiveSpan class PromptMasker: def __init__(self, detector: SensitiveInfoDetector): self.detector detector self.mapping: Dict[str, str] {} self._counter 0 def mask(self, text: str) - Tuple[str, Dict[str, str]]: spans self.detector.detect(text) spans sorted(spans, keylambda s: s.start) pieces [] cursor 0 mapping {} for span in spans: if span.start cursor: continue pieces.append(text[cursor: span.start]) token f[{span.type_name.upper()}_{self._counter}] mapping[token] span.value self.mapping[token] span.value self._counter 1 pieces.append(token) cursor span.end pieces.append(text[cursor:]) return .join(pieces), mapping def restore(self, text: str, unknown_token_policy: str ignore) - str: result text for token, value in self.mapping.items(): result result.replace(token, value) return result由于这里使用了span.start cursor来跳过重叠区间所以不用担心嵌套匹配导致替换错位。Mask 方法返回两个内容脱敏后的 prompt 和本次调用中新生成的映射。每次调用建议使用新的PromptMasker实例避免多个请求共享同一个映射表导致 token 串号。4.3 模型客户端与调用入口模型客户端不需要耦合脱敏逻辑它只负责接收脱敏后的 prompt并返回模型输出。# guard/llm_client.py import requests from typing import Optional class OpenAICompatibleClient: def __init__(self, base_url: str, api_key: str): self.base_url base_url.rstrip(/) self.api_key api_key def complete( self, prompt: str, model: str gpt-4o-mini, temperature: float 0.1, timeout: int 30, ) - str: url f{self.base_url}/chat/completions headers { Authorization: fBearer {self.api_key}, Content-Type: application/json, } payload { model: model, messages: [{role: user, content: prompt}], temperature: temperature, } response requests.post(url, headersheaders, jsonpayload, timeouttimeout) response.raise_for_status() data response.json() return data[choices][0][message][content]如果不方便连接真实模型可以先用 Mock 客户端验证链路。# guard/llm_client.py class MockLLMClient: def complete(self, prompt: str) - str: return 请将验证码发送到邮箱 [EMAIL_0]如果联系不上可以拨打 [PHONE_1]。调用入口可以把检测、脱敏、调用、还原封装成一个流程类。建议把“是否还原输出”做成配置项因为很多场景只需要模型根据脱敏内容完成分类、摘要或结构化抽取不需要把结果还原成原文。# guard/pipeline.py from dataclasses import dataclass, field from typing import Dict, Optional from .detector import SensitiveInfoDetector from .masker import PromptMasker from .llm_client import MockLLMClient dataclass class PrivacyGuardResult: original_prompt: str masked_prompt: str mapping: Dict[str, str] llm_response: str restored_response: str class PromptPrivacyGuard: def __init__( self, client, detector: SensitiveInfoDetector, restore_response: bool True, ): self.client client self.detector detector self.restore_response restore_response def process(self, prompt: str) - PrivacyGuardResult: masker PromptMasker(self.detector) masked_prompt, mapping masker.mask(prompt) llm_response self.client.complete(masked_prompt) restored_response if self.restore_response: restored_response masker.restore(llm_response) return PrivacyGuardResult( original_promptprompt, masked_promptmasked_prompt, mappingmapping, llm_responsellm_response, restored_responserestored_response, )这里没有把original_prompt写入日志也没有返回给任何非授权模块。PrivacyGuardResult中保留original_prompt是为了本地调试和测试生产环境建议改为只保留脱敏结果或哈希值。4.4 日志与审计记录日志是隐私保护最容易翻车的环节。不要以为业务代码没打印敏感信息就安全需要检查所有日志输出点。# guard/audit.py import json import logging logger logging.getLogger(privacy_guard) def write_audit_log(result, trace_id: str) - None: audit { trace_id: trace_id, masked_prompt: result.masked_prompt, llm_response: result.llm_response, token_count: len(result.mapping), restored: bool(result.restored_response), } logger.info(privacy_guard_audit: %s, json.dumps(audit, ensure_asciiTrue))审计日志中记录masked_prompt和llm_response但这不意味着可以完全放松。如果模型响应里出现了原始敏感信息这条日志本身也可能需要脱敏。更稳妥的做法是在写日志之前对llm_response再做一次敏感信息检测发现新敏感字段就只记录检测类型和数量不记录完整响应。5. 关键参数与配置说明5.1 脱敏策略配置示例把检测规则和策略抽成 YAML 配置能显著降低后续维护成本。# config.yaml sensitive_rules: email: [\\w.-][\\w-]\\.[\\w.-] phone: (?!\\d)\\?[1-9]\\d{7,14}(?!\\d) api_key: (?i)(sk-[A-Za-z0-9_\\-]{20,}) ipv4: \\b(?:\\d{1,3}\\.){3}\\d{1,3}\\b mask: default_strategy: token token_prefix: [ token_suffix: ] max_mapping_items: 100 restore: enabled: true unknown_token_policy: ignore audit: record_masked_prompt: true record_response: false配置文件中的sensitive_rules使用了 YAML 双引号包裹正则主要是因为反斜杠在 YAML 中需要转义。实际项目里也可以直接使用 JSON 或 Python 代码加载规则关键是规则不能散落在多个文件里。5.2 核心参数的影响与建议参数含义默认值推荐说明default_strategy默认脱敏策略token需要还原时选 token不需要时选 delete 或 generalizetoken_prefix/suffixtoken 前后缀[]建议使用业务中出现频率很低的字符例如__或{{ }}max_mapping_items单次请求最大脱敏数量100超过上限时应该拒绝执行而不是默默处理导致性能劣化restore.enabled是否还原模型输出true如果业务只需要模型判断结果关闭还原可以降低泄露风险unknown_token_policy遇到未识别 token 的行为ignore调试环境可以设为error生产环境通常用ignore并记录告警audit.record_response是否记录完整模型响应false建议只记录脱敏响应避免输出侧二次泄露max_mapping_items是一个容易被忽略的参数。如果用户一条 prompt 里包含几百个邮箱脱敏映射表会非常大既影响内存又可能在还原时产生性能问题。设置上限后超过上限的请求可以直接返回“请输入不超过 N 条用户信息”从源头限制高风险输入。5.3 映射关系的生命周期Token 与原始值的映射关系不能长期保留。建议遵循以下原则。如果映射只在单次请求内使用放在进程内存中请求结束后删除。如果映射需要跨请求使用必须加密保存并设置过期时间。映射关系不能写入 Redis 时使用原始可读 key建议使用请求 ID 作为 keyvalue 加密。映射关系的访问权限要受到严格控制不能允许任何内部查询直接读取。这里需要区分“token 化”和“匿名化”。Token 化是伪匿名化只要映射关系存在就仍然可能还原。真正的匿名化要求不可逆。因此即使在脱敏后调用模型也不能宣称数据已经“完全匿名”只能说降低了直接泄露的风险。6. 运行验证与结果分析6.1 用一段示例 prompt 验证完整流程编写一个演示脚本用一段包含邮箱和手机号的 prompt 调用完整流程。# scripts/run_demo.py from guard.detector import SensitiveInfoDetector, SENSITIVE_RULES from guard.llm_client import MockLLMClient from guard.pipeline import PromptPrivacyGuard def main(): detector SensitiveInfoDetector(SENSITIVE_RULES) client MockLLMClient() guard PromptPrivacyGuard(clientclient, detectordetector, restore_responseTrue) prompt ( 用户邮箱为 zhangsanexample.com 手机号是 13800138000 请生成一条包含联系方式的客服短信。 ) result guard.process(prompt) print(original_prompt:, result.original_prompt) print(masked_prompt:, result.masked_prompt) print(llm_response:, result.llm_response) print(restored_response:, result.restored_response) if __name__ __main__: main()运行后预期输出如下。original_prompt: 用户邮箱为 zhangsanexample.com手机号是 13800138000请生成一条包含联系方式的客服短信。 masked_prompt: 用户邮箱为 [EMAIL_0]手机号是 [PHONE_1]请生成一条包含联系方式的客服短信。 llm_response: 请将验证码发送到邮箱 [EMAIL_0]如果联系不上可以拨打 [PHONE_1]。 restored_response: 请将验证码发送到邮箱 zhangsanexample.com如果联系不上可以拨打 13800138000。注意Mock 客户端只是把 token 原样放进了响应里真实模型不一定会原样保留 token。模型可能改写为“你的邮箱”或“手机号”所以还原逻辑必须容忍 token 缺失。不要因为某个 token 没有出现就抛异常必要时给业务侧返回提示。6.2 如何评估脱敏效果脱敏模块上线前需要准备一批典型的业务 prompt 样本标注哪些片段是敏感信息。评估指标建议包括以下几项。指标含义理想结果准确率检测出的片段中真正敏感的比例越高越好误报太多会影响模型效果召回率样本中所有敏感片段被识别的比例越高越好漏报会造成隐私风险还原准确率模型输出中 token 被正确还原的比例尽量接近 100%平均耗时单次 prompt 处理耗时控制在业务容忍范围内日志泄露率抽样日志中出现明文敏感信息的比例0%评估时不能只看测试集上的准确率还要针对线上请求做定期抽样。因为业务新上线一个字段规则或 NER 模型很可能没有覆盖到。6.3 验证日志中不出现明文除了运行结果还要检查日志。用一个简单的测试用例验证脱敏前后都没有出现原始明文。# tests/test_pipeline.py from guard.detector import SensitiveInfoDetector, SENSITIVE_RULES from guard.llm_client import MockLLMClient from guard.pipeline import PromptPrivacyGuard def test_mask_and_restore(): detector SensitiveInfoDetector(SENSITIVE_RULES) client MockLLMClient() guard PromptPrivacyGuard(clientclient, detectordetector, restore_responseTrue) prompt 邮箱 zhangsanexample.com手机号 13800138000 result guard.process(prompt) assert zhangsanexample.com not in result.masked_prompt assert 13800138000 not in result.masked_prompt assert zhangsanexample.com in result.restored_response在真实项目中还应该增加一条审计测试检查写日志的 mock 对象没有收到包含明文的参数。7. 常见问题与排查路径7.1 脱敏后模型生成效果变差现象接入脱敏模块后模型输出的相关性下降生成内容开始泛泛而谈。排查思路检查脱敏后的 prompt 是否保留了足够的上下文结构。对比同一批 prompt 在脱敏前后的输出。查看被替换的字段数量是否已经超过正常比例。检查是否把模型本可以忽略的敏感信息也替换掉了。处理建议将固定替换改成 token 替换或泛化标签保留字段类型信息。例如把邮箱替换成[EMAIL_0]模型虽然不知道具体值但知道这里是一个邮箱实体。如果某类信息对模型回答没有帮助可以直接删除而不是替换。7.2 还原失败或还原错位现象模型返回文本中出现了 token但还原后没有替换成功或者替换到了错误位置。可能原因包括模型改写了 token比如把[EMAIL_0]改成了EMAIL_0或直接写成“邮箱”。同一条 prompt 中两个 token 内容相似模型混淆。还原时遍历映射表的顺序不稳定。模型输出是中间结果但业务侧使用了未还原前的文本。处理方式使用冲突概率更低的 token 格式例如__email_0__。还原时增加模糊匹配支持大小写差异和括号丢失。如果模型经常改写 token可以要求模型在输出中保留占位符使用更明确的指令。还原完成后进行人工抽查不能无条件信任自动还原结果。7.3 日志中仍然出现明文现象已经加了脱敏模块但日志系统里还是能看到原始邮箱、手机号或密钥。排查顺序搜索调用堆栈确认日志是在guard.process()之前还是之后打印的。检查是否有其他线程在未经过脱敏模块时直接读取了原始 prompt。检查模型响应日志确认restored_response是否被写入日志。检查配置中心里的日志级别是否开启了 debug 级请求体打印。检查链路追踪系统是否采集了 HTTP body。预防措施统一要求所有请求进入隐私保护网关禁止业务代码直接打印用户输入对日志系统做定期敏感信息扫描发现明文记录触发告警。7.4 检测器漏报或误报严重现象测试样本中大量邮箱没有识别到或者把普通文本错误识别为 IP 地址。排查路径核对正则是否与业务中真实字段格式一致。检查是否存在多行文本、空格、全角字符导致匹配失败。检查规则是否被config.yaml正确加载反斜杠是否需要转义。检查是否存在 span 重叠导致后一个 span 被跳过。增加 NER 模型后确认 NER 模型与正则规则是“或”的关系而不是互相覆盖。误报会让脱敏过度漏报则直接造成隐私风险。建议建立一个小型黄金样本集每次修改规则后都跑一遍回归测试。7.5 排查链路总结出现隐私问题时建议按照“输入是否先经过脱敏模块 - 脱敏后文本是否含明文 - 模型调用出口是否明文 - 响应是否二次脱敏 - 日志是否记录明文”的顺序排查。不要一上来就怀疑脱敏模块本身先确认数据到底是在哪一层“变成明文”的。8. 生产环境最佳实践与扩展方向8.1 将脱敏模块放在客户端还是统一网关脱敏模块放得越早数据离开业务边界的范围越小。如果条件允许建议在客户端或前端 SDK 先做第一层基础脱敏服务端网关再做第二层强制脱敏。客户端脱敏能减少数据上报到业务服务器的明文量但客户端不可信不能把客户端脱敏当作唯一防线。服务端必须对收到的所有 prompt 重新检测和脱敏。对于企业级应用推荐部署一个统一的 LLM 网关所有调用模型服务的请求都经过网关。网关负责脱敏、模型路由、限流、审计、数据脱敏策略下发。业务服务不直接持有模型 API Key也不直接拼接 prompt这样能防止某个业务模块因为写日志不规范而泄露数据。8.2 从正则规则升级到 NER 模型正则能处理格式固定的字段但处理人名、公司名、项目代号这类实体非常吃力。生产项目可以在检测器中加入一个基于 NER 的分支。常见实现方式是使用 spaCy 或 Presidio 的 PII Analyzer也可以训练自定义 NER 模型识别业务专有名词。# 伪代码仅说明接入思路 def detect_with_ner(text: str) - List[SensitiveSpan]: # 在现有正则检测后补充 NER 识别 # 对同一区间优先保留规则类型不同区间则合并排序 pass接入 NER 后需要额外关注模型体积和推理耗时。如果 NER 模型部署在 CPU 上单条 prompt 增加几十到几百毫秒是常见情况需要做超时控制和降级策略。如果 NER 服务不可用不能直接放行应该返回隐私保护模块异常。8.3 学习环境与生产环境的差异维度学习/演示环境生产环境敏感信息规则简单正则正则 NER 业务词典映射关系存储进程内字典加密存储使用 KMS 管理密钥日志记录可打印完整结果只记录脱敏字段和审计指标模型调用Mock 或本地模型统一网关、超时、重试、降级异常处理直接抛异常返回安全错误不泄露内部详情监控无脱敏数量、检测耗时、漏报告警密钥管理代码变量环境变量 KMS/Vault学习环境的核心目标是跑通链路所以可以直接使用进程内字典和 Mock 客户端。生产环境则要重点考虑映射关系如何加密、密钥谁来管理、审计日志如何长期保留、模型服务商的数据协议如何审查。8.4 扩展方向响应恢复控制、本地模型与数据分级提示词隐私保护并不是一次改造就结束的。后续可以往以下几个方向扩展。第一响应恢复控制。当前流程默认允许自动还原生产环境建议增加“敏感字段最小可见范围”配置。模型输出只有在业务明确需要时才能还原并且应记录谁在什么时间调用了还原接口。第二敏感字段的数据分级。企业内部可以把字段分为禁止输入、脱敏后输入、允许明文输入三类。例如 API Key 属于“禁止输入”用户名和邮箱属于“脱敏后输入”客服工单号这类业务数据可以结合权限允许明文输入。分级策略需要写进配置文件并在请求入口强制校验。第三本地模型部署。如果业务对数据出域要求很严格可以考虑把模型部署在私有化环境或私有网络内。本地部署不能替代脱敏因为日志、缓存、调试工具仍然可能泄露数据但可以减少第三方服务商带来的数据留存风险。第四引入数据分类分级审计。定期扫描线上日志、缓存、数据库和模型调用记录检查是否存在原始 prompt 明文。将脱敏模块接入审计平台让每一次脱敏和还原操作都可追踪。这样即使出现问题也可以在最短时间内定位到具体请求、具体链路段和具体责任人。提示词隐私保护的落地最终要落到“敏感信息可见范围可控制、可审计”这句话上。不要因为模型效果好而跳过脱敏也不要因为脱敏影响了一点效果就放弃整个机制。更合理的做法是分场景评估对只需要摘要和分类的 prompt 使用更高强度的脱敏对确实需要原文的少数场景单独走授权和审计流程。这样既能保留模型能力又不会让用户隐私裸奔。 LLM提示词隐私保护：从脱敏到审计的完整落地指南
提示词隐私Prompt Privacy在很多 LLM 应用里仍然被当成“用户输入加密”来对待这是一个普遍的误解。实际上提示词进入大模型前后的每一层都可能被记录、缓存、转发或用于后续统计单靠 TLS 和登录态并不能保证敏感信息不出现在不该出现的地方。要在项目中真正落地提示词隐私保护必须从敏感信息识别、脱敏替换、模型调用、结果还原、日志审计这条完整链路入手而不是只在前端把输入包一层加密。接下来这篇文章会沿着一条可复现的主线展开先梳理 LLM 场景下的隐私风险面再实现一个最小可运行的提示词脱敏与还原模块最后给出生产环境需要的配置、排错链路和最佳实践。适合正在开发对话机器人、智能客服、文档分析、企业知识库等场景的后端工程师也适合刚开始把大模型接入业务系统的技术负责人。1. 先理解 LLM 应用中的提示词隐私风险面1.1 LLM 提示词隐私不只是“用户输入”的隐私传统服务端应用通常只需要保证输入数据在存储时不泄露、在传输时不被截获。LLM 应用多了一层特殊之处原始提示词会被组合成请求发送给模型服务模型输出又可能引用或推断出输入中的敏感内容。也就是说隐私风险不只存在于用户输入那一刻而是覆盖从输入采集、组装 prompt、调用模型、接收响应、记录日志到缓存结果的整个生命周期。日常开发中常见的风险有两种。第一种是“不知道敏感信息在哪个环节被落盘”。应用日志、网关日志、链路追踪系统、消息队列、Redis 缓存都可能保存完整请求体只要其中任何一个环节记录了原始 prompt隐私保护就已经失效。第二种是“把脱敏和加密混为一谈”。对 prompt 做全量加密后再发给模型模型无法理解内容业务上用不了只做网络加密服务端记录明文日志又等于白做。提示词隐私保护的核心目标不是让所有敏感信息永远不出现而是让敏感信息只出现在被允许出现的地方。允许出现的位置包括业务处理内存、用户授权范围内的存储、明确的模型调用出口不允许出现的位置包括无关联的日志、缓存、监控采样、调试输出和第三方非授权系统。1.2 典型风险面应该按请求链路逐层排查在设计保护方案之前先把一条 LLM 请求可能经过的环节列出来更容易确定该在哪里加控制。实际项目中典型的风险面如下表。风险面说明常见触发场景客户端采集页面或客户端把用户输入原样保存到本地前端埋点、浏览器本地缓存、剪贴板记录传输链路prompt 在网络传输过程中被中继设备记录未开启 TLS、经过调试代理、内网网关转发应用日志服务端打印请求参数用于排错logger.info(prompt%s, prompt)第三方模型服务请求体发送到外部模型服务可能被服务端记录或保留使用公网大模型 API未确认数据处理策略模型输出模型可能复述或推导出敏感信息提示词包含 key模型在回复中重复该 key中间件缓存缓存层保存完整 prompt 或完整响应Redis 缓存命中结果缓存 key 或 value 含原文监控与审计APM、链路追踪采集 HTTP body采样器默认采集请求和响应体从表格可以看出即使只保护“用户输入”这一端中间经过的组件仍然可能泄露数据。因此提示词隐私保护方案要按请求链路设计而不仅是按某一个函数设计。1.3 隐私保护与模型效果之间存在取舍一个让很多团队困惑的问题是脱敏之后模型效果变差了。原因在于大模型依赖上下文理解实体之间的关系把“张三”替换成“A”把“zhangsanexample.com”替换成[EMAIL_0]模型仍然可能理解这是某个人的邮箱。但如果把整句话删除或完全 mask模型丢失了必要语义生成结果自然不可控。正确思路不是追求把所有敏感字段全部替换掉而是根据业务场景选择“最小必须可见”原则。对于模型回答不需要知道明文的内容直接脱敏或删除对于模型回答需要引用或操作的内容使用可还原的 token 替换对于模型只需要知道大类的字段使用泛化标签例如[EMAIL]、[PHONE]、[DATE]。所以提示词隐私保护方案必须可配置不能写死一套规则。不同业务、不同阶段、不同模型能力下需要调整的通常不是“是否保护”而是“保护到什么程度”。2. 提示词隐私保护的整体链路与方案选型2.1 推荐主链路识别、替换、调用、还原、审计一个可落地的提示词隐私保护模块可以按照下面的链路设计。在进入业务逻辑之前扫描原始 prompt识别其中的敏感信息。对识别出的敏感信息执行脱敏策略默认使用 token 替换生成脱敏后的 prompt。将 token 与原始值的映射关系保存在短期、受控的内存存储中。把脱敏后的 prompt 发送给大模型服务。对模型返回结果再次做敏感信息扫描防止模型在回复中编造或泄露新的敏感字段。根据业务需要决定是否还原 token或者只保留脱敏结果。记录审计日志但日志中只保存脱敏后的 prompt、模型响应摘要和脱敏数量。这个链路的关键点是“先识别再替换后调用”。如果顺序颠倒先调用再脱敏敏感信息已经到达了模型服务端风险已经扩张到外部。2.2 脱敏策略选型token、泛化、删除、加密不同敏感字段适合不同的处理方式。不要对全部字段使用同一种策略。策略示例适用场景注意事项Token 替换zhangsanexample.com-[EMAIL_0]模型输出需要引用原值业务允许临时保存映射映射关系要短期保存并及时销毁泛化标签13800138000-[PHONE]模型只需要知道字段类型不需要具体值无法还原但安全性高固定替换username-user测试环境、调试环境容易丢失多条数据的区分度删除sk-123456...- API Key、Token、密码删除后模型输出不会引用但可能影响语义加密映射表用 AES 加密后持久化需要跨请求还原或需要临时落盘密钥要放入 KMS不要写死在代码里Token 替换是最推荐的默认策略因为它既保留了“这段内容是一个实体”的结构又让模型无法直接看到真实值。但 token 不是加密token 与原始值的映射关系一旦泄露同样会暴露数据。因此映射关系的生命周期要尽量短并且不能写入普通日志。2.3 需要重点保护的数据类型与检测规则需要保护的数据类型需要结合业务场景界定。常见类型至少有这些。数据类型示例推荐策略说明邮箱zhangsanexample.comtoken 替换正则规则简单但容易误收ab手机号86 13800138000token 替换或泛化不同国家格式不同需要按区域配置证件号110101199001011234删除或泛化结构复杂建议只保留区段API Keysk-abcdefghijklmn...删除绝不能发送给无关模型IP 地址10.20.30.40泛化或删除内网 IP 也要保护用户名zhangsan泛化需要借助词表或 NER正则难以覆盖内部系统名order-db-prod泛化可能需要业务词典参与识别日期时间2025-06-18 12:00:00按需脱敏有些业务需要日期有些不需要正则适合处理格式固定的字段比如邮箱、手机号、常见密钥前缀。人名、地名、公司名这类实体则需要借助命名实体识别NER模型或自定义业务词典。实际生产项目通常采用“正则规则 NER 模型 业务词表”三层结合才能控制漏报和误报。3. 环境准备与项目结构3.1 开发环境要求下面实现一个最小可运行的提示词脱敏与还原模块使用 Python 3.9 以上版本。示例采用标准库re、dataclasses外部 HTTP 调用使用requests。如果只跑本地 mock 演示连requests都可以不装。依赖版本建议用途Python3.9运行环境requests2.31调用兼容 OpenAI 协议的模型服务cryptography41.0可选用于映射关系加密pytest7.x可选运行测试这里没有写死某个大模型 SDK 的版本因为不同项目接入的模型服务不同。落地前需要确认你使用的模型服务地址、协议版本和 SDK 版本不要盲目使用最新版优先使用项目中已经锁定的版本。3.2 项目目录设计建议把脱敏模块作为独立的 Python 包放在项目中避免把检测和脱敏逻辑散落在业务代码里。privacy-guard/ ├── requirements.txt ├── config.yaml ├── guard/ │ ├── __init__.py │ ├── detector.py │ ├── masker.py │ ├── llm_client.py │ ├── pipeline.py │ └── audit.py ├── scripts/ │ └── run_demo.py └── tests/ ├── test_detector.py ├── test_masker.py └── test_pipeline.py目录设计的主要目的是让“检测器、脱敏器、模型客户端、审计日志”相互独立。这样在切换检测规则、更换模型服务、调整日志策略时不需要重写整套调用流程。4. 实现一个最小可运行的提示词脱敏模块4.1 定义敏感信息类型和检测器第一步是定义可扩展的敏感信息类型。为避免不同省份、不同运营商、不同业务系统的差异示例只保留通用规则。# guard/detector.py from dataclasses import dataclass from typing import List, Dict, Pattern import re dataclass class SensitiveSpan: type_name: str value: str start: int end: int SENSITIVE_RULES: Dict[str, str] { email: r[\w.-][\w-]\.[\w.-], phone: r(?!\d)\?[1-9]\d{7,14}(?!\d), api_key: r(?i)(sk-[A-Za-z0-9_\-]{20,}), ipv4: r\b(?:\d{1,3}\.){3}\d{1,3}\b, } class SensitiveInfoDetector: def __init__(self, rules: Dict[str, str] | None None): rules rules or SENSITIVE_RULES self._patterns: Dict[str, Pattern] { name: re.compile(pattern) for name, pattern in rules.items() } def detect(self, text: str) - List[SensitiveSpan]: spans: List[SensitiveSpan] [] for type_name, pattern in self._patterns.items(): for match in pattern.finditer(text): spans.append( SensitiveSpan( type_nametype_name, valuematch.group(0), startmatch.start(), endmatch.end(), ) ) return spans这里把规则以字典形式传入方便后续从config.yaml加载。需要注意多个规则可能匹配同一个字符串片段。例如 email 可能包含一段看起来像 IP 的内容两个规则都命中。生产环境要做重叠区间的去重处理最简单的方式是优先保留更敏感的类型。4.2 提示词脱敏处理器脱敏处理器的职责只有两个把原始 prompt 中的敏感内容替换成 token并维护 token 与原值的映射。# guard/masker.py from typing import Dict, List, Tuple from .detector import SensitiveInfoDetector, SensitiveSpan class PromptMasker: def __init__(self, detector: SensitiveInfoDetector): self.detector detector self.mapping: Dict[str, str] {} self._counter 0 def mask(self, text: str) - Tuple[str, Dict[str, str]]: spans self.detector.detect(text) spans sorted(spans, keylambda s: s.start) pieces [] cursor 0 mapping {} for span in spans: if span.start cursor: continue pieces.append(text[cursor: span.start]) token f[{span.type_name.upper()}_{self._counter}] mapping[token] span.value self.mapping[token] span.value self._counter 1 pieces.append(token) cursor span.end pieces.append(text[cursor:]) return .join(pieces), mapping def restore(self, text: str, unknown_token_policy: str ignore) - str: result text for token, value in self.mapping.items(): result result.replace(token, value) return result由于这里使用了span.start cursor来跳过重叠区间所以不用担心嵌套匹配导致替换错位。Mask 方法返回两个内容脱敏后的 prompt 和本次调用中新生成的映射。每次调用建议使用新的PromptMasker实例避免多个请求共享同一个映射表导致 token 串号。4.3 模型客户端与调用入口模型客户端不需要耦合脱敏逻辑它只负责接收脱敏后的 prompt并返回模型输出。# guard/llm_client.py import requests from typing import Optional class OpenAICompatibleClient: def __init__(self, base_url: str, api_key: str): self.base_url base_url.rstrip(/) self.api_key api_key def complete( self, prompt: str, model: str gpt-4o-mini, temperature: float 0.1, timeout: int 30, ) - str: url f{self.base_url}/chat/completions headers { Authorization: fBearer {self.api_key}, Content-Type: application/json, } payload { model: model, messages: [{role: user, content: prompt}], temperature: temperature, } response requests.post(url, headersheaders, jsonpayload, timeouttimeout) response.raise_for_status() data response.json() return data[choices][0][message][content]如果不方便连接真实模型可以先用 Mock 客户端验证链路。# guard/llm_client.py class MockLLMClient: def complete(self, prompt: str) - str: return 请将验证码发送到邮箱 [EMAIL_0]如果联系不上可以拨打 [PHONE_1]。调用入口可以把检测、脱敏、调用、还原封装成一个流程类。建议把“是否还原输出”做成配置项因为很多场景只需要模型根据脱敏内容完成分类、摘要或结构化抽取不需要把结果还原成原文。# guard/pipeline.py from dataclasses import dataclass, field from typing import Dict, Optional from .detector import SensitiveInfoDetector from .masker import PromptMasker from .llm_client import MockLLMClient dataclass class PrivacyGuardResult: original_prompt: str masked_prompt: str mapping: Dict[str, str] llm_response: str restored_response: str class PromptPrivacyGuard: def __init__( self, client, detector: SensitiveInfoDetector, restore_response: bool True, ): self.client client self.detector detector self.restore_response restore_response def process(self, prompt: str) - PrivacyGuardResult: masker PromptMasker(self.detector) masked_prompt, mapping masker.mask(prompt) llm_response self.client.complete(masked_prompt) restored_response if self.restore_response: restored_response masker.restore(llm_response) return PrivacyGuardResult( original_promptprompt, masked_promptmasked_prompt, mappingmapping, llm_responsellm_response, restored_responserestored_response, )这里没有把original_prompt写入日志也没有返回给任何非授权模块。PrivacyGuardResult中保留original_prompt是为了本地调试和测试生产环境建议改为只保留脱敏结果或哈希值。4.4 日志与审计记录日志是隐私保护最容易翻车的环节。不要以为业务代码没打印敏感信息就安全需要检查所有日志输出点。# guard/audit.py import json import logging logger logging.getLogger(privacy_guard) def write_audit_log(result, trace_id: str) - None: audit { trace_id: trace_id, masked_prompt: result.masked_prompt, llm_response: result.llm_response, token_count: len(result.mapping), restored: bool(result.restored_response), } logger.info(privacy_guard_audit: %s, json.dumps(audit, ensure_asciiTrue))审计日志中记录masked_prompt和llm_response但这不意味着可以完全放松。如果模型响应里出现了原始敏感信息这条日志本身也可能需要脱敏。更稳妥的做法是在写日志之前对llm_response再做一次敏感信息检测发现新敏感字段就只记录检测类型和数量不记录完整响应。5. 关键参数与配置说明5.1 脱敏策略配置示例把检测规则和策略抽成 YAML 配置能显著降低后续维护成本。# config.yaml sensitive_rules: email: [\\w.-][\\w-]\\.[\\w.-] phone: (?!\\d)\\?[1-9]\\d{7,14}(?!\\d) api_key: (?i)(sk-[A-Za-z0-9_\\-]{20,}) ipv4: \\b(?:\\d{1,3}\\.){3}\\d{1,3}\\b mask: default_strategy: token token_prefix: [ token_suffix: ] max_mapping_items: 100 restore: enabled: true unknown_token_policy: ignore audit: record_masked_prompt: true record_response: false配置文件中的sensitive_rules使用了 YAML 双引号包裹正则主要是因为反斜杠在 YAML 中需要转义。实际项目里也可以直接使用 JSON 或 Python 代码加载规则关键是规则不能散落在多个文件里。5.2 核心参数的影响与建议参数含义默认值推荐说明default_strategy默认脱敏策略token需要还原时选 token不需要时选 delete 或 generalizetoken_prefix/suffixtoken 前后缀[]建议使用业务中出现频率很低的字符例如__或{{ }}max_mapping_items单次请求最大脱敏数量100超过上限时应该拒绝执行而不是默默处理导致性能劣化restore.enabled是否还原模型输出true如果业务只需要模型判断结果关闭还原可以降低泄露风险unknown_token_policy遇到未识别 token 的行为ignore调试环境可以设为error生产环境通常用ignore并记录告警audit.record_response是否记录完整模型响应false建议只记录脱敏响应避免输出侧二次泄露max_mapping_items是一个容易被忽略的参数。如果用户一条 prompt 里包含几百个邮箱脱敏映射表会非常大既影响内存又可能在还原时产生性能问题。设置上限后超过上限的请求可以直接返回“请输入不超过 N 条用户信息”从源头限制高风险输入。5.3 映射关系的生命周期Token 与原始值的映射关系不能长期保留。建议遵循以下原则。如果映射只在单次请求内使用放在进程内存中请求结束后删除。如果映射需要跨请求使用必须加密保存并设置过期时间。映射关系不能写入 Redis 时使用原始可读 key建议使用请求 ID 作为 keyvalue 加密。映射关系的访问权限要受到严格控制不能允许任何内部查询直接读取。这里需要区分“token 化”和“匿名化”。Token 化是伪匿名化只要映射关系存在就仍然可能还原。真正的匿名化要求不可逆。因此即使在脱敏后调用模型也不能宣称数据已经“完全匿名”只能说降低了直接泄露的风险。6. 运行验证与结果分析6.1 用一段示例 prompt 验证完整流程编写一个演示脚本用一段包含邮箱和手机号的 prompt 调用完整流程。# scripts/run_demo.py from guard.detector import SensitiveInfoDetector, SENSITIVE_RULES from guard.llm_client import MockLLMClient from guard.pipeline import PromptPrivacyGuard def main(): detector SensitiveInfoDetector(SENSITIVE_RULES) client MockLLMClient() guard PromptPrivacyGuard(clientclient, detectordetector, restore_responseTrue) prompt ( 用户邮箱为 zhangsanexample.com 手机号是 13800138000 请生成一条包含联系方式的客服短信。 ) result guard.process(prompt) print(original_prompt:, result.original_prompt) print(masked_prompt:, result.masked_prompt) print(llm_response:, result.llm_response) print(restored_response:, result.restored_response) if __name__ __main__: main()运行后预期输出如下。original_prompt: 用户邮箱为 zhangsanexample.com手机号是 13800138000请生成一条包含联系方式的客服短信。 masked_prompt: 用户邮箱为 [EMAIL_0]手机号是 [PHONE_1]请生成一条包含联系方式的客服短信。 llm_response: 请将验证码发送到邮箱 [EMAIL_0]如果联系不上可以拨打 [PHONE_1]。 restored_response: 请将验证码发送到邮箱 zhangsanexample.com如果联系不上可以拨打 13800138000。注意Mock 客户端只是把 token 原样放进了响应里真实模型不一定会原样保留 token。模型可能改写为“你的邮箱”或“手机号”所以还原逻辑必须容忍 token 缺失。不要因为某个 token 没有出现就抛异常必要时给业务侧返回提示。6.2 如何评估脱敏效果脱敏模块上线前需要准备一批典型的业务 prompt 样本标注哪些片段是敏感信息。评估指标建议包括以下几项。指标含义理想结果准确率检测出的片段中真正敏感的比例越高越好误报太多会影响模型效果召回率样本中所有敏感片段被识别的比例越高越好漏报会造成隐私风险还原准确率模型输出中 token 被正确还原的比例尽量接近 100%平均耗时单次 prompt 处理耗时控制在业务容忍范围内日志泄露率抽样日志中出现明文敏感信息的比例0%评估时不能只看测试集上的准确率还要针对线上请求做定期抽样。因为业务新上线一个字段规则或 NER 模型很可能没有覆盖到。6.3 验证日志中不出现明文除了运行结果还要检查日志。用一个简单的测试用例验证脱敏前后都没有出现原始明文。# tests/test_pipeline.py from guard.detector import SensitiveInfoDetector, SENSITIVE_RULES from guard.llm_client import MockLLMClient from guard.pipeline import PromptPrivacyGuard def test_mask_and_restore(): detector SensitiveInfoDetector(SENSITIVE_RULES) client MockLLMClient() guard PromptPrivacyGuard(clientclient, detectordetector, restore_responseTrue) prompt 邮箱 zhangsanexample.com手机号 13800138000 result guard.process(prompt) assert zhangsanexample.com not in result.masked_prompt assert 13800138000 not in result.masked_prompt assert zhangsanexample.com in result.restored_response在真实项目中还应该增加一条审计测试检查写日志的 mock 对象没有收到包含明文的参数。7. 常见问题与排查路径7.1 脱敏后模型生成效果变差现象接入脱敏模块后模型输出的相关性下降生成内容开始泛泛而谈。排查思路检查脱敏后的 prompt 是否保留了足够的上下文结构。对比同一批 prompt 在脱敏前后的输出。查看被替换的字段数量是否已经超过正常比例。检查是否把模型本可以忽略的敏感信息也替换掉了。处理建议将固定替换改成 token 替换或泛化标签保留字段类型信息。例如把邮箱替换成[EMAIL_0]模型虽然不知道具体值但知道这里是一个邮箱实体。如果某类信息对模型回答没有帮助可以直接删除而不是替换。7.2 还原失败或还原错位现象模型返回文本中出现了 token但还原后没有替换成功或者替换到了错误位置。可能原因包括模型改写了 token比如把[EMAIL_0]改成了EMAIL_0或直接写成“邮箱”。同一条 prompt 中两个 token 内容相似模型混淆。还原时遍历映射表的顺序不稳定。模型输出是中间结果但业务侧使用了未还原前的文本。处理方式使用冲突概率更低的 token 格式例如__email_0__。还原时增加模糊匹配支持大小写差异和括号丢失。如果模型经常改写 token可以要求模型在输出中保留占位符使用更明确的指令。还原完成后进行人工抽查不能无条件信任自动还原结果。7.3 日志中仍然出现明文现象已经加了脱敏模块但日志系统里还是能看到原始邮箱、手机号或密钥。排查顺序搜索调用堆栈确认日志是在guard.process()之前还是之后打印的。检查是否有其他线程在未经过脱敏模块时直接读取了原始 prompt。检查模型响应日志确认restored_response是否被写入日志。检查配置中心里的日志级别是否开启了 debug 级请求体打印。检查链路追踪系统是否采集了 HTTP body。预防措施统一要求所有请求进入隐私保护网关禁止业务代码直接打印用户输入对日志系统做定期敏感信息扫描发现明文记录触发告警。7.4 检测器漏报或误报严重现象测试样本中大量邮箱没有识别到或者把普通文本错误识别为 IP 地址。排查路径核对正则是否与业务中真实字段格式一致。检查是否存在多行文本、空格、全角字符导致匹配失败。检查规则是否被config.yaml正确加载反斜杠是否需要转义。检查是否存在 span 重叠导致后一个 span 被跳过。增加 NER 模型后确认 NER 模型与正则规则是“或”的关系而不是互相覆盖。误报会让脱敏过度漏报则直接造成隐私风险。建议建立一个小型黄金样本集每次修改规则后都跑一遍回归测试。7.5 排查链路总结出现隐私问题时建议按照“输入是否先经过脱敏模块 - 脱敏后文本是否含明文 - 模型调用出口是否明文 - 响应是否二次脱敏 - 日志是否记录明文”的顺序排查。不要一上来就怀疑脱敏模块本身先确认数据到底是在哪一层“变成明文”的。8. 生产环境最佳实践与扩展方向8.1 将脱敏模块放在客户端还是统一网关脱敏模块放得越早数据离开业务边界的范围越小。如果条件允许建议在客户端或前端 SDK 先做第一层基础脱敏服务端网关再做第二层强制脱敏。客户端脱敏能减少数据上报到业务服务器的明文量但客户端不可信不能把客户端脱敏当作唯一防线。服务端必须对收到的所有 prompt 重新检测和脱敏。对于企业级应用推荐部署一个统一的 LLM 网关所有调用模型服务的请求都经过网关。网关负责脱敏、模型路由、限流、审计、数据脱敏策略下发。业务服务不直接持有模型 API Key也不直接拼接 prompt这样能防止某个业务模块因为写日志不规范而泄露数据。8.2 从正则规则升级到 NER 模型正则能处理格式固定的字段但处理人名、公司名、项目代号这类实体非常吃力。生产项目可以在检测器中加入一个基于 NER 的分支。常见实现方式是使用 spaCy 或 Presidio 的 PII Analyzer也可以训练自定义 NER 模型识别业务专有名词。# 伪代码仅说明接入思路 def detect_with_ner(text: str) - List[SensitiveSpan]: # 在现有正则检测后补充 NER 识别 # 对同一区间优先保留规则类型不同区间则合并排序 pass接入 NER 后需要额外关注模型体积和推理耗时。如果 NER 模型部署在 CPU 上单条 prompt 增加几十到几百毫秒是常见情况需要做超时控制和降级策略。如果 NER 服务不可用不能直接放行应该返回隐私保护模块异常。8.3 学习环境与生产环境的差异维度学习/演示环境生产环境敏感信息规则简单正则正则 NER 业务词典映射关系存储进程内字典加密存储使用 KMS 管理密钥日志记录可打印完整结果只记录脱敏字段和审计指标模型调用Mock 或本地模型统一网关、超时、重试、降级异常处理直接抛异常返回安全错误不泄露内部详情监控无脱敏数量、检测耗时、漏报告警密钥管理代码变量环境变量 KMS/Vault学习环境的核心目标是跑通链路所以可以直接使用进程内字典和 Mock 客户端。生产环境则要重点考虑映射关系如何加密、密钥谁来管理、审计日志如何长期保留、模型服务商的数据协议如何审查。8.4 扩展方向响应恢复控制、本地模型与数据分级提示词隐私保护并不是一次改造就结束的。后续可以往以下几个方向扩展。第一响应恢复控制。当前流程默认允许自动还原生产环境建议增加“敏感字段最小可见范围”配置。模型输出只有在业务明确需要时才能还原并且应记录谁在什么时间调用了还原接口。第二敏感字段的数据分级。企业内部可以把字段分为禁止输入、脱敏后输入、允许明文输入三类。例如 API Key 属于“禁止输入”用户名和邮箱属于“脱敏后输入”客服工单号这类业务数据可以结合权限允许明文输入。分级策略需要写进配置文件并在请求入口强制校验。第三本地模型部署。如果业务对数据出域要求很严格可以考虑把模型部署在私有化环境或私有网络内。本地部署不能替代脱敏因为日志、缓存、调试工具仍然可能泄露数据但可以减少第三方服务商带来的数据留存风险。第四引入数据分类分级审计。定期扫描线上日志、缓存、数据库和模型调用记录检查是否存在原始 prompt 明文。将脱敏模块接入审计平台让每一次脱敏和还原操作都可追踪。这样即使出现问题也可以在最短时间内定位到具体请求、具体链路段和具体责任人。提示词隐私保护的落地最终要落到“敏感信息可见范围可控制、可审计”这句话上。不要因为模型效果好而跳过脱敏也不要因为脱敏影响了一点效果就放弃整个机制。更合理的做法是分场景评估对只需要摘要和分类的 prompt 使用更高强度的脱敏对确实需要原文的少数场景单独走授权和审计流程。这样既能保留模型能力又不会让用户隐私裸奔。