GDPR-এর জন্য বহুভাষিক PII শনাক্তকরণ
২০২৬-এর জন্য আপডেটেড
লুকানো GDPR ফাঁক
GDPR-এর কোনো ভাষা পছন্দ নেই। আর্টিকেল ৪(১) এটি যে ভাষায় উপস্থিত তার নাম না দিয়ে "ব্যক্তিগত ডেটা" সংজ্ঞায়িত করে। একটি জার্মান Steuer-ID মার্কিন সামাজিক নিরাপত্তা নম্বরের মতোই সুরক্ষিত। একটি ফরাসি NIR ইউকে ন্যাশনাল ইন্স্যুরেন্স নম্বরের মতোই নিয়ন্ত্রিত।
বেশিরভাগ PII শনাক্তকরণ টুল কেবল ইংরেজির জন্য তৈরি হয়েছিল।
ACL ২০২৪-এর গবেষণায় দেখা গেছে যে হাইব্রিড NLP টুলগুলো ইউরোপীয় লোকেলের জন্য F1 স্কোর ০.৬০–০.৮৩ অর্জন করে। ইংরেজি-কেবল টুলগুলো অ-ইংরেজি জাতীয় ID ফরম্যাটের জন্য শূন্যের কাছাকাছি স্কোর পায়। ফাঁকটি স্পষ্ট। একটি টুল ইংরেজি PII-এর ৯৫% ধরতে পারে। তবুও এটি একই ফাইলে জার্মান, ফরাসি, পোলিশ, বা ডাচ PII-এর ৪০–৬০% মিস করে। এটি একটি গুরুতর সমস্যা। এটি কোম্পানিগুলোকে উন্মুক্ত রাখে।
এটি একটি বাস্তব GDPR ফাঁক। এটি ইংরেজি-কেন্দ্রিক রিডেকশন টুল ব্যবহার করা প্রায় প্রতিটি বৈশ্বিক সংস্থাকে প্রভাবিত করে। আরো তথ্যের জন্য আমাদের GDPR গাইড দেখুন।
কেন PII লোকেল-নির্দিষ্ট
PII শনাক্তকরণের দুটি অংশ আছে।
প্রথমটি হলো প্যাটার্ন-ভিত্তিক স্ক্যানিং। এটি ট্যাক্স নম্বর এবং ফোন ফরম্যাটের মতো কাঠামোগত আইডি কভার করে।
দ্বিতীয়টি হলো NER-ভিত্তিক স্ক্যানিং। এটি নাম এবং ঠিকানার মতো প্রাসঙ্গিক সত্তা কভার করে।
উভয় অংশ লোকেলের উপর নির্ভর করে।
কাঠামোগত আইডি দেশ অনুযায়ী আলাদা
| দেশ | ট্যাক্স আইডি | ফরম্যাট | যাচাইকরণ |
|---|---|---|---|
| জার্মানি | Steuer-ID | ১১ সংখ্যা | Modulo-11 |
| ফ্রান্স | NIR | ১৫ সংখ্যা + ২-সংখ্যার কী | INSEE |
| সুইডেন | Personnummer | ১০ সংখ্যা | Luhn |
| পোল্যান্ড | PESEL | ১১ সংখ্যা | Modulo-10 |
| নেদারল্যান্ডস | BSN | ৯ সংখ্যা | Elfproef |
| স্পেন | DNI/NIE | ৮ সংখ্যা + অক্ষর | Modulo-23 |
| ইতালি | Codice Fiscale | ১৬ অক্ষর | কাস্টম চেকসাম |
SSN-এর জন্য একটি ইংরেজি-কেবল রেগেক্স (NNN-NN-NNNN) এই ফরম্যাটগুলোর কোনোটিই মেলাবে না। প্রতিটির নিজস্ব রেগেক্স দরকার। প্রতিটির নিজস্ব চেকসাম লজিকও দরকার।
NER-এর জন্য নেটিভ মডেল দরকার
জার্মান নামগুলো ইংরেজি থেকে আলাদা। "Hans-Dieter Müller" একটি নেটিভ জার্মান মডেলের কাছে স্পষ্ট। একটি ইংরেজি-প্রশিক্ষিত মডেল প্রায়শই এই ধরনের নামগুলো মিস করে।
মিথ্যা পজিটিভও একটি সমস্যা। Microsoft Presidio ইস্যু ট্র্যাকার দেখায় জার্মান শব্দগুলো ইংরেজি PII হিসেবে ভুলভাবে শ্রেণিবদ্ধ হচ্ছে। জার্মান ভাষায় "শূন্য" অর্থে "Null" শব্দটি একটি উদাহরণ। এটি ইংরেজি-প্রশিক্ষিত মডেলে মিথ্যা নাম হিট ট্রিগার করে। প্রোডাকশন ব্যবহারে, ত্রুটির হার প্রতি প্রকৃত সত্তায় ৩ মিথ্যা পজিটিভে স্ফীত হয় (Alvaro et al., 2024)।
নিয়ন্ত্রক ঝুঁকি
EU ডেটা সংস্থাগুলো এই সমস্যা সম্পর্কে সচেতন। বেশ কয়েকটি জাতীয় DPA নির্দেশিকা জারি করেছে।
জার্মান BfDI: GDPR আর্টিকেল ৫(১)(f) সমস্ত রেকর্ডে প্রযোজ্য। এটি তৃতীয়-পক্ষের টুলগুলো দ্বারা প্রক্রিয়াকৃত অ-ইংরেজি ডেটা কভার করে।
ফরাসি CNIL: ২০২৪ CNIL বার্ষিক প্রতিবেদন উদ্বেগ উত্থাপন করেছে। এটি ফরাসি-লোকেল PII স্ক্যানিং ছাড়া ফরাসি রেকর্ড পরিচালনাকারী AI টুলগুলোকে চিহ্নিত করেছে।
EU DPA-গুলো ব্যাপকভাবে: GDPR আর্টিকেল ২৫ (ডিজাইন দ্বারা গোপনীয়তা) প্রকৃত প্রক্রিয়াকৃত রেকর্ডের জন্য উপযুক্ত সুরক্ষা প্রয়োজন। এতে বৈশ্বিক ডিপ্লয়মেন্টে অ-ইংরেজি PII অন্তর্ভুক্ত।
ঝুঁকি স্পষ্ট। একটি সংস্থা GDPR অডিটে ইংরেজি বিষয়বস্তুতে ৯৫% PII শনাক্তকরণ দেখাতে পারে। কিন্তু যদি এটি একই টুল দিয়ে জার্মান, ফরাসি, এবং পোলিশ রেকর্ডও পরিচালনা করে, ফাঁকগুলো দেখা দেবে। অডিটরেরা লক্ষ্য করবে। জরিমানা আসতে পারে। আমরা এটি কীভাবে সমাধান করি তার জন্য আমাদের সুরক্ষা পৃষ্ঠা দেখুন।
তিন-স্তরীয় ডিজাইন
গবেষণা এবং প্রোডাকশন ব্যবহার সর্বোত্তম পদ্ধতি হিসেবে তিন-স্তরীয় হাইব্রিড ডিজাইন-এ একমত।
স্তর ১: নেটিভ spaCy মডেল
spaCy ২৫টি লোকেলের জন্য প্রশিক্ষিত মডেল প্রদান করে। এতে জার্মান, ফরাসি, স্প্যানিশ, পর্তুগিজ, ইতালিয়ান, ডাচ, রাশিয়ান, চীনা, জাপানিজ, কোরিয়ান, এবং পোলিশ অন্তর্ভুক্ত। প্রতিটি মডেল নেটিভ টেক্সটে প্রশিক্ষণ পায়। তারা প্রতিটি লোকেলের সিনট্যাক্স এবং সত্তা প্যাটার্ন শেখে। এটি গুরুত্বপূর্ণ। নেটিভ প্রশিক্ষণ মানে ভালো রিকল এবং কম মিথ্যা পজিটিভ।
জার্মানের জন্য: de_core_news_lg যৌগিক বিশেষ্য এবং জার্মান নামের প্যাটার্ন পরিচালনা করে।
ফরাসির জন্য: fr_core_news_lg ফরাসি সত্তা, শিরোনাম, স্থানের নাম, এবং সংগঠন পরিচালনা করে।
নেটিভ মডেল উচ্চ-সম্পদ লোকেলের নাম স্ক্যানিংয়ে ক্রস-লিঙ্গুয়াল মডেলকে হারায়।
স্তর ২: আরো লোকেলের জন্য Stanza
স্ট্যানফোর্ডের Stanza লাইব্রেরি spaCy-তে নেই এমন লোকেলগুলো কভার করে। এতে ক্রোয়েশিয়ান, স্লোভেনিয়ান, এবং ইউক্রেনীয় অন্তর্ভুক্ত। এটি spaCy পরিষেবা না দেওয়া EU স্পিকার গ্রুপের জন্য পৌঁছানো বাড়ায়। Stanza বিনামূল্যে এবং ওপেন সোর্স। এটি বাকি স্ট্যাকের সাথে ভালোভাবে একত্রিত হয়।
স্তর ৩: ব্যাপক পৌঁছানোর জন্য XLM-RoBERTa
যে লোকেলে spaCy এবং Stanza-এর NER মডেল নেই সেখানে XLM-RoBERTa ফাঁক পূরণ করে। এটি ১০০টি লোকেলে Common Crawl টেক্সটে প্রশিক্ষণ পায়। এটি PII শনাক্তকরণের জন্য ৯১.৪% ক্রস-লিঙ্গুয়াল F1 অর্জন করে (HuggingFace 2024)। এটি কোড-স্যুইচিং ভালোভাবে পরিচালনা করে। এটি একটি মূল বৈশিষ্ট্য। এটি গুরুত্বপূর্ণ যখন একটি ডকুমেন্টে একসাথে বেশ কয়েকটি লোকেলে টেক্সট থাকে।
বহুভাষিক ভলিউমের সাথে API কল কীভাবে স্কেল হয় তা দেখতে আমাদের টোকেন সিস্টেম ডকস দেখুন।
লোকেল-নির্দিষ্ট সত্তার ধরন
মডেল একা যথেষ্ট নয়। GDPR সামঞ্জস্যের জন্য দেশ-নির্দিষ্ট আইডির জন্য সত্তার ধরন স্কোপও প্রয়োজন।
দেশ অনুযায়ী EU জাতীয় আইডি:
- DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
- FR: NIR, SIREN, SIRET
- PL: PESEL, NIP, REGON
- NL: BSN
- SE: Personnummer, Samordningsnummer
- ES: DNI, NIE, NIF, CIF
- IT: Codice Fiscale, Partita IVA
ফোন ফরম্যাট: প্রতিটি EU দেশের অনন্য প্রিফিক্স কাঠামো রয়েছে। +৪৯, +৩৩, এবং +৪৮ প্রতিটির নিজস্ব যাচাইকরণ লজিক দরকার।
ঠিকানার ফরম্যাট: পোস্টাল কোড ব্যাপকভাবে পরিবর্তিত হয়। জার্মান PLZ ৫ সংখ্যা ব্যবহার করে। ফরাসি কোড ৫ সংখ্যা (০১–৯৯ পরিসর) ব্যবহার করে। ইউকে পোস্টকোড আলফানিউমেরিক। স্প্যানিশ কোড ৫ সংখ্যা (০১০০০–৫২৯৯৯) ব্যবহার করে।
বাস্তব-বিশ্বের ঘটনা: সুইস ফার্মা
একটি সুইস সংস্থা কর্মসংস্থান চুক্তি প্রক্রিয়া করে। প্রতিটি চুক্তিতে জার্মান, ফরাসি, এবং ইংরেজি টেক্সট মিশ্রিত। সুইজারল্যান্ডের চারটি সরকারি ভাষা রয়েছে। তাদের টুল কেবল জার্মানির জন্য সেট আপ করা হয়েছিল। এটি সমস্ত ফরাসি-বিভাগের PII মিস করেছিল।
জেনেভা-ভিত্তিক কর্মচারীর একটি চুক্তিতে একটি ফরাসি AVS নম্বর (১৩ সংখ্যা), একটি সুইস ব্যাংক IBAN, এবং ফরাসি ফরম্যাটে একটি নাম ছিল। শুধু-জার্মান টুলটি ফরাসি-ফরম্যাটের নাম মিস করেছে। এটি ফরাসি AVS নম্বর খুঁজে পেতে ব্যর্থ হয়েছে। এটি কেবলমাত্র আংশিকভাবে IBAN শনাক্ত করেছে।
তিন-স্তরীয় পদ্ধতি সম্পূর্ণ ডকুমেন্ট প্রক্রিয়া করে। এটি প্রতিটি টেক্সট বিভাগ অনুযায়ী লোকেল শনাক্ত করে। এটি প্রতিটি অংশের জন্য সঠিক NER মডেল প্রয়োগ করে। এটি সঠিক দেশের লজিক দিয়ে প্রতিটি জাতীয় আইডি যাচাই করে।
মিশ্র-লোকেল ডকুমেন্ট
সবচেয়ে কঠিন ঘটনা হলো ইন্ট্রা-ডকুমেন্ট লোকেল মিশ্রণ। উদাহরণ:
- একটি জার্মান ফার্মের ইংরেজি চুক্তিতে জার্মান কর্মচারী রেকর্ড (নাম, ট্যাক্স আইডি)
- একটি ইংরেজি গোপনীয়তা উদ্ধৃতি সহ একটি ফরাসি GDPR সম্মতি ফর্ম
- একটি চ্যাট যেখানে এজেন্ট ইংরেজিতে উত্তর দেয় এবং গ্রাহক আরবিতে লেখে
XLM-RoBERTa এটি নেটিভলি পরিচালনা করে। এটির কোনো স্পষ্ট লোকেল ফ্ল্যাগ দরকার নেই। এটি পূর্ববর্তী বিভাজন ছাড়াই মিশ্র-লোকেল টেক্সট প্রক্রিয়া করে। এটি সময় বাঁচায়। এটি ত্রুটিপূর্ণ বিভাজন থেকে ত্রুটিও এড়ায়।
প্রোডাকশন ব্যবহারের জন্য, XLM-RoBERTa অনুমানের সাথে অটো লোকেল শনাক্তকরণ (বাক্য স্তরে) সংযুক্ত করলে মিশ্র-লোকেল ডকুমেন্টের শক্তিশালী পরিচালনা পাওয়া যায়।
ব্যবহারিক পদক্ষেপ
আপনার টুলের পৌঁছানো অডিট করুন। আপনার রিডেকশন ভেন্ডরের কাছে আপনার নির্দিষ্ট লোকেলের জন্য F1 স্কোর চান। "২০টি ভাষা সমর্থন করে" প্রায়শই মানে টুলটি প্রথমে মেশিন ট্রান্সলেশনের মাধ্যমে টেক্সট রুট করে। এটি নেটিভ স্ক্যানিং নয়।
আপনার রেকর্ডগুলো লোকেলে ম্যাপ করুন। লোকেল বিতরণ অন্তর্ভুক্ত একটি রেকর্ড ইনভেন্টরি করুন। ৭০% ইংরেজি, ২০% জার্মান, এবং ১০% ফরাসি সহ একটি বৈশ্বিক সংস্থা ভিন্ন ঝুঁকির মুখোমুখি। ৯৫% ইংরেজি সহ একটি ভিন্ন অবস্থানে।
জাতীয় আইডি নমুনা দিয়ে পরীক্ষা করুন। আপনার কার্যক্রমে জাতীয় আইডির ১০টি উদাহরণ সহ একটি পরীক্ষা সেট তৈরি করুন — Steuer-ID, NIR, PESEL, BSN, এবং অন্যান্য। শনাক্তকরণের হার যাচাই করুন। এটি পূর্ণ F1 পরীক্ষার চেয়ে দ্রুত।
আপনার DPIA পর্যালোচনা করুন। লোকেল স্কোপ অন্তর্ভুক্ত কিনা পরীক্ষা করুন। একটি অসম্পূর্ণ DPIA যা শুধু-ইংরেজি রেকর্ড ধরে নেয় তার আপডেট দরকার হতে পারে। এখনই পদক্ষেপ নিন। অডিট ফাঁক খুঁজে পাওয়া পর্যন্ত অপেক্ষা করবেন না।
সম্পূর্ণ সত্তার ধরন সংজ্ঞার জন্য সত্তা রেফারেন্স এবং FAQ দেখুন। পরিকল্পনা এবং API কল হারের জন্য মূল্য নির্ধারণ দেখুন।
anonym.legal-এর PII শনাক্তকরণ ইঞ্জিন একটি তিন-স্তরীয় বহুভাষিক পদ্ধতি ব্যবহার করে। এটি নেটিভ spaCy মডেলের মাধ্যমে ২৫টি উচ্চ-সম্পদ লোকেল কভার করে। Stanza অতিরিক্ত লোকেল পৌঁছানো যোগ করে। XLM-RoBERTa ক্রস-লিঙ্গুয়াল ট্রান্সফর্মার স্কোপ ৪৮টি লোকেলে প্রসারিত করে। সমস্ত EU সদস্য রাষ্ট্রের জন্য দেশ-নির্দিষ্ট সত্তার ধরন অন্তর্ভুক্ত।