RTL কমপ্লায়েন্স গ্যাপ
GDPR বসফরাসে শেষ হয় না। EU-এর যে কোম্পানিগুলো ল্যাটিন-স্ক্রিপ্ট টুল ব্যবহার করে, তাদের একটি বড় দুর্বলতা রয়েছে। এটি বাস্তব সমস্যা, এবং এটি বেশিরভাগ ক্ষেত্রেই উপেক্ষিত।
সমস্যাটি শুধু টেক্সটের দিকনির্দেশনার বিষয় নয়। ডান-থেকে-বাম (RTL) স্ক্রিপ্টগুলোর জন্য আলাদা টোকেনাইজেশন দরকার। আলাদা সেগমেন্টেশন দরকার। LTR টেক্সটের তুলনায় এন্টিটি বাউন্ডারি ভিন্নভাবে কাজ করে। ইংরেজিতে প্রশিক্ষিত NER সিস্টেম LTR নিয়ম প্রয়োগ করে। সেই নিয়মগুলো RTL টেক্সটে ভেঙে পড়ে এবং ভুল এন্টিটি বাউন্ডারি দেয়।
আরবি মরফোলজি পরিস্থিতিকে আরও জটিল করে তোলে। ভাষাটি মূল শব্দ (root) ব্যবহার করে। একটি মূল থেকে ডজনখানেক শব্দরূপ তৈরি হয়। Mohammed নামটি "Al-Mohammed", "bin Mohammed" বা "Mohammed al-Rashid" হিসেবে আসতে পারে। পশ্চিমা নামের জন্য তৈরি রেজেক্স প্যাটার্ন এই রূপগুলো ধরতে পারে না। ইংরেজিতে প্রশিক্ষিত মডেলও পারে না।
GDPR ভাষাকে কমপ্লায়েন্সের সীমানা হিসেবে বিবেচনা করে না। MENA ক্লায়েন্টদের মেল প্রসেস করা একটি EU ফার্মকে ফরাসি মেলের মতো একই নিয়ম মানতে হবে। RTL টেক্সটে PII মিস করা GDPR আর্টিকেল 32-এর অধীনে আইনি ব্যর্থতা।
KYC ব্যবহারের ক্ষেত্র
EU ক্লায়েন্টদের জন্য KYC ডকুমেন্ট প্রসেস করা একটি দুবাই ফিনটেক এটি স্পষ্টভাবে দেখায়।
আরব ক্লায়েন্টদের KYC ফাইলে RTL স্ক্রিপ্টে নাম, UAE এমিরেটস আইডি এবং RTL ঠিকানা থাকে। এগুলো ইংরেজি ব্যবসায়িক টেক্সটের পাশে থাকে।
এমিরেটস আইডি ফরম্যাট হলো 784-XXXX-XXXXXXX-X। কান্ট্রি কোড 784। জন্ম সাল। সাতটি ডিজিট। চেক ডিজিট। UAE এন্টিটি ডেফিনিশন ছাড়া পশ্চিমা PII টুল এই ফরম্যাট খুঁজে পাবে না। নামের ফিল্ডগুলো ল্যাটিন-স্ক্রিপ্ট NER-এর মধ্য দিয়ে যায়। সেগমেন্টেশন ভুল হয়। PII ওয়ার্কফ্লোতে অদৃশ্য হয়ে যায়।
এই ডেটার উপর GDPR দায়িত্ব থাকা ফার্মগুলোর জন্য এই গ্যাপটি বাস্তব আইনি ঝুঁকি তৈরি করে। GDPR আর্টিকেল 32 যথাযথ প্রযুক্তিগত ব্যবস্থার দাবি রাখে। বিশ্বের 22% ভাষায় পরিচয়দাতাকারী তথ্য মিস করে এমন একটি টুল যথাযথ ব্যবস্থা নয়।
হিব্রু এবং মিশ্র-ভাষার ডকুমেন্ট
হিব্রু একই ধরনের সমস্যা তৈরি করে। স্ক্রিপ্টটি ডান থেকে বামে চলে। ইসরায়েলি আইডি নম্বর নয়টি ডিজিটে একটি চেকসাম ব্যবহার করে — Luhn-এর মতো পরীক্ষা।
ইসরায়েলি আইনি ডকুমেন্টে প্রায়ই একটি ফাইলে হিব্রু, আরবি-স্ক্রিপ্ট টেক্সট এবং ইংরেজি মিশ্রিত থাকে। চুক্তিতে এটি সাধারণ, যেখানে হিব্রু প্রধান ভাষা এবং ইংরেজি শর্তাবলী রেফারেন্স হিসেবে যোগ করা হয়।
মিশ্র-স্ক্রিপ্ট ফাইলের জন্য NER-এর আগে স্ক্রিপ্ট ডিটেকশন দরকার। এটি না থাকলে একটি NER পাস RTL স্ক্রিপ্টে ল্যাটিন নিয়ম প্রয়োগ করে। আউটপুট ভুল হয়।
Nature Scientific Reports (2025)-এর গবেষণা RTL PII-তে ক্রস-লিঙ্গুয়াল NER পরীক্ষা করেছে। স্ট্যান্ডার্ড মডেল F1 স্কোর 0.60–0.83 পেয়েছে। RTL NER ডেটায় ফাইন-টিউন করা XLM-RoBERTa 0.88 এবং তার উপরে স্কোর করেছে।
ক্রস-লিঙ্গুয়াল আর্কিটেকচারের প্রয়োজনীয়তা
ভালো RTL PII ডিটেকশনে তিনটি জিনিস দরকার যা পশ্চিমা-প্রথম টুলে সাধারণত নেই।
RTL টেক্সট হ্যান্ডলিং: সঠিক টেক্সট ফ্লোর জন্য Unicode বাইডিরেকশনাল কমপ্লায়েন্স। ডানে-বামে টেক্সটে শব্দ সীমানা খুঁজে পেতে RTL-সচেতন টোকেনাইজেশন।
মরফোলজি-সচেতন NER: আরবির জন্য Farasa-এর মতো মরফোলজিক্যাল অ্যানালাইজার, অথবা RTL NER ডেটায় ফাইন-টিউন করা ট্রান্সফর্মার মডেল। মডেলটিকে অবশ্যই মরফোলজিক্যাল বৈচিত্র্য শিখতে হবে।
রিজিয়ন-স্পেসিফিক এন্টিটি টাইপ: এমিরেটস আইডি, ইসরায়েলি আইডি, সৌদি ন্যাশনাল আইডি এবং ইজিপশিয়ান ন্যাশনাল আইডি প্রতিটির জন্য ফরম্যাট নিয়ম সহ স্পষ্ট ডেফিনিশন দরকার। জেনেরিক পশ্চিমা টুলে এগুলো নেই।
48টি ভাষায় স্ক্রিপ্ট ডিটেকশন কীভাবে পরিচালনা করে তা দেখুন আমাদের মাল্টিলিঙ্গুয়াল NER পাইপলাইন-এ। আমরা যে MENA পরিচয়দাতাকারী ধরনগুলো সমর্থন করি তার সম্পূর্ণ তালিকার জন্য এন্টিটি ক্যাটালগ দেখুন। GDPR কমপ্লায়েন্স গাইড-এ আলোচনা করা হয়েছে কীভাবে ডিটেকশন গ্যাপ আর্টিকেল 32-এর ঝুঁকি তৈরি করে।