डाटा लीक रोकथाम र PII मास्किङ — सुरक्षा र कर्पोरेट सुशासन

लाभ:

प्रम्प्ट, लग, आउटपुट र प्रशिक्षण मार्फत डाटा लीक भेक्टरहरू पहिचान गर्ने क्षमता
मोडेलमा पठाउनु अघि PII डाटालाई रिडेक्शन वा टोकनाइजेसनको साथ मास्क गर्ने क्षमता
सुरक्षा डिजाइनमा शून्य डाटा रिटेन्सन (ZDR) र डाटा रेसिडेन्सी अवधारणाहरू समावेश गर्ने क्षमता

संगठनको सबैभन्दा महँगो एआई दुर्घटना सामान्यतया फैंसी जेलब्रेक होइन, तर रन-अफ-द-मिल डाटा लीक हो: एक कर्मचारीले सहायकमा संवेदनशील ग्राहक फाइल टाँस्छन्, त्यो डाटा प्रदायकको लगमा समाप्त हुन्छ, त्यसपछि एक अडिटले सोध्छ "यो डाटा किन संगठन छोड्यो?" तपाईंले यो प्रश्नको सामना गर्नुहुनेछ: यस इकाईमा, हामी यो मोडेलमा पठाउनु अघि व्यक्तिगत डेटा (PII - व्यक्तिगत रूपमा पहिचान योग्य जानकारी, व्यक्तिको पहिचान गर्ने डेटा: नाम, आईडी, इ-मेल, कार्ड नम्बर) मास्क गर्ने तरिका, र कुन कर्पोरेट सुरक्षाहरू (शून्य डाटा रिटेन्सन, डाटा रेसिडेन्सी) ले जोखिम कम गर्छ भन्ने कुरा सिक्ने छौँ।

चुहावट कहाँबाट आउँछ? चार भेक्टर

सुरक्षा वा डाटा सुरक्षा पेशेवरको मानसिक नक्सा यो हो - डाटाले संगठन बाहिर वा गलत हातमा चार तरिकामा आफ्नो बाटो फेला पार्न सक्छ:

प्रम्प्ट मार्फत: प्रयोगकर्ताले सिधै प्रम्प्टमा संवेदनशील डाटा टाँस्छ र यो डाटा प्रदायकमा जान्छ।
लग मार्फत: अनुरोधहरू र प्रतिक्रियाहरू लगहरू डिबग गर्न कच्चा रूपमा लेखिएका छन्; लगहरूमा पहुँच भएका जो कोहीले डाटा देख्छन्।
आउटपुट मार्फत: मोडेलले एक प्रयोगकर्ताको डेटा अर्को प्रयोगकर्तामा लीक गर्छ (विशेष गरी साझा सन्दर्भ वा RAG मा)।
तालिमद्वारा: यदि प्रदायकले मोडेललाई तालिम दिन तपाईंले पेश गर्नुभएको डाटा प्रयोग गर्नुहुन्छ भने, तपाईंको डाटा भविष्यका प्रतिक्रियाहरूमा प्रतिबिम्बित हुन सक्छ।

सावधानी: धेरै पटक बेवास्ता गरिएको भेक्टर लग हो। एप्लिकेसनले राम्रोसँग काम गरे पनि, यदि तपाइँसँग कच्चा अनुरोध/प्रतिक्रिया लग गर्ने कोडको एउटा लाइन छ भने, तपाइँ तपाइँको आफ्नै प्रणालीहरूमा PII लीक गर्दै हुनुहुन्छ।

स्टेप बाइ स्टेप: मास्किङ पाइपलाइन (रिडेक्शन पाइपलाइन)

पत्ता लगाउनुहोस्। मोडेलमा पाठ पठाउनु अघि PII क्षेत्रहरू (regex, अफ-द-शेल्फ PII डिटेक्टर वा संस्था पहिचान) फेला पार्नुहोस्।
यसलाई बदल्नुहोस्। प्रत्येक PII लाई प्लेसहोल्डरले बदल्नुहोस्: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1]।
म्यापिङ राख्नुहोस्। अस्थायी र सुरक्षित नक्सामा प्लेसहोल्डर ↔ वास्तविक मान म्यापिङलाई आफ्नो छेउमा मात्र राख्नुहोस्।
मोडेलमा मास्क गरिएको पाठ पठाउनुहोस्। मोडेलले [AD_1] मात्र देख्छ, वास्तविक डेटा कहिल्यै देख्दैन।
रिहाइड्रेट। जब मोडेल प्रतिक्रिया आइपुग्छ, नक्साबाट वास्तविक मानहरूसँग प्लेसहोल्डरहरू प्रतिस्थापन गर्नुहोस् (यदि यो अधिकृत प्रयोगकर्तालाई प्रदर्शन गरिनेछ भने मात्र)।

यसलाई टोकनाइजेसन पनि भनिन्छ: संवेदनशील मानलाई उल्टाउन मिल्ने तर अर्थहीन टोकनले प्रतिस्थापन गर्ने। अर्कोतर्फ रिडेक्सन, रिभर्ट नगरी पूर्ण रूपमा हटाउँदै/अस्पष्ट गर्दैछ — यदि मोडेललाई वास्तविक मान आवश्यक पर्दैन भने यसलाई प्राथमिकता दिनुहोस्।

चार प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू

निर्णय मास्क गर्न को लागी एक सरल गाइड:

निर्णय नियम: के मोडेललाई आफ्नो काम गर्न वास्तविक PII चाहिन्छ? - होइन (संक्षेपीकरण, वर्गीकरण, टोन विश्लेषण) -> REDACTION (कुनै उल्टो) - हो तर केवल स्थिरताको लागि (उही व्यक्तिको लागि समान सन्दर्भ) -> TOKENIZATION- हो र वास्तविक मूल्य उत्पन्न हुनेछ (व्यक्तिगत अक्षर, यसको पछाडि मास्क) -> मास्कको अन्त्यमा।

प्रूफरीडिङ निर्देशन (यदि कोड साइडमा कुनै डिटेक्टर छैन भने, कम्तिमा मोडेलको नियमको रूपमा):

तलको पाठ प्रशोधन गर्नुहोस्। तपाईंको प्रतिक्रियामा कुनै पनि व्यक्तिगत डेटा (नाम, टेलिफोन, इ-मेल, TR ID, IBAN, ठेगाना) दोहोर्याउनुहोस्। यदि तपाइँ तिनीहरूलाई सन्दर्भ गर्न आवश्यक छ भने, [PERSON], [PHONE], आदि जस्ता सामान्य ट्यागहरू प्रयोग गर्नुहोस्।<text>{{ प्रविष्टि }}</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 - 4,500 रेकर्डको लग लीक। एक बीमा कम्पनीको दावी सहायकले प्रत्येक अनुरोधलाई डिबगिङको लागि कच्चा लगहरूमा लेखिरहेको थियो। एक लेखापरीक्षणले पत्ता लगायो कि यी लगहरू 90 दिनको लागि भण्डारण गरिएको थियो र 12 व्यक्तिहरूको पहुँच थियो; यसमा ४,५०० नीतिधारकहरूको परिचयपत्र र टेलिफोन जानकारी समावेश थियो। पूर्व-लग रिडेक्शन थपिएपछि, उही लगहरूमा PII शून्यमा घट्यो र KVKK खोज बन्द गरियो।

केस 2 - टोकनकरण स्थिरता कायम राख्यो। एक मानव संसाधन टोलीले उम्मेदवार मूल्याङ्कन सारांशहरू उत्पादन गरिरहेको थियो। जब PII redact गरिएको थियो, मोडेलले सोचे कि एउटै उम्मेद्वार विभिन्न ठाउँहरूमा फरक व्यक्ति हो। टोकनाइजेसनमा स्विच गरेर, प्रत्येक उम्मेद्वारले [CANDIDATE_1] जस्ता लगातार टोकन प्राप्त गरे; मोडेलले सही एट्रिब्युशन बनायो, जबकि वास्तविक नाम कहिल्यै बाहिर आएन।

केस ३ — गैर-ZDR प्रदायक हटाइयो। एक स्वास्थ्य प्रविधि फर्मले तीन प्रदायकहरूको मूल्याङ्कन गर्यो। सबैभन्दा कम मूल्य भएकोले ३० दिनसम्म डाटा राख्छ र "सेवा सुधार" को लागि प्रयोग गर्न सकिन्छ। कम्पनीले यो क्लज अस्वीकार्य फेला पारेको छ किनभने यसले बिरामी डेटा प्रशोधन गर्दछ; ZDR र डाटा रेसिडेन्सीको ग्यारेन्टी गर्ने १८% बढी महँगो प्रदायक छनोट गर्नुहोस्। त्यसपछिको लेखापरीक्षणमा यो निर्णयले जोखिमलाई निकै कम गरेको मानिएको थियो ।

सामान्य गल्तीहरू

मोडेलमा कच्चा PII पठाएर र प्रम्प्टमा "बचत नगर्नुहोस्" टाइप गरेर यो सुरक्षित छ भन्ने सोच्दै।
एप्लिकेसन कायम गर्दा डिबग लगहरूमा कच्चा प्रम्प्ट/प्रतिक्रिया बिर्सिँदै।
टोकनाइजेशनको साथ भ्रमित सुधार; स्थिरता आवश्यक भएको ठाउँमा सुधार गर्ने र मोडेललाई भ्रामक बनाउने।
प्लेसहोल्डर ↔ असुरक्षित वा निरन्तर स्थानमा वास्तविक मान म्यापिङ भण्डारण गर्दै।
"शिक्षामा प्रयोग" ग्यारेन्टी र "डेटा भण्डारण" ग्यारेन्टी एउटै कुराको रूपमा गलत।
डाटा निवासको लागि कहिल्यै सोध्नु हुँदैन (कुन देशमा डाटा प्रशोधन गरिन्छ)।

संक्षेपमा

चार भेक्टरहरू मार्फत डाटा लीक हुन्छ: प्रम्प्ट, लग, आउटपुट, र प्रशिक्षण। यो लग हो जुन प्रायः बेवास्ता गरिन्छ।
मोडेलमा पठाउनु अघि PII मास्क गर्नुहोस्: यदि वास्तविक मान आवश्यक छैन भने सुधार, स्थिरता आवश्यक भएमा टोकनकरण।
प्लेसहोल्डर राख्नुहोस् ↔ वास्तविक मान म्यापिङ केवल तपाईंको छेउमा, अस्थायी र सुरक्षित।
ZDR (शून्य डाटा रिटेन्सन) र डाटा रेसिडेन्सी आपूर्तिकर्ता छनोटको निर्णायक कर्पोरेट सुरक्षा उपायहरू हुन्।
"शैक्षिक प्रयोग" र "डेटा अवधारण" अलग-अलग वारेन्टीहरू हुन्; सम्झौतामा दुवैको लागि अलग-अलग सोध्नुहोस्।

आवेदन कार्य

तपाईंको आफ्नै AI पाइपलाइन (परीक्षण डेटाको साथ) मार्फत जाने वास्तविक अनुरोधको एकल उदाहरण लिनुहोस्। यो अनुरोधको (1) प्रम्प्ट, (2) लग, र (3) प्रतिक्रिया चरणहरूमा कुन PII देखिन्छ भनेर चिन्ह लगाउनुहोस्। प्रत्येक PII को लागी, "रिडेक्सन, टोकनाइजेशन, कुनै पोस्टिंग छैन?" आफ्नो निर्णय लिनुहोस् र नयाँ मास्क गरिएको संस्करण लेख्नुहोस्। अन्तमा, माथिको नियन्त्रण प्रम्प्टको साथ तपाईंको लगहरूमा PII समावेश छ कि छैन भनेर जाँच गर्नुहोस्।

चेकलिस्ट

[ ] मैले मेरो प्रणालीमा चार लीक भेक्टरहरू (प्रम्प्ट, लग, आउटपुट, प्रशिक्षण) म्याप गरें।
[ ] म मोडेलमा पठाउनु अघि PII मास्क (संशोधन/टोकनाइज) गर्छु।
[ ] लगहरूमा PII समावेश हुँदैन; लगिङ गर्नु अघि प्रूफरीडिङ छ।
[] प्लेसहोल्डर म्यापिङ अस्थायी र सुरक्षित रूपमा भण्डारण गरिएको छ।
[ ] मैले प्रदायकबाट ZDR र "शिक्षामा गैर-प्रयोग" वारेन्टी प्राप्त गरें।
[ ] मैले मेरो डाटा निवास आवश्यकता (KVKK/GDPR) प्रमाणित गरेको छु।