AI पर डेटा अपलोड करने से पहले: निजी जानकारी, कंपनी रहस्य और सरकारी फाइलों की सुरक्षा गाइड

AI से सारांश बनवाना, अनुवाद कराना, कॉन्ट्रैक्ट पढ़वाना या कोड डिबग कराना सुविधाजनक है। लेकिन फाइल, स्प्रेडशीट, ईमेल, टेंडर दस्तावेज़, सरकारी नोट या सोर्स कोड अपलोड करने से पहले सवाल यह नहीं होना चाहिए कि यह AI सुरक्षित है या नहीं। बेहतर सवाल है: अगर यह डेटा बाहर चला गया तो किसे नुकसान होगा? सेवा इसे कितने समय तक रखेगी? क्या इसे मॉडल सुधारने या किसी और व्यावसायिक उपयोग में लिया जा सकता है? कौन इसे देख सकता है? और घटना होने पर क्या पता चल पाएगा कि क्या हुआ?

अमेरिका के NIST के जनरेटिव AI जोखिम-प्रबंधन दस्तावेज़ में data provenance, data protection, data retention, commercial use, opt-outs, impact assessments, incident response, monitoring और risk-based controls जैसे मुद्दों को governance का हिस्सा माना गया है। यूरोपीय डेटा संरक्षण बोर्ड यानी EDPB का LLM privacy दस्तावेज़ भी बड़े भाषा मॉडल से जुड़े privacy risks और उन्हें कम करने के उपायों पर केंद्रित है।

इस लेख में पब्लिक या सामान्य सार्वजनिक AI से मतलब ऐसे क्लाउड AI टूल से है जिसे आपके संगठन ने मंज़ूरी नहीं दी है, या जिसके बारे में आपने यह साफ नहीं किया है कि वह input-output को कैसे रखता है, क्या उनका दोबारा उपयोग करता है, opt-out देता है या नहीं, access और monitoring कैसे होती है, और incident response की व्यवस्था क्या है। इसका अर्थ यह नहीं कि AI कभी संवेदनशील डेटा पर काम नहीं कर सकता; अर्थ यह है कि पहले data governance के ठोस और जांचे जा सकने वाले जवाब चाहिए।

सीधा जवाब: जवाब न हो, तो मूल दस्तावेज़ अपलोड न करें

पहचान योग्य निजी जानकारी, कंपनी की गोपनीय सामग्री और अप्रकाशित सरकारी दस्तावेज़ों को सीधे किसी बिना मंज़ूरी वाले पब्लिक AI में नहीं डालना चाहिए। काम चाहे छोटा ही क्यों न लगे—सारांश, अनुवाद, भाषा सुधार, कानूनी ड्राफ्टिंग या कोड डिबगिंग—अगर input से व्यक्ति, ग्राहक, आंतरिक निर्णय, credential, protected information या कोई संवेदनशील मामला उजागर हो सकता है, तो पहले उसे de-identify करें, संवेदनशील कॉलम हटाएँ, सिर्फ सारांश दें या संगठन द्वारा मंज़ूर नियंत्रित वातावरण का उपयोग करें।

सबसे सुरक्षित कसौटी AI का नाम नहीं है। असली कसौटी चार बातों की है: डेटा कितना संवेदनशील है, सेवा उस डेटा को कैसे रखती या इस्तेमाल करती है, आपका संगठन इसकी अनुमति देता है या नहीं, और कुछ गड़बड़ होने पर ट्रैकिंग व सुधार संभव है या नहीं। NIST डेटा सुरक्षा, डेटा-रिटेंशन, monitoring, incident response, opt-out और risk-based controls को जनरेटिव AI governance में रखता है; इनका जवाब न हो, तो मूल डेटा अपलोड न करें।

निजी डेटा, कंपनी रहस्य और सरकारी दस्तावेज़: कैसे पहचानें?

डेटा का प्रकार	मूल नियम	अपलोड से पहले क्या जांचें
निजी जानकारी	पहचान योग्य व्यक्ति से जुड़ा कच्चा डेटा सीधे अपलोड न करें। जरूरत हो तो data minimization, masking या de-identification करें और सेवा की शर्तों व संगठन के नियम देखें।	EDPB ने LLM systems में privacy risks और mitigations को अलग से विषय बनाया है; NIST भी data protection, data retention, impact assessment और monitoring को AI governance में रखता है।
कंपनी की गोपनीय जानकारी	बिना मंज़ूरी वाले पब्लिक AI में न डालें। कॉन्ट्रैक्ट, ग्राहक सूची, बोली या अधिग्रहण से जुड़े कागज़, कानूनी राय, सोर्स कोड, API key, credential और system details को high-risk मानें।	NIST के governance topics में commercial use, data provenance, data protection, data retention, incident response, monitoring और secure software development शामिल हैं।
सरकारी दस्तावेज़	पहले अलग करें: क्या सामग्री पहले से सार्वजनिक, कम-संवेदनशील और कानूनन पुनः उपयोग योग्य है, या यह अप्रकाशित फाइल, आंतरिक नोटिंग, नीति मसौदा, जांच, प्रवर्तन या खरीद-प्रक्रिया से जुड़ी जानकारी है? दूसरी श्रेणी को पब्लिक AI में न डालें।	JRC की Generative AI Outlook रिपोर्ट सार्वजनिक क्षेत्र में जनरेटिव AI उपयोग को अलग विषय के रूप में देखती है; यूरोपीय संसद के एक annex में Bundestag के official data के उपयोग का उदाहरण भी personal या sensitive information से बचने की बात करता है।

अपलोड से पहले 5 सवाल पूछें

अगर इनमें से किसी एक सवाल का भी साफ जवाब नहीं है, तो कच्चा दस्तावेज़ पब्लिक AI में न डालें।

1. क्या सामग्री में निजी या संवेदनशील जानकारी है? अगर डेटा किसी व्यक्ति की पहचान करा सकता है या privacy risk पैदा कर सकता है, तो उसे सीधे paste न करें। EDPB का LLM दस्तावेज़ इसी तरह के privacy risks और mitigations पर केंद्रित है।
2. क्या सेवा input या output को रखती है? कितने समय तक? NIST ने data retention को जनरेटिव AI risk management का हिस्सा माना है।
3. क्या डेटा commercial use, re-processing या service improvement में जा सकता है? opt-out है या नहीं? NIST commercial use, data protection, data retention और opt-outs को governance topics में रखता है।
4. टूल कौन इस्तेमाल कर सकता है, और इस्तेमाल trace हो सकता है? NIST AI actor credentials, anonymous use को discouraging करने और monitoring जैसे पहलुओं का उल्लेख करता है; व्यवहार में इसका मतलब है कि संगठन को पता होना चाहिए कि कौन, क्यों और किस डेटा के साथ टूल इस्तेमाल कर रहा है।
5. क्या impact assessment, incident response और risk-based controls मौजूद हैं? ये सभी NIST के जनरेटिव AI risk management में शामिल विषय हैं।

Prompt में केवल यह लिख देना कि कृपया इसे गोपनीय रखें, सुरक्षा नियंत्रण नहीं है। असली नियंत्रण यह है कि डेटा कहाँ सेव होगा, कौन access कर सकता है, reuse से बाहर निकलने का विकल्प है या नहीं, घटना पर जिम्मेदारी किसकी होगी और आपका संगठन इस उपयोग को अनुमति देता है या नहीं।

रेड, येलो, ग्रीन चेकलिस्ट

नीचे की सूची कानूनी सलाह नहीं है। इसे data protection, retention और risk-based governance के व्यावहारिक रूप में पढ़ें। अंतिम फैसला हमेशा आपके संगठन की IT, cyber security, legal, privacy और records-management policy के अनुसार होना चाहिए।

ग्रीन: विचार कर सकते हैं, फिर भी शर्तें पढ़ें

• ऐसी सामग्री जो पहले से सार्वजनिक है, कम-संवेदनशील है और जिसके इस्तेमाल का अधिकार आपके पास है।
• ऐसा डेटा जिसमें पहचान योग्य जानकारी, संवेदनशील कॉलम और internal identifiers हटाए जा चुके हैं, और जिसे देखकर सामान्य रूप से किसी व्यक्ति, ग्राहक, केस या आंतरिक रहस्य तक वापस नहीं पहुंचा जा सकता।
• पूरा कॉन्ट्रैक्ट, पूरी सरकारी फाइल, पूरी customer sheet या पूरा codebase देने के बजाय सिर्फ जरूरी पृष्ठभूमि और सीमित अंश।

सार्वजनिक होने का अर्थ zero risk नहीं है। अगर सार्वजनिक सामग्री में भी निजी या संवेदनशील जानकारी है, तो privacy risk और data protection के नियम लागू रहेंगे।

येलो: पहले बदलें, ढकें या मंज़ूरी लें

• ग्राहक, कर्मचारी, vendor, नागरिक, मरीज, विद्यार्थी, केस के पक्षकार या किसी identifiable व्यक्ति से जुड़ी जानकारी।
• कॉन्ट्रैक्ट ड्राफ्ट, वित्तीय विवरण, internal presentation, meeting minutes, legal opinion या policy draft।
• सोर्स कोड, तकनीकी दस्तावेज़ और system architecture, खासकर अगर उनमें API key, password, token, credential, vulnerability या deployment details शामिल हो सकती हों; NIST secure software development और risk-based controls को AI governance में रखता है।
• सरकारी विभागों की internal files, अप्रकाशित पत्राचार, नोटिंग, मूल्यांकन सामग्री या inter-agency collaboration documents; सार्वजनिक क्षेत्र में जनरेटिव AI उपयोग के उदाहरणों में भी personal या sensitive information के जोखिम को अलग रखा गया है।

ऐसे डेटा पर AI का उपयोग हमेशा असंभव नहीं है, लेकिन बिना मंज़ूरी, बिना retention rules, बिना monitoring और बिना incident response mechanism के इसे पब्लिक AI में डालना सही तरीका नहीं है।

रेड: पब्लिक AI में अपलोड न करें

• वह डेटा जिसे कानून, अनुबंध या internal policy के तहत बाहर भेजना मना है।
• classified या secret स्तर के दस्तावेज़, राष्ट्रीय सुरक्षा, जांच, प्रवर्तन, procurement evaluation या अत्यधिक संवेदनशील सरकारी प्रक्रिया से जुड़ी सामग्री।
• password, API key, private key, certificate, access token या कोई भी जानकारी जिससे system में प्रवेश किया जा सके।
• ऐसा डेटा जिसके source, authorization, retention, deletion और reuse conditions आप स्पष्ट रूप से confirm नहीं कर सकते।

De-identification सिर्फ नाम हटाने का नाम नहीं

कई बार लोग नाम हटाकर समझ लेते हैं कि डेटा सुरक्षित हो गया। लेकिन ID नंबर, फोन, ईमेल, पता, account number, case number, दुर्लभ job title, तारीख और स्थान का खास combination भी किसी व्यक्ति या मामले तक पहुंचा सकता है। EDPB का एक प्रमुख फोकस LLM systems में privacy risks और mitigations है; इसलिए upload से पहले identifiable details, वापस जोड़कर पहचान कराने वाली जानकारी और गैर-जरूरी field हटाना या बदलना जरूरी है।

व्यावहारिक तरीका यह हो सकता है: असली नामों को व्यक्ति A, कंपनी X जैसे labels से बदलें; सिर्फ जरूरी अंश दें; मूल दस्तावेज़ को abstract scenario में बदलें; lists, logs या tables को पहले aggregate करें; और अगर असली दस्तावेज़ पर ही काम कराना आवश्यक हो, तो संगठन द्वारा मंज़ूर tool और controlled workflow का उपयोग करें।

सरकारी दस्तावेज़: सार्वजनिक डेटा और internal file अलग रखें

सार्वजनिक क्षेत्र में जनरेटिव AI का प्रश्न केवल हाँ या नहीं का नहीं है। JRC की Generative AI Outlook रिपोर्ट public sector use को अलग deep-dive क्षेत्र के रूप में देखती है; यूरोपीय संसद के annex में एक उदाहरण official Bundestag data के इस्तेमाल और personal या sensitive information से बचने की बात करता है।

आम तौर पर विचार करने योग्य सामग्री वह हो सकती है जो पहले से सार्वजनिक, कम-संवेदनशील और कानूनन उपयोग योग्य हो। अधिक सावधानी वाली श्रेणी में आती हैं: अप्रकाशित सरकारी पत्र, internal noting, policy drafts, investigation material, enforcement data, procurement evaluation records और कोई भी फाइल जिसमें निजी या संवेदनशील जानकारी हो। पहली श्रेणी में भी इस्तेमाल की शर्तें जांचें; दूसरी श्रेणी को सीधे पब्लिक AI में न डालें।

सबसे आसान निर्णय नियम

अगर डेटा लीक होने से किसी व्यक्ति, संगठन, सार्वजनिक हित या compliance status को नुकसान हो सकता है, तो उसका मूल रूप पब्लिक AI को न दें। पहले masking, summarization और data minimization करें। अगर काम के लिए असली दस्तावेज़ जरूरी है, तो मंज़ूर प्रक्रिया और controlled tool अपनाएँ, और data protection, data retention, access rights, monitoring और incident response की व्यवस्था स्पष्ट रूप से confirm करें।