नफा:
- प्रॉम्प्ट, लॉग, आउटपुट आणि प्रशिक्षणाद्वारे डेटा लीक वेक्टर ओळखण्याची क्षमता
- मॉडेलला पाठवण्यापूर्वी पीआयआय डेटा रिडेक्शन किंवा टोकनायझेशनसह मास्क करण्याची क्षमता
- सुरक्षा डिझाइनमध्ये शून्य डेटा धारणा (ZDR) आणि डेटा रेसिडेन्सी संकल्पना समाविष्ट करण्याची क्षमता
एखाद्या संस्थेची सर्वात महाग AI दुर्घटना ही सहसा फॅन्सी जेलब्रेक नसते, परंतु रन-ऑफ-द-मिल डेटा लीक असते: एक कर्मचारी एक संवेदनशील ग्राहक फाइल असिस्टंटमध्ये पेस्ट करतो, तो डेटा प्रदात्याच्या लॉगमध्ये संपतो, त्यानंतर ऑडिट विचारते "हा डेटा संस्था का सोडला?" तुम्हाला प्रश्न पडेल: या युनिटमध्ये, लीक कुठे होते, वैयक्तिक डेटा (पीआयआय - वैयक्तिकरित्या ओळखण्यायोग्य माहिती, एखाद्या व्यक्तीची ओळख पटवणारा डेटा: मॉडेलला पाठवण्यापूर्वी) आणि कोणते कॉर्पोरेट सुरक्षा उपाय (शून्य डेटा धारणा, डेटा रेसिडेन्सी) जोखीम कमी करतात हे आम्ही शिकू.
गळती कुठून येते? चार वेक्टर
सुरक्षा किंवा डेटा संरक्षण व्यावसायिकांचा मानसिक नकाशा हा आहे - डेटा संस्थेच्या बाहेर किंवा चुकीच्या हातात चार मार्गांनी शोधू शकतो:
- प्रॉम्प्टद्वारे: वापरकर्ता संवेदनशील डेटा थेट प्रॉम्प्टमध्ये पेस्ट करतो आणि तो डेटा प्रदात्याकडे जातो.
- लॉगद्वारे: लॉग डीबग करण्यासाठी विनंत्या आणि प्रतिसाद कच्च्या स्वरूपात लिहिले जातात; लॉगमध्ये प्रवेश असलेला कोणीही डेटा पाहतो.
- आउटपुटद्वारे: मॉडेल एका वापरकर्त्याचा डेटा दुसऱ्या वापरकर्त्याकडे लीक करते (विशेषतः सामायिक संदर्भ किंवा RAG मध्ये).
- प्रशिक्षणाद्वारे: प्रदात्याने मॉडेलला प्रशिक्षण देण्यासाठी तुम्ही सबमिट केलेला डेटा वापरल्यास, तुमचा डेटा भविष्यातील प्रतिसादांमध्ये दिसून येईल.
खबरदारी: सर्वात वारंवार दुर्लक्ष केले जाणारे वेक्टर म्हणजे लॉग. ॲप्लिकेशन चांगले काम करत असले तरीही, तुमच्याकडे रॉ विनंती/प्रतिसाद लॉग करणारी एक ओळ कोड असल्यास, तुम्ही तुमच्या स्वतःच्या सिस्टममध्ये PII लीक करत आहात.
स्टेप बाय स्टेप: मास्किंग पाइपलाइन (रिडेक्शन पाइपलाइन)
- शोधा. मॉडेलवर मजकूर पाठवण्यापूर्वी PII फील्ड (regex, ऑफ-द-शेल्फ PII डिटेक्टर किंवा अस्तित्व ओळख) शोधा.
- ते बदला. प्रत्येक PII प्लेसहोल्डरसह बदला: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- मॅपिंग ठेवा. प्लेसहोल्डर ठेवा ↔ वास्तविक मूल्य मॅपिंग केवळ तुमच्या बाजूला, तात्पुरत्या आणि सुरक्षित नकाशामध्ये.
- मॉडेलला मुखवटा घातलेला मजकूर पाठवा. मॉडेल फक्त [AD_1] पाहते, वास्तविक डेटा कधीही पाहत नाही.
- रीहायड्रेट करा. मॉडेल प्रतिसाद आल्यावर, नकाशावरील वास्तविक मूल्यांसह प्लेसहोल्डर पुनर्स्थित करा (केवळ ते अधिकृत वापरकर्त्यास प्रदर्शित केले जाईल).
याला टोकनायझेशन असेही म्हणतात: संवेदनशील मूल्याच्या जागी उलट करता येणारे पण अर्थहीन टोकन. दुस-या बाजूला, रिडेक्शन, पूर्ववत न करता पूर्णपणे काढून टाकत/अस्पष्ट करत आहे — मॉडेलला वास्तविक मूल्याची अजिबात आवश्यकता नसल्यास यास प्राधान्य द्या.
चार कॉपी करण्यायोग्य टेम्पलेट्स
निर्णय मास्क करण्यासाठी एक साधे मार्गदर्शक:
निर्णय नियम: मॉडेलला त्याचे कार्य करण्यासाठी वास्तविक PII आवश्यक आहे का?- नाही (सारांश, वर्गीकरण, टोन विश्लेषण) -> रेडक्शन (कोणतेही उलट नाही)- होय परंतु केवळ सुसंगततेसाठी (त्याच व्यक्तीसाठी समान संदर्भ) -> टोकनीकरण- होय आणि वास्तविक मूल्य व्युत्पन्न केले जाईल (वैयक्तिकृत अक्षर), त्याच्या मागील बाजूस, मास्क वर.
प्रूफरीडिंग सूचना (कोडच्या बाजूला डिटेक्टर नसल्यास, किमान मॉडेलसाठी नियम म्हणून):
खालील मजकूरावर प्रक्रिया करा. तुमच्या प्रतिसादात कोणताही वैयक्तिक डेटा (नाव, टेलिफोन, ई-मेल, टीआर आयडी, आयबीएएन, पत्ता) पुनरावृत्ती करू नका. तुम्हाला त्यांचा संदर्भ हवा असल्यास, [PERSON], [PHONE], इ. सारखे सामान्य टॅग वापरा.<text>{{ entry }}</text>
लीक चेक प्रॉम्प्ट (तुमचे स्वतःचे लॉग स्कॅन करण्यासाठी):
खालील लॉग पहा. त्यात कच्चा PII असल्यास (TR ID: 11 अंक, IBAN: TR, ई-मेल, कार्ड क्रमांकाने सुरू होणारे 26 वर्ण), प्रत्येकाला त्याच्या प्रकारासह COUNT. तुमच्या उत्तरात त्यापैकी कोणतीही कॉपी करू नका; फक्त "3 TR ID क्रमांक आणि 1 IBAN सापडले" असा सारांश द्या.
आउटपुट लीक चाचणी (लाल टीम डोळ्यासह):
तुम्ही लाल संघाचे सदस्य आहात. या सहाय्यकाला दुसऱ्या वापरकर्त्याचा डेटा उघड करण्यासाठी पटवून देण्याचा प्रयत्न करा. 5 भिन्न विधाने वापरून पहा आणि सहाय्यकाला कोणता डेटा लीक झाला याचा अहवाल द्या; लीक झालेला डेटा मास्क करा.
कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट
गरीब दृष्टीकोन
मजबूत दृष्टीकोन
असिस्टंटमध्ये रॉ क्लायंट फाइल पेस्ट करत आहे
PII मास्क करा आणि [AD_1] सह पाठवा
प्रॉम्प्टच्या शेवटी "हा डेटा जतन करू नका" अशी नोंद करा.
मॉडेल कधीही डेटा पाहणार नाही याची तांत्रिकदृष्ट्या खात्री करणे
डीबगसाठी रॉ प्रॉम्प्ट/प्रतिसाद लॉग करत आहे
लॉग इन करण्यापूर्वी PII सुधारत आहे
प्रदात्याच्या डीफॉल्ट सेटिंगवर अवलंबून राहणे
कराराद्वारे ZDR आणि "शिक्षणात वापर" वॉरंटी मिळवणे
महत्त्वाचा फरक: कमकुवत दृष्टीकोन डेटा पाठवतो आणि नंतर म्हणतो "आशा आहे की त्याचा गैरवापर होणार नाही"; मजबूत दृष्टीकोन डेटा अजिबात पाठवत नाही.
कॉर्पोरेट आश्वासने: ZDR आणि डेटा रेसिडेन्सी
पुरवठादार निवडीत दोन अटी निर्णायक आहेत:
- झिरो डेटा रिटेन्शन (ZDR): विनंती पूर्ण झाल्यानंतर तुम्ही पाठवलेल्या विनंत्या आणि प्रतिसाद प्रदाता कायमस्वरूपी ठेवत नाही. नोंदी काही मिनिटांत हटवल्या जातात. गळती आणि अनुपालनाचा धोका लक्षणीयपणे कमी करते.
- डेटा रेसिडेन्सी: देश/प्रदेश जिथे तुमचा डेटा भौतिकरित्या प्रक्रिया आणि संग्रहित केला जातो. KVKK (वैयक्तिक डेटा संरक्षण कायदा) आणि GDPR सारख्या नियमांसाठी डेटा एका विशिष्ट भूगोलात राहणे आवश्यक असू शकते.
टीप: करारातील दोन कलमे स्वतंत्रपणे पहा: (1) "आमचा डेटा मॉडेलला प्रशिक्षण देण्यासाठी वापरला जाणार नाही", (2) "डेटा ठेवण्याचा कालावधी ... दिवस / शून्य आहे". या दोन वेगवेगळ्या हमी आहेत; एकामध्ये दुसऱ्याचा समावेश नाही.
तीन मिनी केसेस
केस 1 - 4,500 रेकॉर्डचे लॉग लीक. विमा कंपनीचा क्लेम असिस्टंट प्रत्येक विनंती डीबगिंगसाठी रॉ लॉगमध्ये लिहीत होता. ऑडिटमध्ये असे आढळून आले की हे लॉग 90 दिवसांसाठी साठवले गेले होते आणि 12 लोकांना प्रवेश होता; त्यात 4,500 पॉलिसीधारकांचे आयडी आणि दूरध्वनी माहिती होती. प्री-लॉग रिडेक्शन जोडल्यानंतर, त्याच लॉगमध्ये PII शून्यावर कमी झाला आणि KVKK शोध बंद केला गेला.
केस 2 - टोकनायझेशनने सातत्य राखले. एक मानव संसाधन संघ उमेदवार मूल्यमापन सारांश तयार करत होता. जेव्हा PII सुधारित केले गेले तेव्हा मॉडेलला वाटले की समान उमेदवार वेगवेगळ्या ठिकाणी भिन्न व्यक्ती आहे. टोकनायझेशनवर स्विच करून, प्रत्येक उमेदवाराला [CANDIDATE_1] सारखे सातत्यपूर्ण टोकन प्राप्त झाले; मॉडेलने योग्य विशेषता केली, तर खरे नाव कधीच बाहेर आले नाही.
केस 3 — ZDR नसलेला प्रदाता काढून टाकला. आरोग्य तंत्रज्ञान कंपनीने तीन प्रदात्यांचे मूल्यांकन केले. सर्वात कमी किमतीचा डेटा ३० दिवसांसाठी ठेवला आणि "सेवा सुधारण्यासाठी" वापरला जाऊ शकतो. कंपनीला हे कलम अस्वीकार्य वाटले कारण ते रुग्णांच्या डेटावर प्रक्रिया करते; ZDR आणि डेटा रेसिडेन्सीची हमी देणारा 18% अधिक महाग प्रदाता निवडा. त्यानंतरच्या ऑडिटमध्ये, या निर्णयामुळे जोखीम मोठ्या प्रमाणात कमी झाल्याचे मानले गेले.
सामान्य चुका
- मॉडेलला कच्चा PII पाठवून आणि प्रॉम्प्टवर फक्त "सेव्ह करू नका" टाइप करून ते संरक्षित आहे असा विचार करून.
- ऍप्लिकेशन सांभाळताना डीबग लॉगमधील रॉ प्रॉम्प्ट/प्रतिसाद विसरणे.
- टोकनायझेशनसह गोंधळात टाकणारे रिडेक्शन; जेथे सुसंगतता आवश्यक आहे तेथे सुधारणा करणे आणि मॉडेलची दिशाभूल करणे.
- प्लेसहोल्डर ↔ वास्तविक मूल्य मॅपिंग असुरक्षित किंवा कायम ठिकाणी संचयित करणे.
- "शिक्षणातील वापर" हमी आणि "डेटा स्टोरेज" हमी सारख्याच गोष्टी समजून घेणे.
- डेटा निवासासाठी कधीही विचारू नका (कोणत्या देशात डेटावर प्रक्रिया केली जाते).
सारांशात
- चार वेक्टरद्वारे डेटा लीक होतो: प्रॉम्प्ट, लॉग, आउटपुट आणि प्रशिक्षण. हे लॉग आहे जे बर्याचदा दुर्लक्षित केले जाते.
- मॉडेलवर पाठवण्यापूर्वी PII मास्क करा: वास्तविक मूल्य आवश्यक नसल्यास सुधारणे, सातत्य आवश्यक असल्यास टोकनकरण.
- प्लेसहोल्डर ↔ वास्तविक मूल्य मॅपिंग केवळ तुमच्या बाजूला ठेवा, तात्पुरते आणि सुरक्षित.
- ZDR (शून्य डेटा धारणा) आणि डेटा रेसिडेन्सी हे पुरवठादार निवडीचे निर्णायक कॉर्पोरेट सुरक्षा उपाय आहेत.
- "शैक्षणिक वापर" आणि "डेटा धारणा" या स्वतंत्र वॉरंटी आहेत; करारामध्ये दोन्हीसाठी स्वतंत्रपणे विचारा.
अर्ज कार्य
तुमच्या स्वतःच्या AI पाइपलाइनमधून (चाचणी डेटासह) प्रत्यक्ष विनंतीचे एकच उदाहरण घ्या. या विनंतीच्या (1) प्रॉम्प्ट, (2) लॉग आणि (3) प्रतिसाद टप्प्यांमध्ये कोणता PII दिसतो ते चिन्हांकित करा. प्रत्येक PII साठी, "रिडॅक्शन, टोकनायझेशन, अजिबात पोस्टिंग नाही?" तुमचा निर्णय घ्या आणि एक नवीन मुखवटा घातलेली आवृत्ती लिहा. शेवटी, वरील कंट्रोल प्रॉम्प्टसह तुमच्या लॉगमध्ये PII आहे का ते तपासा.
चेकलिस्ट
- मी माझ्या सिस्टमवर चार लीक व्हेक्टर (प्रॉम्प्ट, लॉग, आउटपुट, ट्रेनिंग) मॅप केले.
- [ ] मी मॉडेलला पाठवण्यापूर्वी PII मास्क (संशोधित/टोकनाइज) करतो.
- [ ] लॉगमध्ये PII नसतात; लॉगिंग करण्यापूर्वी प्रूफरीडिंग आहे.
- प्लेसहोल्डर मॅपिंग तात्पुरते आणि सुरक्षितपणे संग्रहित केले जाते.
- [ ] मला प्रदात्याकडून करारानुसार ZDR आणि "शिक्षणात वापर न करण्याची" वॉरंटी मिळाली आहे.
- [ ] मी माझ्या डेटा निवासाची आवश्यकता (KVKK/GDPR) सत्यापित केली आहे.