ایک AI سے چلنے والا سپورٹ سسٹم، جسے ماڈل آؤٹ پٹ کے مرحلے پر محفوظ سمجھا جا رہا تھا، "سائیڈ ڈور" کے ذریعے کسٹمر کا ڈیٹا لیک کر رہا تھا جو CRM ریکارڈز کو پرامپٹ (prompt) میں فراہم کرتا ہے۔ تخلیق کار کے پوسٹ مارٹم (post-mortem) سے پتہ چلتا ہے کہ صرف اس متن کی حفاظت کرنا جو ماڈل تیار کرتا ہے کافی نہیں ہے – ان باؤنڈ ریکویسٹ (inbound request)، اندرونی ٹولز سے حاصل کردہ ڈیٹا، اور حتمی ایمیشن (emission) سب کو آزادانہ حفاظتی اقدامات کی ضرورت ہے، ورنہ کوئی کاروبار ماڈل آؤٹ پٹ کی خلاف ورزی دیکھے بغیر ہی نام، ای میلز اور آئی ڈیز (IDs) کو ظاہر کر سکتا ہے۔

یہ تینوں حدود کیوں اہم ہیں

زیادہ تر آپریٹرز یہ سمجھتے ہیں کہ ڈیٹا لیک تب ہوتا ہے جب لینگویج ماڈل کسی ایسی خفیہ معلومات کو دہراتا ہے جو اس نے دیکھی ہو۔ عملی طور پر، سب سے بڑا خطرہ ماڈل کے ڈیٹا دیکھنے سے پہلے ہی پیدا ہو جاتا ہے۔ ایک AI ایجنٹ معلومات کے تین بہاؤ (streams) وصول کرتا ہے:

  • Ingress – وہ خام سوال (raw query) جو کسٹمر ٹائپ کرتا ہے۔
  • Return path – وہ معلومات جو ایجنٹ ڈاؤن اسٹریم سسٹمز جیسے کہ CRM سے حاصل کرتا ہے۔
  • Emission – وہ متن جو ماڈل صارف کو واپس بھیجتا ہے۔

اگر ان میں سے کسی بھی بہاؤ میں غیر محفوظ شناختی معلومات (identifiers) ہوں، تو ایجنٹ غیر ارادی طور پر انہیں اپنے جواب میں شامل کر سکتا ہے، چاہے آؤٹ پٹ لیئر فلٹر شدہ ہی کیوں نہ ہو۔

ڈیمو سے پروڈکشن تک: مشکل سے حاصل کیے گئے اسباق

ایک پروٹو ٹائپ کو لائیو ہیلپ ڈیسک پر منتقل کرنے سے ایسی ٹھوس ناکامیاں سامنے آئیں جنہیں محض "ریڈیکٹ-پھر-بھیجیں" (redact-then-send) والا طریقہ کار نظر انداز کر گیا تھا۔

  • ریڈیکٹ کرنے کے بجائے ٹوکنائز (Tokenize) کریں – ماڈل تک پہنچنے سے پہلے نام یا ای میل کو حذف کرنا سسٹم کو درست جواب تیار کرنے سے روک دیتا ہے۔ اصل ویلیو کو ایک محفوظ والٹ (vault) میں محفوظ کریں، پرامپٹ میں اسے ایک رینڈم UUID سے بدل دیں، اور ماڈل کے کام مکمل کرنے کے بعد UUID کو واپس اصل ویلیو سے بدل دیں۔ اس سے فنکشنلٹی برقرار رہتے ہوئے خام ڈیٹا ماڈل کے سیاق و سباق (context) سے باہر رہتا ہے۔

  • چیک سم (checksums) کے ذریعے شناختی معلومات کی تصدیق کریں – ایک ریگولر ایکسپریشن (regular expression) اس اسٹرنگ کی نشاندہی کرتی ہے جو اکاؤنٹ نمبر جیسی نظر آتی ہے؛ جبکہ چیک سم اس بات کی تصدیق کرتا ہے کہ آیا یہ ایک حقیقی آئی ڈی ہے۔ چیک سم فلٹر ایجنٹ کو من مانے نمبروں کو حساس ڈیٹا سمجھنے سے روکتا ہے، جس سے غلط مثبت (false positives) نتائج کم ہو جاتے ہیں جو بلا ضرورت ریڈیکشن کا باعث بن سکتے ہیں۔

  • اوورلیپنگ اسپینز (overlapping spans) کو ضم کریں – کسٹمر کے ریکارڈز میں اکثر نام کے بعد ای میل ایڈریس ہوتا ہے جس میں کچھ حروف مشترک ہوتے ہیں (مثلاً "John Doe john.doe@example.com")۔ صرف نام کو ٹوکنائز کرنے سے ای میل کا حصہ واضح متن (clear text) میں رہ جاتا ہے، جو آؤٹ پٹ میں ظاہر ہو سکتا ہے۔ پورے اوورلیپنگ حصے کو ایک ہی ٹوکن کے طور پر سمجھیں۔

  • درست حد (boundary) کا ٹیسٹ کریں – ایسا ٹیسٹ جو صرف ایمیشن لیئر کو چیک کر کے پاس ہو جائے، وہ تحفظ کا غلط احساس دلاتا ہے۔ ایک ناکام ٹیسٹ جو ریٹرن پاتھ میں ڈیٹا لیک کو پکڑ لے، وہ اصلاح پر مجبور کرتا ہے۔ ایسے ٹیسٹ سویٹس (test suites) ڈیزائن کریں جو واضح طور پر ان تینوں حدود کی تصدیق کریں۔

  • گراؤنڈ ٹرتھ (ground truth) پر نظر رکھیں – جب کوئی انسان AI کے تیار کردہ ڈرافٹ کو بھیجنے سے پہلے اس میں ترمیم کرتا ہے، تو ماڈل پہلے ہی ایک غلط جواب تیار کر چکا ہوتا ہے۔ AI کے ڈرافٹ کا حتمی انسانی منظور شدہ پیغام سے موازنہ کرنے سے اعتماد کے فرق (confidence gaps) کا پتہ چلتا ہے اور سسٹم کو غلطیاں دہرانے سے سیکھنے سے روکتا ہے۔

کاروبار کے لیے خطرات

کسٹمر سروس AI ایجنٹس عوامی تعامل اور اندرونی ڈیٹا اسٹورز کے سنگم پر موجود ہوتے ہیں۔

مخالف دلیل: کچھ لوگ اب بھی ریڈیکشن کو کیوں ترجیح دیتے ہیں

خلاصہ

AI سے چلنے والے کسٹمر سروس ایجنٹ کو محفوظ بنانا کسی ایک دروازے کا مسئلہ نہیں ہے۔ ان باؤنڈ ریکویسٹ، اندرونی سسٹمز سے حاصل کردہ ڈیٹا، اور آؤٹ باؤنڈ متن کو الگ الگ دیواروں کے طور پر سمجھیں؛ اگر ایک بھی دیوار ٹوٹ جائے تو پوری سروس خطرے میں پڑ جاتی ہے۔ حساس فیلڈز کو ٹوکنائز کرنا، شناختی معلومات کی تصدیق کرنا، اوورلیپنگ اسپینز کو ضم کرنا، درست حد کا ٹیسٹ کرنا، اور AI کے ڈرافٹس کا حتمی انسانی پیغامات سے مسلسل موازنہ کرنا وہ عملی اقدامات ہیں جو ایک "کو پائلٹ" (copilot) کو ایک قابل اعتماد اور ایجنٹک سروس میں بدل دیتے ہیں۔