GDPR没有语言偏好
通用数据保护条例同样适用于德语、法语、波兰语、瑞典语、西班牙语、意大利语及所有其他由受条例约束的组织处理的个人数据。错过德语客户数据中的标识符与错过英语客户数据中的标识符所带来的监管风险是相同的。GDPR不区分语言。
大多数个人身份信息检测工具却是如此。
主流的商业和开源个人身份信息检测工具主要是基于英语文本构建和基准测试的。它们的实体识别器反映了这一点：美国社会安全号码、美国驾驶执照、美国护照格式以及常见的通用标识符（电子邮件地址、NANP格式的电话号码、信用卡号码）。非英语国家标识符的识别器——如果存在——通常准确性较低，维护不足，更可能产生假阴性。
对于在欧盟成员国之间运营的企业来说，这造成了一个系统性的合规差距：工具报告检测到并移除了个人身份信息，但在某些司法管辖区中代表最大GDPR风险的非英语标识符仍然保留在数据中。
国家标识符之间的结构差异
以英语为中心的工具与真正多语言工具之间的差距并不是简单地增加更多的正则表达式模式。欧盟成员国之间的国家标识符格式在结构上是不同的，这需要特定于司法管辖区的知识才能正确检测。
德国税号（Steuer-ID）： 11位数字的税务标识符，基于Luhn公式变体的特定校验和算法。通用的社会安全号码正则表达式无法匹配此格式。匹配任何11位数字的正则表达式将在德国财务文件中产生巨大的假阳性率。
法国NIR（Numéro d'inscription au répertoire）： 15位标识符，包含持有人的性别、出生年份、出生月份、出生部门或国家代码、出生顺序号和2位控制键。检测需要理解结构并验证控制键。
瑞典个人号码（Personnummer）： 10位标识符（有时带有世纪指示符，使其变为12位），带有Luhn校验位。格式因年龄而异：1990年之前出生的个人使用+分隔符而不是-，改变了必须检测的格式。
波兰PESEL： 11位标识符，编码出生日期、性别和基于加权和算法的校验位。正确检测需要格式匹配和校验和验证。
这些不是共同模式上的格式变体。它们是结构上不同的标识符，具有不同的长度、不同的验证算法和不同的位置编码方案。一个以英语训练的命名实体识别模型在文本中遇到法语NIR时不会将其识别为国家标识符——它要么忽略它，要么如果匹配某种其他模式，则错误分类。
实际合规后果
对于同时处理来自德国、法国、波兰和荷兰的客户服务数据的欧洲BPO的合规官来说，实际后果是非英语客户记录中存在系统性的检测差距。
合规官的工具报告成功进行了个人身份信息匿名化。匿名化的数据仍然包含德国记录中的税号、法国记录中的NIR号码和波兰记录中的PESEL号码——因为这些格式的识别器要么缺失，要么准确性不足。
当匿名化数据集随后用于分析、测试或与研究合作伙伴共享时，这些“匿名化”数据仍然包含可重新识别的国家标识符数据。GDPR的违规行为在工具的输出日志中不可见。当数据主体访问请求、监督机构审计或数据泄露揭示未移除非英语标识符时，这一问题才会显现。
研究比较混合多语言个人身份信息检测方法与单语言英语中心工具发现，混合方法在欧洲地区的F1得分为0.60到0.83——而仅应用于非英语标识符格式的英语工具几乎没有表现。
全面覆盖的要求
真正的多语言个人身份信息检测以符合欧盟GDPR要求，需要三个架构层次的结合：
语言本地的spaCy模型提供对文本语言中名称、组织和地点的语义理解。一个在德语文本上训练的spaCy模型理解“穆勒”在德语环境中是一个常见的姓——而不仅仅是一个大写的单词。针对25种高资源欧盟语言的模型已经存在。
Stanza NLP模型扩展了对spaCy未覆盖的其他语言的覆盖，保持相同的准确性水平。
跨语言变换模型（XLM-RoBERTa）处理纯模式匹配无法解决的跨语言歧义——即使检测引擎没有针对该名称进行特定训练，也能识别出出现在法语句子中的名称是一个人名。
带有特定于司法管辖区的验证的正则表达式覆盖结构化国家标识符——税号、NIR、PESEL、个人号码——并进行校验和验证，以消除假阳性。
对于当前错过非英语标识符的合规官来说：差距是结构性的，而不是配置问题。添加词汇表或扩展正则表达式覆盖仅提供边际改善。全面的欧盟GDPR合规对于多语言数据要求构建一个以欧盟标识符覆盖为设计要求的工具，而不是事后考虑。
来源：