विषय-सूची

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

यह लेख समझाता है कि AI निर्भरता जोखिम क्या है, किन तरीकों से कोई AI "गायब" हो सकता है (छह प्रकार), और—व्यक्तियों तथा प्रोडक्शन सिस्टम दोनों के लिए—वे ठोस कदम जो AI के रुक जाने पर भी आपको परेशान न होने दें। इसे बिना किसी पूर्व जानकारी के पढ़ने लायक लिखा गया है, और इसका दूसरा भाग डेवलपर्स के लिए रिडंडेंसी डिज़ाइन तक जाता है।

AI DEPENDENCY RISK

किसी एक AI पर पूरी तरह न झुकें

— "यह रुकेगा" मानकर डिज़ाइन करें, फिर रुकने से नुकसान नहीं होगा

जोखिम

एक ही मॉडल पर पूरी निर्भरता

एक "सिंगल पॉइंट ऑफ़ फ़ेलियर": जिस पल वह सस्पेंड, रिटायर, री-प्राइस या बदल जाता है, आपका काम उसी के साथ रुक जाता है।

सोच

भविष्यवाणी से नहीं, डिज़ाइन से बचाव करें

"यह कब रुकेगा" अनुमान लगाने की कोशिश न करें। ऐसा बना दें कि रुकने पर यह "स्विच हो जाए"।

तैयारी

विकल्प, रिडंडेंसी, स्व-संरक्षण

एक बैकअप मॉडल तैयार, आपका डेटा और प्रॉम्प्ट आपके पास सुरक्षित, और स्विच-ओवर की योजना पहले से तैयार।

1. AI निर्भरता जोखिम क्या है? "बहुत ज़्यादा सुविधाजनक" होने का दूसरा पहलू

AI निर्भरता जोखिम वह स्थिति है जिसमें आपका काम या जीवन किसी विशेष AI सेवा या मॉडल पर इतना ज़्यादा निर्भर हो जाता है कि जब वह उपलब्ध न रहे, बदल जाए या महँगा हो जाए तो आपको गंभीर नुकसान उठाना पड़ता है। डरावनी बात इतनी नहीं कि "AI गलतियाँ करता है", बल्कि वह असंततता है—"जो AI कल काम कर रहा था, वह आज आपके हाथ में नहीं है।"

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

💡 मुख्य बात: निर्भरता अपने आप में समस्या नहीं है। समस्या है बिना किसी विकल्प वाली निर्भरता। बस एक बैकअप होने भर से जोखिम "घातक" से घटकर "असुविधाजनक" रह जाता है।

2. यह पहले ही हो चुका है: Fable 5 और Mythos 5 एक रात में गायब

12 जून 2026 को, Anthropic ने अपने टॉप मॉडल Claude Fable 5 और Mythos 5 तक सभी उपयोगकर्ताओं की पहुँच सस्पेंड कर दी। यह अमेरिकी सरकार के एक एक्सपोर्ट-कंट्रोल निर्देश की प्रतिक्रिया थी, और ये मॉडल सिर्फ़ 9 जून को ही लॉन्च हुए थे—रिलीज़ के सिर्फ़ तीन दिन बाद पूरा शटडाउन। ऐप, API, क्लाउड—हर रास्ता प्रभावित हुआ, फ़्री हो या पेड, सब समान रूप से, जिससे ऐसी स्थिति बनी कि "कोई भी दरवाज़ा काम नहीं करता।"

लिखे जाने के समय (जून 2026 के अंत) तक, दोनों मॉडल अब भी सस्पेंड हैं। Anthropic के एक अधिकारी ने जून के मध्य में कहा कि वे "आने वाले दिनों में" लौटेंगे, पर आधिकारिक स्टेटस पर अब तक रिस्टोरेशन नहीं दिखा है, और समय अनिश्चित बना हुआ है। पूरी घटनाक्रम हमारे Fable 5 / Mythos 5 सस्पेंशन वाले लेख में दिया गया है।

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

Fable 5 तो बस हिमशैल की नोक है। दरअसल 2026 वह साल भी रहा जिसमें प्रोवाइडर एक के बाद एक पुराने मॉडल रिटायर करते गए। सस्पेंशन और रिटायरमेंट कोई "विशेष घटनाएँ" नहीं—जब तक आप AI इस्तेमाल करते हैं, ये एक स्थायी जोखिम बनते जा रहे हैं।

3. निर्भरता जोखिम के 6 प्रकार

"AI उपलब्ध नहीं रहता" यह बहुत अलग-अलग तरीकों से हो सकता है। बचाव सोचने से पहले, यह समझ लेना मददगार है कि परेशानी किन रूपों में आती है, जिन्हें छह में बाँटा गया है।

① अचानक सस्पेंशन

नियमन, राष्ट्रीय सुरक्षा या कानूनी परेशानी सेवा को बिना चेतावनी रोक देती है। Fable 5 इसका क्लासिक उदाहरण है—और इस पर समय रहते प्रतिक्रिया देना सबसे कठिन है।

② मॉडल रिटायरमेंट (डिप्रिकेशन)

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

③ दाम बढ़ना / बिलिंग में बदलाव

रेट में बदलाव, फ़्री टियर का सिकुड़ना, प्लान बंद होना। सेवा ज़िंदा है, पर अर्थशास्त्र अब बैठता नहीं, इसलिए आप उसे इस्तेमाल नहीं कर पाते।

④ क्वालिटी में बदलाव / चुपचाप परिवर्तन

एक ही मॉडल नाम के तहत व्यवहार बदल जाता है या सेफ़्टी सीमाएँ कड़ी हो जाती हैं। "कल का प्रॉम्प्ट आज नहीं चलता।" मुश्किल यह है कि इसे पकड़ना आसान नहीं।

⑤ आउटेज / रेट लिमिट / बैन

सर्वर आउटेज, उपयोग की सीमा, अकाउंट सस्पेंशन। भले अस्थायी हो, उस पल यह निश्चित रूप से रुक जाता है।

⑥ वेंडर लॉक-इन

आप किसी एक वेंडर के प्रॉपराइटरी फ़ीचर्स और फ़ॉर्मैट के इर्द-गिर्द इतनी कसकर निर्माण कर लेते हैं कि दूसरे पर जा ही नहीं सकते—जब ①–⑤ टकराते हैं तो अपना ही भागने का रास्ता बंद कर बैठते हैं।

①–⑤ ऐसे जोखिम हैं जो "बाहर से आप पर आ गिरते हैं"; ⑥ वह जोखिम है जिसे आप "खुद बनाते हैं।" पहले वालों को आप पूरी तरह नहीं रोक सकते, पर सिर्फ़ ⑥ से बचकर ही उस घड़ी का नुकसान काफ़ी हद तक घट जाता है।

4. सबसे पहले, अपनी निर्भरता मापें

तैयारी का पहला कदम खरीदारी नहीं—स्टॉक-टेकिंग (हिसाब-किताब) है। विशेषज्ञ इस पर सहमत हैं कि शुरुआती बिंदु है "अपनी AI निर्भरता-शृंखलाओं का साफ़ नज़र से ऑडिट।" नीचे दी तीन चीज़ें लिख लें और आपके पास अपनी निर्भरता मैपिंग तैयार होगी।

🧭

आप किस पर निर्भर हैं

किस काम के लिए कौन-सी सेवा और कौन-सा मॉडल इस्तेमाल करते हैं। सब कुछ सूचीबद्ध करें—ऐप्स, API और बिल्ट-इन फ़ीचर्स।

⚖️

रुकने पर क्या टूटता है

"इसके बिना काम नहीं चल सकता" वाले कामों को "इसके बिना भी निभ जाएगा" वालों से अलग करें। महत्व × विकल्प की कठिनाई के अनुसार प्राथमिकता तय करें।

🔁

गायब होने पर आप क्या करेंगे

हर निर्भरता के लिए एक "दूसरा हाथ" पहले से तय करें: कोई दूसरा मॉडल, हाथ से किया गया काम, या अस्थायी विराम।

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

5. व्यक्तिगत उपयोगकर्ता कैसे तैयारी करें (5 कदम)

जो सामान्य उपयोगकर्ता सिस्टम नहीं बनाते, वे भी आज से तैयारी कर सकते हैं। संक्षेप में, यह "सब कुछ AI के भरोसे न छोड़ने" की आदत है।

1

एक विकल्प तैयार रखें

अगर आप आमतौर पर Claude इस्तेमाल करते हैं, तो ChatGPT या Gemini के फ़्री टियर भी आज़माकर देखें। बस एक "जिसे चलाना आप जानते हैं" ऐसा विकल्प होने से उस घड़ी में बहुत बड़ा फ़र्क पड़ता है।

2

अपने आउटपुट अपने पास सहेजें

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

3

अपने बेहतरीन प्रॉम्प्ट को संपत्ति की तरह रखें

जो प्रॉम्प्ट अच्छे चले, उन्हें जमा करें। ज़्यादातर लगभग वैसे-के-वैसे किसी दूसरे AI पर भी चल जाते हैं। अपनी संपत्ति "AI के अंदर" नहीं, "अपने हाथ में" बनाएँ।

4

"AI के बिना भी कर सकना" बनाए रखें

अंतिम फ़ैसला लेने, तथ्य जाँचने और अच्छे-बुरे लेखन में फ़र्क पहचानने की क्षमता अपने पास रखें। सब कुछ AI के भरोसे न छोड़ना ही, उसके रुकने पर, आपका सबसे बड़ा बीमा है।

5

अपने राज़ न तो सौंपें—न फैलाएँ

अपने कारोबार की सारी अहम जानकारी एक ही प्रोवाइडर में न उँडेलें। इनपुट की सावधानियाँ मानें और AI को इतनी सीमा में इस्तेमाल करें कि रुकना—या लीक—आपको डुबो न दे।

6. प्रोडक्शन सिस्टम की तैयारी (डिज़ाइन से रिडंडेंसी)

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

(1) एक एब्स्ट्रैक्शन लेयर (LLM गेटवे) बीच में डालें

अपने ऐप से हर प्रोवाइडर का API सीधे कॉल करने के बजाय, बीच में एक साझा प्रवेशद्वार (गेटवे) रखें। फिर मॉडल बदलना बस एक कॉन्फ़िग बदलाव रह जाता है। प्रमुख विकल्प:

LiteLLM

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

OpenRouter

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

Vercel AI SDK

कोड की तरफ़ से प्रोवाइडर को एब्स्ट्रैक्ट करने वाली एक लाइब्रेरी। आप अपने ऐप का कोड बदले बिना मॉडल अदल-बदल सकते हैं। वेब और ऐप डेवलपमेंट के साथ अच्छी जोड़ी बनती है।

✅ माइग्रेशन जितना सोचते हैं उससे हल्का है: कई प्रमुख गेटवे एक "OpenAI-compatible API" देते हैं, इसलिए अक्सर आपको बस बेस URL और API की बदलनी होती है। मौजूदा कोड ज़्यादातर वैसे-का-वैसा चलता है। अभी एक डाल लेना सबसे किफ़ायती बीमा है।

(2) एक फ़ॉलबैक चेन बनाएँ (पर हमेशा उसे टेस्ट करें)

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

⚠️ जाल: फ़ॉलबैक को "ज़रूरत पड़ने से पहले" टेस्ट करें। ऐसा सेटअप जिसे आप कॉन्फ़िगर किया मान बैठे हैं पर जो कभी चलता ही नहीं—या चुपचाप विफल हो जाता है—फ़ॉलबैक न होने से भी बुरा है (आपको पता ही नहीं चलता कि कुछ टूटा)। शांत समय में जानबूझकर प्राइमरी मॉडल रोककर पुष्टि करें कि यह ठीक से स्विच होता है।

(3) लेयरें अलग करें—AI को "निकाला जा सकने वाला पुर्ज़ा" बनाएँ

अपने सिस्टम को दो लेयरों में सोचें। तरकीब यह है कि जिन हिस्सों को आपको AI से बदलना नहीं चाहिए, उन्हें AI से स्वतंत्र रखें।

AI ऑगमेंटेशन (निकाला जा सकने वाला)

ड्राफ़्टिंग, समराइज़िंग, सुझाव

अगर AI रुक जाए, तो आपने बस इतना ही खोया। इसे ऐसे डिज़ाइन करें कि उत्पादकता घटे पर काम चलता रहे।

सिस्टम ऑफ़ रिकॉर्ड (बचाएँ)

डेटा, बहीखाते, कोर सिस्टम

इन्हें अपने नियंत्रण में रखें, बाहरी AI पर निर्भर नहीं। AI गायब भी हो जाए, तो भी आपका कोर डेटा और प्रोसेसिंग ज़िंदा रहती है।

(4) आख़िरी रक्षा-पंक्ति के तौर पर एक लोकल LLM

एक लोकल LLM रखना जो आपके अपने हार्डवेयर पर चले—भले पूरा क्लाउड ही ठप हो जाए—नेटवर्क आउटेज, API सस्पेंशन और नियमन, तीनों के ख़िलाफ़ काम करता है। यह भले टॉप परफ़ॉर्मेंस वाला न हो, पर यह आपको अपने नियंत्रण में एक रेखा देता है: "कम-से-कम यहाँ तक हम कभी AI-विहीन नहीं होते।" यह उन इस्तेमालों के साथ भी अच्छी जोड़ी बनाता है जहाँ गोपनीय डेटा परिसर से बाहर नहीं जा सकता।

(5) एक पन्ने की रिकवरी प्लेबुक लिखें

जब सचमुच कुछ रुक जाए, तब शून्य से रिसर्च करने में जुट जाना रिकवरी को धीमा कर देता है। बस एक पन्ना रखना—"अगर प्राइमरी मॉडल ठप हो → इस कमांड से विकल्प पर स्विच करें → इस टेम्पलेट से स्टेकहोल्डरों को सूचित करें"—टाइम-टू-रिकवरी (MTTR) को "दिनों" से घटाकर "घंटों" में ले आता है। साल में एक बार असली स्विच-ओवर ड्रिल करें, और ज़रूरत के वक़्त यह पक्के तौर पर काम करेगी।

7. वेंडर चुनने के लिए चेकलिस्ट

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

⏳ रिटायरमेंट की अग्रिम सूचना

किसी सार्वजनिक मॉडल को रिटायर करने से पहले वे कितनी मोहलत देते हैं। Anthropic कम-से-कम 60 दिन बताता है; OpenAI सामान्य रूप से उपलब्ध मॉडलों के लिए कम-से-कम 6 महीने। पर प्रीव्यू मॉडल को महज़ ~2 सप्ताह तक ही मिल सकते हैं—इसलिए प्रीव्यू वर्शन पर निर्भर रहना सावधानी माँगता है।

🔔 बदलावों की पारदर्शिता

क्या वे स्पेक बदलावों और सीमाओं की घोषणा ऐसे तरीके से करते हैं जिसे उपयोगकर्ता देख सकें। "चुपचाप क्वालिटी गिराना" निर्भरता में खतरनाक है। उनके नोटिस, माइग्रेशन गाइड और स्टेटस पेज जाँचें।

🗄️ रिटायरमेंट के बाद राहत

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

📌 ध्यान दें: सूचना अवधि और नीतियाँ हर प्रोवाइडर समय-समय पर संशोधित करता है। अपनाने से पहले, हमेशा आधिकारिक "model deprecation" पेज पर नवीनतम आँकड़े पक्के करें। इस लेख के आँकड़े जून 2026 के अनुसार दिशा-संकेत मात्र हैं।

सारांश

AI निर्भरता जोखिम की तैयारी तीन पंक्तियों में सिमट आती है।

  • जानें कि यह असली है: जैसा Fable 5 ने दिखाया, सबसे बेहतर परफ़ॉर्म करने वाला AI भी नियमन, कारोबार या आउटेज की वजह से एक रात में गायब हो सकता है। सस्पेंशन और रिटायरमेंट एक स्थायी जोखिम हैं।
  • भविष्यवाणी से नहीं, डिज़ाइन से बचाव करें: आप अनुमान नहीं लगा सकते कि "यह कब रुकेगा।" सही जवाब है इसे ऐसा बनाना कि रुकने पर यह "स्विच हो जाए / नुकसान न हो।" एक विकल्प, एक एब्स्ट्रैक्शन लेयर, एक रिकवरी प्लेबुक।
  • संपत्ति अपने पास रखें: अपना डेटा, प्रॉम्प्ट और निर्णय-क्षमता "AI के अंदर" नहीं, "अपने हाथ में" रखें। बस ⑥ वेंडर लॉक-इन से बचकर ही आपका भागने का रास्ता खुला रहता है।

AI एक शक्तिशाली औज़ार है—पर औज़ार कभी-कभी आपके हाथ से गायब हो जाते हैं। ऐसा डिज़ाइन करना कि उनके रुकने पर आपका कोर काम न रुके, वही वह नींव है जो आपको AI पर गहराई से और भरोसे के साथ झुकने देती है।

FAQ

Q. तो इस्तेमाल के लिए सबसे सुरक्षित AI कौन-सा है?

A. "सिर्फ़ एक" चुनने का विचार ही जोखिम है। सुरक्षित कोई विशेष सेवा नहीं, बल्कि किसी भी समय दूसरे AI पर स्विच कर पाना है। रोज़ इस्तेमाल के लिए एक तय कर लें, साथ ही कम-से-कम एक विकल्प जिसे आप छू सकें—यही व्यावहारिक रूप से सबसे बढ़िया है।

Q. अगर मैं इसे सिर्फ़ शौक़ के लिए हल्के-फुल्के इस्तेमाल करता हूँ, तो भी तैयारी ज़रूरी है?

A. हल्की तैयारी काफ़ी है। बस दो चीज़ें—"ज़रूरी आउटपुट लोकल सहेजें" और "जो प्रॉम्प्ट चले उन्हें एक मेमो में रखें"—सेवा रुकने पर लगभग सारा नुकसान रोक देती हैं। पूरी रिडंडेंसी की बात काम के इस्तेमाल के लिए है।

Q. क्या "डिप्रिकेशन" और "सस्पेंशन" अलग हैं?

A. डिप्रिकेशन एक नियोजित विराम है जो नए मॉडल पर जाने के लिए होता है, आमतौर पर कुछ सप्ताह से कुछ महीनों की अग्रिम सूचना के साथ। Fable 5 जैसा सस्पेंशन अचानक, बिना चेतावनी हो सकता है। पहले से माइग्रेशन से निपटें, दूसरे से रिडंडेंसी से—यह बँटवारा चीज़ों को साफ़ कर देता है।

Q. क्या कई AI को सपोर्ट करने से लागत और मेहनत नहीं बढ़ती?

A. एक एब्स्ट्रैक्शन लेयर (एक LLM गेटवे) डाल दें तो सपोर्ट की लागत तेज़ी से गिरती है। कई OpenAI-compatible हैं, इसलिए स्विच करना मोटे तौर पर बस एंडपॉइंट और की बदलने जितना है। आप हर समय दो प्रोवाइडर नहीं चलाते—बस "कभी भी स्विच कर सकने" की तैयारी रखते हैं, और रोज़मर्रा की मेहनत मुश्किल से बढ़ती है।

Q. अगर मेरे पास लोकल LLM है, तो क्या मुझे फिर भी क्लाउड AI चाहिए?

A. इनकी भूमिकाएँ अलग हैं। एक लोकल LLM अक्सर परफ़ॉर्मेंस में किसी टॉप-टियर क्लाउड मॉडल की बराबरी नहीं कर पाता, पर इसका मूल्य "ऐसी आख़िरी रेखा जो कभी ठप नहीं होती" के रूप में है। आम तौर पर क्लाउड, आपात में लोकल—यह दो-स्तरीय सेटअप ही व्यावहारिक तरीका है।