敏感内容红线：涉密文档不上公共 AI，脱敏处理后再考虑上传

一、问题的起点：为什么“上传”等于“出域”

很多团队对“涉密文档不上公共AI”的理解停留在“别把机密文件粘进去”。但在工程视角下，真正的风险边界不是“文件是否被保存”，而是数据是否离开了你的可控域。一旦文本通过网络进入第三方推理服务，它就跨越了组织安全边界，进入一个你无法审计、无法删除、无法回滚的外部环境。

这里需要区分三个常被混淆的概念：数据出域（data egress）、数据留存（data retention）与数据复用（data reuse）。出域是动作，留存是状态，复用是后果。多数公共AI服务的用户协议会声明“不用于训练”，但这并不等于“不记录、不缓存、不用于安全审查”。笔者认为，把合规判断建立在“厂商承诺”之上是脆弱的，工程上应当默认任何离开内网的明文都可能被持久化，并据此设计防线。

1.1 一个被低估的事实：提示词本身就是数据

在检索增强生成（RAG）与长上下文场景下，用户往往把整段文档作为上下文输入。此时“提示词”不再是简单的指令，而是承载了完整业务信息的载体。根据OWASP 2025年发布的《Top 10 for LLM Applications》，提示注入（LLM01）与敏感信息泄露（LLM02）连续两年位列前十，其中敏感信息泄露的核心诱因正是“用户将未脱敏数据直接送入模型上下文”。（来源：OWASP GenAI Security Project, 2025）

本文评述：OWASP的这份清单价值在于把“提示词”当作攻击面来对待，但它偏重应用层，对“数据出域后的不可控性”着墨不多。工程团队需要补上这一环——把每一次外部推理调用都视为一次数据出境申报。

1.2 红线不是“机密”两个字，而是可识别性

很多团队只盯着“密级”标签，却忽略了可识别性（identifiability）才是脱敏的真正标尺。一段文本即使没有“机密”字样，只要包含可定位到具体自然人、具体项目、具体交易的信息，就构成敏感数据。欧盟GDPR第4条对“个人数据”的定义、我国《个人信息保护法》第4条对“个人信息”的界定，都指向同一个核心：能否关联到特定个体。

因此，“涉密文档不上公共AI”应当扩展为一条更严格的操作红线：任何可识别到个体、组织、项目或交易的信息，在未脱敏前不得进入公共推理接口。这条红线与密级无关，与数据本身的关联能力有关。

二、公共AI的数据生命周期与泄露机理

要设计有效的脱敏方案，必须先理解数据在公共AI服务中会经历哪些环节。下图给出一个典型的生命周期模型（本文整理，基于多家厂商公开文档与学术研究综合绘制，属整合模型，非单一来源）。

[用户终端] → [网络传输 TLS] → [API 网关/负载均衡]
      → [内容审核/安全过滤] → [推理集群(可能缓存 KV)]
      → [日志与监控] → [留存策略(0~30天不等)]
      → [可选:人工审核/标注] → [可选:训练数据回流]

2.1 传输层：TLS 保护的是通道，不是内容

TLS 1.3 能防止中间人窃听，但它对服务端是“透明”的。数据到达推理集群后以明文形式存在于内存中，供模型前向计算使用。这意味着传输加密解决的是“路上安全”，不解决“落地安全”。

2.2 推理层：KV Cache 与上下文残留

Transformer 推理过程中，键值缓存（KV Cache）会保存上下文的中间表示。在多租户共享的推理集群中，若缓存隔离不严，理论上存在跨请求信息残留的风险。2024年发表的“Prompt Leakage”相关研究指出，通过精心构造的提示，攻击者可在特定条件下诱导模型复现上下文片段（来源：Hui et al., "Prompt Leakage in Large Language Models", arXiv:2405.xxxxx 系列研究综述，2024）。

本文评述：这类攻击的实际成功率受模型架构、服务实现与温度参数影响较大，不宜夸大。但它揭示了一个工程事实——只要明文进入推理上下文，就存在被复现的可能。因此脱敏必须发生在“进入上下文之前”，而非之后。

2.3 日志层：最容易被忽视的泄露面

多数服务会记录请求日志用于计费、风控与调试。日志中可能包含完整提示词。根据IBM《Cost of a Data Breach Report 2024》，全球数据泄露平均成本达到488万美元，其中“云环境与第三方服务”是主要增长点之一（来源：IBM Security, 2024）。

从上表可见，越靠后的环节，用户可控性越低。这正是“脱敏前置”原则的工程依据：把控制点放在数据离开终端之前。

三、国内外合规框架与红线边界

脱敏不是技术洁癖，而是合规刚需。本节梳理主要法域的要求，并给出可映射到工程动作的边界。

3.1 中国：数据出境与保密双重约束

《数据安全法》《个人信息保护法》《数据出境安全评估办法》构成三层约束。其中，《促进和规范数据跨境流动规定》（2024年3月发布）进一步明确了豁免与评估情形。对于涉密信息，《保守国家秘密法》及其实施条例明确禁止在非涉密信息系统、非涉密载体中处理国家秘密。

笔者认为，工程团队最容易踩的坑是“把内部敏感数据当成普通数据”。内部项目代号、未公开财务数据、客户名单，虽未必构成国家秘密，但一旦出境可能触发商业秘密与个人信息双重风险。

3.2 欧盟：GDPR 与 AI Act 的叠加

GDPR 第5条确立“数据最小化”与“目的限制”原则；第25条要求“通过设计与默认实现数据保护”。欧盟《人工智能法案》（AI Act，2024年生效）对通用目的AI提出透明度与风险管理要求。两者叠加意味着：向公共AI传输个人数据，必须同时满足合法性基础与最小化原则。

3.3 美国：行业监管与州法并行

联邦层面以NIST AI RMF（AI风险管理框架，2023年发布，2024年持续更新配套文件）为代表，提供自愿性框架；州层面以加州CCPA/CPRA、科罗拉多州AI法案等为代表。NIST AI RMF 的“MAP-MEASURE-MANAGE”循环对脱敏工程有直接参考价值。

本文评述：合规文件给出的是“目标状态”，而工程需要的是“过程控制”。把法条翻译成可执行动作，是脱敏工程化的第一步。例如“数据最小化”对应到工程就是“只上传必要字段，且字段级脱敏”。

四、脱敏技术栈：从规则到模型

脱敏技术并非新事物，但LLM场景带来了新挑战：文本非结构化、语义依赖强、上下文长。本节按“规则—统计—模型—生成”四层递进梳理技术栈。

4.1 规则层：正则与词典

正则表达式适合处理身份证号、手机号、银行卡号、邮箱等强模式数据。词典匹配适合机构名、项目代号、人名。优点是快、可解释、易审计；缺点是覆盖有限、易漏。

# 示例：中国手机号正则（简化）
import re
PHONE = re.compile(r'(?<!\d)1[3-9]\d{9}(?!\d)')
text = PHONE.sub('[PHONE]', text)

4.2 统计层：命名实体识别（NER）

基于预训练模型的NER可识别人名、地名、机构名、时间、金额等。中文NER常用模型包括BERT-BiLSTM-CRF系列。根据CLUENER2020等中文基准，主流模型F1可达0.78~0.82区间（来源：CLUENER2020基准论文及后续改进研究，2020-2024）。

本文评述：NER的召回率是脱敏的生命线。工程上应把NER作为“候选生成器”，再用规则做“兜底校验”，形成双通道。

4.3 模型层：领域微调与提示工程

通用NER对行业术语识别有限。可用少量标注数据对模型做领域微调，或使用LLM本身做“脱敏助手”。后者需注意：如果用公共LLM做脱敏，等于先把敏感数据送出去了，因此必须使用本地部署模型。

4.4 生成层：合成替换与格式保持

脱敏后文本若完全变成占位符，会破坏语义，影响AI回答质量。因此需要“格式保持的合成替换”：把“张三”替换为“李四”，把“2024年3月”替换为“2023年7月”，保持类型与结构一致。这被称为“格式保持加密/替换”（format-preserving pseudonymization）。

五、工程化落地：分级流程与操作步骤

本节给出一条可直接落地的流水线。核心思想是分级管控、逐级脱敏、人工兜底。

5.1 数据分级：四级模型

1. L1 公开级：已公开发布，可直接上传。
2. L2 内部级：内部可见，脱敏后可上传。
3. L3 敏感级：含个人信息或商业秘密，强脱敏+审批后上传。
4. L4 涉密级：禁止上传，仅限本地环境处理。

5.2 操作步骤：七步流水线

Step 1 分类分级 → Step 2 字段裁剪 → Step 3 实体识别
→ Step 4 替换/泛化 → Step 5 一致性校验 → Step 6 人工复核
→ Step 7 审计留痕 → 上传

每一步都应有明确输入输出与责任人。其中 Step 6 人工复核是很多团队省略却最不该省略的一环。自动化脱敏的漏检率在复杂文本中仍不可忽略，人工抽检是最后防线。

5.3 一致性维护：映射表管理

同一文档中“张三”多次出现，替换后必须保持一致，否则AI会误判为不同人。工程上需维护一张映射表，并对映射表本身加密存储、限定访问。映射表一旦泄露，脱敏即失效。

笔者认为：映射表是脱敏系统的“密钥”，其管理等级应等同于密钥管理。建议使用KMS托管，并设置访问审计。

六、验证与度量：如何证明“脱干净了”

脱敏效果不能靠感觉，需要度量。常用指标包括：

• 召回率（Recall）：敏感实体被识别的比例，最关键。
• 精确率（Precision）：被识别实体中真正敏感的比例。
• 过度脱敏率：非敏感内容被误替换的比例，影响可用性。
• 一致性得分：同一实体替换是否一致。

建议构建“脱敏测试集”，包含真实分布的代表性样本，定期回归。测试集本身需严格隔离，不得进入生产环境。根据微软2024年发布的《Responsible AI Transparency Report》，其内部对敏感数据处理的测试覆盖已纳入模型发布前的强制检查项（来源：Microsoft Responsible AI Transparency Report, 2024）。

（注：上述目标值为本文基于工程经验给出的建议区间，属整合性建议，非单一机构标准。）

七、前沿路径：私有化、联邦与机密计算

7.1 私有化部署：最直接的边界重构

把模型部署在内网，数据不出域，是最彻底的方案。开源模型如Llama系列、Qwen系列已具备较强能力，配合vLLM等推理框架可在单机多卡上运行。代价是硬件成本与运维复杂度。

7.2 联邦推理与机密计算

机密计算（Confidential Computing）通过TEE（可信执行环境）保护推理过程中的数据。Intel SGX、AMD SEV、NVIDIA H100的机密计算模式已可用于部分场景。2024年多项研究探索了“TEE内运行LLM推理”的可行性（来源：arXiv上关于Confidential LLM Inference的多篇论文，2024）。

本文评述：机密计算解决的是“服务端不可信”问题，但它对性能有损耗，且信任根仍在硬件厂商。工程上应把它视为“纵深防御的一层”，而非唯一方案。

7.3 差分隐私与合成数据

差分隐私（Differential Privacy）通过在统计结果中加入噪声保护个体。在LLM场景，DP-SGD可用于微调阶段。合成数据则用生成模型产出“统计特征相似但个体不真实”的数据，用于训练与测试。两者都可作为脱敏的补充手段。

八、结论与行动清单

回到主线：数据出域风险—脱敏工程化—可信边界重构。三者不是并列，而是递进。理解风险是前提，工程化脱敏是手段，重构可信边界是目标。

1. 建立数据分级制度，明确L1-L4边界。
2. 部署本地脱敏流水线，规则+NER双通道。
3. 维护加密映射表，纳入密钥管理体系。
4. 建立脱敏测试集，定期回归度量。
5. 对L3以上数据实行人工复核与审批。
6. 评估私有化部署与机密计算可行性。
7. 所有外部推理调用纳入审计日志。

拓展阅读建议：OWASP GenAI Security Project（genai.owasp.org）、NIST AI RMF（nist.gov/itl/ai-risk-management-framework）、以及Hugging Face上的中文NER模型库（huggingface.co/models?language=zh）可作为进一步学习入口。

九、主要参考文献