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

हे तीन सीमा (boundaries) का महत्त्वाच्या आहेत

बहुतेक ऑपरेटर्सना असे वाटते की जेव्हा लँग्वेज मॉडेलने पाहिलेली एखादी गुप्त माहिती पुन्हा सांगितली जाते, तेव्हा डेटा लीक होतो. प्रत्यक्षात, मॉडेलला डेटा दिसण्यापूर्वीच सर्वात मोठी असुरक्षितता निर्माण होते. एक AI एजंट माहितीचे तीन प्रवाह प्राप्त करतो:

  • Ingress (प्रवेश) – ग्राहकाने टाईप केलेली मूळ क्वेरी.
  • Return path (परतीचा मार्ग) – एजंट CRM सारख्या डाउनस्ट्रीम सिस्टममधून मिळवलेली माहिती.
  • Emission (एमिशन) – मॉडेल वापरकर्त्याला परत पाठवलेला मजकूर.

जर यापैकी कोणत्याही प्रवाहामध्ये असुरक्षित आयडेंटिफायर्स (ओळख पटवणारी माहिती) असतील, तर आउटपुट लेयर फिल्टर केलेला असूनही, एजंट नकळतपणे ते त्याच्या प्रतिसादात समाविष्ट करू शकतो.

डेमोपासून प्रोडक्शनपर्यंत: कष्टाने शिकलेले धडे

प्रोटोटाइप थेट हेल्प डेस्कवर आणताना अशा काही ठोस त्रुटी समोर आल्या, ज्या केवळ "रेडॅक्ट-देन-सेंड" (माहिती लपवून पाठवणे) या साध्या पद्धतीमुळे सुटल्या होत्या.

  • रेडॅक्ट करण्याऐवजी टोकनाइझ करा (Tokenize instead of redact) – मॉडेलपर्यंत पोहोचण्यापूर्वी नाव किंवा ईमेल हटवल्यामुळे सिस्टमला अचूक उत्तर तयार करण्यास अडथळा येतो. मूळ व्हॅल्यू एका सुरक्षित व्हॉल्टमध्ये साठवा, प्रॉम्प्टमध्ये त्याऐवजी एक रँडम UUID वापरा आणि मॉडेलचे काम पूर्ण झाल्यावर तो UUID पुन्हा मूळ व्हॅल्यूने बदला. यामुळे कार्यक्षमता कायम ठेवत कच्चा डेटा मॉडेलच्या कॉन्टेक्स्टपासून दूर ठेवता येतो.

  • चेकसमसह (checksums) आयडेंटिफायर्सची पडताळणी करा – रेग्युलर एक्स्प्रेशन (regular expression) खाते क्रमांकासारखा दिसणारा स्ट्रिंग शोधू शकते; परंतु चेकसम हे ते खरोखरच वैध आयडी आहे की नाही याची खात्री देते. चेकसम फिल्टरमुळे एजंट कोणत्याही आकड्यांना संवेदनशील डेटा मानण्यापासून थांबतो, ज्यामुळे अनावश्यक रेडॅक्शनमुळे निर्माण होणारे 'फॉल्स पॉझिटिव्ह' कमी होतात.

  • ओव्हरलॅपिंग स्पॅन्स (overlapping spans) एकत्र करा – ग्राहक रेकॉर्डमध्ये अनेकदा नावाच्या पुढे ईमेल पत्ता असतो ज्यामध्ये काही अक्षरे समान असू शकतात (उदा. “John Doe john.doe@example.com”). केवळ नाव टोकनाइझ केल्यास ईमेलचा भाग स्पष्ट मजकुरात (clear text) राहतो, जो बाहेर पडू शकतो. संपूर्ण ओव्हरलॅपिंग भागाला एकच टोकन म्हणून treat करा.

  • योग्य सीमांची चाचणी घ्या (Test the right boundary) – केवळ एमिशन लेयर तपासून पास होणारी चाचणी सुरक्षेचा खोटा आभास देते. रिटर्न पाथमधील डेटा लीक पकडणारी अयशस्वी चाचणी सुधारणेसाठी भाग पाडते. अशा टेस्ट सूट्सची रचना करा जे स्पष्टपणे या तीनही सीमांची पडताळणी करतील.

  • ग्राउंड ट्रुथचा (ground truth) मागोवा घ्या – जेव्हा एखादा माणूस AI-निर्मित मसुदा पाठवण्यापूर्वी त्यात बदल करतो, तेव्हा मॉडेलने आधीच चुकीचा प्रतिसाद दिलेला असतो. AI चा मसुदा आणि मानवाने मंजूर केलेला अंतिम संदेश यांची तुलना केल्यास विश्वासातील तफावत (confidence gaps) समजते आणि सिस्टमला चुका पुन्हा करण्याची सवय होण्यापासून रोखता येते.

व्यवसायांसाठी असलेले धोके

कस्टमर-सर्व्हिस AI एजंट्स हे सार्वजनिक संवाद आणि अंतर्गत डेटा स्टोअर्स यांच्या संगमावर असतात.

प्रतिवाद: काही लोक अजूनही रेडॅक्शनला का पसंती देतात

निष्कर्ष (Takeaway)

AI-आधारित कस्टमर-सर्व्हिस एजंट सुरक्षित करणे ही केवळ एका दरवाजाची समस्या नाही. इनबाउंड रिक्वेस्ट, अंतर्गत सिस्टममधून मिळवलेला डेटा आणि आउटबाउंड मजकूर यांना स्वतंत्र भिंती मानून पहा; त्यातील एकाही भिंतीचा भंग झाला तर संपूर्ण सेवा धोक्यात येते. संवेदनशील फील्ड्सना टोकनाइझ करणे, आयडेंटिफायर्सची पडताळणी करणे, ओव्हरलॅपिंग स्पॅन्स एकत्र करणे, योग्य सीमांची चाचणी घेणे आणि AI मसुद्यांची अंतिम मानवी संदेशांशी सतत तुलना करणे, हे असे व्यावहारिक टप्पे आहेत जे एका "कोपायलट" (copilot) ला विश्वासार्ह आणि एजन्टिक (agentic) सेवेमध्ये रूपांतरित करतात.