从右到左文字的合规盲区
GDPR 的效力并不止步于博斯普鲁斯海峡。使用拉丁字母工具的欧盟企业存在一个真实且普遍被忽视的盲区。
问题并非仅仅是文字方向。从右到左（RTL）的书写系统需要不同的分词逻辑和文本分割方式，实体边界的识别规则也与从左到右（LTR）的文本截然不同。基于英语训练的命名实体识别（NER）系统套用 LTR 规则，在 RTL 文本上会产生错误的实体边界。
阿拉伯语的词形变化使问题更加复杂。阿拉伯语以词根为基础，一个词根可以衍生出数十种词形变体。「Mohammed」这个名字可能以「Al-Mohammed」、「bin Mohammed」或「Mohammed al-Rashid」等形式出现。针对西方姓名构建的正则表达式无法匹配这些变体，基于英语训练的模型同样如此。
GDPR 不将语言视为合规边界。一家处理中东和北非客户邮件的欧盟企业，须与处理法语邮件时遵守同等规则。对 RTL 文本中 PII 的漏检，在法律上构成 GDPR 第 32 条下的违规。
KYC 使用场景的典型问题
一家为欧盟客户处理 KYC 文件的迪拜金融科技公司清晰地展示了这一困境。
阿拉伯客户的 KYC 文件包含 RTL 脚本书写的姓名、阿联酋身份证号码和 RTL 地址，这些内容与英文商业文本并排出现。
阿联酋身份证格式为 784-XXXX-XXXXXXX-X：国家代码 784、出生年份、七位数字、校验位。不具备阿联酋实体定义的西方 PII 工具根本无法识别这一格式。姓名字段经过拉丁字母 NER 处理后，由于分词有误，PII 在工作流程中变得「隐形」。
对于承担 GDPR 合规义务的企业而言，这一空白带来了切实的法律风险。GDPR 第 32 条要求采取适当的技术措施。一款遗漏了全球 22% 语言标识符的工具，不符合「适当措施」的标准。
希伯来语与混合语言文档
希伯来语面临类似挑战。该语言从右向左书写；以色列身份证号码采用校验算法——对九位数字进行类似 Luhn 算法的验证。
以色列法律文件常将希伯来语、阿拉伯字母文字和英语混合于同一文件中，这在以希伯来语为主体、通过参引条款附加英文术语的合同中尤为普遍。
混合文字文件在 NER 处理前需要先进行文字类型检测。若缺少这一步骤，单次 NER 扫描将对 RTL 文字套用拉丁语规则，导致输出结果有误。
《自然·科学报告》2025 年的一项研究测试了跨语言 NER 对 RTL PII 的检测效果：标准模型的 F1 值在 0.60 至 0.83 之间，而在 RTL NER 数据上微调后的 XLM-RoBERTa 可达到 0.88 及以上。
跨语言架构的必要条件
可靠的 RTL PII 检测需要具备三项西方优先工具通常缺乏的能力。
RTL 文本处理能力： 符合 Unicode 双向规范的文本流处理，以及能够在从右到左的文本中准确识别词语边界的 RTL 感知分词机制。
形态感知 NER： 适用于阿拉伯语的形态分析器（如 Farasa），或在 RTL NER 数据上微调的 Transformer 模型——模型必须学习并掌握词形变化规律。
区域专属实体类型： 阿联酋身份证、以色列身份证、沙特国家身份证、埃及国家身份证，每种格式都需要具备明确格式规则的专项定义，通用的西方工具并不包含这些定义。
请参阅我们的多语言 NER 技术管道，了解我们如何在 48 种语言中进行文字类型检测。中东北非地区支持的标识符类型完整列表，请访问实体目录。GDPR 合规指南中涵盖了检测漏洞如何引发第 32 条合规风险，请参阅法律合规页面。