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

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

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

अपलोड से पहले 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 करें।