自托管 PII 工具为何无法通过合规审计
GDPR 需要证明。你必须证明每次 PII 删除操作都以相同的方式执行。数据保护局审计员会重点核查这一点——他们要看到跨所有数据的清晰、一致的处理方法。
自托管 Presidio 在这里存在一个真实问题，这不是配置问题，而是自托管 NLP 工具的根本局限。
什么是环境漂移？
自托管 Presidio 分别运行于开发环境、预发布环境和生产环境，每个环境的行为可能存在差异，导致相同输入在不同环境产生不同的输出结果。
这种现象称为环境漂移，主要由以下四个原因造成。
模型版本漂移
spaCy 模型是有版本的。en_core_web_lg 3.4.4 与 en_core_web_lg 3.5.1 在训练数据和模型架构上均有差异，因此同一份文档经不同版本处理后可能产生不同的 NER 结果。
一种常见的环境配置如下：
- 开发环境：
en_core_web_lg 3.4.4— 项目启动时安装 - 预发布环境：
en_core_web_lg 3.5.0— 常规维护时更新 - 生产环境：
en_core_web_lg 3.5.1— 安全修复时更新
三个环境，三个模型版本，三套不同的检测结果。测试在预发布环境通过，但生产环境运行的是不同版本的模型，差距因此持续隐藏。
依赖版本漂移
spaCy 3.4.x 与 3.5.x 在句子分割方式上存在差异，这一变化会影响句子边界附近的姓名识别。相关变更记录在 spaCy 发布说明中，但大多数团队不会主动排查其对 PII 检测的影响。
配置漂移
在开发环境设置的置信度阈值可能未同步到生产环境，自定义词表也可能在不同环境间存在差异。这类问题十分普遍，却很少被追踪。关于审计员的关注重点，请参阅我们的 GDPR 合规指南。
硬件差异
NLP 模型的浮点运算在不同 CPU 和 GPU 上并不完全一致，消费级笔记本与服务器可能产生略有差异的置信度分数，导致某些姓名在一台机器上被识别，在另一台机器上却被遗漏。
一次真实的审计发现
某银行对其自托管 Presidio 部署进行了测试。
测试环境： 预发布集群上的 Presidio，搭配 spaCy 3.4.4。
生产环境： 生产集群上的 Presidio，搭配 spaCy 3.5.1。
他们将同一批文档分别在两个环境中运行并对比结果，发现：3% 的文档产生了不同的 PII 删除结果——某些姓名在预发布环境中被识别，在生产环境中却未被识别；部分实体的检测文本范围也存在差异。
审计结论直截了当：「由于不同环境的检测输出存在差异，该机构无法证明技术性 PII 删除措施的一致性应用。」
GDPR 第 32 条要求采取适当的技术措施，EDPB 关于 PII 删除的规则要求保证一致性和可重复性。按每月处理 10 万份文档计算，3% 的差异率意味着每月有 3000 份文档存在不一致的处理结果，其中部分为漏报——预发布环境能识别的 PII 留存在了生产输出中。这是合规失败。
此后，该银行迁移至托管 SaaS 方案，审计发现随之关闭。关于托管方案如何处理这一问题，请参阅我们的安全与合规页面。
为何托管服务有所不同
托管服务运行单一引擎版本，所有用户在同一时间使用相同版本，模型更新从单一位置统一推送，配置同样从单一位置集中管理并保留完整变更日志，用户的硬件环境不会影响检测结果。
因此，今天处理的文档与下个月处理的结果相同。若引擎版本发生变更，该变更会被记录并带有版本标识。
审计追踪的差异至关重要。
自托管审计追踪：
- 「在 Ubuntu 22.04 上使用 Presidio 2.2.35 搭配 spaCy
en_core_web_lg 3.5.1。」 - 版本是否与预发布环境一致？未知。
- 文档处理后模型是否更新过？除非主动追踪，否则无从得知。
- 置信度阈值与测试时是否相同？取决于配置管理。
托管服务审计追踪：
- 「使用 anonym.legal API，引擎版本 4.22.1，时间戳 2025-03-15T14:22:31Z。」
- 所有用户使用相同版本？是的。
- 是否有变更？引擎版本被锁定，版本号 4.22.1 始终对应同一引擎。
- 配置是否可重现？是的，预设 ID 已记录，该版本的配置可随时查阅。
托管方案的审计追踪清晰明确，自托管方案则需要大多数团队都会忽略的严格版本管理。
如何提升自托管一致性
如果必须自托管，可通过以下四个步骤降低漂移风险。
首先，锁定模型版本。 在所有部署配置文件中固定模型版本，禁止自动更新，并在版本控制系统中追踪版本信息。
其次，冻结容器镜像。 构建将精确模型版本内置的 Docker 镜像，为每个镜像打上模型版本、Presidio 版本和日期标签，在充分测试前不更新基础镜像。
然后，将配置纳入代码管理。 将所有 Presidio 设置存储在版本控制系统追踪的配置文件中，包括检测器、置信度阈值和启用语言，与应用代码一同部署。
最后，跨环境测试。 每次更新后，使用固定的测试文档集在新环境中运行，将结果与存储的基准对比，并将此检查自动化。关于自动化 PII 回归测试的常见问题，请参阅 FAQ。
这些步骤有助于改善一致性，但也会增加运营负担。托管服务无需额外工作即可实现同等一致性。
结语
一致的 PII 删除不会出现在产品说明书上，但当审计员要求提供证据时，它会变得至关重要。
缺乏主动管理，自托管 PII 工具就会发生漂移，版本变更悄无声息地制造差距，这些差距最终以审计发现的形式浮出水面。
托管服务默认提供一致性——引擎在单一位置运行，用户的硬件环境不影响结果。对于合规优先的团队，这是直接的竞争优势。