2026 के लिए अपडेट किया गया
छिपा हुआ GDPR अंतर
GDPR की कोई भाषा प्राथमिकता नहीं है। अनुच्छेद 4(1) "व्यक्तिगत डेटा" को उस भाषा का उल्लेख किए बिना परिभाषित करता है जिसमें वह दिखाई देता है। एक जर्मन Steuer-ID उतनी ही संरक्षित है जितनी एक US सोशल सिक्योरिटी नंबर। एक फ्रेंच NIR उतनी ही विनियमित है जितनी एक UK राष्ट्रीय बीमा संख्या।
अधिकांश PII पहचान टूल केवल अंग्रेज़ी के लिए बनाए गए थे।
ACL 2024 के शोध ने पाया कि हाइब्रिड NLP टूल यूरोपीय लोकेल के लिए 0.60–0.83 का F1 स्कोर प्राप्त करते हैं। गैर-अंग्रेज़ी राष्ट्रीय ID प्रारूपों के लिए अंग्रेज़ी-केवल टूल शून्य के करीब स्कोर करते हैं। अंतर स्पष्ट है। एक टूल अंग्रेज़ी PII का 95% पकड़ सकता है। फिर भी वह उसी फाइल में जर्मन, फ्रेंच, पोलिश या डच PII का 40–60% चूक जाता है। यह एक गंभीर समस्या है। यह कंपनियों को उजागर छोड़ देती है।
यह एक वास्तविक GDPR अंतर है। यह अंग्रेज़ी-केंद्रित रिडेक्शन टूल का उपयोग करने वाली लगभग हर वैश्विक फर्म को प्रभावित करता है। अधिक जानकारी के लिए हमारा GDPR गाइड देखें।
PII लोकेल-विशिष्ट क्यों है
PII पहचान के दो भाग हैं।
पहला है पैटर्न-आधारित स्कैनिंग। यह कर नंबर और फोन प्रारूप जैसे संरचित ID को कवर करता है।
दूसरा है NER-आधारित स्कैनिंग। यह नाम और पते जैसी संदर्भ संस्थाओं को कवर करता है।
दोनों भाग लोकेल पर निर्भर करते हैं।
संरचित ID देश के अनुसार भिन्न होते हैं
| देश | कर ID | प्रारूप | सत्यापन |
|---|---|---|---|
| जर्मनी | Steuer-ID | 11 अंक | Modulo-11 |
| फ्रांस | NIR | 15 अंक + 2-अंकीय कुंजी | INSEE |
| स्वीडन | Personnummer | 10 अंक | Luhn |
| पोलैंड | PESEL | 11 अंक | Modulo-10 |
| नीदरलैंड | BSN | 9 अंक | Elfproef |
| स्पेन | DNI/NIE | 8 अंक + अक्षर | Modulo-23 |
| इटली | Codice Fiscale | 16 वर्ण | कस्टम चेकसम |
SSN (NNN-NN-NNNN) के लिए एक अंग्रेज़ी-केवल regex इनमें से किसी भी प्रारूप से मेल नहीं खाएगा। प्रत्येक को अपना regex चाहिए। प्रत्येक को अपना चेकसम तर्क भी चाहिए।
NER को नेटिव मॉडल की आवश्यकता है
जर्मन नाम अंग्रेज़ी से भिन्न हैं। "Hans-Dieter Müller" एक नेटिव जर्मन मॉडल के लिए स्पष्ट है। अंग्रेज़ी-प्रशिक्षित मॉडल अक्सर ऐसे नाम चूक जाते हैं।
झूठी सकारात्मकता भी एक समस्या है। Microsoft Presidio इश्यू ट्रैकर जर्मन शब्दों को अंग्रेज़ी PII के रूप में गलत वर्गीकृत दिखाता है। शब्द "Null" (जर्मन में "शून्य") एक उदाहरण है। यह अंग्रेज़ी-प्रशिक्षित मॉडल में गलत नाम हिट ट्रिगर करता है। उत्पादन उपयोग में, त्रुटि दरें प्रति वास्तविक संस्था 3 झूठी सकारात्मकता तक बढ़ जाती हैं (Alvaro et al., 2024)।
नियामक जोखिम
EU डेटा निकाय इस समस्या से अवगत हैं। कई राष्ट्रीय DPA ने मार्गदर्शन जारी किया है।
जर्मन BfDI: GDPR अनुच्छेद 5(1)(f) सभी रिकॉर्ड पर लागू होता है। यह तृतीय-पक्ष टूल द्वारा संसाधित गैर-अंग्रेज़ी डेटा को कवर करता है।
फ्रेंच CNIL: 2024 CNIL वार्षिक रिपोर्ट ने चिंताएं जताईं। इसने उन AI टूल को चिह्नित किया जो फ्रेंच-लोकेल PII स्कैनिंग के बिना फ्रेंच रिकॉर्ड संभालते हैं।
EU DPA व्यापक रूप से: GDPR अनुच्छेद 25 (डिज़ाइन द्वारा गोपनीयता) के लिए वास्तविक रिकॉर्ड के अनुरूप सुरक्षा उपाय आवश्यक हैं। इसमें वैश्विक डेप्लॉयमेंट में गैर-अंग्रेज़ी PII शामिल है।
जोखिम स्पष्ट है। एक फर्म GDPR ऑडिट में अंग्रेज़ी सामग्री पर 95% PII पहचान दिखा सकती है। लेकिन यदि वह उसी टूल से जर्मन, फ्रेंच और पोलिश रिकॉर्ड भी संभालती है, तो अंतराल दिखाई देंगे। ऑडिटर नोटिस लेते हैं। जुर्माने लग सकते हैं। हम इसे कैसे संबोधित करते हैं इसके लिए हमारा सुरक्षा उपाय पृष्ठ देखें।
तीन-स्तरीय डिज़ाइन
शोध और उत्पादन उपयोग सर्वोत्तम दृष्टिकोण के रूप में तीन-स्तरीय हाइब्रिड डिज़ाइन पर सहमत हैं।
स्तर 1: नेटिव spaCy मॉडल
spaCy 25 लोकेल के लिए प्रशिक्षित मॉडल प्रदान करता है। इनमें जर्मन, फ्रेंच, स्पेनिश, पुर्तगाली, इतालवी, डच, रूसी, चीनी, जापानी, कोरियाई और पोलिश शामिल हैं। प्रत्येक मॉडल नेटिव टेक्स्ट पर प्रशिक्षित होता है। वे प्रत्येक लोकेल के वाक्यविन्यास और संस्था पैटर्न सीखते हैं। यह मायने रखता है। नेटिव प्रशिक्षण का मतलब बेहतर रिकॉल और कम झूठी सकारात्मकता है।
जर्मन के लिए: de_core_news_lg यौगिक संज्ञाओं और जर्मन नाम पैटर्न को संभालता है।
फ्रेंच के लिए: fr_core_news_lg फ्रेंच संस्थाओं, शीर्षकों, स्थान नामों और संगठनों को संभालता है।
नेटिव मॉडल उच्च-संसाधन लोकेल पर नाम स्कैनिंग के लिए क्रॉस-लिंग्वल मॉडल को हराते हैं।
स्तर 2: अधिक लोकेल के लिए Stanza
Stanford की Stanza लाइब्रेरी उन लोकेल को कवर करती है जो spaCy में नहीं हैं। इनमें क्रोएशियाई, स्लोवेनियाई और यूक्रेनी शामिल हैं। यह EU स्पीकर समूहों के लिए पहुँच जोड़ता है जिन्हें spaCy सेवा नहीं देता। Stanza मुफ्त और ओपन सोर्स है। यह शेष स्टैक के साथ अच्छी तरह से एकीकृत होता है।
स्तर 3: व्यापक पहुँच के लिए XLM-RoBERTa
उन लोकेल के लिए जहाँ spaCy और Stanza में NER मॉडल की कमी है, XLM-RoBERTa अंतर भरता है। यह 100 लोकेल में Common Crawl टेक्स्ट पर प्रशिक्षित है। यह PII पहचान के लिए 91.4% क्रॉस-लिंग्वल F1 प्राप्त करता है (HuggingFace 2024)। यह कोड-स्विचिंग को अच्छी तरह संभालता है। यह एक प्रमुख विशेषता है। यह मायने रखती है जब एक दस्तावेज़ में एक साथ कई लोकेल में टेक्स्ट हो।
API कॉल बहुभाषी वॉल्यूम के साथ कैसे स्केल होते हैं, यह देखने के लिए हमारे टोकन सिस्टम दस्तावेज़ देखें।
लोकेल-विशिष्ट संस्था प्रकार
केवल मॉडल पर्याप्त नहीं हैं। GDPR संरेखण के लिए देश-विशिष्ट ID के लिए संस्था प्रकार दायरे की भी आवश्यकता है।
देश के अनुसार EU राष्ट्रीय ID:
- 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 देश के अद्वितीय उपसर्ग संरचनाएं हैं। +49, +33 और +48 प्रत्येक को अपना सत्यापन तर्क चाहिए।
पता प्रारूप: पोस्टल कोड व्यापक रूप से भिन्न होते हैं। जर्मन PLZ 5 अंक उपयोग करता है। फ्रेंच कोड 5 अंक उपयोग करते हैं (01–99 रेंज)। UK पोस्टकोड अल्फान्यूमेरिक हैं। स्पेनिश कोड 5 अंक उपयोग करते हैं (01000–52999)।
वास्तविक मामला: स्विस फार्मा
एक स्विस फर्म रोज़गार अनुबंध संसाधित करती है। प्रत्येक अनुबंध जर्मन, फ्रेंच और अंग्रेज़ी टेक्स्ट मिलाता है। स्विट्ज़रलैंड की चार आधिकारिक भाषाएं हैं। उनका टूल केवल जर्मन के लिए सेट था। यह सभी फ्रेंच-अनुभाग PII चूक गया।
जिनेवा-आधारित एक कर्मचारी के अनुबंध में एक फ्रेंच AVS नंबर (13 अंक), एक स्विस बैंक IBAN और एक फ्रेंच प्रारूप में नाम शामिल था। जर्मन-केवल टूल ने फ्रेंच-प्रारूप नाम चूका। यह फ्रेंच AVS नंबर खोजने में विफल रहा। इसने IBAN को केवल आंशिक रूप से पहचाना।
तीन-स्तरीय दृष्टिकोण पूरे दस्तावेज़ को संसाधित करता है। यह प्रति टेक्स्ट खंड लोकेल पहचानता है। यह प्रत्येक भाग के लिए सही NER मॉडल लागू करता है। यह सही देश तर्क के साथ प्रत्येक राष्ट्रीय ID सत्यापित करता है।
मिश्रित-लोकेल दस्तावेज़
सबसे कठिन मामला दस्तावेज़ के भीतर लोकेल मिश्रण है। उदाहरण:
- एक जर्मन फर्म का अंग्रेज़ी अनुबंध जर्मन कर्मचारी रिकॉर्ड (नाम, कर ID) के साथ
- अंग्रेज़ी गोपनीयता अंश के साथ एक फ्रेंच GDPR सहमति फॉर्म
- एक चैट जिसमें एजेंट अंग्रेज़ी में जवाब देता है और ग्राहक अरबी में लिखता है
XLM-RoBERTa इसे मूल रूप से संभालता है। इसे कोई स्पष्ट लोकेल फ्लैग की आवश्यकता नहीं है। यह पूर्व खंडीकरण के बिना मिश्रित-लोकेल टेक्स्ट संसाधित करता है। इससे समय की बचत होती है। यह गलत विभाजन से होने वाली त्रुटियों से भी बचाता है।
उत्पादन उपयोग के लिए, ऑटो लोकेल पहचान (वाक्य स्तर पर) को XLM-RoBERTa अनुमान के साथ संयोजित करना मिश्रित-लोकेल दस्तावेज़ों को मजबूत तरीके से संभालता है।
व्यावहारिक कदम
अपने टूल की पहुँच की जाँच करें। अपने रिडेक्शन विक्रेता से अपने विशिष्ट लोकेल के लिए F1 स्कोर माँगें। "20 भाषाओं का समर्थन करता है" का अक्सर मतलब होता है कि टूल पहले मशीन ट्रांसलेशन के माध्यम से टेक्स्ट रूट करता है। यह नेटिव स्कैनिंग नहीं है।
अपने रिकॉर्ड को लोकेल में मैप करें। एक रिकॉर्ड इन्वेंटरी करें जिसमें लोकेल वितरण शामिल हो। 70% अंग्रेज़ी, 20% जर्मन और 10% फ्रेंच के साथ एक वैश्विक फर्म अलग-अलग जोखिम का सामना करती है। 95% अंग्रेज़ी वाली एक फर्म अलग स्थिति में है।
राष्ट्रीय ID नमूनों के साथ परीक्षण करें। अपने संचालन में राष्ट्रीय ID के 10 उदाहरणों के साथ एक परीक्षण सेट बनाएं — Steuer-ID, NIR, PESEL, BSN और अन्य। पहचान दरों को सत्यापित करें। यह पूर्ण F1 परीक्षण से तेज़ है।
अपने DPIA की समीक्षा करें। जाँचें कि क्या लोकेल दायरा शामिल है। अंग्रेज़ी-केवल रिकॉर्ड मानने वाली अधूरी DPIA को अपडेट की आवश्यकता हो सकती है। अभी कार्य करें। किसी ऑडिट के अंतर खोजने का इंतज़ार न करें।
पूर्ण संस्था प्रकार परिभाषाओं के लिए, संस्थाएं संदर्भ और FAQ देखें। योजनाओं और API कॉल दरों के लिए, मूल्य निर्धारण देखें।
anonym.legal की PII पहचान इंजन तीन-स्तरीय बहुभाषी दृष्टिकोण उपयोग करती है। यह नेटिव spaCy मॉडल के माध्यम से 25 उच्च-संसाधन लोकेल को कवर करती है। Stanza अतिरिक्त लोकेल पहुँच जोड़ता है। XLM-RoBERTa क्रॉस-लिंग्वल ट्रांसफॉर्मर दायरे को 48 लोकेल तक बढ़ाते हैं। सभी EU सदस्य राज्यों के लिए देश-विशिष्ट संस्था प्रकार शामिल हैं।