Chrome, Gemini Nano और निजता: 4 GB से बड़ा सवाल नियंत्रण का है

Chrome और Gemini Nano पर चल रही बहस में सबसे ज्यादा ध्यान 4 GB के कथित AI डाउनलोड पर गया है। लेकिन निजता के लिहाज से असली सवाल फ़ाइल के आकार से बड़ा है: क्या ब्राउज़र में जोड़ी जा रही नई AI परत को साफ-साफ बताया गया है, उसका उद्देश्य सीमित है, उसका दस्तावेज़ीकरण पर्याप्त है और उसे सचमुच बंद या हटाया जा सकता है?

पहले तथ्य अलग कर लें: क्या पक्का है, क्या दावा है

आधिकारिक रूप से दर्ज बात: Google Chrome को Built-in AI के प्लेटफॉर्म के रूप में पेश करता है, जहाँ वेबसाइटें और वेब ऐप ब्राउज़र द्वारा प्रबंधित मॉडल और API के जरिए AI कार्य चला सकते हैं; Chrome की डेवलपर डॉक्युमेंटेशन इस संदर्भ में Gemini Nano का स्पष्ट उल्लेख करती है . Built-in AI दस्तावेज़ यह भी कहते हैं कि ऐप्स को तेज़ शुरू करने के लिए मॉडल को डिवाइस पर कैश किया जा सकता है . Google के एक डेवलपर ब्लॉग में Chrome को उन उत्पादों में गिना गया है जिनमें LiteRT-LM, On-device Gemini Nano को संभव बनाता है .

रिपोर्टों में दावा, पर आधिकारिक रूप से स्पष्ट पुष्टि नहीं: कई प्रकाशनों ने दावा किया है कि Chrome ने OptGuideOnDeviceModel नाम के प्रोफाइल फ़ोल्डर में लगभग 4 GB की weights.bin मॉडल फ़ाइल रखी, वह भी स्पष्ट सूचना के बिना, और मैनुअल रूप से हटाने के बाद उसे फिर डाउनलोड कर लिया गया . हालांकि Chrome की आधिकारिक डेवलपर साइटें Built-in AI और on-device caching को दर्ज करती हैं, वे इन दस्तावेज़ों में इस खास फ़ाइल साइज, फ़ाइल नाम या हटाने के बाद फिर से बहाल होने के दावे की पुष्टि नहीं करतीं .

इसलिए इसे न तो तुरंत साबित निजता-घोटाला मान लेना ठीक है, न ही सिर्फ एक सामान्य अपडेट कहकर टाल देना। असली कसौटी यह है कि यूज़र और सिस्टम एडमिन स्थानीय AI पर कितनी स्पष्ट और प्रभावी पकड़ रखते हैं।

4 GB नहीं, पारदर्शिता ज्यादा अहम है

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

Chrome Built-in AI सिर्फ अंदरूनी तकनीकी सुधार नहीं है। Google उन API का वर्णन करता है जिनसे वेब ऐप ब्राउज़र-प्रबंधित मॉडल के जरिए AI कार्य कर सकते हैं . Google I/O से जुड़ी सामग्री में अनुवाद, सारांश, लिखने और टेक्स्ट को दोबारा लिखने जैसे उपयोग बताए गए हैं . जब ऐसी क्षमताएँ ब्राउज़र में आ जाती हैं, तो केवल स्टोरेज की सूचना काफी नहीं रहती; यूज़र को समझने योग्य विकल्प चाहिए।

उद्देश्य की सीमा: Chrome में Gemini Nano किस काम के लिए है?

डेटा सुरक्षा में उद्देश्य बहुत मायने रखता है। वही स्थानीय मॉडल कभी लिखने की मदद, कभी अनुवाद, कभी सारांश और कभी सुरक्षा फीचर के लिए इस्तेमाल हो सकता है। Google की डॉक्युमेंटेशन और Google I/O सामग्री Built-in AI के कार्यों में अनुवाद, सारांश, लेखन और री-राइटिंग का उल्लेख करती हैं . इसके अलावा Infosecurity Magazine ने रिपोर्ट किया कि Google Chrome 137 में Safe Browsing के Enhanced Protection मोड के तहत स्पैम, स्कैम और फिशिंग के खिलाफ अतिरिक्त सुरक्षा परत के रूप में Gemini Nano के प्रयोग पर काम कर रहा है .

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

On-device का मतलब अपने-आप जोखिम-मुक्त नहीं

Google अपने On-device दस्तावेज़ों में Gemini Nano को ऐसा मॉडल बताता है जो नेटवर्क कनेक्शन या क्लाउड में डेटा भेजे बिना जनरेटिव AI अनुभव दे सकता है . स्थानीय AI का सबसे मजबूत निजता लाभ यही है: यदि सामग्री सचमुच डिवाइस पर रहती है, तो क्लाउड तक जाने वाले डेटा प्रवाह कम हो सकते हैं।

लेकिन स्थानीय होना और पारदर्शी होना दो अलग बातें हैं। अब भी ये प्रश्न महत्वपूर्ण रहते हैं:

• कौन-सी सामग्री स्थानीय मॉडल को भेजी जाती है?
• Chrome की कौन-सी सुविधाएँ या कौन-से वेब ऐप इस मॉडल को कॉल कर सकते हैं?
• क्या prompts, आउटपुट, त्रुटि संदेश, उपयोग मेट्रिक्स या टेलीमेट्री कहीं सेव या भेजी जाती है?
• मॉडल अपडेट कैसे वितरित होते हैं?
• यदि मॉडल हटाया या निष्क्रिय किया गया, तो क्या वह स्थायी रूप से हटता है?

Chrome दस्तावेज़ यह दर्ज करते हैं कि वेब ऐप Built-in AI API के जरिए ब्राउज़र-प्रबंधित मॉडल के साथ काम कर सकते हैं . इसलिए सवाल केवल मॉडल फ़ाइल का नहीं, बल्कि उसके चारों ओर बनी अनुमति और एक्सेस व्यवस्था का भी है।

संवेदनशील सामग्री के लिए स्पष्ट सीमाएँ जरूरी हैं

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

अच्छी व्यवस्था में यह साफ संकेत होना चाहिए कि Chrome की कोई सुविधा या कोई वेबसाइट स्थानीय मॉडल का उपयोग कर रही है। साथ ही यह भी समझ में आना चाहिए कि संबंधित काम पूरी तरह डिवाइस पर हो रहा है या कोई अतिरिक्त डेटा Google या किसी और सेवा तक भेजा जा रहा है। Chrome की आधिकारिक AI साइटें Built-in AI API के अस्तित्व को समझाती हैं, लेकिन नियंत्रण और टेलीमेट्री से जुड़े हर ऐसे व्यावहारिक प्रश्न का उत्तर वहाँ स्पष्ट नहीं मिलता .

ऑप्ट-आउट और डिलीट करना असली परीक्षा है

सबसे गंभीर आरोप केवल कथित डाउनलोड को लेकर नहीं हैं, बल्कि उसके बाद यूज़र के नियंत्रण को लेकर हैं। कई रिपोर्टों का दावा है कि फ़ाइल को मैनुअल रूप से हटाने के बाद वह फिर डाउनलोड हो जाती है और सामान्य Chrome सेटिंग्स में आम यूज़र के लिए आसान opt-out उपलब्ध नहीं है . यदि यह सही है, तो यह यूज़र स्वायत्तता की गंभीर समस्या होगी: हटाना तब सचमुच हटाना नहीं रहेगा, और उपयोग न करना स्पष्ट असहमति नहीं माना जा सकेगा।

आम यूज़र के लिए मुद्दा स्टोरेज, बैंडविड्थ और भरोसे का है। संगठनों के लिए इसके साथ सॉफ्टवेयर इन्वेंट्री, अनुमोदन प्रक्रियाएँ, ब्राउज़र पॉलिसी और नियंत्रित वातावरण में AI कंपोनेंट के इस्तेमाल जैसे सवाल भी जुड़ जाते हैं। कुछ रिपोर्टें इस मामले को vendor-risk और compliance के संदर्भ में भी रखती हैं .

GDPR और ePrivacy: संभावित जोखिम, लेकिन साबित उल्लंघन नहीं

उपलब्ध स्रोतों से किसी अंतिम कानूनी उल्लंघन का निष्कर्ष नहीं निकाला जा सकता। इसके लिए वास्तविक डिलीवरी, यूज़र नोटिस, सेटिंग्स, सक्रिय होने की प्रक्रिया और डेटा प्रवाह के बारे में भरोसेमंद विवरण चाहिए। फिर भी कुछ निजता-केंद्रित रिपोर्टें इसे यूरोपीय संघ के GDPR जैसे नियमों के सिद्धांतों — पारदर्शिता और privacy by design — तथा ePrivacy नियमों से जोड़ती हैं, जो डिवाइस पर जानकारी स्टोर करने या उस तक पहुँचने से संबंधित हैं .

अंतर समझना जरूरी है: कोई मॉडल फ़ाइल सिर्फ इसलिए समस्या नहीं बनती कि वह बड़ी है। निजता के लिहाज से मामला तब संवेदनशील बनता है जब Chrome बिना साफ जानकारी के ऐसी कंपोनेंट इंस्टॉल करे जो यूज़र सामग्री प्रोसेस कर सकती है, या जब टेलीमेट्री, सक्रियता डेटा या उपयोग डेटा के बारे में पर्याप्त व्याख्या न हो।

निजता-अनुकूल लागू करने के लिए क्या जरूरी है

ब्राउज़र में स्थानीय AI के लिए कुछ न्यूनतम मानक साफ होने चाहिए:

• बड़े AI कंपोनेंट इंस्टॉल होने से पहले समझने योग्य अपडेट सूचना,
• मॉडल को चालू, बंद और हटाने के लिए स्पष्ट सेटिंग,
• यह भरोसा कि हटाया गया मॉडल कब और किन शर्तों पर फिर डाउनलोड होगा,
• सुविधा फीचर्स, सुरक्षा फीचर्स और डेवलपर API के लिए अलग-अलग स्विच,
• स्थानीय प्रोसेसिंग, संभावित क्लाउड कॉल और टेलीमेट्री की साफ डॉक्युमेंटेशन,
• कंपनियों, संस्थानों और सार्वजनिक निकायों के लिए एडमिन पॉलिसी,
• जब कोई वेबसाइट या Chrome फीचर स्थानीय मॉडल का उपयोग करे, तो दिखने वाला संकेत।

ये बातें केवल कानूनी औपचारिकता नहीं हैं। इन्हीं से तय होगा कि on-device AI को निजता का लाभ माना जाएगा या ब्राउज़र में ऐसी नई परत, जिसके बारे में यूज़र पर्याप्त नहीं जानते।

निष्कर्ष

Chrome Built-in AI और Gemini Nano का संबंध आधिकारिक रूप से दस्तावेज़ित है . लेकिन weights.bin नाम की कथित 4 GB फ़ाइल, चुपचाप डाउनलोड और हटाने के बाद फिर डाउनलोड होने का खास आरोप कई रिपोर्टों में है; Chrome की आधिकारिक डेवलपर डॉक्युमेंटेशन में इसकी स्पष्ट पुष्टि नहीं मिलती .

इसलिए संतुलित निष्कर्ष यह है: स्थानीय AI का अस्तित्व अपने-आप मुख्य समस्या नहीं है। On-device AI, अगर सामग्री सचमुच डिवाइस पर रहे, तो निजता को बेहतर भी बना सकती है . असली सवाल यह है कि Chrome कितनी पारदर्शिता से बताता है कि कौन-सी AI कंपोनेंट इंस्टॉल हो रही है, उसका उपयोग किस लिए है, कौन-से डेटा प्रवाह बनते हैं और यूज़र या एडमिन उसे प्रभावी रूप से कैसे बंद कर सकते हैं।