Bloga DönTeknik

Orta Doğu Uyum Açığı: Neden Arapça ve İbranice PII...

GDPR Boğaziçi'nde sona ermiyor. AB iş akışlarında Arapça ve İbranice PII sistematik olarak korunmuyor.

April 1, 20268 dk okuma
Arabic PII detectionHebrew NERRTL text processingMENA GDPR complianceXLM-RoBERTa multilingual

RTL Uyum Açığı

Arapça ve İbranice, sağdan sola Latin alfabesi dillerine göre geliştirilmiş araçlar kullanan organizasyonlar için sistematik bir PII tespit başarısızlığı sunar. Problem yalnızca yönsel değildir. Sağdan sola yazılan diller, LTR yaklaşımlarından farklı tokenizasyon, farklı segmentasyon mantığı ve farklı varlık sınır tespiti gerektirir. İngilizce verilerle eğitilmiş standart NER sistemleri, Arapça ve İbranice metinlerde yanlış varlık sınırları üreten LTR segmentasyon varsayımlarını uygular.

Yönselliğin ötesinde, Arapça morfoloji daha derin bir zorluk ekler. Arapça, bir kök sistemine dayanır; tek bir kök, ön ekler ve son ekler aracılığıyla onlarca yüzey biçimi üretebilir. Bir kişinin adı — Mohammed — "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid" veya gramer bağlamına bağlı olarak birkaç çekim biçiminde görünebilir. Batılı isim formatları için tasarlanmış Regex desenleri bu morfolojik varyasyonu yakalayamaz. Temelde İngilizce verilerle eğitilmiş bir ML modeli, alternatif yüzey biçimlerini gözden kaçıracaktır.

GDPR, dili bir uyum sınırı olarak tanımaz. MENA müşterilerinden gelen Arapça dilindeki müşteri yazışmalarını işleyen bir AB şirketi, Fransızca yazışmalar için uygulanan aynı veri koruma standartlarını uygulamak zorundadır. Arapça PII'yi tespit etme konusundaki teknik başarısızlık, GDPR'nın 32. Maddesi uyarınca yasal bir uyum başarısızlığıdır.

KYC Kullanım Durumu

Dubai'deki bir fintech şirketi, AB müşterileri için KYC (Müşterinizi Tanıyın) belgelerini işlerken bu modeli örneklemektedir. Arap müşterileri için KYC belgeleri, Arapça müşteri adları, BAE Emirlik Kimlikleri (15 haneli format) ve İngilizce iş yazışmalarıyla birlikte Arapça yazılı adresleri içerir.

Emirlik Kimliği formatı — 784-XXXX-XXXXXXX-X — belirli bir yapıya sahiptir: ülke kodu 784, doğum yılı, yedi haneli sıra, kontrol haneleri. BAE'ye özgü varlık tanımları olmayan Batılı PII araçları bu tanımlayıcı formatını hiç tespit edemez. Arapça ad alanları, yanlış segmentasyon üreten Latin alfabesi NER tarafından işlenir. Sonuç: KYC uyum iş akışlarında sistematik PII görünmezliği.

GDPR yükümlülükleri altında bu verileri kapsayan organizasyonlar için teknik boşluk doğrudan düzenleyici bir maruziyet yaratır. GDPR'nın 32. Maddesi, "uygun teknik ve organizasyonel önlemler" gerektirir — 22% dünyanın dillerinde tanımlayıcıları tespit edemeyen bir sistem uygun bir teknik önlem değildir.

İbranice ve Karışık Dilli Belgeler

İbranice benzer zorluklar sunar. İbranice alfabesi sağdan sola yazılır; İsrail kimlik numaralarının belirli bir doğrulama algoritması vardır (9 haneli İsrail kimlik numaraları için Luhn benzeri kontrol rakamı). İsrail hukuki belgeleri, aynı belgede İbranice, Arapça ve İngilizce metin içerebilir — özellikle İbranice'nin ana dil olduğu ticari sözleşmelerde, İngilizce hizmet şartları referansla dahil edilir ve Arapça, Arapça konuşan taraflar için kullanılır.

Aynı metin bloğunda birden fazla yazı tipi içeren karışık dilli belgeler, varlık tanıma öncesinde yazı tipi tespiti gerektirir. Yazı tipi tespiti olmadan, tek bir NER geçişi, Semitik yazılara Latin tokenizasyonu uygulayabilir ve tamamen yanlış segmentasyon üretebilir.

Nature Scientific Reports (2025) dergisinde yayımlanan araştırma, Arapça PII tespiti için çok dilli NER performansını özel olarak incelemiş ve standart modeller için F1 puanlarının 0.60–0.83, amaç odaklı çok dilli yaklaşımlar (Arapça NER verileri üzerinde ince ayar yapılmış XLM-RoBERTa) için ise 0.88+ olduğunu bulmuştur.

Çok Dilli Mimari Gereksinimi

Etkili Arapça ve İbranice PII tespiti, Batılı öncelikli araçların genellikle eksik olduğu üç bileşen gerektirir:

RTL metin işleme: Doğru metin akışının render edilmesi için Unicode iki yönlü algoritma uyumu ve sağdan sola metinlerde kelime sınırlarını dikkate alan RTL uyumlu tokenizasyon.

Morfolojiye duyarlı NER: Ya bir morfolojik analizör (Arapça için Farasa veya eşdeğeri) ya da morfolojik varyasyonu öğrenmiş Arapça/İbranice NER verileri üzerinde ince ayar yapılmış bir transformer modeli.

Bölgeye özgü varlık tanımları: Emirlik Kimliği, İsrail Kimliği, Suudi Ulusal Kimliği, Mısır Ulusal Kimliği ve diğer MENA'ya özgü tanımlayıcı formatlar, format spesifikasyonları ile açık varlık türü tanımları gerektirir.

Kaynaklar:

Verilerinizi korumaya hazır mısınız?

48 dilde 285+ varlık türü ile PII anonimleştirmeye başlayın.