प्राइवेसी कानून डिज़ाइन को आकार देते हैं

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 4 (कुल 6 में से) — अध्याय डेटा गुणवत्ता और गवर्नेंस, Data Architect कोर्स का अध्याय 5। हर मॉड्यूल अपने आप में पूरा है। पिछला: अपने डेटा को जानें · अगला: सहमति और भुला दिए जाने का अधिकार

यह मॉड्यूल किस सवाल का जवाब देता है: प्राइवेसी और इंडस्ट्री के नियम किसी Salesforce डिज़ाइन से क्या माँगते हैं?

जब मैं ऑस्ट्रेलिया में काम करता था, तो मुझे ऐसे बहुत-से उभरते आर्किटेक्ट मिले जिन्होंने GDPR का नाम कभी नहीं सुना था। यूरोप के लोगों ने अक्सर कैलिफ़ोर्निया, कनाडा या ब्राज़ील के प्राइवेसी कानून के बारे में नहीं सुना होता। यह स्वाभाविक है: आप उस जगह के नियम जानते हैं जहाँ आप काम करते हैं। लेकिन ये कानून सीमाओं के पार पहुँचते हैं, और ये सिस्टम डिज़ाइन को आकार देते हैं, भले ही इनमें से कोई भी Salesforce के बारे में नहीं है। इसलिए इनकी जगह एक डेटा आर्किटेक्चर कोर्स में है।

आपको वकील बनने की ज़रूरत नहीं है। लेकिन आपको यह देखना होगा कि कोई नियम यह बदल सकता है कि डेटा कहाँ स्टोर होता है, आप क्या इकट्ठा करते हैं, उसे कौन देखता है, आप उसे किस वजह से इस्तेमाल कर सकते हैं, उसे कितने समय रखते हैं, कहाँ भेजते हैं, क्या आप उसे डिलीट कर सकते हैं, कौन-सा इतिहास रखते हैं, और बाद में आप क्या साबित कर सकते हैं। ये सिर्फ़ कानूनी सवाल नहीं हैं। ये डेटा आर्किटेक्चर के सवाल हैं।

यह मॉड्यूल आर्किटेक्चर का मार्गदर्शन है, कानूनी सलाह नहीं। कौन-से कानून लागू होते हैं और वे क्या माँगते हैं, यह लीगल और कम्प्लायंस टीमें तय करती हैं। आर्किटेक्ट उन आवश्यकताओं को लागू किए जा सकने वाले डिज़ाइन में बदलता है।

कानून सीमा पर नहीं रुकते

पहले सबसे बड़ी गलतफ़हमी: “हम यूरोप में नहीं हैं, इसलिए GDPR लागू नहीं होता।” हो सकता है, न भी हो। GDPR का क्षेत्रीय दायरा (territorial scope) EU के बाहर के उन संगठनों तक पहुँचता है जो EU में लोगों को सामान या सेवाएँ देते हैं, या वहाँ उनके व्यवहार पर नज़र रखते हैं (Article 3, Regulation (EU) 2016/679 (opens in a new tab))। इसलिए आपकी कंपनी का मुख्यालय कहाँ है, यह सवाल का अंत नहीं है। आपके ग्राहक, कर्मचारी, वे लोग जिनका डेटा आपके पास है, आपके सिस्टम, आपके प्रोसेसर कहाँ हैं? डेटा कहाँ-कहाँ जाता है? यह फिर से अध्याय 4 का लैंडस्केप है। यह जाने बिना कि डेटा कहाँ जाता है, आप प्राइवेसी के अच्छे फ़ैसले नहीं ले सकते।

वे नियम जिन्हें आपको पहचानना चाहिए

ये वे नाम हैं जो एक आर्किटेक्ट को पता होने चाहिए, साथ में यह कि हर एक किस चीज़ को कवर करता है। यह पहचानने की टेबल है, लागू होने का मैट्रिक्स नहीं: इसे पढ़कर यह तय न करें कि “कैलिफ़ोर्निया में हमारे ग्राहक हैं, इसलिए आवश्यकता X लागू होती है।” यह लीगल का फ़ैसला है। आपका काम इतना जानना है कि सिस्टम बनने से पहले सवाल पूछ सकें।

कानून या मानक	कहाँ या किस पर	आर्किटेक्ट को इसे क्यों पहचानना चाहिए
GDPR (opens in a new tab)	यूरोपीय संघ (EU)	व्यक्तिगत डेटा, वैध प्रोसेसिंग, व्यक्ति के अधिकार, रिटेंशन, ट्रांसफ़र, privacy by design
CCPA, जिसे CPRA ने संशोधित किया (opens in a new tab)	कैलिफ़ोर्निया	बिज़नेस उपभोक्ताओं के बारे में जो व्यक्तिगत जानकारी इकट्ठा करते हैं, उस पर उपभोक्ताओं के अधिकार
PIPEDA (opens in a new tab)	कनाडा	प्राइवेट सेक्टर के संगठन व्यक्तिगत जानकारी को कैसे संभालते हैं
LGPD (opens in a new tab)	ब्राज़ील	ब्राज़ील का सामान्य व्यक्तिगत-डेटा संरक्षण कानून
Privacy Act 1988 (opens in a new tab)	ऑस्ट्रेलिया	Australian Privacy Principles के तहत संगठन व्यक्तिगत जानकारी को कैसे संभालते हैं
HIPAA (opens in a new tab)	अमेरिका की हेल्थकेयर	कवर किए गए संदर्भों में संरक्षित स्वास्थ्य जानकारी (protected health information)
PCI DSS (opens in a new tab)	पेमेंट कार्ड	पेमेंट-कार्ड खाते के डेटा की सुरक्षा
Sarbanes-Oxley (SOX) (opens in a new tab)	अमेरिका की पब्लिक कंपनियाँ	वित्तीय रिपोर्टिंग के पीछे के कंट्रोल और सबूत
COPPA (opens in a new tab)	अमेरिका, ऑनलाइन बच्चे	बच्चों से ऑनलाइन इकट्ठा की गई व्यक्तिगत जानकारी

सूची बढ़ती जाती है (अमेरिका के और राज्यों के अपने कानून हैं), और कानून बदलते रहते हैं। इसीलिए मैं नहीं चाहता कि आप एक टेबल रटकर सोचें कि आपने प्राइवेसी आर्किटेक्चर सीख लिया। नाम सीखें, फिर वे सवाल सीखें जो उनके बाद भी टिके रहते हैं।

कानूनों में क्या साझा है

ब्योरे अलग हैं, लेकिन बड़े प्राइवेसी कानून बार-बार उन्हीं कुछ बातों पर लौटते हैं, और हर एक का असर आर्किटेक्चर पर पड़ता है।

अधिकार। लोग अपना डेटा देखने, उसे सुधारने, डिलीट करवाने और अपने साथ ले जाने के लिए कह सकते हैं; कैलिफ़ोर्निया और ब्राज़ील के कानूनों के तहत वे उसके बेचे जाने से इनकार (opt out) भी कर सकते हैं। इनमें से हर अनुरोध का मतलब है उस व्यक्ति का डेटा ढूँढना, पूरा का पूरा।

ट्रांसफ़र। GDPR और LGPD अपने अधिकार-क्षेत्र से बाहर जाने वाले व्यक्तिगत डेटा को नियंत्रित करते हैं और जहाँ वह जाता है वहाँ पर्याप्त सुरक्षा माँगते हैं; PIPEDA उम्मीद करता है कि जब कोई थर्ड पार्टी डेटा प्रोसेस करे, तो सुरक्षा का स्तर वही रहे, चाहे वह कहीं भी हो। यह फिर से लैंडस्केप है: कौन-से तीर सीमा पार करते हैं?

उल्लंघन की सूचना (breach notification)। जब व्यक्तिगत डेटा उजागर होता है, तो कानून उम्मीद करते हैं कि आप अधिकारियों को, और कभी-कभी प्रभावित लोगों को, एक समय-सीमा के भीतर बताएँ, जो हर कानून में अलग है। आप उस डेटा के बारे में सूचना नहीं दे सकते जिसके होने का आपको पता ही नहीं था, और अगर आप कॉपियाँ ढूँढ नहीं सकते तो यह नहीं बता सकते कि क्या उजागर हुआ।

जवाबदेही। आपको कम्प्लायंस दिखा पाना होगा: आप क्या प्रोसेस करते हैं और क्यों, इसके रिकॉर्ड; ज़्यादा जोखिम वाली प्रोसेसिंग के लिए इम्पैक्ट असेसमेंट; और GDPR और LGPD के तहत एक डेटा प्रोटेक्शन ऑफ़िसर (DPO)। आर्किटेक्चर को ये रिकॉर्ड पैदा करने होंगे।

जो व्यक्तिगत है, वहाँ से शुरू करें

व्यक्तिगत जानकारी की रक्षा करने से पहले, उसे ढूँढें। कुछ तो ज़ाहिर है: नाम, घर का पता, फ़ोन, ईमेल। कुछ नहीं: लोकेशन, डिवाइस पहचानकर्ता, IP पते, इमेज, व्यवहार का डेटा, कुछ भी जिसे किसी व्यक्ति से वापस जोड़ा जा सके। और संदर्भ मायने रखता है। Steve Trucking की एक डिलीवरी में प्राप्तकर्ता का नाम, पता, फ़ोन नंबर, डिलीवरी नोट्स और फ़ोटो होते हैं। एक फ़ोटो में दरवाज़े पर रखा डिब्बा हो सकता है, या कोई व्यक्ति, या घर का अंदरूनी हिस्सा। डिलीवरी ऑपरेशनल डेटा है, लेकिन उसके कुछ एट्रिब्यूट व्यक्तिगत हैं। इसीलिए मॉड्यूल 3 ने फ़ील्ड वर्गीकृत किए: प्राइवेसी यह जानने से शुरू होती है कि आपके पास क्या है।

यह कहाँ रहता है?

“Salesforce में।” शायद सिर्फ़ Salesforce में नहीं। क्या यह किसी रिटेल पार्टनर से आया? क्या इसे Snowflake में कॉपी किया गया, Data 360 ने इन्जेस्ट किया, किसी इंटीग्रेशन लॉग में लिखा गया, किसी यूज़र ने एक्सपोर्ट किया, फ़ील्ड हिस्ट्री में छूट गया, आर्काइव हुआ, किसी सैंडबॉक्स में कॉपी हुआ, किसी पार्टनर को दिया गया, किसी एजेंट की बातचीत में इस्तेमाल हुआ? व्यक्तिगत डेटा फैलता है। इसलिए जब लीगल पूछे “इस व्यक्ति की जानकारी हमारे पास कहाँ-कहाँ है?”, तो “हमें पता है कि मौजूदा वैल्यू कहाँ है” कोई जवाब नहीं है। मुझे लैंडस्केप और लिनिएज चाहिए: कॉपियाँ कहाँ गईं।

Click to enlarge

एक फ़ोन नंबर, कई कॉपियाँ। प्राइवेसी कॉपियों पर भी लागू होती है।

आपको इसे इस्तेमाल करने की अनुमति क्यों है?

डेटा का होना और उसे इस्तेमाल करने की अनुमति होना एक ही बात नहीं है। Steve Trucking के पास आज की डिलीवरी का तालमेल करने के लिए प्राप्तकर्ता का फ़ोन नंबर है। क्या इससे वह मार्केटिंग लिस्ट बन जाता है? नहीं। कानूनी आधार (legal basis) अधिकार-क्षेत्र और स्थिति पर निर्भर करता है, और लीगल इसका मार्गदर्शन करता है, लेकिन आर्किटेक्चर को जवाब साथ लेकर चलना होगा: इसे क्यों इकट्ठा किया गया, किस इस्तेमाल की अनुमति दी गई, क्या सहमति की ज़रूरत थी, क्या वह दी गई, वापस ली गई, और किस चैनल, पते और मकसद के लिए। डेटा इस्तेमाल करने की अनुमति को डेटा के रूप में दर्शाया जा सकना चाहिए, क्योंकि कोई नीति दस्तावेज़ रनटाइम पर फ़ैसला नहीं ले सकता। अगला मॉड्यूल इसका मॉडल बनाता है।

कम इकट्ठा करना एक आर्किटेक्चर फ़ैसला है

प्राइवेसी के सबसे मज़बूत कंट्रोल में से एक है डेटा इकट्ठा ही न करना, या उसे वहाँ कॉपी न करना जहाँ उसकी ज़रूरत नहीं। क्या Snowflake को प्राप्तकर्ता का फ़ोन नंबर चाहिए? क्या एनालिटिक्स को पूरा पता चाहिए? क्या सैंडबॉक्स को डिलीवरी की असली फ़ोटो चाहिए? क्या इस सवाल का जवाब देने के लिए एजेंट को प्राप्तकर्ता का व्यक्तिगत विवरण चाहिए? अगर नहीं, तो सबसे मज़बूत कंट्रोल शायद उसे वहाँ न रखना है। हर वह कॉपी जो आप नहीं बनाते, एक ऐसी कॉपी है जिसे आपको सुरक्षित नहीं करना, रखना नहीं, डिलीट नहीं करना, जिसकी सहमति ट्रैक नहीं करनी, ऑडिट नहीं करना, या उल्लंघन में रिपोर्ट नहीं करना। गवर्न करने के लिए सबसे सस्ता संवेदनशील डेटा वह है जिसे आपने कभी कॉपी ही नहीं किया।

रिटेंशन मॉडल का हिस्सा है

“अभी के लिए हम सब कुछ रख लेंगे” भी एक रिटेंशन नीति है। बस एक खराब नीति। अहम डेटा के लिए मैं डिज़ाइन के समय ही जानना चाहता हूँ कि हमें उसकी कितने समय तक ज़रूरत है और क्यों; क्या कोई नियम न्यूनतम अवधि तय करता है या कोई दूसरा अधिकतम; घड़ी कब शुरू होती है; और अंत में क्या होता है: डिलीट, आर्काइव, डी-आइडेंटिफ़ाई, और कॉपियाँ कहाँ हैं? वित्तीय रिकॉर्ड शायद एक तय अवधि तक रखने पड़ें। डिलीवरी के सालों बाद किसी प्राप्तकर्ता के गेट कोड का कोई मकसद नहीं है। ये फ़ैसले डेटाबेस के बड़ा होने का इंतज़ार नहीं करते।

अनामीकृत, छद्मनामीकृत, एन्क्रिप्टेड, मास्क्ड

“Jane Smith” की जगह 7F92A1 लिख दें। क्या Jane अनामीकृत हो गई? नहीं, अगर किसी दूसरी टेबल में अब भी लिखा है 7F92A1 = Jane Smith। यह छद्मनामीकरण (pseudonymization) है: सीधा पहचानकर्ता बदल दिया जाता है, लेकिन अलग से रखी जानकारी से डेटा को फिर से जोड़ा जा सकता है, और GDPR के तहत छद्मनामीकृत डेटा अब भी व्यक्तिगत डेटा है (Article 4(5))। अनामीकरण (anonymization) इससे आगे जाता है: डेटा को अब वाजिब तौर पर उस व्यक्ति से जोड़ा नहीं जा सकता (Recital 26)। इसलिए जब कोई कहे “हमें इसे डिलीट करने की ज़रूरत नहीं, हम बस नाम हटा देंगे,” तो सावधान रहें। अगर व्यक्ति को अब भी वाजिब तौर पर पहचाना जा सकता है, तो आपने वह रेखा पार नहीं की। कोई नतीजा कानून की शर्तें पूरी करता है या नहीं, यह लीगल का फ़ैसला है; आर्किटेक्ट का काम ठीक-ठीक बताना है कि सिस्टम क्या करता है: क्या इसे फिर से जोड़ा जा सकता है, कौन-सी keys बची हैं, मैपिंग कहाँ हैं?

शब्दों का इस्तेमाल सटीकता से करें, क्योंकि वे अलग-अलग समस्याएँ हल करते हैं। एन्क्रिप्शन डेटा को अनधिकृत खुलासे से बचाता है; अधिकृत यूज़र अब भी उसे डिक्रिप्ट कर सकता है। मास्किंग बदलती है कि खास यूज़र या एनवायरनमेंट क्या देखते हैं। छद्मनामीकरण सीधी पहचान को अलग करता है, पर वापस जाने का रास्ता रखता है। अनामीकरण व्यक्ति को पहचानने की वाजिब क्षमता हटा देता है। सिर्फ़ आखिरी वाला डेटा को “व्यक्तिगत” की श्रेणी से बाहर निकालता है।

नियम आवश्यकताएँ बनते हैं

लीगल को मुझसे परमिशन सेट बनाने के लिए कहने की ज़रूरत नहीं; वह रेखा का मेरा हिस्सा है। लीगल कह सकता है “इस श्रेणी की व्यक्तिगत जानकारी तक सिर्फ़ वे कर्मचारी पहुँच सकते हैं जिनकी जायज़ बिज़नेस ज़रूरत है।” फिर मैं अनुवाद करता हूँ: वे कौन हैं, हम उस श्रेणी को कैसे पहचानते हैं, एक्सेस कैसे दिया जाता है, किसी के नौकरी बदलने पर क्या होता है, क्या कोई इंटीग्रेशन उसे पढ़ सकता है, क्या कोई एजेंट, क्या उसे एक्सपोर्ट किया जा सकता है, और हम कैसे साबित करें कि उसे किसने देखा? नीति मालिक तय करते हैं; आर्किटेक्ट उसे लागू करते हैं। लीगल और कम्प्लायंस दायित्व तय करते हैं, डेटा के मालिक बिज़नेस नीति तय करते हैं, और आर्किटेक्ट उसे लागू करने का डिज़ाइन बनाता है।

Click to enlarge

नियम से सबूत तक: लीगल व्याख्या करता है, मालिक नीति तय करता है, आर्किटेक्ट उसे काम करने और साबित करने लायक बनाता है।

और कम्प्लायंस कोई प्रोडक्ट नहीं है। आप “compliance: on” नहीं खरीद सकते। एन्क्रिप्शन किसी आवश्यकता को सहारा दे सकता है, ऑडिट फ़ीचर सबूत देते हैं, रिटेंशन टूलिंग नीति पर अमल करती है, सहमति का डेटा अनुमति वाले इस्तेमाल को सहारा देता है, लेकिन किसी फ़ीचर का लाइसेंस लेने से आर्किटेक्चर कम्प्लायंट नहीं हो जाता। कम्प्लायंस पूरे डिज़ाइन से आता है: लोग, नीति, प्रक्रिया, डेटा, कंट्रोल और सबूत। Salesforce इसका हिस्सा है, पूरा नहीं। और अगर कोई नीति लागू करने लायक ज़रूरी है, तो पूछें कि क्या वह साबित करने लायक भी ज़रूरी है: 17 मार्च को इस रिकॉर्ड को किसने एक्सेस किया, इस फ़ील्ड को किसने बदला, उस एक्सपोर्ट में क्या था? मॉड्यूल 6 सबूत को कवर करता है।

प्राइवेसी लैंडस्केप को बदलती है

Steve Trucking में, प्राप्तकर्ता का व्यक्तिगत डेटा तीन पार्टनर इंटीग्रेशन से आता है। Salesforce को डिलीवरी चलाने के लिए उसकी ज़रूरत है; क्रू को उसमें से कुछ चाहिए, सिर्फ़ अपने स्टॉप के लिए, सिर्फ़ उसी दिन; Snowflake को डिलीवरी एनालिटिक्स चाहिए; फ़ाइनेंस को बिल बनाने भर का चाहिए, लेकिन वह नहीं जो क्रू देखता है। और एक रिटेल पार्टनर को कभी दूसरे के प्राप्तकर्ता नहीं दिखने चाहिए। प्राइवेसी तीरों को बदलती है: कुछ फ़ील्ड Snowflake नहीं जाते, एनालिटिक्स को कम पहचाने जा सकने वाला संस्करण मिलता है, क्रू सिर्फ़ अपने स्टॉप देखते हैं, आगे के सिस्टमों का रिटेंशन ऑपरेशनल रिटेंशन से अलग होता है। प्राइवेसी की आवश्यकता लैंडस्केप डायग्राम के बगल में नहीं बैठती। वह उसे बदल देती है।

वे सवाल जो नियमों से ज़्यादा टिकते हैं

नियम बदलते हैं, इसलिए किसी भी संवेदनशील या विनियमित डेटा के लिए सवालों का एक टिकाऊ सेट साथ रखें:

• यह क्या है? व्यक्तिगत, संवेदनशील, वित्तीय, स्वास्थ्य, पेमेंट, बच्चों का, या किसी और तरह से विनियमित?
• यह कहाँ रहता है? हर कॉपी: इंटीग्रेशन, हिस्ट्री, एनालिटिक्स, आर्काइव, सैंडबॉक्स, लॉग, AI का इस्तेमाल।
• हम इसे क्यों इस्तेमाल कर सकते हैं? कौन-सा मकसद और कानूनी आधार लागू होता है? क्या सहमति शामिल है?
• इसे कौन इस्तेमाल कर सकता है? लोग, सिस्टम, पार्टनर, इंटीग्रेशन, एजेंट।
• हम इसे कितने समय रखते हैं, और अंत में क्या होता है?
• क्या व्यक्ति इस पर अपने अधिकारों का इस्तेमाल कर सकता है? एक्सेस, सुधार, डिलीशन, पोर्टेबिलिटी, आपत्ति, जैसा कानून देता है।
• क्या हम साबित कर सकते हैं कि क्या हुआ? एक्सेस, बदलाव, एक्सपोर्ट, सहमति, डिलीशन, रिटेंशन।

AI गवर्नेंस कानून बनती जा रही है

AI गवर्न किए गए डेटा का एक और उपभोक्ता जोड़ता है। क्या कोई AI सिस्टम इस डेटा को इस्तेमाल कर सकता है, किस मकसद के लिए, grounding के रूप में, किसके साथ जोड़कर, अपने आउटपुट में दोहराकर, कहाँ लॉग करके, कितने समय के लिए? AI की गवर्नेंस कंपनी की नीति से कानून की ओर बढ़ रही है: यूरोपीय संघ का AI Act (Regulation (EU) 2024/1689 (opens in a new tab)) पहला व्यापक उदाहरण है। वह क्या माँगता है, यह सिस्टम और इस्तेमाल पर निर्भर करता है। आर्किटेक्ट्स के लिए दिशा साफ़ है: AI गवर्नेंस के बाहर नहीं बैठता; वह गवर्न किए गए डेटा का एक और उपभोक्ता है।

आर्किटेक्ट यहाँ क्या तय करता है

• पूरे लैंडस्केप में विनियमित या संवेदनशील डेटा कहाँ आता है, रहता है, चलता है और कॉपी होता है।
• लीगल और कम्प्लायंस की नीति लागू किए जा सकने वाली आवश्यकताएँ कैसे बनती है, बिना आर्किटेक्ट के कानून की व्याख्या किए।
• संवेदनशील डेटा पाने वाले हर सिस्टम को सच में उसकी ज़रूरत है, या कम पहचाने जा सकने वाला संस्करण काफ़ी होगा।
• रिटेंशन, डिलीशन, अनामीकरण, छद्मनामीकरण, सुरक्षा और सबूत डेटा के जीवनचक्र को कैसे आकार देते हैं।
• यह दिखाने के लिए कौन-सा सबूत मौजूद होना चाहिए कि अहम कंट्रोल ने सच में काम किया।

नियम किसी स्लाइड पर उनके नाम लिख देने से आर्किटेक्चर नहीं बनते। वे तब आर्किटेक्चर बनते हैं जब वे यह बदलते हैं कि डेटा कैसे इकट्ठा, वर्गीकृत, स्थानांतरित, सुरक्षित, रिटेन, डिलीट और साबित किया जाता है।

और जानें

• नियमों के आधिकारिक स्रोत ऊपर की टेबल में लिंक किए गए हैं (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): Article 3 (क्षेत्रीय दायरा), Article 4(5) (छद्मनामीकरण), Recital 26 (अनाम जानकारी)।
• Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex (अंग्रेज़ी में)।