सहमति और भुला दिए जाने का अधिकार

🌐 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

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

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

Steve Trucking के पास एक प्राप्तकर्ता का फ़ोन नंबर है। सीधा सवाल: क्या हम उन्हें मैसेज भेज सकते हैं? शायद। आज की डिलीवरी के बारे में? कल की? क्या हम नंबर को किसी प्रमोशन के लिए इस्तेमाल कर सकते हैं? अगर उन्होंने कहा हो कि कोई मैसेज नहीं, या डिलीवरी अपडेट के लिए हाँ पर मार्केटिंग के लिए नहीं, और फिर अपना मन बदल लिया हो, तो?

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

सहमति डेटा है

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

वह मॉडल इस्तेमाल करें जो Salesforce पहले से बना चुका है

मेरा पक्ष: जहाँ भी हो सके, out-of-the-box सहमति मॉडल इस्तेमाल करें, बजाय इसके कि वही चीज़ कस्टम फ़ील्ड में दोबारा बनाएँ। Salesforce का सहमति डेटा मॉडल चार स्तरों पर सहमति संभालता है, हर स्तर एक ज़्यादा खास सवाल है (Understand the Salesforce Consent Data Model (opens in a new tab)):

• ग्लोबल सहमति, Individual पर: यह व्यक्ति कौन है, और क्या उसने हर चीज़ के लिए मना कर दिया है?
• एंगेजमेंट चैनल की सहमति (Contact Point Type Consent): क्या हम इस तरह का चैनल, जैसे SMS या ईमेल, इस्तेमाल कर सकते हैं?
• कॉन्टैक्ट पॉइंट की सहमति: इस खास फ़ोन नंबर या ईमेल पते का क्या?
• डेटा इस्तेमाल का मकसद (Data Use Purpose): किस वजह से: डिलीवरी की सूचनाएँ, सर्विस, मार्केटिंग?

इन्हें साथ रखें, तो आर्किटेक्चर इसका जवाब दे सकता है: “क्या हम इस व्यक्ति की जानकारी, इस कॉन्टैक्ट पॉइंट से, इस मकसद के लिए इस्तेमाल कर सकते हैं?” यह “सहमति = हाँ” से कहीं ज़्यादा काम का है। कोई भी रिकॉर्ड जो किसी व्यक्ति से जुड़ा हो, इसमें हिस्सा ले सकता है: lead, contact, person account, user।

Click to enlarge

चार सवाल, हर एक पिछले से ज़्यादा संकरा। एक अकेला opt-in फ़्लैग इनमें से किसी का भी अच्छा जवाब नहीं देता।

मकसद मायने रखता है

एक रिटेल पार्टनर Steve Trucking को प्राप्तकर्ता का नंबर भेजता है ताकि क्रू डिलीवरी का तालमेल कर सके। इससे प्राप्तकर्ता मार्केटिंग lead नहीं बन जाता। एक ही डेटा के अलग-अलग अनुमति वाले इस्तेमाल हो सकते हैं: डिलीवरी का तालमेल, सर्विस फ़ॉलो-अप, मार्केटिंग, AI से पर्सनलाइज़ेशन। अगर नीति या कानून उन्हें अलग-अलग देखते हैं, तो मॉडल को उनमें फ़र्क करना होगा। सवाल यह नहीं है कि क्या हमारे पास फ़ोन नंबर है? सवाल यह है कि हमें इसके साथ क्या करने की अनुमति है?

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

सहमति का एक जीवनचक्र और एक अधिकार होता है

लोग सहमति देते हैं, वापस लेते हैं, अपनी पसंद बदलते हैं, नंबर बदलते हैं। बिज़नेस नए मकसद जोड़ता है; कानून बदलते हैं। इसलिए जीवनचक्र डिज़ाइन करें: क्या चुना गया, कब, कैसे, किस मकसद के लिए, और सहमति वापस लेने पर क्या होता है। और यहीं बात दिलचस्प हो जाती है: जब कोई प्राप्तकर्ता सहमति वापस लेता है, तो Salesforce को पता होता है। क्या मैसेजिंग प्लेटफ़ॉर्म को पता है? एनालिटिक्स को? एजेंट को? जो सहमति एक सिस्टम में रहती है, जबकि बाकी सिस्टम पुरानी अनुमति पर काम करते रहते हैं, वह कोई खास कंट्रोल नहीं है।

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

अब व्यक्ति कहता है: मुझे भूल जाओ

पहला मन यह होता है कि contact डिलीट करें और मान लें कि काम हो गया। लेकिन व्यक्ति का डेटा किसी contact, डिलीवरी, डिलीवरी नोट, केस, फ़ोटो पर, फ़ील्ड हिस्ट्री में, Snowflake में, किसी आर्काइव, इंटीग्रेशन लॉग, सर्च इंडेक्स या किसी एजेंट की बातचीत के इतिहास में हो सकता है। इसीलिए डेटा मिटाने (erasure) पर मेरा पक्ष पहले से शुरू होता है: व्यवहार में डिलीशन दुर्लभ और मुश्किल है, इसलिए पहले यह नियंत्रित करें कि व्यक्तिगत डेटा कहाँ जाता है। ऐसा डिज़ाइन करें कि वह कम से कम जगहों पर पहुँचे। फिर, जब अनुरोध आए, तो जहाँ इससे नीति पूरी होती हो, वहाँ उसे छिपाएँ (obfuscate) या उसका जुड़ाव तोड़ें (de-link), और हर कॉपी ढूँढ निकालें: फ़ील्ड हिस्ट्री, आर्काइव, Data 360, और अब सर्च इंडेक्स और एजेंट की बातचीत भी।

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

Click to enlarge

“मुझे भूल जाओ” अनुरोध हर कॉपी के लिए एक फ़ैसला है।

घड़ी चल रही है

इन अनुरोधों के साथ समय-सीमा आती है। GDPR के तहत, संगठन को किसी व्यक्ति के अनुरोध पर बिना अनुचित देरी के और उसे पाने के एक महीने के भीतर कार्रवाई करनी होती है; जटिल या बहुत सारे अनुरोधों के लिए इसे दो और महीने बढ़ाया जा सकता है, लेकिन व्यक्ति को पहले महीने के भीतर कारणों के साथ बताना होता है (Article 12(3), Regulation (EU) 2016/679 (opens in a new tab))। दूसरे कानून अपनी समय-सीमाएँ तय करते हैं; कौन-सी लागू होती हैं, यह लीगल बताएगा। जो भी हो, लैंडस्केप खोजने के लिए एक महीना काफ़ी नहीं है। कॉपियों के नक्शे को इसी समय-सीमा से आगे रहना है।

डिलीट करें, डी-आइडेंटिफ़ाई करें या रखें?

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

मॉड्यूल 4 का फ़र्क याद रखें। जुड़ाव तोड़ना (de-linking) भूलना तभी माना जाता है जब व्यक्ति को वाजिब तौर पर दोबारा पहचाना न जा सके। छद्मनामीकृत डेटा अब भी व्यक्तिगत डेटा है। डेटा छिपाने (obfuscation) को किसी कानूनी आवश्यकता से बचने का शॉर्टकट न बनाएँ।

जो आप ढूँढ नहीं सकते, उसे डिलीट नहीं कर सकते

किसी का डेटा मिटाने से पहले, आपको उसे ढूँढना होगा। अनुरोध एक ईमेल पते से आता है। एक रिटेल पार्टनर ने “Jane Smith” भेजा, दूसरे ने “J. Smith,” और फ़ोन नंबर बदल गया। प्राप्तकर्ता कोई contact है ही नहीं; उसका विवरण हर डिलीवरी पर रखा है। एक ही व्यक्ति को दो अलग पार्टनर्स की डिलीवरी मिलीं। एक सिस्टम उसे ईमेल से जानता है, दूसरा एक external ID से। डेटा मिटाना पहचान पर निर्भर है, और आप नहीं चाहेंगे कि आपकी मैचिंग ज़रूरत से ज़्यादा आक्रामक होने के कारण किसी और का डेटा डिलीट हो जाए। आइडेंटिटी आर्किटेक्चर, प्राइवेसी आर्किटेक्चर का हिस्सा है।

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

फ़ोटो और फ़्री टेक्स्ट भी डेटा हैं

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

और फ़्री टेक्स्ट खतरनाक है। आप नाम, फ़ोन और पता हटाते हैं, फिर यह डिलीवरी नोट मिलता है: “Jane को 602-555-0198 पर कॉल करें। गेट कोड 4821। आँगन में कुत्ता है।” लो, वहीं है। डिलीवरी नोट्स को संवेदनशील के रूप में वर्गीकृत करने से पता चलता है कि समस्या हो सकती है; इससे टेक्स्ट के अंदर का व्यक्तिगत डेटा ढूँढकर हटाया नहीं जाता। कभी-कभी सबसे अच्छा जवाब है गैर-ज़रूरी व्यक्तिगत विवरणों को वहाँ पहुँचने से ही रोकना। पहले यह नियंत्रित करें कि व्यक्तिगत डेटा कहाँ जाता है।

Privacy Center एक टूल है, पूरा आर्किटेक्चर नहीं

Salesforce Privacy Center इन प्रक्रियाओं को चलाने में मदद करता है। इसकी right-to-be-forgotten नीतियाँ हर ऑब्जेक्ट के लिए बनाई जाती हैं, ताकि वह सब पकड़ा जा सके जिसे आप हटाना चाहते हैं, और वे किसी खास ग्राहक रिकॉर्ड पर चलाई जाती हैं (Delete Data with Right to Be Forgotten Policies (opens in a new tab))। यह काम का है। लेकिन “हमने Privacy Center खरीद लिया, तो काम हो गया” कोई आर्किटेक्चर नहीं है। व्यक्ति का डेटा किसी भी एक टूल की पहुँच से बाहर रह सकता है: Data 360, वेयरहाउस, पार्टनर सिस्टम, आर्काइव, लॉग, सर्च, फ़ाइलें, एजेंट की बातचीत। एंटरप्राइज़ को अब भी एंटरप्राइज़ स्तर का जवाब चाहिए, और किसी टूल पर भरोसा करने से पहले आपको जाँचना होगा कि वह असल में क्या-क्या कवर करता है।

पोर्टेबिलिटी और सबूत

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

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

परीक्षा से आगे: AI क्या बदलता है। AI नए मकसद और नई कॉपियाँ पैदा करता है। कोई सेवा देने के लिए डेटा इस्तेमाल करने की अनुमति अपने आप किसी एजेंट की grounding, पर्सनलाइज़ेशन या ट्रेनिंग को कवर नहीं करती; Data Use Purpose इनमें फ़र्क करने की स्वाभाविक जगह है। और व्यक्तिगत डेटा प्रॉम्प्ट, grounding के संदर्भ, बातचीत, सारांश, सर्च और वेक्टर इंडेक्स, और लॉग में बचा रह सकता है। “हमने सोर्स रिकॉर्ड डिलीट कर दिया” पूरा जवाब नहीं है, अगर AI परत को अब भी याद है।

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

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

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

और जानें

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), Article 12(3), किसी अनुरोध पर कार्रवाई की समय-सीमा (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।