RTL تعمیل کا خلا
GDPR باسفورس پر ختم نہیں ہوتا۔ یورپی کمپنیاں جو لاطینی رسم الخط کے ٹولز استعمال کرتی ہیں ان کے پاس ایک اندھا مقام ہے۔ یہ حقیقی ہے اور بڑے پیمانے پر نظرانداز کیا جاتا ہے۔
مسئلہ صرف متن کی سمت نہیں ہے۔ دائیں سے بائیں رسم الخط کو مختلف ٹوکنائزیشن کی ضرورت ہے۔ انہیں مختلف سیگمنٹیشن کی ضرورت ہے۔ ہستی کی حدیں LTR متن سے مختلف طریقے سے کام کرتی ہیں۔ انگریزی پر تربیت یافتہ NER سسٹم LTR قواعد لاگو کرتے ہیں۔ وہ قواعد RTL متن پر ٹوٹ جاتے ہیں اور غلط ہستی کی حدود دیتے ہیں۔
عربی مورفولوجی چیزوں کو مزید مشکل بناتی ہے۔ یہ زبان جڑوں کا استعمال کرتی ہے۔ ایک جڑ سے درجنوں الفاظ کی شکلیں بنتی ہیں۔ محمد جیسا نام "الـمحمد"، "بن محمد"، یا "محمد الـراشد" کے طور پر ظاہر ہو سکتا ہے۔ مغربی ناموں کے لیے بنائے گئے Regex پیٹرن ان شکلوں کو چھوڑ دیتے ہیں۔ انگریزی پر تربیت یافتہ ماڈل بھی انہیں چھوڑ دیتے ہیں۔
GDPR زبان کو تعمیل کی حد کے طور پر نہیں مانتا۔ ایک EU فرم جو MENA کلائنٹس کی میل پر کارروائی کرتی ہے اسے فرانسیسی میل کے لیے ایک جیسے قواعد پر پورا اترنا ہوگا۔ RTL متن میں PII چھوٹنا GDPR آرٹیکل 32 کے تحت قانونی ناکامی ہے۔
KYC کا استعمالی معاملہ
دبئی کی ایک فن ٹیک کمپنی جو EU کلائنٹس کے لیے KYC دستاویزات پر کارروائی کرتی ہے، یہ واضح طور پر ظاہر کرتی ہے۔
عرب کلائنٹس کی KYC فائلوں میں RTL رسم الخط میں نام، UAE ایمریٹس ID، اور RTL پتے ہوتے ہیں۔ یہ انگریزی کاروباری متن کے ساتھ موجود ہوتے ہیں۔
ایمریٹس ID کی شکل 784-XXXX-XXXXXXX-X ہے۔ ملک کا کوڈ 784۔ پیدائش کا سال۔ سات ہندسے۔ چیک ڈیجٹ۔ مغربی PII ٹولز جن میں UAE ہستی کی تعریفیں نہیں ہیں، یہ شکل نہیں ڈھونڈ سکتے۔ نام کے شعبے لاطینی رسم الخط NER سے گزرتے ہیں۔ سیگمنٹیشن غلط ہے۔ PII ورک فلو میں غیر مرئی ہو جاتا ہے۔
اس ڈیٹا پر GDPR ذمہ داریوں والی فرموں کے لیے، یہ خلا حقیقی قانونی خطرہ پیدا کرتا ہے۔ GDPR آرٹیکل 32 مناسب تکنیکی اقدامات کا تقاضا کرتا ہے۔ ایک ٹول جو دنیا کی 22% زبانوں میں شناختوں کو چھوڑتا ہے وہ مناسب اقدام نہیں ہے۔
عبرانی اور ملی جلی زبان کی دستاویزات
عبرانی بھی ایسی ہی مشکلات پیش کرتی ہے۔ رسم الخط دائیں سے بائیں چلتا ہے۔ اسرائیلی شناختی نمبر ایک checksum استعمال کرتے ہیں — نو ہندسوں پر Luhn جیسا ٹیسٹ۔
اسرائیلی قانونی دستاویزات اکثر ایک فائل میں عبرانی، عربی رسم الخط کا متن، اور انگریزی ملاتی ہیں۔ یہ ان معاہدوں میں عام ہے جہاں عبرانی مرکزی زبان ہے اور انگریزی اصطلاحات حوالہ کے طور پر شامل کی جاتی ہیں۔
ملی جلی رسم الخط کی فائلوں کو NER سے پہلے رسم الخط کی شناخت کی ضرورت ہے۔ اس کے بغیر، ایک NER پاس RTL رسم الخط پر لاطینی قواعد لاگو کرتا ہے۔ آؤٹ پٹ غلط ہوتا ہے۔
Nature Scientific Reports (2025) کی تحقیق نے RTL PII پر کراس لسانی NER کو آزمایا۔ معیاری ماڈلوں نے 0.60–0.83 کا F1 اسکور حاصل کیا۔ RTL NER ڈیٹا پر فائن ٹیون کیا گیا XLM-RoBERTa 0.88 اور اس سے اوپر اسکور کیا۔
کراس لسانی آرکیٹیکچر کی ضرورت
اچھے RTL PII ڈیٹیکشن کو تین چیزوں کی ضرورت ہے جو مغرب پہلے ٹولز میں عموماً نہیں ہوتیں۔
RTL متن کی ہینڈلنگ: صحیح متن کے بہاؤ کے لیے Unicode بی دائرکشنل تعمیل۔ RTL متن میں لفظ کی حدیں تلاش کرنے کے لیے RTL سے واقف ٹوکنائزیشن۔
مورفولوجی سے واقف NER: عربی کے لیے Farasa جیسا مورفولوجیکل تجزیہ کار، یا RTL NER ڈیٹا پر فائن ٹیون کیا گیا ٹرانسفارمر ماڈل۔ ماڈل کو مورفولوجیکل تغیر سیکھنا چاہیے تھا۔
خطہ مخصوص ہستی کی اقسام: ایمریٹس ID، اسرائیلی ID، سعودی قومی ID، اور مصری قومی ID ہر ایک کو فارمیٹ قواعد کے ساتھ واضح تعریفوں کی ضرورت ہے۔ عام مغربی ٹولز میں یہ نہیں ہیں۔
دیکھیں کہ ہماری کثیر لسانی NER پائپ لائن 48 زبانوں میں رسم الخط کی شناخت کیسے کرتی ہے۔ ہم جو MENA شناختی اقسام سپورٹ کرتے ہیں ان کی مکمل فہرست کے لیے، ہستی کیٹالاگ ملاحظہ کریں۔ ہماری GDPR تعمیل گائیڈ اس بارے میں بتاتی ہے کہ ڈیٹیکشن کے خلا آرٹیکل 32 کی نمائش کیسے پیدا کرتے ہیں۔