GDPR AI ورک فلو کے لیے ٹوکن میپنگ
2026 کے لیے اپ ڈیٹ شدہ
آپ کی ٹیم AI سے گاہک کے جوابات تیار کرتی ہے۔ ایک گاہک لکھتا ہے۔ AI دیکھنے سے پہلے اس کا نام گمنام کیا جاتا ہے۔ AI placeholder کے ساتھ جواب تیار کرتا ہے۔ ایجنٹ کو اسے دستی طور پر واپس بدلنا ہوتا ہے۔ روزانہ 200 تعاملات پر یہ لاگت تیزی سے بڑھتی ہے۔
سیشن پر مبنی ٹوکن میپنگ اسے حل کرتی ہے۔ یہ اصل نام خودکار طور پر بحال کرتی ہے۔
ٹوکن میپنگ کے بغیر مسئلہ
گمنامی کا قدم ایک ٹوکن بناتا ہے۔ "Maria Schmidt" بن جاتی ہے `[CUSTOMER_1]`۔ Claude ڈرافٹ کرتا ہے: "Dear [CUSTOMER_1], we apologize for the delay."
کلیمز ہینڈلر کو اب بھیجنے سے پہلے `[CUSTOMER_1]` کو "Maria Schmidt" سے بدلنا ہوتا ہے۔ پیمانے پر، یہ قدم AI مدد کا مقصد ناکام بنا دیتا ہے۔ یہ وہ دہرایا جانے والا کام ہے جو ختم نہیں ہوتا۔
سیشن ٹوکنز کیسے کام کرتے ہیں
سیشن ایک تلاش کی جدول محفوظ کرتا ہے: `[CUSTOMER_1]` → "Maria Schmidt"۔ جب Claude اپنا ڈرافٹ واپس کرتا ہے تو آٹو-ڈیکرپٹ پرت وہ جدول پڑھتی اور نام بحال کرتی ہے۔ ایجنٹ دیکھتا ہے "Dear Maria Schmidt" — پہلے سے درست۔ کوئی دستی قدم نہیں۔ GDPR تحفظ خاموشی سے چلتا رہتا ہے۔
سیشن مستقل مزاجی کیوں اہم ہے
ٹوکن جدول پورے سیشن میں مستقل ہونی چاہیے۔ اگر "Maria Schmidt" ابتدائی شکایت اور پھر فالو اپ میں آتی ہے تو دونوں کو `[CUSTOMER_1]` سے حل ہونا چاہیے۔ اس کے بغیر Claude انہیں دو مختلف لوگ سمجھ سکتا ہے۔ اس کا جواب بے ربط ہو جاتا ہے۔
ایک شخص کو ایک سیشن میں ایک ٹوکن ملتا ہے۔ Claude پھر گفتگو پر درست طور پر استدلال کر سکتا ہے۔
ڈیزائن کے ذریعے GDPR تطابق
GDPR آرٹیکل 4(5) pseudonymization کو خطرہ کم کرنے کی تکنیک کے طور پر بیان کرتا ہے۔ EDPB کی 2022 ہدایات ایک شرط رکھتی ہیں: کلید pseudonymized ڈیٹا سے الگ رکھی جانی چاہیے۔
سیشن ٹوکن جداول یہ اصول پورا کرتی ہیں۔ تلاش ب browser میں رہتی ہے۔ یہ کبھی Claude کو نہیں جاتی۔ سیشن ختم ہونے کے بعد یہ ختم ہو جاتی ہے۔ کوئی ذاتی ڈیٹا بیرونی سرورز تک نہیں پہنچتا۔ آرٹیکل 46 منتقلی کا سوال نہیں اٹھتا۔
انشورنس کلیمز: ایک ٹھوس مثال
ایک جرمن انشورنس کمپنی گاہک کی شکایتی ای میلز پروسیس کرتی ہے۔ ہر ای میل میں نام، پالیسی نمبر، اور کلیم رقم ہے۔
AI پروسیسنگ سے پہلے Chrome Extension یا MCP Server تینوں فیلڈز گمنام کرتا ہے۔ Claude `[CUSTOMER_1]`، `[POLICY_2024-08847]`، اور `[AMOUNT_1]` دیکھتا ہے۔ یہ انہی ٹوکنز کے ساتھ جواب تیار کرتا ہے۔
آٹو-ڈیکرپٹ پرت پھر تینوں فیلڈز بحال کرتی ہے۔ کلیمز ہینڈلر ڈرافٹ میں اصل نام اور پالیسی نمبر دیکھتا ہے۔ وہ جائزہ لے کر بھیج دیتا ہے۔ کوئی placeholder تبدیلی ضروری نہیں۔
GDPR نتیجہ: Claude کے امریکی سرورز کو بھیجا گیا ڈیٹا کوئی ذاتی ڈیٹا نہیں رکھتا تھا۔ گاہک کا اصل نام اور پالیسی نمبر ہینڈلر کے browser پر جرمنی میں رہا۔
مکمل حلقے کے لیے کیا ضروری ہے
بغیر رکاوٹ ورک فلو کے لیے تین اجزاء مل کر کام کریں:
1. مستقل ٹوکنز۔ ہر ادارے کو ایک سیشن میں ایک ٹوکن ملتا ہے۔ ہمیشہ ایک ہی۔
2. ایک مقامی تلاش جدول۔ یہ سیشن میں رہتی ہے۔ AI کو نہیں بھیجی جاتی۔
3. آؤٹ پٹ پر آٹو-ڈیکرپٹ۔ ایجنٹ دیکھنے سے پہلے جدول AI ڈرافٹ پر لاگو ہوتی ہے۔
تینوں کے بغیر ایجنٹ ہاتھ سے ٹوکنز بدلتے ہیں۔ تینوں کے ساتھ ورک فلو خود چلتا ہے اور GDPR تطابق برقرار رہتا ہے۔
نتیجہ
یہ طریقہ AI سے مدد شدہ گاہک کام میں حلقہ بند کرتا ہے۔ گمنامی AI تک پہنچنے سے پہلے ڈیٹا محفوظ کرتی ہے۔ آٹو-ڈیکرپشن جواب میں اصل نام واپس لاتی ہے۔ ایجنٹ ہر قدم پر درست نام دیکھتے ہیں۔ GDPR تطابق ہر جگہ برقرار رہتا ہے۔
ذرائع
- EDPB Guidelines 01/2025 on Pseudonymization — Pseudonymization کی ضروریات بشمول کلید کو pseudonymized ڈیٹا سے الگ رکھنا۔
- GDPR Article 4(5) — Pseudonymization کی قانونی تعریف۔
- IAPP: GDPR کے 10 اہم آپریشنل اثرات — صرف 23% گمنامی ٹولز حقیقی واپسی پیش کرتے ہیں۔