GDPR AI वर्कफ़्लो के लिए टोकन मैपिंग
2026 के लिए अपडेटेड
आपकी टीम ग्राहक उत्तर तैयार करने के लिए AI का उपयोग करती है। एक ग्राहक लिखता है। AI देखने से पहले उसका नाम अनामीकृत हो जाता है। AI एक placeholder के साथ उत्तर का मसौदा बनाता है। एजेंट को इसे मैन्युअल रूप से वापस बदलना होता है। प्रति दिन 200 इंटरैक्शन पर, यह लागत तेज़ी से बढ़ती है।
Session-based टोकन मैपिंग इसे हल करती है। यह वास्तविक नाम स्वचालित रूप से वापस लाती है।
टोकन मैपिंग के बिना समस्या
अनामीकरण चरण एक टोकन बनाता है। "Maria Schmidt" [CUSTOMER_1] बन जाती है। Claude लिखता है: "Dear [CUSTOMER_1], हम देरी के लिए माफी माँगते हैं।"
दावा हैंडलर को अब भेजने से पहले [CUSTOMER_1] को "Maria Schmidt" से बदलना होगा। इस पैमाने पर, यह चरण AI सहायता का उद्देश्य ही विफल कर देता है। यह दोहराव का काम है जो जाता नहीं।
Session टोकन कैसे काम करते हैं
Session एक lookup table संग्रहीत करती है: [CUSTOMER_1] → "Maria Schmidt।" जब Claude अपना मसौदा वापस करता है, तो auto-decrypt layer उस table को पढ़ता है और नाम वापस लाता है। एजेंट "Dear Maria Schmidt" देखता है — पहले से सही। कोई मैन्युअल चरण नहीं। GDPR सुरक्षा चुपचाप चलती है।
Session Consistency क्यों महत्वपूर्ण है
टोकन table पूरी session में सुसंगत होनी चाहिए। अगर "Maria Schmidt" प्रारंभिक शिकायत में और फिर एक फॉलो-अप में आती है, तो दोनों को [CUSTOMER_1] पर resolve करना होगा। इसके बिना, Claude उन्हें दो अलग-अलग लोग मान सकता है। उसका जवाब असंगत हो जाता है।
एक व्यक्ति को प्रति session एक टोकन मिलता है। Claude तब बातचीत के बारे में सही तरीके से तर्क कर सकता है।
डिज़ाइन द्वारा GDPR अनुपालन
GDPR Article 4(5) स्यूडोनिमाइज़ेशन को जोखिम-न्यूनीकरण तकनीक के रूप में परिभाषित करता है। EDPB के 2022 दिशानिर्देशों में एक आवश्यकता है: कुंजी स्यूडोनिमाइज़्ड डेटा से अलग रखी जानी चाहिए।
Session टोकन tables इस नियम को पूरा करती हैं। Lookup ब्राउज़र में रहती है। यह Claude के पास कभी नहीं जाती। Session समाप्त होने के बाद, यह चली जाती है। कोई व्यक्तिगत डेटा बाहरी सर्वर तक नहीं पहुँचता। Article 46 transfer प्रश्न उत्पन्न ही नहीं होता।
बीमा दावे: एक ठोस उदाहरण
एक जर्मन बीमाकर्ता ग्राहक शिकायत ईमेल संसाधित करता है। प्रत्येक ईमेल में एक नाम, एक पॉलिसी नंबर और एक दावा राशि होती है।
AI प्रसंस्करण से पहले, Chrome Extension या MCP Server तीनों फ़ील्ड को अनामीकृत करता है। Claude [CUSTOMER_1], [POLICY_2024-08847], और [AMOUNT_1] देखता है। यह उन टोकन के साथ एक उत्तर का मसौदा बनाता है।
Auto-decrypt layer फिर तीनों फ़ील्ड वापस लाती है। दावा हैंडलर मसौदे में वास्तविक नाम और पॉलिसी नंबर देखता है। वे समीक्षा करते हैं और भेजते हैं। कोई placeholder प्रतिस्थापन की जरूरत नहीं।
GDPR परिणाम: Claude के US सर्वर को भेजे गए डेटा में कोई व्यक्तिगत डेटा नहीं था। ग्राहक का वास्तविक नाम और पॉलिसी नंबर हैंडलर के ब्राउज़र में जर्मनी में रहा।
पूरे लूप के लिए क्या चाहिए
निर्बाध वर्कफ़्लो के लिए तीन घटकों को एक साथ काम करना होगा:
1. सुसंगत टोकन। प्रत्येक entity को प्रति session एक टोकन मिलता है। हमेशा एक ही।
2. एक local lookup table। यह session में रहती है। AI के पास नहीं भेजी जाती।
3. आउटपुट पर Auto-decrypt। एजेंट के देखने से पहले table AI मसौदे पर लागू होती है।
तीनों के बिना, एजेंट हाथ से टोकन बदलते हैं। तीनों के साथ, वर्कफ़्लो अपने आप चलता है और GDPR-अनुपालक रहता है।
निष्कर्ष
यह दृष्टिकोण AI-सहायता प्राप्त ग्राहक कार्य में लूप बंद करता है। अनामीकरण AI तक पहुँचने से पहले डेटा सुरक्षित करता है। Auto-decryption उत्तर में वास्तविक नाम वापस रखती है। एजेंट हर चरण में सही नाम देखते हैं। GDPR अनुपालन पूरे समय बना रहता है।
स्रोत
- EDPB Guidelines 01/2025 on Pseudonymization — स्यूडोनिमाइज़ेशन आवश्यकताएँ जिसमें कुंजी को स्यूडोनिमाइज़्ड डेटा से अलग रखना शामिल है।
- GDPR Article 4(5) — स्यूडोनिमाइज़ेशन की कानूनी परिभाषा।
- IAPP: GDPR के शीर्ष 10 परिचालन प्रभाव