शेयर करने से पहले: AI गोपनीयता को सिर्फ़ एक वादे से ज़्यादा चाहिए

परिचय: बातचीत आपकी ज़िंदगी बनती जा रही है

आप एक कठिन जवाब लिखने के लिए AI सहायक खोलते हैं। आप संदेश पेस्ट करते हैं, रिश्ते का संदर्भ समझाते हैं, और कुछ ऐसी बातें जोड़ते हैं जो आपने कहीं और साझा नहीं की हैं। किसी और दिन, आप एक अनुबंध अपलोड करते हैं, किसी अधूरे विचार पर चर्चा करते हैं, या अपना इनबॉक्स कनेक्ट करते हैं ताकि सहायक समझ सके कि किस चीज़ पर आपका ध्यान चाहिए।

इनमें से कोई भी काम ऐसा नहीं लगता जैसे आप कुछ प्रकाशित कर रहे हों। आप मदद माँग रहे हैं।

फिर भी यह जानकारी ऐसे इन्फ्रास्ट्रक्चर, स्टोरेज सिस्टम, समीक्षा प्रक्रियाओं और कानूनी दायित्वों से होकर गुजर सकती है जो बातचीत की विंडो से लगभग अदृश्य रहते हैं। कोई सहायक बहुत पहले व्यक्तिगत महसूस होने लग सकता है, जबकि आपके डेटा के साथ उसका व्यवहार अभी उस अपेक्षा के अनुरूप न हो।

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

मैंने यह लेख Dvina टीम के सहयोग से तैयार किया है। इसमें ChatGPT, Claude, Cursor, Perplexity, Manus, Meta के Muse और Dvina से जुड़ी प्रलेखित घटनाओं और मौजूदा प्रथाओं की जाँच की गई है। इसका उद्देश्य यह समझाना है कि जैसे-जैसे AI हमारी ज़िंदगी में अधिक शामिल होता जा रहा है, गोपनीयता को इंजीनियरिंग की एक केंद्रीय प्राथमिकता क्यों बनना चाहिए—और Dvina इस ज़िम्मेदारी को कैसे देख रहा है।

ये घटनाएँ हमें क्या बताती हैं

यह चिंता काल्पनिक नहीं है। लेकिन अलग-अलग तरह के प्रमाण अलग-अलग समस्याएँ उजागर करते हैं। किसी पुष्ट डेटा-एक्सपोज़र, अधिकृत मानव-समीक्षा, और शोध के दुरुपयोग के आरोप को ऐसे पेश नहीं किया जाना चाहिए मानो वे एक ही घटना हों।

ChatGPT का 2023 एक्सपोज़र: सिस्टम के भीतर की विफलता।

20 मार्च 2023 को, एक सॉफ़्टवेयर बग के कारण कुछ ChatGPT उपयोगकर्ता किसी दूसरे सक्रिय उपयोगकर्ता के बातचीत-इतिहास के शीर्षक देख सके। OpenAI ने कहा कि कुछ परिस्थितियों में नई बनाई गई बातचीत का पहला संदेश भी दिखाई दे सकता था। उसकी जाँच में यह सामने आया कि एक विशेष नौ घंटे की अवधि के दौरान सक्रिय Plus सब्सक्राइबरों में से 1.2% के लिए भुगतान-संबंधी जानकारी के एक्सपोज़र की संभावना थी। पूरे कार्ड नंबर उजागर नहीं हुए थे। OpenAI ने बग को पैच किया और प्रभावित उपयोगकर्ताओं को सूचित किया। 1

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

The New York Times मुकदमा: हटाने की प्रक्रिया एक कानूनी दायित्व से टकराई।

2025 में, OpenAI को अदालत के एक आदेश का सामना करना पड़ा, जिसके तहत उस डेटा को सुरक्षित रखना अनिवार्य था जिसे अन्यथा हटा दिया गया होता। उसके अक्टूबर अपडेट में कहा गया कि नए डेटा को अनिश्चितकाल तक सुरक्षित रखने की व्यापक बाध्यता 26 September 2025 को समाप्त हो गई थी, जबकि सीमित ऐतिहासिक डेटा-समूह अब भी कानूनी रोक के तहत बना रहा। मूल संरक्षण-आवश्यकता में कुछ उत्पादों और zero-data-retention व्यवस्थाओं को बाहर रखा गया था। 2

इसके बाद की एक प्रगति को अलग से पढ़ा जाना चाहिए: December 2025 में, Reuters ने रिपोर्ट किया कि एक न्यायाधीश ने copyright मामले में OpenAI को 20 million anonymized chat logs प्रस्तुत करने का आदेश दिया, उसकी आपत्तियों को खारिज करते हुए de-identification और protective safeguards पर भरोसा किया। यह discovery order था, न कि इंटरनेट पर सबकी निजी chats का प्रकाशन। 3

इन घटनाओं को साथ रखकर देखने पर स्पष्ट होता है कि deletion setting हर उस प्रश्न का समाधान नहीं करती जो सुरक्षित रखी गई जानकारी से जुड़ा है। एक बार किसी जानकारी की प्रति मौजूद हो जाए, तो उपयोगकर्ता के नियंत्रण से बाहर की बाध्यताएँ यह प्रभावित कर सकती हैं कि उसके साथ आगे क्या होगा। अनावश्यक retention को कम करना, विवाद शुरू होने से पहले ही उस exposure को बदल देता है।

मानवीय समीक्षा: breach के बिना भी access की अनुमति दी जा सकती है।

OpenAI के consumer documentation में स्पष्ट रूप से यह अनुमति दी गई है कि अधिकृत कर्मी और service providers सीमित access प्राप्त कर सकते हैं, और वह भी निर्दिष्ट उद्देश्यों के लिए, जिनमें security investigations, support, legal matters, और eligible model improvement शामिल हैं। Anthropic की consumer guidance यह अनुमति देती है कि नामित staff usage-policy enforcement के लिए conversations की समीक्षा कर सके, और consented feedback से जुड़ा access अलग से हो। 4, 8

ये documented access paths हैं, अफवाहें नहीं। ये यह स्थापित नहीं करते कि कर्मचारी हर conversation पढ़ते हैं। लेकिन ये यह अवश्य स्थापित करते हैं कि निजी दिखने वाला chat interface, provider access के विरुद्ध आवश्यक रूप से कोई तकनीकी बाधा नहीं है।

Anthropic का वर्तमान documentation business पक्ष का एक महत्वपूर्ण उदाहरण जोड़ता है। उसके नामित Covered Models के लिए कुछ deployments में 30-day retention आवश्यक है, जहाँ पहले zero data retention लागू था, साथ में नियंत्रित human review और exceptions भी हैं। इस नियम की model, platform, और eligibility सीमाएँ हैं; यह हर Claude product पर लागू होने वाला blanket change नहीं है। Consumer plans को अप्रभावित बताया गया है क्योंकि उन surfaces पर inputs और outputs पहले से ही retain किए जाते हैं। 9

Safety monitoring का एक वैध उद्देश्य है। इंजीनियरिंग की चुनौती यह है कि उस उद्देश्य को पूरा करते हुए monitoring systems और reviewers के लिए उपलब्ध संवेदनशील जानकारी को न्यूनतम रखा जाए। Safety का औचित्य privacy के प्रश्न को गायब नहीं कर देता।

गणितीय विवाद: एक अनसुलझा आरोप, भरोसे की एक वास्तविक समस्या

September 2026 में OpenAI की Navier–Stokes घोषणा को लेकर उठा विवाद एक अलग चिंता सामने लाया: जब निजी शोध में मदद करने वाला assistant ऐसी कंपनी का हो जो स्वयं भी शोध कर रही हो, तब क्या होता है?

यह विवाद अप्रकाशित गणितीय कार्य और श्रेय से संबंधित था। रिपोर्टिंग में बताया गया कि गणितज्ञ Tristan Buckmaster और Levent Alpöge अपने काम में AI tools का उपयोग कर रहे थे, और Buckmaster ने यह सवाल उठाया कि क्या उनकी निजी सामग्री ने OpenAI के परिणाम में योगदान दिया था। 10

OpenAI इस विवरण से असहमत है। उसके प्रकाशित उत्तर में कहा गया है कि publication से पहले न तो उसके researchers और न ही उसके agents ने उस जोड़ी का काम देखा। 10 September दिनांकित एक अपडेट में उसने आगे कहा कि एक जांच ने पिछले दो महीनों के दौरान Buckmaster के Codex prompts से किसी भी प्रभाव को बाहर कर दिया है, जिसमें training के माध्यम से प्रभाव भी शामिल है। समय-सीमा से बंधा यह कथन कुछ रिपोर्टिंग में दिए गए पहले के विवरण की तुलना में अधिक विशिष्ट है। 11

सार्वजनिक विवरण अब भी विवादित हैं। यहाँ समीक्षा किए गए स्रोत स्वतंत्र रूप से यह स्थापित नहीं करते कि OpenAI ने अपने परिणाम तक पहुँचने के लिए उन निजी conversations का उपयोग किया।

फिर भी, यह विवाद एक ऐसे प्रश्न को उजागर करता है जिसका स्पष्ट उत्तर होना चाहिए: जब लोग अधूरा काम AI के पास लाते हैं, तो उस काम के सूचनात्मक मूल्य की रक्षा क्या करती है? किसी proof से लेखक का नाम हटा देने से proof नहीं हटता। किसी commercial strategy की पहचान-हटाने की प्रक्रिया उसे सार्वजनिक संपत्ति नहीं बना देती।

इसीलिए मजबूत privacy के लिए identity और content, दोनों की सुरक्षा आवश्यक है। उपयोगकर्ताओं को यह समझने में सक्षम होना चाहिए कि क्या उनकी सामग्री training, research, evaluation, या review workflows में जा सकती है—और कौन-से technical controls उन सीमाओं को लागू करते हैं।

चार प्रश्न जिन्हें कभी एक में समेटना नहीं चाहिए

काफी भ्रम इसलिए पैदा होता है क्योंकि “private” को एक ही गुण मान लिया जाता है। व्यवहार में, चार अलग-अलग प्रश्न तय करते हैं कि किसी conversation के साथ क्या होता है।

Training: क्या यह content किसी model के विकास या सुधार में मदद कर सकता है? opt-out जानकारी के एक अनुमत उपयोग को बदलता है। यह आवश्यक रूप से यह नहीं बदलता कि जानकारी transmit या store की गई थी या नहीं।

Access: कौन-से systems और लोग इसका निरीक्षण कर सकते हैं? transmission और storage के दौरान encryption महत्वपूर्ण है, लेकिन यह अपने-आप यह नहीं रोकता कि कोई अधिकृत service processing या review के लिए content को decrypt न कर सके।

Retention: क्या बचा रहता है, कहाँ, और कितने समय तक? interface से किसी chat को हटाना, production records को delete करना, backups का expire होना, और भविष्य की training से data को बाहर रखना—ये अलग-अलग operations हैं।

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

एक उपयोगी गोपनीयता तुलना इन सवालों को अलग-अलग रखती है। कोई सशुल्क सदस्यता, प्रशिक्षण स्विच, या private-task लेबल इन चारों का जवाब नहीं दे सकता।

सेवाओं की तुलना कैसे करें

नीचे दी गई तालिका, जब तक अलग दायरा न बताया गया हो, व्यक्तिगत उपयोग पर केंद्रित है। यह स्वतंत्र सुरक्षा ऑडिट के नतीजों के बजाय समीक्षा किए गए दस्तावेज़ों का सार प्रस्तुत करती है।

Service	Training position	समझने के लिए अलग सीमा
ChatGPT	व्यक्तिगत सामग्री का उपयोग सुधार के लिए किया जा सकता है; नियंत्रण नई बातचीतों और Codex tasks को बाहर रखते हैं। Temporary Chat बाहर रखा जाता है। 4, 5	अधिकृत पहुँच और retention अलग मुद्दे बने रहते हैं। Codex में full-environment training के लिए भी एक अलग सेटिंग है।
Claude	उपभोक्ता मॉडल सुधार उपयोगकर्ता की पसंद पर निर्भर करता है; feedback और safety-related उपयोगों के लिए अलग नियम हैं। Incognito को सामान्य सुधार से बाहर रखा जाता है। 6	review और retention के अपवाद फिर भी लागू होते हैं। कुछ commercial Covered Models के लिए अतिरिक्त retention आवश्यकताएँ हैं। 7–9
Cursor	Privacy Mode, बताए गए अपवादों के अधीन, ग्राहक डेटा को Cursor training से बाहर रखता है और provider no-retention व्यवस्थाओं का वर्णन करता है। 12	अनुरोध फिर भी Cursor के backend से होकर गुजरते हैं। abuse investigations, caching, और model-specific notices महत्वपूर्ण हैं।
Perplexity	consumer AI training collection डिफ़ॉल्ट रूप से सक्षम है, Pro और Max पर भी; उपयोगकर्ता भविष्य के लिए opt out कर सकते हैं। 13	opt out करने से service operations या legal compliance के लिए processing नहीं रुकती। Enterprise terms अलग हैं।
Manus	Team documentation में training opt-out सूचीबद्ध है; यह समीक्षा definitive individual-plan training rule की पुष्टि नहीं कर सकी। 15	individual tasks का डिफ़ॉल्ट रूप से private होना sharing visibility का वर्णन करता है, provider use पर पूर्ण प्रतिबंध का नहीं। 14
Meta’s Muse	launch documentation डिफ़ॉल्ट रूप से sanitized interaction data पर training का वर्णन करती है, साथ में opt-out भी है। 16	training से पहले sanitizing, inference से पहले masking के समान नहीं है। launch-time operator restrictions, planned Confidential VM से अलग हैं।
Dvina	conversations, files, prompts, और workspace data का उपयोग AI models को train करने के लिए नहीं किया जाता। 17, 18	automatic masking एक पहले की सीमा को संबोधित करता है: पहचाने गए personal identifiers को model processing से पहले बदल दिया जाता है।

नीचे दिए गए विवरण बताते हैं कि रोज़मर्रा के उपयोग में ये भेद कहाँ महत्वपूर्ण हो जाते हैं।

ChatGPT और Claude: आप जो कार्रवाई करते हैं, वही नियम बदल देती है।

OpenAI उपयोगकर्ताओं को सामान्य chat history हटाए बिना training बंद करने देता है। Temporary Chat किसी बातचीत के प्रबंधन को और बदल देता है, लेकिन उसके दस्तावेज़ फिर भी abuse review की अनुमति देते हैं और 30-दिन की deletion period का वर्णन करते हैं। Codex उपयोगकर्ताओं को भी account-wide content setting और उसकी अलग full-environment setting के बीच अंतर समझना चाहिए। 4, 5

Claude के साथ, feedback पर विशेष ध्यान देना चाहिए। Anthropic कहता है कि thumbs-up, thumbs-down, या bug report में संबंधित बातचीत को पाँच साल तक संग्रहीत करना शामिल हो सकता है, और उसका उपयोग model training सहित कई उद्देश्यों के लिए किया जा सकता है। सामान्य model improvement सक्षम करने से योग्य de-identified सामग्री को training pipelines में पाँच साल तक बने रहने की अनुमति भी मिलती है। ये नियम सामान्य chat deletion जैसे नहीं हैं। 6, 7

इसलिए कोई व्यक्ति एक ही product के भीतर गोपनीयता से जुड़े कई निर्णय ले सकता है, बिना यह समझे कि वे अलग-अलग निर्णय हैं। product design को उपयोग के उसी क्षण इन अंतरों को स्पष्ट करना चाहिए।

Cursor और Perplexity: product label, processing boundary नहीं होता।

Cursor का Privacy Mode training और provider retention पर सार्थक प्रतिबंध देता है। यह editor को local-only नहीं बनाता: Cursor कहता है कि requests फिर भी उसके backend से होकर जाती हैं, भले ही उपयोगकर्ता अपनी API key दे। उसके दस्तावेज़ temporary encrypted file caching और abuse investigations या designated models से जुड़े अपवादों का भी वर्णन करते हैं। 12

Perplexity एक अलग तरह का भेद दिखाता है। उसके Free, Pro, और Max accounts consumer training controls के अंतर्गत आते हैं, जहाँ collection डिफ़ॉल्ट रूप से सक्षम है। प्रकाशित opt-out बाद में एकत्र किए गए डेटा पर लागू होता है, पहले के training data को पीछे से हटाने पर नहीं। व्यक्तिगत subscription खरीद लेने से वह Enterprise account नहीं बन जाता। 13

दोनों ही मामलों में, असली सवाल यह है कि चुना गया mode और account क्या बदलते हैं—न कि product name से क्या संकेत मिलता है।

Manus और Muse: private workspaces को भी स्पष्ट सीमाएँ चाहिए।

Manus कहता है कि individual tasks, साझा किए जाने तक private रहते हैं। उसकी Team documentation यह भी समझाती है कि owners team session content तक पहुँच सकते हैं। ये उपयोगी visibility rules हैं, लेकिन ये individual training policy स्थापित नहीं करते। इस समीक्षा के लिए Manus का पूरा privacy page प्राप्त नहीं किया जा सका, इसलिए इस प्रश्न की पुष्टि नहीं हो सकी; इसे किसी दूसरे plan से भरकर नहीं माना गया। 14, 15

Muse की launch documentation operational restrictions और technical prevention के बीच अंतर को असामान्य रूप से स्पष्ट करती है। Meta कहता है कि launch-time Secure VM नीतियों के माध्यम से staff access को सीमित करता है, लेकिन सेवा को चलाने, support देने, या सुरक्षित रखने के लिए ज़रूरत पड़ने पर access को रोकता नहीं है। operator access को cryptographically रोकने के लिए intended एक Confidential VM को आने वाला बताया गया था और वह limited testing में था। किसी planned protection को ऐसा नहीं गिना जाना चाहिए मानो वह पहले से सभी के लिए उपलब्ध हो। 16

Muse वास्तविक connector credentials को अपने main agent से दूर भी रखता है और action approvals को एक अलग permission authority के अधीन रखता है। यह एक मूल्यवान सिद्धांत दिखाता है: किसी agent को कोई secret या permission सिर्फ इसलिए नहीं मिलनी चाहिए कि ऐसा करना सुविधाजनक हो सकता है। 16

सुरक्षा को exposure से पहले वाले बिंदु तक ले जाएँ

training exclusion डेटा के एक उपयोग को नियंत्रित करता है। masking processing के लिए उपलब्ध डेटा को बदल देती है। restricted retention बची रहने वाली प्रतियों को कम करती है। permission controls यह सीमित करते हैं कि कोई agent क्या कर सकता है। ये सुरक्षा उपाय एक-दूसरे के पूरक हैं, और इनमें से हर एक किस चरण पर काम करता है, यह महत्वपूर्ण है।

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

यह मूल पाठ भेजने और यह वादा करने से अलग है कि किसी बाद के उपयोग से पहले पहचानकर्ताओं को हटा दिया जाएगा।

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

उद्योग भर में इस विषय पर प्रासंगिक काम हो रहा है। OpenAI ने April 2026 में स्थानीय रूप से चलाया जा सकने वाला Privacy Filter जारी किया, और Meta के Muse दस्तावेज़ तकनीकी isolation तथा विकासाधीन एक अधिक मज़बूत confidential-computing डिज़ाइन का वर्णन करते हैं। ये प्रयास इस बात को मज़बूत करते हैं कि privacy को सिस्टम में इंजीनियरिंग के स्तर पर शामिल किया जाना चाहिए। लेकिन केवल किसी tool release या roadmap का होना अपने-आप में इस बात का प्रमाण नहीं है कि हर consumer conversation को पहले से वही सुरक्षा मिल रही है। 16, 19

मानक वही सुरक्षा होनी चाहिए जो किसी व्यक्ति को आज उस उत्पाद में मिलती है जिसका वह उपयोग कर रहा है।

Dvina: privacy को सामान्य interaction का हिस्सा बनाना

Dvina का दृष्टिकोण इस शुरुआती सुरक्षा को assistant अनुभव में लाता है। इसके प्रलेखित डिज़ाइन के अनुसार, लोग टाइप करते समय या सामग्री अपलोड करते समय संवेदनशील व्यक्तिगत जानकारी का स्थानीय स्तर पर पता लगाया जाता है, पहचाने गए व्यक्तिगत डेटा को encrypt किया जाता है, और मॉडल प्रोसेसिंग से पहले placeholders रख दिए जाते हैं। मॉडल मूल पहचाने गए पहचानकर्ताओं के बजाय उन्हीं placeholders के साथ काम करता है। 17, 18

अंतर व्यावहारिक है। उपयोगकर्ता को हर कार्य के बीच रुककर नाम और संपर्क विवरण हाथ से हटाने की ज़रूरत नहीं होनी चाहिए, और न ही केवल इस वादे पर निर्भर रहना चाहिए कि मॉडल के उन्हें प्राप्त करने के बाद क्या होगा। सुरक्षा interaction के साथ-साथ चलनी चाहिए।

Dvina उपयोगकर्ता की conversations, files, prompts, और workspace data को model training से भी बाहर रखता है। यह संयोजन महत्वपूर्ण है: no-training प्रतिबद्धता पुन: उपयोग को सीमित करती है, जबकि pre-processing सुरक्षा सबसे पहले मॉडल के सामने आने वाली व्यक्तिगत जानकारी को ही सीमित कर देती है। 17, 18

अन्य परतें भी इस दृष्टिकोण का समर्थन करती हैं। Dvina encrypted conversation storage, संग्रहीत संदेशों और उपयोगकर्ता की पहचान के बीच separation, तथा GDPR-स्तर की सुरक्षा के साथ EU-hosted data का वर्णन करता है। इनमें से हर एक handling process के अलग हिस्से को संबोधित करता है, बजाय इसके कि पूरा बोझ किसी एक training preference पर डाल दिया जाए। 17, 18

तकनीकी अंतर स्पष्ट है: पहचाने गए व्यक्तिगत पहचानकर्ताओं को मॉडल input में बदल दिया जाता है, जबकि आसपास का कार्य प्रोसेसिंग के लिए उपलब्ध रहता है। privacy डेटा प्रवाह का हिस्सा बन जाती है, केवल ऐसी preference नहीं रहती जिसे उपयोगकर्ताओं को याद रखकर स्वयं प्रबंधित करना पड़े।

मेरे लिए, AI की यही अधिक उपयोगी दिशा है: लोगों को अपने काम में सार्थक संदर्भ लाने दें, लेकिन सिस्टम को इस तरह डिज़ाइन करें कि वह कार्य की आवश्यकता से कम उनकी पहचान उजागर करे।

निष्कर्ष: privacy तय करेगी कि लोग AI को अपनी ज़िंदगी में कितनी दूर तक आने देते हैं

AI assistants तब अधिक उपयोगी होते जाते हैं जब वे हमारी परिस्थितियों को अधिक समझते हैं। इससे उस समझ के पीछे की जानकारी की रक्षा करने की ज़िम्मेदारी पैदा होती है। लोगों से अधिक पहुँच माँगना, लेकिन बदले में केवल एक और settings page देना, पर्याप्त उत्तर नहीं है।

साक्ष्य कई अलग-अलग जोखिमों की ओर संकेत करते हैं। सॉफ़्टवेयर खातों के बीच डेटा उजागर कर सकता है। संग्रहीत conversations कानूनी माँगों के दायरे में आ सकती हैं। बिना किसी security breach के भी अधिकृत समीक्षा मौजूद हो सकती है। निजी शोध को लेकर विवाद भरोसे को कमज़ोर कर सकते हैं, भले ही आरोप स्वतंत्र रूप से स्थापित न हुआ हो।

इन जोखिमों के लिए इंजीनियरिंग कार्य चाहिए, केवल बेहतर शब्दों की नहीं। संवेदनशील डेटा की पहचान, pre-processing सुरक्षा, पहचान का separation, सीमित retention, और लागू की जा सकने वाली permissions को AI safety की बुनियादी क्षमताओं के रूप में निरंतर ध्यान मिलना चाहिए। assistant की उपयोगिता और उसके उपयोगकर्ता की सुरक्षा को साथ-साथ आगे बढ़ना होगा।

Dvina के साथ, हम model processing से पहले सुरक्षा को उत्पाद की बुनियाद का हिस्सा बनाकर इस बदलाव का नेतृत्व करने में मदद कर रहे हैं। लक्ष्य अधिक मज़बूत दावों के ज़रिए अधिक भरोसा माँगना नहीं है। लक्ष्य यह है कि केवल एक वादे पर टिके रहने वाले भरोसे की मात्रा कम की जाए।

लोगों को मदद ले पाने, किसी विचार को विकसित करने, और आगे बढ़ने के लिए आवश्यक संदर्भ साझा करने में सक्षम होना चाहिए—बिना हर बातचीत को अपनी privacy के संभावित समर्पण की तरह मानने के। यही भरोसा बनाना AI के सामने आने वाले सबसे महत्वपूर्ण कार्यों में से एक है।

स्रोत और दायरा

22 September 2026 को स्रोतों की समीक्षा की गई। यह लेख provider documentation और attributed reporting पर आधारित है; यह कोई स्वतंत्र security audit नहीं है। तुलना का मुख्य दायरा individual plans है। Commercial, API, और model-specific exceptions को अलग से चिह्नित किया गया है। mathematics section में reported concerns और OpenAI के updated response के बीच अंतर किया गया है; इनमें से किसी को भी स्वतंत्र निष्कर्ष के रूप में प्रस्तुत नहीं किया गया है। Manus की individual-plan training rule अप्रमाणित बनी हुई है क्योंकि उसकी पूरी privacy policy प्राप्त नहीं की जा सकी।