एक AI-संचालित सपोर्ट सिस्टम, जिसे मॉडल-आउटपुट चरण पर सुरक्षित माना जा रहा था, "साइड डोर" के माध्यम से ग्राहक डेटा लीक कर रहा था, जो प्रॉम्प्ट में CRM रिकॉर्ड फीड करता है। निर्माता के पोस्ट-मॉर्टम से पता चलता है कि केवल उस टेक्स्ट की सुरक्षा करना जो मॉडल जेनरेट करता है, पर्याप्त नहीं है – इनबाउंड रिक्वेस्ट, आंतरिक टूल्स से प्राप्त डेटा और अंतिम एमिशन (emission), सभी को स्वतंत्र सुरक्षा उपायों की आवश्यकता होती है, अन्यथा कोई व्यवसाय मॉडल-आउटपुट ब्रीच देखे बिना ही नाम, ईमेल और आईडी को उजागर कर सकता है।

ये तीन सीमाएं क्यों महत्वपूर्ण हैं

अधिकांश ऑपरेटर यह मान लेते हैं कि लीक तब होता है जब लैंग्वेज मॉडल उस गुप्त जानकारी को दोहराता है जिसे उसने देखा है। वास्तव में, सबसे बड़ा जोखिम मॉडल द्वारा डेटा देखे जाने से पहले ही हो जाता है। एक AI एजेंट सूचना के तीन स्ट्रीम प्राप्त करता है:

  • Ingress – वह रॉ क्वेरी जो ग्राहक टाइप करता है।
  • Return path – वह जानकारी जिसे एजेंट CRM जैसे डाउनस्ट्रीम सिस्टम से निकालता है।
  • Emission – वह टेक्स्ट जो मॉडल यूजर को वापस भेजता है।

यदि इनमें से किसी भी स्ट्रीम में असुरक्षित आइडेंटिफायर (identifiers) होते हैं, तो एजेंट अनजाने में उन्हें अपने जवाब में शामिल कर सकता है, भले ही आउटपुट लेयर को फ़िल्टर किया गया हो।

डेमो से प्रोडक्शन तक: कठिन परिश्रम से सीखे गए सबक

एक प्रोटोटाइप को लाइव हेल्प डेस्क में ले जाने से ऐसी ठोस विफलताएं सामने आईं, जिन्हें एक साधारण "रिडैक्ट-देन-सेंड" (redact-then-send) दृष्टिकोण नहीं पकड़ सका।

  • रिडैक्ट करने के बजाय टोकनाइज़ करें – मॉडल तक पहुँचने से पहले नाम या ईमेल को डिलीट करने से सिस्टम सही उत्तर को फिर से बनाने (reconstruct) में असमर्थ हो जाता है। मूल वैल्यू को एक सुरक्षित वॉल्ट में स्टोर करें, प्रॉम्प्ट में उसे एक रैंडम UUID से बदल दें, और मॉडल के काम पूरा करने के बाद UUID को वापस बदल दें। यह कार्यक्षमता बनाए रखते हुए रॉ डेटा को मॉडल के कॉन्टेक्स्ट से बाहर रखता है।

  • चेकसम के साथ आइडेंटिफायर को वैलिडेट करें – एक रेगुलर एक्सप्रेशन (regular expression) उस स्ट्रिंग को पहचान लेता है जो अकाउंट नंबर जैसी दिखती है; एक चेकसम पुष्टि करता है कि क्या वह एक वास्तविक आईडी है। एक चेकसम फ़िल्टर एजेंट को मनमाने नंबरों को संवेदनशील डेटा मानने से रोकता है, जिससे उन फॉल्स पॉजिटिव्स (false positives) में कमी आती है जो अन्यथा अनावश्यक रिडक्शन (redactions) को ट्रिगर कर सकते थे।

  • ओवरलैपिंग स्पैन को मर्ज करें – ग्राहक रिकॉर्ड में अक्सर एक नाम के बाद ईमेल एड्रेस होता है जिसमें कुछ अक्षर समान होते हैं (जैसे, “John Doe john.doe@example.com”)। केवल नाम को टोकनाइज़ करने से ईमेल का हिस्सा सादे टेक्स्ट (clear text) में रह जाता है, जिसे एमिशन (emitted) किया जा सकता है। पूरे ओवरलैपिंग क्षेत्र को एक सिंगल टोकन के रूप में मानें।

  • सही बाउंड्री का परीक्षण करें – केवल एमिशन लेयर की जाँच करके पास होने वाला टेस्ट सुरक्षा का झूठा अहसास देता है। रिटर्न पाथ में लीक पकड़ने वाला एक फेल होने वाला टेस्ट सुधार के लिए मजबूर करता है। ऐसे टेस्ट सुइट्स डिज़ाइन करें जो स्पष्ट रूप से तीनों सीमाओं को वैलिडेट करते हों।

  • ग्राउंड ट्रुथ (ground truth) को ट्रैक करें – जब कोई इंसान भेजने से पहले AI-जेनरेटेड ड्राफ्ट को एडिट करता है, तो मॉडल पहले ही एक त्रुटिपूर्ण प्रतिक्रिया दे चुका होता है। AI के ड्राफ्ट की तुलना अंतिम मानव-अनुमोदित संदेश से करने पर कॉन्फिडेंस गैप का पता चलता है और सिस्टम को गलतियाँ दोहराना सीखने से रोकता है।

व्यवसायों के लिए जोखिम

कस्टमर-सर्विस AI एजेंट सार्वजनिक बातचीत और आंतरिक डेटा स्टोर के संगम पर स्थित होते हैं।

काउंटर-आर्ग्युमेंट: कुछ लोग अभी भी रिडक्शन (redaction) का समर्थन क्यों करते हैं

निष्कर्ष (Takeaway)

AI-संचालित कस्टमर-सर्विस एजेंट को सुरक्षित करना कोई सिंगल-डोर समस्या नहीं है। इनबाउंड रिक्वेस्ट, आंतरिक सिस्टम से प्राप्त डेटा और आउटबाउंड टेक्स्ट को अलग-अलग दीवारों की तरह मानें; यदि किसी एक में भी सेंध लगती है, तो पूरी सेवा खतरे में पड़ जाती है। संवेदनशील फ़ील्ड्स को टोकनाइज़ करना, आइडेंटिफायर को वैलिडेट करना, ओवरलैपिंग स्पैन को मर्ज करना, सही बाउंड्री का परीक्षण करना और AI ड्राफ्ट की लगातार अंतिम मानव संदेशों से तुलना करना वे व्यावहारिक कदम हैं जो एक "को-पायलट" (copilot) को एक भरोसेमंद, एजेंटिक सर्विस में बदल देते हैं।