𝗧𝗵𝗲 𝗔𝘀𝘆𝗺𝗺𝗲𝘁𝗿𝗶𝗰 𝗙𝗮𝗹𝗹𝗮𝗰𝘆: 𝗪𝗵𝘆 𝗔𝗜 𝗕𝗮𝗻𝘀 𝗛𝘂𝗿𝘁 𝗖𝗹𝗼𝘂𝗱 𝗗𝗲𝗳𝗲𝗻𝗱𝗲𝗿𝘀
नियामकों ने हाल ही में zero-day discovery की चिंताओं के कारण Anthropic के Claude Fable मॉडल्स पर प्रतिबंध लगा दिया है। वे स्वायत्त (autonomous) AI को कमजोरियों (vulnerabilities) को खोजने से रोकना चाहते हैं।
यह कदम विफल है। यह हमलावरों को नहीं रोकता। यह केवल डिफेंडर्स (defenders) की गति को धीमा करता है।
अन्य देशों के हमलावर विनियमित (regulated) APIs का उपयोग नहीं करते हैं। वे निजी हार्डवेयर पर open-source मॉडल्स चलाते हैं। जब आप उन्नत reasoning tools तक पहुंच खो देते हैं, तो हमलावर अपने टूल्स का उपयोग जारी रखते हैं।
परिणाम स्पष्ट है:
- हमलावर अपना AI लाभ बनाए रखते हैं।
- डिफेंडर्स वापस मैन्युअल कोड और regex लिखने पर मजबूर हो जाते हैं।
यदि आपकी सुरक्षा पाइपलाइन (security pipeline) किसी एक AI प्रदाता पर निर्भर है, तो आप एक बड़े जोखिम में हैं। यदि रात के 3:00 बजे आपके प्रदाता पर कोई निर्यात नियंत्रण (export control) लागू होता है, तो आपका स्वचालित बचाव (automated defense) अंधा हो जाएगा। जब आपके नेटवर्क पर हमला होगा, तब आपका सिस्टम विफल हो जाएगा।
आपको एक Zero-Trust LLM Architecture बनाना चाहिए। AI को एक स्थायी उपयोगिता (permanent utility) के रूप में मानना बंद करें। अपने सिस्टम को चालू रखने के लिए Cognitive Fallbacks का उपयोग करें।
इस fallback chain का पालन करें:
- Tier 1 (Primary): अपने सबसे अच्छे reasoning model का उपयोग करें।
- Tier 2 (Secondary): किसी अलग प्रदाता या अधिकार क्षेत्र (jurisdiction) के मॉडल का उपयोग करें।
- Tier 3 (Local): अपने EC2 पर अपने स्वयं के VPC के भीतर Llama या Mistral जैसे छोटे मॉडल चलाएं।
यदि प्राथमिक API डाउन हो जाता है, तो आपका सिस्टम Tier 2 पर चला जाता है। यदि इंटरनेट विफल हो जाता है, तो Tier 3 आपके निजी subnet के भीतर चलता है। यह कम स्मार्ट हो सकता है, लेकिन यह सक्रिय रहता है।
अपनी सुरक्षा को राजनीतिक रूप से अस्थिर API पर न बनाएं। यदि आप होस्ट (host) को नियंत्रित नहीं करते हैं, तो आप कंप्यूट (compute) के मालिक नहीं हैं।
आपकी टीम अचानक होने वाले API परिवर्तनों को कैसे संभाल रही है? क्या आप अपने लॉजिक को फिर से बना रहे हैं या प्रदाताओं को बदल रहे हैं? मुझे नीचे अपनी रणनीति बताएं।
Optional learning community: https://t.me/GyaanSetuAi