सॉवरेन AI सिर्फ डेटा रेज़िडेंसी नहीं है: संगठनों को वास्तव में किस पर नियंत्रण रखना होता है

Google, Microsoft, IBM और AWS की अक्टूबर 2026 की घोषणाएं दिखाती हैं कि सॉवरेन AI इंफ्रास्ट्रक्चर किस दिशा में विकसित हो रहा है। व्यावहारिक चुनौती यह तय करना है कि मॉडल कहां चलते हैं, परिवेश पर नियंत्रण किसका है और कौन सी निर्भरताएं बाकी रहती हैं।

एक विनियमित संगठन चाहता है कि एक AI असिस्टेंट गोपनीय रिपोर्टों और आंतरिक दस्तावेज़ों में खोज करे।

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

डेटा भले ही स्थानीय रूप से रखा गया हो, लेकिन ज़रूरी नहीं कि पूरा AI सिस्टम स्थानीय ऑपरेशनल नियंत्रण में हो।

यही डेटा रेज़िडेंसी और ऑपरेशनल संप्रभुता का फ़र्क़ है।

डेटा रेज़िडेंसी का संबंध इस बात से है कि जानकारी कहां रखी या प्रोसेस की जाती है। ऑपरेशनल संप्रभुता का संबंध इससे भी है कि सिस्टम तक पहुंच और उन पर नियंत्रण किसके पास है, ज़रूरी सेवाएं कहां चलती हैं और बाहरी निर्भरताएं उपलब्ध न रहने पर क्या होता है।

Google Cloud, Microsoft और IBM की हाल की घोषणाएं, AWS के एक ऑपरेशनल अभ्यास के साथ मिलकर, दिखाती हैं कि प्रोवाइडर इस समस्या के अलग अलग हिस्सों को कैसे संबोधित कर रहे हैं।

1. सॉवरेन AI की छह सीमाएं

सॉवरेन AI डिप्लॉयमेंट का मतलब सिर्फ किसी स्थानीय डेटा सेंटर में इंस्टॉल किया गया मॉडल नहीं है।

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

हर कदम एक संभावित निर्भरता जोड़ता है।

सीमा	संगठन को क्या तय करना होगा
डेटा	दस्तावेज़, प्रॉम्प्ट, एम्बेडिंग, जवाब, लॉग और बैकअप कहां रखे और प्रोसेस किए जाते हैं
मॉडल	इन्फ़रेंस कहां चलता है और क्या अनुरोध बाहरी मॉडल सेवाओं तक पहुंचते हैं
कंट्रोल प्लेन	परिवेश को कौन डिप्लॉय, कॉन्फ़िगर, बदल या बंद कर सकता है
आइडेंटिटी और कीज़	अनुमतियों, क्रेडेंशियल और एन्क्रिप्शन कीज़ का प्रबंधन कौन करता है
ऑपरेशन	रखरखाव, अपडेट, सपोर्ट, मॉनिटरिंग और रिकवरी कौन करता है
निरंतरता	बाहरी कनेक्टिविटी या निर्भरताएं विफल होने पर कौन सी सेवाएं काम करती रहती हैं

ये सीमाएं आर्किटेक्चर के आकलन का एक ढांचा हैं, संप्रभुता की कोई सार्वभौमिक कानूनी परिभाषा नहीं।

ये यह भी समझाती हैं कि दस्तावेज़ों को किसी मंज़ूरशुदा क्षेत्र में रखने भर से संगठन की ज़रूरतें अपने आप पूरी क्यों नहीं हो जातीं।

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

अगर इन्फ़रेंस स्थानीय रूप से चलता है लेकिन कंट्रोल प्लेन को किसी बाहरी सेवा के उपलब्ध रहने की ज़रूरत है, तो एप्लिकेशन की एक ऑपरेशनल निर्भरता उसके प्रोसेसिंग परिवेश के बाहर है।

ये निर्भरताएं स्वीकार्य हैं या नहीं, यह संगठन की खास कानूनी, अनुबंध संबंधी, सुरक्षा और निरंतरता की ज़रूरतों पर निर्भर करता है।

2. अक्टूबर 2026 में क्या बदला?

चार घटनाक्रम सॉवरेन इंफ्रास्ट्रक्चर और AI के प्रति अलग अलग दृष्टिकोण दिखाते हैं।

प्रोवाइडर	घटनाक्रम	यह क्या दिखाता है
Google Cloud	Google Distributed Cloud air-gapped की AI क्षमताओं का विस्तार, जिसमें Gemini 3.5 Flash और एंटरप्राइज़ सर्च शामिल हैं	एक अलग थलग परिवेश के भीतर स्थानीय मॉडल एक्ज़िक्यूशन और रिट्रीवल
Microsoft	पब्लिक, प्राइवेट और ग्राहक द्वारा संचालित परिवेशों में Sovereign Cloud नियंत्रणों का विस्तार	एडमिनिस्ट्रेशन, कीज़ और डिस्कनेक्टेड ऑपरेशन के लिए वर्कलोड के हिसाब से विकल्प
IBM	Sovereign Core और Fusion को जोड़ने वाले एक वैलिडेटेड आर्किटेक्चर की घोषणा	इंफ्रास्ट्रक्चर और ग्राहक द्वारा संचालित गवर्नेंस का एकीकरण
AWS	24 अक्टूबर के European Sovereign Cloud स्वतंत्रता अभ्यास के बताए गए नतीजे	तय वैश्विक AWS सिस्टम के बिना संचालन जारी रहने का परीक्षण

ये घटनाक्रम बराबर के उत्पाद नहीं हैं, न ही स्वतंत्र रूप से स्थापित रैंकिंग।

Google Cloud: 20 अक्टूबर को Google ने Google Distributed Cloud air-gapped पर Gemini 3.5 Flash को सामान्य रूप से उपलब्ध (generally available) बताया। उसका Gemini पर आधारित एंटरप्राइज़-सर्च अनुभव प्रीव्यू में था। Google का कहना है कि सर्च वर्कफ़्लो इंडेक्सिंग, प्रॉम्प्ट और रिट्रीवल को सॉवरेन दायरे के भीतर रखता है। यह एक दस्तावेज़ित प्रोडक्ट डिज़ाइन है, इस बात का प्रमाण नहीं कि हर डिप्लॉयमेंट अपने आप संप्रभुता की हर ज़रूरत पूरी करता है।

स्रोत: Google Cloud, 20 अक्टूबर 2026

Microsoft: उसकी 20 अक्टूबर की घोषणा में ऑपरेटर एक्सेस, एन्क्रिप्शन-की प्रबंधन, ग्राहक द्वारा संचालित इंफ्रास्ट्रक्चर और कनेक्टेड या डिस्कनेक्टेड परिवेशों को कवर करने वाले नियंत्रणों का वर्णन था। अलग अलग फ़ीचर परिपक्वता के अलग अलग स्तर पर हैं। Azure Managed HSM के साथ बाहरी कीज़ का प्रबंधन सामान्य रूप से उपलब्ध था, जबकि वर्कलोड को कनेक्टेड और डिस्कनेक्टेड संचालन के बीच ले जाने की क्षमता पब्लिक प्रीव्यू में आ रही थी।

स्रोत: Microsoft, 20 अक्टूबर 2026

IBM: 22 अक्टूबर को IBM ने Sovereign Core सॉफ़्टवेयर को Fusion इंफ्रास्ट्रक्चर के साथ जोड़ने वाले एक वैलिडेटेड डिप्लॉयमेंट आर्किटेक्चर की घोषणा की। इसका उद्देश्य ग्राहक द्वारा संचालित परिवेशों के लिए कंप्यूट, स्टोरेज, नेटवर्किंग और गवर्नेंस के एकीकरण को आसान बनाना है। तेज़ डिप्लॉयमेंट और आसान संचालन IBM के बताए गए फ़ायदे हैं, हर ग्राहक के लिए स्वतंत्र रूप से प्रदर्शित नतीजे नहीं।

स्रोत: IBM, 22 अक्टूबर 2026

AWS: 1 नवंबर को AWS ने 24 अक्टूबर के एक अभ्यास की जानकारी दी, जिसमें दो वैश्विक सिस्टम डिस्कनेक्ट किए जाने के बाद भी उसका European Sovereign Cloud चलता रहा। AWS के अनुसार ग्राहकों के वर्कलोड उपलब्ध बने रहे।

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

स्रोत: AWS Security Blog, 1 नवंबर 2026

3. संगठनों को वास्तव में क्या जांचना चाहिए?

विनियमित संगठन के डॉक्यूमेंट-सर्च असिस्टेंट पर लौटते हैं।

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

समीक्षा से यह तय होना चाहिए कि हर कदम कहां चलता है और कौन से पक्ष उस तक पहुंच सकते हैं या उसका एडमिनिस्ट्रेशन कर सकते हैं।

चार जांचें खास तौर पर उपयोगी हैं।

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

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

ऑपरेशनल निर्भरताएं जांचें। तय करें कि अपडेट, मॉनिटरिंग, वेंडर सपोर्ट और डिज़ास्टर रिकवरी कैसे काम करते हैं। सामान्य संचालन या बहाली के लिए ज़रूरी किसी भी बाहरी सेवा की पहचान करें।

ज़रूरी विफलता स्थितियों का परीक्षण करें। अगर बाहरी कनेक्टिविटी के बिना संचालन जारी रहना ज़रूरी है, तो उसी स्थिति का परीक्षण करें। किसी वेंडर का नेटवर्क बैकबोन से अलगाव का सफल अभ्यास किसी ग्राहक के पूरी तरह डिस्कनेक्टेड एप्लिकेशन के परीक्षण की जगह नहीं ले सकता।

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

कौन सा साक्ष्य मायने रखता है, यह संगठन की ज़रूरतें तय करती हैं। हर सिस्टम को एक जैसी विफलताएं झेलने या बाहरी पहुंच के एक जैसे रूपों पर रोक लगाने की ज़रूरत नहीं होती।

4. ज़्यादा स्वतंत्रता की ऑपरेशनल कीमत होती है

संप्रभुता के ज़्यादा मज़बूत नियंत्रण संगठन की ऑपरेशनल ज़िम्मेदारियां बढ़ा सकते हैं।

एयर-गैप्ड AI परिवेश के लिए समर्पित एक्सेलरेटर, स्थानीय स्टोरेज, मॉडल आर्टिफ़ैक्ट, नेटवर्क इंफ्रास्ट्रक्चर और विशेषज्ञ सपोर्ट की ज़रूरत पड़ सकती है।

सॉफ़्टवेयर पैच और मॉडल अपडेट को प्रतिबंधित परिवेश में नियंत्रित तरीके से पहुंचाना होता है। मॉनिटरिंग, बैकअप और रिकवरी को भी अनुमत ऑपरेटिंग सीमाओं के भीतर काम करना होता है।

कनेक्टेड पब्लिक क्लाउड में मिलने वाली कुछ सेवाएं डिस्कनेक्ट होने पर उपलब्ध नहीं हो सकतीं या अलग तरह से काम कर सकती हैं।

ये कीमतें इसलिए मायने रखती हैं क्योंकि ज़्यादा से ज़्यादा आइसोलेशन अपने आप सबसे अच्छा आर्किटेक्चर नहीं होता।

जिस संगठन की ज़रूरतें नियंत्रित क्षेत्रीय क्लाउड सेवाओं की अनुमति देती हैं, उसे पूरी तरह डिस्कनेक्टेड AI प्लेटफ़ॉर्म बनाए रखने से बहुत कम फ़ायदा मिल सकता है।

अत्यधिक प्रतिबंधित जानकारी संभालने वाले किसी दूसरे संगठन के पास शायद कोई स्वीकार्य विकल्प न हो।

फ़ैसला ज़रूरतों के आधार पर होना चाहिए, किसी पसंदीदा वेंडर या संप्रभुता के किसी लेबल से शुरू होकर नहीं।

5. संप्रभुता को प्रदर्शित किया जाना चाहिए, मान नहीं लिया जाना चाहिए

अक्टूबर के घटनाक्रम स्थानीय AI इन्फ़रेंस, ग्राहक द्वारा संचालित इंफ्रास्ट्रक्चर, प्रशासनिक नियंत्रणों और ऑपरेशनल स्वतंत्रता में प्रगति दिखाते हैं।

लेकिन वे अलग अलग ज़रूरतों को संबोधित करते हैं, और उनके पीछे के साक्ष्य अलग अलग हैं।

सामान्य रूप से उपलब्ध सेवा, प्रीव्यू क्षमता, वेंडर का वैलिडेटेड आर्किटेक्चर और बताया गया ऑपरेशनल अभ्यास, इन्हें बराबर का प्रमाण नहीं माना जाना चाहिए।

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

सॉवरेन AI पूरे डिप्लॉय किए गए सिस्टम का गुण है, सिर्फ उस देश का नहीं जहां उसका डेटा रखा जाता है, और न ही उसके इंफ्रास्ट्रक्चर पर लगे लेबल का।

---

संदर्भ और आगे पढ़ने के लिए

1. Google Cloud, Enabling the next era of sovereign AI। 20 अक्टूबर 2026।
2. Google Cloud, Managed RAG search inside the sovereign perimeter। 20 अक्टूबर 2026।
3. Microsoft, Advancing digital sovereignty with greater control and choice। 20 अक्टूबर 2026।
4. IBM, IBM Sovereign Core on IBM Fusion simplifies sovereign AI deployment। 22 अक्टूबर 2026।
5. AWS Security Blog, Inside a successful AWS European Sovereign Cloud exercise। 1 नवंबर 2026।

स्रोत समीक्षा: 4 नवंबर 2026। प्रकाशन से पहले उत्पादों की उपलब्धता और ऑपरेशनल दावों की दोबारा पुष्टि की जानी चाहिए। यह लेख आर्किटेक्चर से जुड़े विचारों का वर्णन करता है, कानूनी अनुपालन प्रमाणन का नहीं।