分析师A将姓名替换为假名，分析师B则将其遮黑处理。两人都遵循了同一份GDPR规则，针对同一类文档——至少他们自己是这么认为的。
审计时，同一数据集里出现了两种处理方式。审计员问道：「你们对个人姓名的标准处理流程是什么？」你无法作答，因为存在两套流程，而非一套。
这就是配置漂移。它不需要数据泄露才能造成风险——它会直接产生审计问题。问题反复出现，最终导致罚款。
配置漂移的形成过程
漂移是缓慢积累的，没人察觉，直到审计来临。
第0个月——初始配置： 合规经理完成PII工具的配置，团队接受了简短演示。
第2个月——新人入职： 一位新分析师加入，他照着同事的配置复制了一份。大体相符，但少了一种实体类型。
第4个月——政策更新： 一份指导说明新增了出生日期检测要求。部分团队成员更新了配置，另一些人则错过了变更。
第6个月——本地调整： 某位分析师为了减少过度遮黑，降低了置信度阈值。该变更影响了他此后的所有工作，且从未被记录在案。
第8个月——DPA审计： 审计员抽取了五十份文档，发现同一类文档出现了三套不同规则：
- 第1—20份：姓名假名化、出生日期遮黑、地址遮黑
- 第21—35份：姓名直接遮黑、无出生日期处理、地址保留
- 第36—50份：姓名替换、地址遮黑、电子邮件保留
审计结论：缺乏系统性控制机制以确保脱敏处理的一致性。
混乱配置的三重危害
审计不通过
DPA审计员会核查脱敏处理是否具有系统性。同一类文档出现三种不同处理方式，说明缺乏管控——即便每种方式本身都是合理的。
数据质量下降
多位分析师的输出结果合并后，差异会叠加放大。一个数据集中40%的记录姓名被假名化、60%被遮黑，其实用价值低于统一采用任意一种方式。在混合输出上训练的模型表现更差。
法律抗辩能力减弱
在法庭上，对方律师可以质疑遮黑的完整性。当不同审阅者适用不同标准时，法官已对电子证据发现中的遮黑提出质疑。日志混乱会削弱「遮黑处理严谨彻底」的主张。
预设配置的解决方案
解决方案很简单：把配置决策从每位用户手中收回。
使用预设前： 每位用户根据自己对规则的理解进行配置，设置因人而异，甚至因会话而异。
使用预设后： 合规经理创建命名预设，每个预设包含经审批的规则集。用户选择适当的预设，决策由合适的人统一作出，并适用于所有人。
预设包含的内容：
- 需检测的实体类型
- 适用的处理方式（替换、遮黑、假名化、掩码、加密）
- 自定义实体定义（内部ID、特定站点格式）
- 语言设置
- 置信度阈值
用户仍需决定的内容：
- 当前文档适用哪个预设——这是基于规则的选择，而非配置选择
- 某个标记项是否需要人工审查
合规决策——该怎么处理——已经预先做好。日常选择——用哪个预设——遵循明确规则。
六步掌控配置
第一步——梳理现有配置
询问所有团队成员当前的工具配置，记录差异，评估漂移程度。
第二步——定义经审批的规则集
针对每种文档类型，制定经审批的配置标准，由数据保护官（DPO）签字确认。
第三步——创建命名预设
将每套经审批的规则集转化为命名预设，使用清晰的名称。「GDPR标准——欧盟客户数据」优于「Config1」。
第四步——取消自主配置选项
将临时配置选项从标准工作流中移除。用户选择预设，而非从头构建。
第五步——记录配置过程
记录每个预设的创建者和创建时间，并设定审查周期：GDPR预设每季度审查，HIPAA预设每年审查。
第六步——建立审计追踪
日志应记录：X批次于Y日期由用户Z使用预设「GDPR标准——欧盟客户数据」运行，预设的规则集同步记录，追踪链完整可查。
等待的代价
许多团队跳过了预设治理。前期成本显而易见，风险成本却感觉遥远。
一旦看了真实的执法数据，账就算清楚了：
- 2024年GDPR执法行动增加了56%（DLA Piper《2025年年度报告》）
- 首次流程违规通常会触发整改令，并设有整改期限
- 同一领域的重复问题将导致罚款
- 违反第32条的罚款从数千欧元到数百万欧元不等，取决于违规规模和严重程度
整改令迫使你建立本应提前建立的管控机制。在压力下亡羊补牢，通常比提前主动应对贵出三到五倍。
结语
配置漂移并非故意为之，而是允许每位用户在缺乏集中监管的情况下自主管理配置的必然结果。
更好的培训无法解决这个问题。更清晰的记录无法解决这个问题。从工作流中移除自主配置选项，才能解决这个问题。
预设是系统性合规的技术实现形式。它确保由合格人员作出的决策适用于所有人——无论其经验水平或个人判断如何。