超越社保号和电子邮件地址：匿名化您组织的自定义标识符
您的GDPR匿名化工具可以检测电子邮件地址。它可以检测电话号码。它可以检测姓名和社会安全号码。您将支持工单导出通过它，下载匿名化的输出，并与您的分析团队分享。
您的客户账户号码（ACC-XXXXXXXX-XX格式）仍然在每个工单中。您的订单ID（ORD-XXXXXXX）仍然存在。您的内部用户ID仍然在。
这些标识符在孤立状态下是伪匿名的——没有访问查找表就无法直接识别一个人。但您的分析团队可以访问该查找表。您的支持数据库有它。您的CRM有它。任何有权访问这些系统的人都可以在几秒钟内重新识别匿名化的导出。
这是GDPR伪匿名化的失败——不是因为工具遗漏了标准PII，而是因为它无法了解特定于您组织的标识符。
标准PII工具检测的内容
标准PII检测工具——包括基础的Microsoft Presidio配置——是围绕通用标识符格式构建的：
覆盖的内容：
- 社会安全号码（美国SSNs，英国NINOs，欧盟国家ID格式）
- 电子邮件地址（RFC 5322格式）
- 电话号码（E.164和国家格式）
- 信用卡号码（Luhn算法验证）
- 姓名（基于NER模型的检测）
- 护照/驾驶执照号码（国家特定格式）
未覆盖的内容：
- 您的员工ID格式（EMP-XXXXX）
- 您的客户账户号码格式（ACC-XXXXXXXX-XX）
- 您的订单ID格式（ORD-XXXXXXX）
- 您的内部用户ID（UUID或自定义格式）
- 您的内部参考代码
- 合作伙伴特定标识符
标准工具检测的是通用的。特定于组织的标识符，按定义来说，并不是通用的。它们需要自定义配置。
实践中的重新识别风险
一家金融服务公司处理客户支持工单以进行质量分析。他们的标准PII匿名化工作流程移除了：
- 客户姓名 ✓
- 电子邮件地址 ✓
- 电话号码 ✓
- 账户号码（ACC-XXXXXXXX-XX格式）✗ — 未被检测
工单导出发送给分析团队。一名数据分析师根据账户号码将工单表与客户数据库连接。重新识别是立即和完整的。
这并不需要复杂的攻击技术。这是任何分析师都会执行的常规SQL连接，以将客户人口统计上下文添加到支持工单分析中。"匿名化"的导出并不匿名。
GDPR第4(5)条将伪匿名化定义为"以某种方式处理个人数据，使得在没有额外信息的情况下，个人数据无法再归属于特定的数据主体。" 当额外信息（客户数据库）随时可用时，账户号码未能通过此测试。
构建自定义实体模式
自定义实体创建遵循非技术合规团队的简单工作流程：
步骤1：识别标识符格式 记录您组织特定标识符及其格式：
- 客户账户：ACC-XXXXXXXX-XX（ACC前缀，8位数字，2个字符后缀）
- 订单ID：ORD-XXXXXXX（ORD前缀，7位数字）
- 员工ID：EMP-XXXXX（EMP前缀，5位数字）
- 内部用户ID：UUID格式（8-4-4-4-12十六进制）
步骤2：生成检测模式 用简单的语言描述格式："以ACC开头的账户号码，后跟一个破折号，然后是8位数字，再后跟一个破折号，最后是2个大写字母。"
AI辅助的模式生成产生：ACC-d{8}-[A-Z]{2}
步骤3：验证样本数据 上传包含标识符的20-30个文档。验证：
- 所有实例均被检测到（无假阴性）
- 无假阳性（非标识符文本错误标记）
步骤4：配置匿名化方法 对于用作连接键的标识符（在多个系统中出现且需要在分析中保持一致的订单ID）：
- 伪匿名化： 在所有文档中将ACC-00123456-AB一致替换为ACC-99876543-XY。替换是一致的——相同的输入总是产生相同的输出——因此分析连接仍然有效。没有密钥无法恢复原始值。
对于不需要分析的标识符：
- 删除： 替换为**[已删除]**。更简单，不可逆。
步骤5：保存为预设 自定义实体（或多个自定义实体）保存为团队预设，在所有处理过程中一致应用——批量上传、API调用、浏览器界面。新团队成员自动获得完整配置。
案例研究：180,000个支持工单
一家金融服务公司在历史支持工单导出中出现客户账户号码（ACC-XXXXXXXX-XX格式）。标准PII工具完全遗漏了它们。
识别的差距： 在合规审查后，团队意识到其分析仓库中的180,000个历史支持工单包含未删除的账户号码，以及（已匿名化的）姓名和电子邮件。
解决时间表：
- 合规官定义ACC模式（15分钟）
- 对30个样本工单进行测试（20分钟）
- 确认模式准确性（10分钟）
- 在过夜批处理中处理180,000个工单
- 用重新匿名化的版本替换仓库表
关闭合规差距的总时间：合规官时间45分钟 + 过夜批处理。没有自定义实体创建，这将需要一个工程工单、开发时间、代码审查和部署——几周，而不是几小时。
超越支持工单：自定义标识符出现的地方
自定义组织标识符在比大多数合规团队意识到的更多文档类型中传播：
内部文档：
- 参考账户号码或订单ID的会议记录
- 包含客户引用的电子邮件线程
- 带有案例研究数据的演示文稿
与第三方共享：
- 向监管机构提交的带有案例参考号码的报告
- 与审计师共享的数据
- 带有客户引用的供应商文档
研究和分析：
- 客户旅程分析数据集
- 支持质量审查数据集
- 用于内部机器学习模型的训练数据
每一个都需要相同的自定义实体配置，以产生真正匿名的输出。
GDPR伪匿名化与匿名化：技术区别
GDPR区分：
伪匿名化： 可以通过访问额外信息重新识别的数据。伪匿名化的数据在GDPR下仍然是个人数据。该法规鼓励伪匿名化作为风险降低措施，但并未消除GDPR义务。
匿名化： 无法合理重新识别的数据。匿名数据不是个人数据，不受GDPR约束。
账户号码、订单ID和员工ID在存在查找表时是伪匿名的——而不是匿名的。用一致的伪名替换它们（伪匿名化）降低了风险，但并未消除GDPR义务。用随机令牌替换它们（通过销毁密钥进行匿名化）消除了GDPR义务，但破坏了连接。
对于与没有访问您查找表的第三方共享：伪匿名化可能是足够的（他们无法在没有密钥的情况下重新识别）。对于内部分析：完全匿名化或对密钥的访问控制是必要的。
结论
标准PII检测差距不是检测算法的技术限制——而是配置差距。没有检测工具可以知道您组织的账户号码格式，除非您告诉它。
自定义实体创建在几小时内填补了这一差距，而不是几周。合规团队——没有工程支持——可以定义特定于组织的模式，验证它们与样本数据的一致性，并在所有处理模式中一致应用。
案例研究中发现的180,000个未删除的账户号码并不是因为工具失败而存在。它们存在是因为从未告诉工具去查找它们。
来源：