RTL Uyum Açığı
GDPR Boğaz'da bitmez. Latin alfabesi kullanan araçlara sahip AB şirketleri körleşiyor. Bu gerçek bir sorun ve büyük ölçüde görmezden geliniyor.
Sorun yalnızca metin yönü değil. Sağdan sola (RTL) yazılar farklı tokenizasyon gerektiriyor. Farklı parçalara bölme gerektiriyor. Varlık sınırları LTR metinlerden farklı çalışıyor. İngilizce üzerinde eğitilmiş NER sistemleri LTR kurallarını uyguluyor. Bu kurallar RTL metinde bozuluyor ve yanlış varlık sınırları üretiyor.
Arapça morfolojisi işi daha da güçleştiriyor. Dil kök tabanlı çalışıyor. Tek bir kökten düzinelerce kelime türüyor. Muhammed gibi bir isim "Al-Muhammed", "bin Muhammed" veya "Muhammed al-Raşid" biçiminde görünebiliyor. Batılı isimler için oluşturulan regex desenleri bu biçimleri kaçırıyor. İngilizce üzerinde eğitilen modeller de aynı şekilde başarısız oluyor.
GDPR, dili bir uyum sınırı olarak tanımlamıyor. MENA müşterilerinden Arapça posta işleyen bir AB şirketi, Fransızca postaya uygulanan kuralların aynısına tabidir. RTL metindeki kişisel verilerin kaçırılması, GDPR Madde 32 kapsamında hukuki bir ihlal oluşturuyor.
KYC Kullanım Senaryosu
AB müşterileri için KYC belgelerini işleyen Dubai merkezli bir fintech şirketi durumu net biçimde ortaya koyuyor.
Arap müşterilere ait KYC dosyaları RTL yazıyla yazılmış isimler, BAE Emirlik kimlikleri ve RTL adresleri içeriyor. Bunlar İngilizce ticari metinlerin yanında yer alıyor.
Emirates ID formatı 784-XXXX-XXXXXXX-X şeklinde. Ülke kodu 784. Doğum yılı. Yedi basamak. Kontrol basamağı. BAE varlık tanımı olmayan Batılı KBV araçları bu formatı bulamıyor. İsim alanları Latin alfabesi NER'inden geçiyor. Parçalama yanlış yapılıyor. KBV iş akışında görünmez hale geliyor.
Bu veriler üzerinde GDPR yükümlülüğü bulunan şirketler için bu açık gerçek hukuki risk yaratıyor. GDPR Madde 32, uygun teknik tedbirleri zorunlu kılıyor. Dünyanın dillerinin %22'sindeki tanımlayıcıları kaçıran bir araç uygun bir tedbir sayılamaz.
İbranice ve Karma Dilli Belgeler
İbranice de benzer sorunlar yaratıyor. Yazı sağdan sola ilerliyor. İsrail kimlik numaraları dokuz basamak üzerinde Luhn benzeri bir sağlama toplamı kullanıyor.
İsrail hukuki belgeleri çoğunlukla tek bir dosyada İbranice, Arapça metin ve İngilizce içeriyor. Bu durum İbranicenin ana dil olduğu ve İngilizce terimlerin referans olarak eklendiği sözleşmelerde yaygın.
Karma alfabeli dosyalar NER öncesinde alfabe tespiti gerektiriyor. Bu olmadan tek bir NER geçişi RTL yazılara Latin kurallarını uyguluyor ve çıktı hatalı oluyor.
Nature Scientific Reports (2025) dergisinde yayımlanan bir araştırma, RTL kişisel verileri üzerinde çapraz dilsel NER testi yaptı. Standart modeller F1 skoru 0,60-0,83 arasında kaldı. RTL NER verileri üzerinde ince ayarlı XLM-RoBERTa ise 0,88 ve üzerinde skor elde etti.
Çapraz Dilsel Mimari Gereksinimi
İyi bir RTL KBV tespiti, Batı odaklı araçların genellikle yoksun olduğu üç unsura ihtiyaç duyuyor.
RTL metin işleme: Doğru metin akışı için Unicode çift yönlü uyum. Sağdan sola metinde kelime sınırlarını bulan RTL'ye duyarlı tokenizasyon.
Morfoloji duyarlı NER: Arapça için Farasa gibi bir morfoloji analizörü ya da RTL NER verileri üzerinde ince ayarlı bir transformer modeli. Modelin morfolojik çeşitliği öğrenmiş olması şart.
Bölgeye özgü varlık türleri: Emirates ID, İsrail kimlik numarası, Suudi Ulusal Kimliği ve Mısır Ulusal Kimliğinin her biri format kurallarıyla birlikte açıkça tanımlanmayı gerektiriyor. Genel Batı araçları bunlara sahip değil.
Çok dilli NER boru hattımızın 48 dilde alfabe tespitini nasıl ele aldığını görün. Desteklediğimiz MENA tanımlayıcı türlerinin tam listesi için varlık kataloğunu ziyaret edin. GDPR uyum rehberimiz tespit açıklarının Madde 32 riski nasıl yarattığını açıklıyor.