RTLコンプライアンスの盲点
GDPRはボスポラス海峡で終わらない。ラテン文字向けツールを使うEU企業には盲点がある。それは現実の問題であり、広く見過ごされている。
問題はテキストの方向だけではない。右から左に書く文字体系には、別のトークン化が必要だ。別のセグメント化も必要だ。エンティティの境界はLTRテキストとは異なる動作をする。英語で訓練されたNERシステムはLTRのルールを適用する。そのルールはRTLテキストでは機能しない。間違ったエンティティ境界を生成する。
アラビア語の形態論はさらに難しくする。この言語は語根を使う。一つの語根から何十もの語形が生まれる。モハメッドという名前は「Al-Mohammed」「bin Mohammed」「Mohammed al-Rashid」として現れることがある。西洋の名前向けに作られた正規表現パターンはこれらの形式を捉えられない。英語で訓練されたモデルも同様だ。
GDPRは言語をコンプライアンスの境界として扱わない。MENA地域のクライアントからの顧客書簡を処理するEU企業は、フランス語の書簡と同じルールを適用しなければならない。RTLテキストで個人情報を見逃すことは、GDPR第32条に基づく法的違反だ。
KYCのユースケース
EUクライアント向けのKYC書類を処理するドバイのフィンテック企業がこれをよく示している。
アラブ人クライアントのKYCファイルには、RTL文字での名前、UAEエミレーツID、RTL住所が含まれる。これらは英語のビジネス文書と混在している。
エミレーツIDのフォーマットは784-XXXX-XXXXXXX-Xだ。国コード784。生年。7桁の番号。チェックデジット。UAEエンティティ定義を持たないPII検出ツールはこのフォーマットを見つけられない。名前フィールドはラテン文字NERで処理される。セグメント化は間違っている。PIIはワークフロー内で不可視になる。
このデータに対するGDPR義務を持つ企業にとって、このギャップは現実の法的リスクを生む。GDPR第32条は適切な技術的措置を要求する。世界の言語の22%で識別子を見逃すツールは、適切な措置ではない。
ヘブライ語と多言語文書
ヘブライ語も同様の問題を提示する。文字は右から左に書かれる。イスラエルのID番号はチェックサムを使う——9桁のLuhn類似テストだ。
イスラエルの法的文書は、ヘブライ語、アラビア文字テキスト、英語を一つのファイルに混在させることが多い。ヘブライ語が主要言語であり、英語の条件が参照によって組み込まれる契約でよく見られる。
混在文字体系の文書は、NERの前にスクリプト検出が必要だ。それなしでは、単一のNERパスがRTLスクリプトにラテン語ルールを適用する。結果は間違っている。
Nature Scientific Reports（2025年）の研究はRTL個人情報のクロスリンガルNER性能をテストした。標準モデルはF1スコア0.60–0.83を達成した。RTL NERデータでファインチューニングされたXLM-RoBERTaは0.88以上を達成した。
必要なクロスリンガルアーキテクチャ
優れたRTL PII検出には、西洋中心のツールが通常持っていない3つの要素が必要だ。
RTLテキスト処理： 正しいテキストフローのためのUnicode双方向アルゴリズム準拠。右から左のテキストで単語境界を見つけるRTL対応トークン化。
形態論を考慮したNER： アラビア語向けFarasaのような形態素解析器、またはRTL NERデータでファインチューニングされたトランスフォーマーモデル。モデルは形態論的変異を学習している必要がある。
地域固有のエンティティタイプ： エミレーツID、イスラエルID、サウジ国民ID、エジプト国民IDはそれぞれフォーマットルールを持つ明示的な定義が必要だ。汎用的な西洋ツールはこれらを持っていない。
48言語にわたるスクリプト検出を処理する多言語NERパイプラインをご覧ください。サポートするMENA地域の識別子タイプの完全なリストは、エンティティカタログをご覧ください。GDPRコンプライアンスガイドでは、検出ギャップが第32条のリスクをどのように生むかを説明しています。