“क्या हमारा डेटा सुरक्षित है?” लगभग हर AI प्रोजेक्ट का पहला सवाल होता है, और अक्सर वही सवाल जिसका जवाब सबसे कम सटीकता से दिया जाता है। ईमानदार जवाब इस पर निर्भर करता है कि डेटा असल में कहाँ-कहाँ से गुज़रता है, और AI सिस्टम के रास्ते में ज़्यादातर लोगों की उम्मीद से ज़्यादा पड़ाव होते हैं।
छह जगहें, जहाँ आपका डेटा पहुँच सकता है
एक आम नॉलेज असिस्टेंट को लीजिए, जो अंदरूनी दस्तावेज़ों से कर्मचारियों के सवालों के जवाब देता है। डेटा इनसे होकर गुज़रता है:
- स्रोत सिस्टम: SharePoint, दस्तावेज़ प्रबंधन सिस्टम, ERP। इनके पहले से मालिक और ऐक्सेस नियम होते हैं।
- इनजेशन पाइपलाइन, जो दस्तावेज़ों से टेक्स्ट निकालती है और उन्हें छोटे हिस्सों में बाँटती है।
- एम्बेडिंग मॉडल, जो सर्च के लिए हर हिस्से को एक वेक्टर में बदलता है। अगर यह क्लाउड API है, तो हर दस्तावेज़ इससे होकर गुज़रता है।
- वेक्टर डेटाबेस, जो उन हिस्सों और वेक्टरों को सहेजता है, अक्सर संवेदनशील कंटेंट की एक कॉपी के रूप में।
- लैंग्वेज मॉडल, जिसे हर एक अनुरोध पर सवाल के साथ निकाले गए हिस्से मिलते हैं।
- लॉग और ट्रेस, जो डिबगिंग और क्वालिटी कंट्रोल के लिए प्रॉम्प्ट और जवाब दर्ज करते हैं, और यही वह जगह है जहाँ संवेदनशील डेटा सबसे ज़्यादा बिना किसी की नज़र में आए जमा होता रहता है।
स्विस डेटा सुरक्षा क़ानून (nDSG) और GDPR के अर्थ में इनमें से हर एक प्रोसेसिंग की जगह है। हर एक के लिए तीन सवालों का जवाब चाहिए: यह कहाँ है, इसे कौन चलाता है, और डेटा कितने समय तक रखा जाता है?
पहले अनुबंध
जैसे ही कोई बाहरी प्रदाता आपकी ओर से निजी डेटा प्रोसेस करता है, आपको nDSG के अनुच्छेद 9 और GDPR के अनुच्छेद 28 के तहत डेटा प्रोसेसिंग समझौता चाहिए। व्यवहार में इसका मतलब है:
- आपके इम्प्लीमेंटेशन साझेदार के साथ DPA, जिसमें तय हो कि प्रोजेक्ट के दौरान वे क्या देख और कर सकते हैं।
- सब-प्रोसेसरों की सूची: क्लाउड प्रदाता, मॉडल प्रदाता, मॉनिटरिंग टूल। यह सूची, और इसमें होने वाले बदलाव, आपको मंज़ूर करने चाहिए।
- स्विट्ज़रलैंड और EU के बाहर के किसी भी प्रदाता के लिए ट्रांसफ़र के क़ानूनी आधार की जाँच, जैसे पर्याप्तता का फ़ैसला या मानक अनुबंध खंड।
NDA कारोबारी राज़ों की रक्षा करता है; यह निजी डेटा के लिए DPA की जगह नहीं लेता। आम तौर पर आपको दोनों चाहिए।
डिज़ाइन के फ़ैसले जो डेटा को काबू में रखते हैं
अनुबंध नियम तय करते हैं; आर्किटेक्चर तय करता है कि दाँव पर कितना है। सबसे अहम फ़ैसले:
रीजन सोच-समझकर चुनें। बड़े क्लाउड प्रदाताओं के डेटा सेंटर स्विट्ज़रलैंड में हैं, और कई प्रदाता स्विस या EU रीजन में लैंग्वेज मॉडल देते हैं। जहाँ ज़रूरी रीजन में कोई सक्षम मॉडल उपलब्ध नहीं है, वहाँ ओपन-वेट मॉडल आपके अपने इंफ़्रास्ट्रक्चर या किसी स्विस क्लाउड पर चल सकते हैं।
जो ज़रूरी नहीं, उसे बंद करें। कई मॉडल API ज़ीरो डेटा रिटेंशन के विकल्प देते हैं और कारोबारी ग्राहकों के डेटा को डिफ़ॉल्ट रूप से ट्रेनिंग से बाहर रखते हैं। दोनों बातें लिखित में पक्की करें और उन्हें साफ़ तौर पर कॉन्फ़िगर करें, बजाय उन डिफ़ॉल्ट सेटिंग्स पर भरोसा करने के जो बदल सकती हैं।
भेजने से पहले कम करें। हर फ़ील्ड का मॉडल तक पहुँचना ज़रूरी नहीं। नाम, खाता नंबर और पते अक्सर अनुरोध से पहले प्लेसहोल्डर से बदले जा सकते हैं और बाद में वापस भरे जा सकते हैं। मॉडल अपना काम करता रहता है; प्रदाता पहचान की जानकारी कभी नहीं देखता।
मौजूदा अनुमतियों का सम्मान करें। नॉलेज असिस्टेंट ऐक्सेस नियमों से बचने का रास्ता नहीं बनना चाहिए। हर जवाब सिर्फ़ उन दस्तावेज़ों से बनना चाहिए जिन्हें पूछने वाला उपयोगकर्ता देख सकता है, और यह रिट्रीवल के समय लागू हो, न कि मॉडल से सावधान रहने की गुज़ारिश करके।
लॉग को संवेदनशील डेटा मानें। ट्रेस में निजी डेटा छिपाएँ, रखने की अवधि तय करें, और सीमित करें कि उन्हें कौन पढ़ सकता है। हमेशा के लिए रखे गए डिबग लॉग ऑडिट में अक्सर पकड़े जाते हैं।
बाहर निकलने की योजना बनाएँ। प्रोजेक्ट के अंत में डेटा लौटाया या डिलीट किया जाता है, वेक्टर डेटाबेस, बैकअप और टेस्ट एनवायरनमेंट की कॉपियों समेत, और डिलीट होने की लिखित पुष्टि की जाती है।
एक पेज का डेटा नक्शा
कोई भी असली डेटा चलने से पहले, हम सिस्टम का एक पेज का नक्शा बनाते हैं: हर हिस्सा, उसकी जगह, उसे कौन चलाता है, वह कौन-सा डेटा देखता है और कितने समय तक रखता है। यही वह दस्तावेज़ है जो आपका डेटा सुरक्षा अधिकारी माँगेगा, इससे प्रोसेसिंग गतिविधियों का रिकॉर्ड बनाना आसान हो जाता है, और यह “क्या हमारा डेटा सुरक्षित है?” को एक ठोस, जाँचे जा सकने वाले जवाब वाले सवाल में बदल देता है।