شکاف انطباق در خطوط نوشتاری راست‌به‌چپ
GDPR در بسفر تمام نمی‌شود. شرکت‌های اتحادیه اروپا که از ابزارهای مبتنی بر الفبای لاتین استفاده می‌کنند، نقطه کور جدی دارند. این مشکل واقعی است و به‌طور گسترده‌ای نادیده گرفته می‌شود.
مشکل تنها به جهت نوشتار مربوط نمی‌شود. متون راست‌به‌چپ به توکن‌بندی متفاوت نیاز دارند. به تقطیع متفاوت نیاز دارند. مرزهای موجودیت‌ها نسبت به متون چپ‌به‌راست به شکل دیگری عمل می‌کنند. سیستم‌های NER که بر روی زبان انگلیسی آموزش دیده‌اند، قوانین چپ‌به‌راست را اعمال می‌کنند. این قوانین در متن راست‌به‌چپ از کار می‌افتند و مرزهای موجودیت را اشتباه تشخیص می‌دهند.
ریخت‌شناسی زبان عربی مسئله را پیچیده‌تر می‌کند. این زبان بر پایه ریشه است. از یک ریشه، ده‌ها فرم واژگانی ساخته می‌شود. نامی مثل «محمد» می‌تواند به صورت «المحمد»، «بن محمد» یا «محمد الرشید» ظاهر شود. الگوهای regex که برای نام‌های غربی طراحی شده‌اند این فرم‌ها را از دست می‌دهند. مدل‌های آموزش‌دیده بر روی انگلیسی هم همین‌طور.
GDPR زبان را به عنوان مرز انطباقی تلقی نمی‌کند. یک شرکت اتحادیه اروپا که نامه‌های مشتریان منطقه خاورمیانه و شمال آفریقا را پردازش می‌کند، باید از همان قوانینی پیروی کند که برای نامه‌های فرانسوی اعمال می‌شود. نادیده گرفتن اطلاعات شخصی در متون راست‌به‌چپ، نقض حقوقی آشکار ماده ۳۲ GDPR محسوب می‌شود.
مورد استفاده: احراز هویت مشتری (KYC)
یک شرکت فین‌تک دبی که اسناد KYC مشتریان اتحادیه اروپا را پردازش می‌کند، این مشکل را به خوبی نشان می‌دهد.
پرونده‌های KYC مشتریان عرب شامل نام‌ها به خط راست‌به‌چپ، شماره‌های هویت اماراتی (Emirates ID)، و آدرس‌های راست‌به‌چپ هستند. این داده‌ها در کنار متن تجاری انگلیسی قرار می‌گیرند.
فرمت Emirates ID به شکل ۷۸۴-XXXX-XXXXXXX-X است: کد کشور ۷۸۴، سال تولد، هفت رقم، و رقم کنترل. ابزارهای غربی تشخیص اطلاعات شخصی که تعریفی برای موجودیت‌های اماراتی ندارند، این فرمت را نمی‌یابند. فیلدهای نام از طریق NER الفبای لاتین پردازش می‌شوند. تقطیع اشتباه است. اطلاعات شناسایی شخصی در فرآیند پردازش نامرئی می‌شوند.
برای شرکت‌هایی که تعهدات GDPR بر این داده‌ها دارند، این شکاف ریسک حقوقی واقعی ایجاد می‌کند. ماده ۳۲ GDPR مستلزم اتخاذ تدابیر فنی مناسب است. ابزاری که شناسه‌ها را در ۲۲ درصد از زبان‌های جهان از دست می‌دهد، تدبیر فنی مناسبی نیست.
عبری و اسناد چندزبانه
زبان عبری مشکلات مشابهی دارد. این خط راست‌به‌چپ نوشته می‌شود. شماره‌های هویت ملی اسرائیل از یک جمع کنترلی استفاده می‌کنند — آزمونی شبیه الگوریتم Luhn بر روی نه رقم.
اسناد حقوقی اسرائیلی اغلب عبری، متن عربی و انگلیسی را در یک فایل ترکیب می‌کنند. این امر در قراردادهایی که عبری زبان اصلی و اصطلاحات انگلیسی به عنوان مرجع اضافه می‌شوند رایج است.
فایل‌های چندخطی نیاز به تشخیص نوع خط پیش از NER دارند. بدون این مرحله، یک پاس NER واحد قوانین لاتین را بر خطوط راست‌به‌چپ اعمال می‌کند. خروجی نادرست خواهد بود.
تحقیقات منتشرشده در Nature Scientific Reports (2025) مدل‌های NER چندزبانه را بر روی اطلاعات شخصی راست‌به‌چپ آزمود. مدل‌های استاندارد امتیاز F1 بین ۰.۶۰ تا ۰.۸۳ کسب کردند. مدل XLM-RoBERTa که بر داده‌های NER راست‌به‌چپ تنظیم دقیق شده بود، امتیاز ۰.۸۸ و بالاتر به دست آورد.
الزامات معماری چندزبانه
تشخیص خوب اطلاعات شناسایی شخصی در خطوط راست‌به‌چپ به سه چیز نیاز دارد که ابزارهای غرب‌محور معمولاً فاقد آن‌ها هستند.
پشتیبانی از متن راست‌به‌چپ: رعایت استاندارد دوجهته یونیکد برای جریان صحیح متن. توکن‌بندی آگاه به راست‌به‌چپ که مرزهای کلمات را در متون راست‌به‌چپ شناسایی کند.
NER آگاه از ریخت‌شناسی: تحلیلگر ریخت‌شناختی مانند Farasa برای عربی، یا یک مدل ترانسفورمر که بر داده‌های NER راست‌به‌چپ تنظیم دقیق شده است. مدل باید تنوعات ریخت‌شناختی را آموخته باشد.
انواع موجودیت‌های منطقه‌ای: Emirates ID، شناسه ملی اسرائیل، شناسه ملی عربستان، و شناسه ملی مصر هرکدام به تعریف‌های صریح با قوانین فرمت نیاز دارند. ابزارهای غربی عمومی این موجودیت‌ها را ندارند.
ببینید پایپ‌لاین NER چندزبانه ما چگونه تشخیص نوع خط را در ۴۸ زبان مدیریت می‌کند. برای فهرست کامل انواع شناسه‌های MENA که پشتیبانی می‌کنیم، به کاتالوگ موجودیت‌ها مراجعه کنید. راهنمای انطباق GDPR ما توضیح می‌دهد که شکاف‌های تشخیص چگونه مواجهه با ماده ۳۲ را ایجاد می‌کنند.