Kesenjangan Kepatuhan RTL
GDPR tidak berhenti di Bosphorus. Perusahaan-perusahaan EU yang menggunakan alat berbasis skrip Latin memiliki titik buta. Masalah ini nyata dan sebagian besar diabaikan.
Problematika ini bukan sekadar soal arah teks. Skrip yang ditulis dari kanan ke kiri (RTL) membutuhkan tokenisasi yang berbeda dan segmentasi yang berbeda pula. Batas entitas bekerja secara berbeda dibandingkan teks dari kiri ke kanan (LTR). Sistem NER yang dilatih menggunakan bahasa Inggris menerapkan aturan LTR. Aturan tersebut gagal pada teks RTL dan menghasilkan batas entitas yang salah.
Morfologi bahasa Arab mempersulit situasi ini. Bahasa Arab berbasis akar kata, di mana satu akar menghasilkan puluhan bentuk kata. Nama seperti Mohammed dapat muncul sebagai "Al-Mohammed," "bin Mohammed," atau "Mohammed al-Rashid." Pola regex yang dibangun untuk nama Barat melewatkan variasi ini. Model yang dilatih menggunakan bahasa Inggris pun mengalami hal yang sama.
GDPR tidak memperlakukan bahasa sebagai batas kepatuhan. Perusahaan EU yang memproses surat dari klien MENA harus memenuhi aturan yang sama seperti untuk surat berbahasa Prancis. Melewatkan PII dalam teks RTL adalah kegagalan hukum berdasarkan Pasal 32 GDPR.
Kasus Penggunaan KYC
Sebuah fintech Dubai yang memproses dokumen KYC untuk klien EU menggambarkan hal ini dengan jelas.
Berkas KYC untuk klien Arab memuat nama dalam skrip RTL, Emirates ID UEA, dan alamat RTL. Semuanya berdampingan dengan teks bisnis berbahasa Inggris.
Format Emirates ID adalah 784-XXXX-XXXXXXX-X: kode negara 784, tahun lahir, tujuh digit, dan digit cek. Alat PII Barat yang tidak memiliki definisi entitas UEA tidak dapat menemukan format ini. Kolom nama diproses oleh NER berbasis skrip Latin dengan segmentasi yang salah. Hasilnya: PII menjadi tidak terlihat dalam alur kerja.
Bagi perusahaan yang memiliki kewajiban GDPR atas data ini, kesenjangan tersebut menciptakan risiko hukum yang nyata. Pasal 32 GDPR mensyaratkan langkah-langkah teknis yang memadai. Alat yang melewatkan pengenal dalam 22% bahasa di dunia bukanlah langkah yang memadai.
Bahasa Ibrani dan Dokumen Multibahasa
Bahasa Ibrani menghadirkan masalah serupa. Skripnya berjalan dari kanan ke kiri. Nomor ID Israel menggunakan checksum — uji mirip Luhn pada sembilan digit.
Dokumen hukum Israel sering memadukan teks Ibrani, Arab, dan Inggris dalam satu berkas. Hal ini umum dalam kontrak di mana Ibrani adalah bahasa utama dan istilah Inggris ditambahkan sebagai referensi.
Berkas dengan skrip campuran membutuhkan deteksi skrip sebelum tahap NER. Tanpa itu, satu kali NER akan menerapkan aturan Latin pada skrip RTL dan menghasilkan output yang salah.
Penelitian dalam Nature Scientific Reports (2025) menguji NER lintas bahasa pada PII RTL. Model standar mencapai skor F1 antara 0,60–0,83. XLM-RoBERTa yang di-fine-tune pada data NER RTL mencapai 0,88 ke atas.
Persyaratan Arsitektur Lintas Bahasa
Deteksi PII RTL yang andal membutuhkan tiga hal yang biasanya tidak dimiliki oleh alat berbasis Barat.
Penanganan teks RTL: kepatuhan bidireksi Unicode untuk alur teks yang benar, serta tokenisasi RTL-aware yang menemukan batas kata dalam teks dari kanan ke kiri.
NER yang memahami morfologi: penganalisis morfologi seperti Farasa untuk bahasa Arab, atau model transformer yang di-fine-tune pada data NER RTL yang telah mempelajari variasi morfologi.
Tipe entitas spesifik wilayah: Emirates ID, ID Israel, Saudi National ID, dan Egyptian National ID masing-masing membutuhkan definisi eksplisit dengan aturan format. Alat Barat generik tidak memiliki ini.
Lihat bagaimana pipeline NER multibahasa kami menangani deteksi skrip dalam 48 bahasa. Untuk daftar lengkap tipe pengenal MENA yang kami dukung, kunjungi katalog entitas. Panduan kepatuhan GDPR kami menjelaskan bagaimana kesenjangan deteksi menciptakan eksposur berdasarkan Pasal 32.