क्यों आपका PII पहचान उपकरण केवल अंग्रेजी बोलने वालों...

छिपा हुआ GDPR अनुपालन अंतर

GDPR की कोई भाषा प्राथमिकता नहीं है। अनुच्छेद 4(1) "व्यक्तिगत डेटा" को उस भाषा के संदर्भ के बिना परिभाषित करता है जिसमें यह प्रकट होता है। एक जर्मन Steuer-ID एक अमेरिकी सामाजिक सुरक्षा नंबर के रूप में सुरक्षित है। एक फ्रेंच NIR एक यूके राष्ट्रीय बीमा संख्या के रूप में विनियमित है।

लेकिन अधिकांश PII पहचान उपकरण अंग्रेजी के लिए बनाए गए थे।

ACL 2024 में प्रकाशित शोध ने पाया कि हाइब्रिड NLP दृष्टिकोण यूरोपीय स्थलों के लिए 0.60-0.83 के F1 स्कोर प्राप्त करते हैं - लेकिन गैर-अंग्रेजी पाठ पर लागू अंग्रेजी-केवल उपकरण संरचित राष्ट्रीय पहचानकर्ताओं के लिए लगभग शून्य स्कोर करते हैं। व्यावहारिक निहितार्थ: एक बहुराष्ट्रीय संगठन में तैनात एक अनामकरण उपकरण अंग्रेजी PII का 95% पहचान सकता है जबकि उसी डेटा सेट में जर्मन, फ्रेंच, पोलिश, या डच PII का 40-60% चूक सकता है।

यह एक प्रणालीगत GDPR अनुपालन अंतर है जो लगभग हर बहुराष्ट्रीय उद्यम को प्रभावित करता है जो अंग्रेजी-केंद्रित अनामकरण उपकरणों का उपयोग करता है।

क्यों PII भाषा-विशिष्ट है

PII पहचान में दो घटक होते हैं: पैटर्न-आधारित पहचान (संरचित पहचानकर्ता जैसे कर आईडी, फोन प्रारूप) और NER-आधारित पहचान (संदर्भित संस्थाएँ जैसे व्यक्ति के नाम, संगठन के नाम, पते)।

दोनों घटक गहराई से भाषा-विशिष्ट हैं।

संरचित पहचानकर्ता देश के अनुसार मौलिक रूप से भिन्न होते हैं

एक अंग्रेजी-केवल regex पैटर्न SSNs (फॉर्मेट: NNN-NN-NNNN) इनमें से किसी भी पहचानकर्ता से मेल नहीं खाएगा। प्रत्येक को देश-विशिष्ट regex तर्क और चेकसम सत्यापन की आवश्यकता होती है।

नामित इकाई पहचान के लिए भाषा-स्थानीय मॉडल की आवश्यकता होती है

जर्मन में व्यक्ति के नाम अंग्रेजी नामों की तुलना में अलग पैटर्न का पालन करते हैं। "Hans-Dieter Müller" और "Anna-Lena Schreiber-Koch" संदर्भ द्वारा जर्मन नामों के रूप में पहचाने जाते हैं - लेकिन एक मॉडल जो मुख्य रूप से अंग्रेजी पाठ पर प्रशिक्षित है, अक्सर उन्हें चूक जाएगा या गलत वर्गीकृत करेगा।

और अधिक समस्याग्रस्त: एक भाषा में झूठे सकारात्मक दूसरे में झूठे नकारात्मक बन सकते हैं। Microsoft Presidio GitHub समस्या ट्रैकर जर्मन शब्दों के अंग्रेजी PII के रूप में गलत वर्गीकृत होने के लिए प्रणालीगत झूठे सकारात्मक दस्तावेज करता है। वही शब्द "Null" (जर्मन में "शून्य") अंग्रेजी-प्रशिक्षित मॉडलों में नाम-पहचान झूठे सकारात्मक को ट्रिगर करता है। यह बहुभाषी उत्पादन वातावरण में 1 वास्तविक इकाई पर 3 त्रुटियों तक झूठे सकारात्मक दरों को बढ़ाता है (Alvaro et al., 2024)।

नियामक जोखिम

EU डेटा संरक्षण प्राधिकरण इस अंतर के प्रति लगातार जागरूक हो रहे हैं। कई राष्ट्रीय DPAs ने बहुभाषी प्रसंस्करण को प्रभावित करने वाले मार्गदर्शन या प्रवर्तन कार्रवाई जारी की है:

जर्मन BfDI: ने स्पष्ट किया है कि GDPR अनुच्छेद 5(1)(f) (अखंडता और गोपनीयता) सभी प्रसंस्करण रूपों में डेटा पर लागू होता है, जिसमें तीसरे पक्ष के उपकरणों द्वारा संसाधित गैर-अंग्रेजी डेटा शामिल है।

फ्रेंच CNIL: 2024 CNIL वार्षिक रिपोर्ट ने फ्रेंच-भाषा डेटा को संसाधित करने वाले AI उपकरणों के बारे में बढ़ती चिंताओं को नोट किया है जिनमें फ्रेंच-भाषा PII पहचान क्षमताएँ नहीं हैं।

यूरोपीय DPAs सामान्य रूप से: GDPR अनुच्छेद 25 (प्राइवेसी बाय डिज़ाइन) के तहत, तकनीकी उपायों को संसाधित किए जा रहे वास्तविक डेटा के लिए उपयुक्त होना चाहिए - जिसमें बहुराष्ट्रीय तैनाती में गैर-अंग्रेजी PII शामिल है।

व्यावहारिक जोखिम: एक संगठन एक GDPR ऑडिट के दौरान अंग्रेजी सामग्री पर 95% PII पहचान प्रभावशीलता प्रदर्शित कर सकता है, लेकिन यदि वे उसी उपकरण के साथ जर्मन, फ्रेंच, और पोलिश सामग्री भी संसाधित करते हैं, तो ऑडिट उन भाषाओं के लिए प्रणालीगत अंतर प्रकट कर सकता है।

बहुभाषी PII पहचान के लिए तीन-स्तरीय दृष्टिकोण

शैक्षणिक शोध और उत्पादन तैनाती ने बहुभाषी PII पहचान के लिए सबसे प्रभावी दृष्टिकोण के रूप में तीन-स्तरीय हाइब्रिड आर्किटेक्चर पर सहमति व्यक्त की है:

स्तर 1: भाषा-स्थानीय spaCy मॉडल (उच्च-संसाधन भाषाएँ)

spaCy 25 भाषाओं के लिए प्रशिक्षित पाइपलाइन घटक प्रदान करता है, जिनमें जर्मन, फ्रेंच, स्पेनिश, पुर्तगाली, इतालवी, डच, रूसी, चीनी, जापानी, कोरियाई, पोलिश और अन्य शामिल हैं। ये मॉडल स्थानीय भाषा के कॉर्पस पर प्रशिक्षित होते हैं और प्रत्येक भाषा के रूपविज्ञान, व्याकरण और इकाई पैटर्न को समझते हैं।

जर्मन के लिए: spaCy de_core_news_lg मॉडल यौगिक संज्ञाओं, मामले के रूपांतरण, और जर्मन नाम पैटर्न को समझता है। फ्रेंच के लिए: fr_core_news_lg फ्रेंच इकाई पैटर्न को संभालता है जिसमें शीर्षक, स्थान के नाम, और संगठन के प्रारूप शामिल हैं।

भाषा-स्थानीय मॉडल नाम पहचान के लिए क्रॉस-भाषाई मॉडलों की तुलना में काफी उच्च सटीकता और पुनः प्राप्ति प्राप्त करते हैं जो विशिष्ट उच्च-संसाधन भाषाओं पर लागू होते हैं।

स्तर 2: Stanza (अतिरिक्त भाषाएँ)

स्टैनफोर्ड की Stanza लाइब्रेरी उन अतिरिक्त भाषाओं के लिए NER प्रदान करती है जो spaCy के व्यावसायिक प्रस्ताव द्वारा कवर नहीं की गई हैं, जिनमें क्रोएशियाई, स्लोवेनियाई, यूक्रेनी, और अन्य शामिल हैं। यह छोटे लेकिन फिर भी महत्वपूर्ण EU बोलने वाली जनसंख्या वाली भाषाओं को कवर करता है।

स्तर 3: XLM-RoBERTa (क्रॉस-भाषाई कवरेज)

उन भाषाओं के लिए जहां न तो spaCy और न ही Stanza प्रशिक्षित NER मॉडल प्रदान करते हैं, XLM-RoBERTa क्रॉस-भाषाई स्थानांतरण प्रदान करता है। 100 भाषाओं में सामान्य क्रॉल डेटा पर प्रशिक्षित, XLM-RoBERTa PII पहचान के लिए 91.4% क्रॉस-भाषाई F1 प्राप्त करता है (HuggingFace 2024), जो कम संसाधन भाषाओं के लिए उचित पहचान सक्षम करता है।

क्रॉस-भाषाई मॉडल कोड-स्विचिंग (मिश्रित-भाषा पाठ) को विशेष रूप से अच्छी तरह से संभालता है - एक गुण जो अंतरराष्ट्रीय संगठनों के लिए महत्वपूर्ण हो जाता है जहां एकल दस्तावेज़ में कई भाषाओं में पाठ हो सकता है।

भाषा-विशिष्ट इकाई प्रकार

पहचान मॉडल के अलावा, GDPR अनुपालन के लिए देश-विशिष्ट पहचानकर्ताओं के लिए इकाई प्रकार कवरेज की आवश्यकता होती है। एक बहुभाषी उपकरण को आवश्यकता होती है:

EU राष्ट्रीय पहचानकर्ता:

• DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
• FR: NIR, SIREN, SIRET, numéro de téléphone
• PL: PESEL, NIP, REGON
• NL: BSN, BurgerServiceNummer
• SE: Personnummer, Samordningsnummer
• ES: DNI, NIE, NIF, CIF
• IT: Codice Fiscale, Partita IVA

फोन नंबर प्रारूप: प्रत्येक EU देश के पास अद्वितीय मोबाइल प्रीफिक्स संरचनाएँ, क्षेत्र कोड प्रारूप, और स्थानीय डायलिंग परंपराएँ हैं। +49 (जर्मनी), +33 (फ्रांस), +48 (पोलैंड) सभी को देश-विशिष्ट सत्यापन की आवश्यकता होती है।

पता प्रारूप: डाक कोड प्रारूप मौलिक रूप से भिन्न होते हैं - जर्मन PLZ (5 अंक), फ्रेंच कोड पोस्टल (5 अंक जो 01-99 से शुरू होते हैं), यूके पोस्टकोड (अल्फ़ान्यूमेरिक, कई प्रारूप), स्पेनिश código postal (5 अंक 01000-52999)।

उपयोग का मामला: स्विस फार्मास्यूटिकल बहुभाषी दस्तावेज़

एक स्विस फार्मास्यूटिकल कंपनी रोजगार अनुबंधों को संसाधित करती है जिनमें एक ही दस्तावेज़ के भीतर जर्मन, फ्रेंच, और अंग्रेजी में पाठ होता है (स्विट्ज़रलैंड में चार आधिकारिक भाषाएँ हैं)। उनका वर्तमान उपकरण जर्मन के लिए कॉन्फ़िगर किया गया है और सभी फ्रेंच-खंड PII को चूक जाता है।

जिनेवा स्थित कर्मचारी के लिए एक रोजगार अनुबंध उनके फ्रेंच AVS नंबर (13 अंक), उनके स्विस बैंक खाता IBAN, उनके निवास का кантन, और उनके नाम को फ्रेंच प्रारूप में संदर्भित करता है। जर्मन-कॉन्फ़िगर किया गया उपकरण फ्रेंच-फॉर्मेट नाम को चूक जाता है, फ्रेंच AVS नंबर पैटर्न (जर्मन AHV-Nummer प्रारूप से भिन्न) का पता लगाने में विफल रहता है, और केवल आंशिक रूप से IBAN का पता लगाता है।

तीन-स्तरीय दृष्टिकोण दस्तावेज़ को एक संपूर्ण के रूप में संसाधित करता है, प्रत्येक पाठ खंड के लिए स्वचालित रूप से भाषा का पता लगाता है, भाषा-उपयुक्त NER मॉडल लागू करता है, और प्रत्येक राष्ट्रीय पहचानकर्ता प्रकार के लिए देश-विशिष्ट regex सत्यापनकर्ताओं का उपयोग करता है - चाहे वह किसी भी भाषा खंड में प्रकट हो।

मिश्रित-भाषा दस्तावेज़ प्रबंधन

सबसे कठिन बहुभाषी PII समस्या आंतरिक दस्तावेज़ भाषा मिश्रण है: एक दस्तावेज़ जिसमें विभिन्न भाषाओं में अनुच्छेद, कोड-स्विच किए गए वाक्य, या संदर्भित पाठ होता है जो चारों ओर के संदर्भ से भिन्न भाषा में होता है।

उदाहरण:

• एक जर्मन कंपनी का अंग्रेजी-भाषा अनुबंध जिसमें जर्मन कर्मचारी डेटा (नाम, कर आईडी)
• एक फ्रेंच GDPR सहमति फॉर्म जिसमें एक अंग्रेजी-भाषा गोपनीयता नीति का अंश शामिल है
• एक बहुभाषी ग्राहक सेवा चैट लॉग जहां एजेंट अंग्रेजी में प्रतिक्रिया देता है लेकिन ग्राहक अरबी में लिखता है

XLM-RoBERTa इसे स्वदेशी रूप से संभालता है: इसका क्रॉस-भाषाई प्रशिक्षण इसका अर्थ है कि इसे स्पष्ट भाषा घोषणाओं की आवश्यकता नहीं होती है और मिश्रित-भाषा पाठ को बिना विभाजन की आवश्यकता के संसाधित करता है।

उत्पादन तैनाती के लिए, स्वचालित भाषा पहचान (वाक्य स्तर पर लागू) और XLM-RoBERTa क्रॉस-भाषाई अनुमान का संयोजन मिश्रित-भाषा दस्तावेज़ों के सबसे मजबूत प्रबंधन प्रदान करता है।

व्यावहारिक तैनाती मार्गदर्शन

अपने वर्तमान उपकरण की भाषा कवरेज का ऑडिट करें: अपने वर्तमान अनामकरण विक्रेता से पूछें कि वे आपके डेटा में विशिष्ट भाषाओं के लिए F1 स्कोर प्रदान करें। "20 भाषाओं का समर्थन करता है" अक्सर इसका अर्थ है कि उपकरण पाठ को Google Translate के माध्यम से पास करता है इससे पहले कि वह अंग्रेजी-प्रशिक्षित NER लागू करे - जो भाषा-स्थानीय पहचान के समान नहीं है।

अपने डेटा को भाषाओं से मैप करें: एक डेटा इन्वेंटरी करें जिसमें भाषा वितरण शामिल हो। एक बहुराष्ट्रीय जिसमें 70% अंग्रेजी, 20% जर्मन, और 10% फ्रेंच डेटा है, उसका जोखिम एक ऐसे बहुराष्ट्रीय की तुलना में भिन्न है जिसमें 95% अंग्रेजी है।

राष्ट्रीय पहचानकर्ता नमूनों के साथ परीक्षण करें: अपने संचालन से संबंधित राष्ट्रीय पहचानकर्ताओं (Steuer-ID, NIR, PESEL, BSN, आदि) के 10 उदाहरणों के साथ एक परीक्षण डेटा सेट बनाएं और पहचान दरों की पुष्टि करें। यह बड़े पैमाने पर F1 मूल्यांकन की तुलना में एक तेज़ ऑडिट है।

अपने DPIAs की समीक्षा करें: यदि आपके पास अपने अनामकरण उपकरणों को कवर करने वाले डेटा प्रोटेक्शन इम्पैक्ट असेसमेंट हैं, तो सुनिश्चित करें कि भाषा कवरेज विश्लेषण शामिल है। एक अधूरा DPIA जो केवल अंग्रेजी कवरेज मानता है, उसे अपडेट करने की आवश्यकता हो सकती है।

anonym.legal का PII पहचान इंजन तीन-स्तरीय बहुभाषी दृष्टिकोण का उपयोग करता है: 25 उच्च-संसाधन भाषाओं के लिए भाषा-स्थानीय spaCy मॉडल, अतिरिक्त भाषा कवरेज के लिए Stanza, और कुल मिलाकर 48-भाषा कवरेज के लिए XLM-RoBERTa क्रॉस-भाषाई ट्रांसफार्मर। सभी EU सदस्य राज्यों के लिए देश-विशिष्ट इकाई प्रकार शामिल हैं।

स्रोत:

• ACL 2024: यूरोपीय स्थलों के लिए हाइब्रिड PII पहचान
• स्केलेबल बहुभाषी PII एनोटेशन फ्रेमवर्क (arXiv 2025)
• HuggingFace XLM-RoBERTa क्रॉस-भाषाई NER बेंचमार्क
• Microsoft Presidio GitHub समस्या #1071 — जर्मन झूठे सकारात्मक
• EDPB दिशानिर्देश अनुच्छेद 25 प्राइवेसी बाय डिज़ाइन पर
• CNIL 2024 वार्षिक रिपोर्ट