एआई घटनाएं संचालन संकट बन रही हैं। हमें उन्हें उसी तरह से इलाज करने की जरूरत है।

पिछले कुछ वर्षों में, अधिकांश संगठनों ने एआई जोखिम के बारे में शासन की भाषा में बात की है।

क्या मॉडल सटीक है? क्या यह न्यायसंगत है? क्या डेटा अनुमोदित है? क्या हम उभर रहे नियमन के अनुसार पालन कर रहे हैं? वे महत्वपूर्ण प्रश्न हैं, लेकिन वे एकमात्र प्रश्न नहीं हैं। अधिक तत्काल प्रश्न यह है कि जब कुछ गलत हो जाता है तो क्या होता है?

क्या होता है जब एक एआई एजेंट एक ऐसी कार्रवाई करता है जो कभी नहीं करना था? क्या होता है जब एक मॉडल संवेदनशील डेटा लीक करता है? क्या होता है जब एक हॉलुसिनेटेड उत्तर कानूनी जोखिम पैदा करता है, या एक स्वचालित निर्णय एक ग्राहक, कर्मचारी, रोगी, या भागीदार को एक ऐसे तरीके से प्रभावित करता है जिसे आसानी से उलटा नहीं किया जा सकता?

और शायद सबसे व्यावहारिक रूप से: संगठन प्रतिक्रिया का समन्वय करने के लिए कहां जाता है? यह वह बदलाव है जो अब चल रहा है। एआई जोखिम एक संचालन लचीलापन मुद्दा बन रहा है, न कि केवल एक शासन मुद्दा।

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

ओईसीडी एआई घटना मॉनिटर ने जनवरी 2026 में अकेले 596 एआई घटनाओं को ट्रैक किया, जो वर्ष-दर-वर्ष 200% की वृद्धि है। ओईसीडी एआई घटना मॉनिटर और एआई घटना डेटाबेस जैसे प्रयास एआई प्रणालियों से जुड़े नकारात्मक या हानिकारक परिणामों का दस्तावेजीकरण करते हैं ताकि उद्योग अनुभव से सीख सके, जिस तरह साइबर सुरक्षा और विमानन ने वर्षों से किया है।

यह तुलना महत्वपूर्ण है। परिपक्व उद्योग यह पूछते हैं कि विफलता को कैसे रोका जाए और जब विफलता वैसे भी होती है तो कैसे प्रतिक्रिया दी जाए।

एआई घटनाएं पारंपरिक सॉफ्टवेयर बग्स की तरह व्यवहार नहीं करती हैं

एक पारंपरिक सॉफ्टवेयर बग आमतौर पर एक सापेक्ष स्पष्ट सीमा होती है। कुछ टूट जाता है, इंजीनियर जांच करते हैं, और टीम समस्या को पुन: उत्पन्न करती है, कोड को पैच करती है, और एक समाधान भेजती है।

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

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

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

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

प्रतिक्रिया क्रॉस-फंक्शनल होगी

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

एआई घटनाएं उसी पैटर्न का पालन करेंगी।

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

या एक एआई एजेंट की कल्पना करें जो उद्यम प्रणालियों में अनियंत्रित कार्रवाई करना शुरू कर देता है। तकनीकी टीम इसे बंद करने में सक्षम हो सकती है, लेकिन संगठन को अभी भी यह जानने की जरूरत है कि यह क्या करता था, कौन प्रभावित हुआ, कौन से निर्णय लिए गए, क्या अनुबंध दायित्वों को ट्रिगर किया गया, और भविष्य में उसी विफलता को कैसे रोका जाएगा। यह एआई टीम द्वारा अकेले नहीं किया जा सकता है।

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

एक संकट में, समन्वय बुनियादी ढांचा है, न कि केवल एक नरम कौशल।

जांच के अधीन एआई को प्रतिक्रिया को नियंत्रित नहीं करना चाहिए

एक और मुद्दा है जिस पर संगठनों को बहुत अधिक सावधानी से विचार करने की आवश्यकता है। यदि जांच के अधीन एआई प्रणाली उन्हीं संचार, दस्तावेजों, कार्य प्रवाह, या स्वचालन तक पहुंच सकती है जो प्रतिक्रिया का समन्वय करने के लिए उपयोग की जा रही है, तो संगठन के पास एक समस्या है।

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

एआई के लिए भी यही तर्क लागू होता है।

एक एआई प्रणाली मानव अर्थ में दुर्भावनापूर्ण नहीं हो सकती है, लेकिन यदि यह प्रतिक्रिया योजना देख सकती है, प्रतिक्रिया बैठक का सारांश बना सकती है, कार्य प्रवाह को प्रभावित कर सकती है, अगले चरण की सिफारिश कर सकती है, या उसी वातावरण में संचालित हो सकती है जिसे उसे सीमित करने के लिए उपयोग किया जा रहा है, तो संगठन ने वास्तव में प्रतिक्रिया को अलग नहीं किया है।

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

इसे एक आग की जांच की तरह सोचें। आप उसी दोषपूर्ण प्रणाली से जुड़े स्प्रिंकलर नियंत्रण नहीं चाहेंगे जिसे आप निदान करने की कोशिश कर रहे हैं।

तैयार करें, अभ्यास करें, प्रतिक्रिया दें, रिपोर्ट करें

एआई घटना तैयारी के लिए एक उपयोगी फ्रेमवर्क साइबर सुरक्षा में परिपक्व हुआ है: तैयार करें, अभ्यास करें, प्रतिक्रिया दें, रिपोर्ट करें।

तैयार करने का अर्थ है घटना के प्रकारों को परिभाषित करना जो होने से पहले ही होते हैं, जैसे कि पूर्वाग्रह, हॉलुसिनेशन, डेटा लीक, मॉडल ड्रिफ्ट, प्रॉम्प्ट इंजेक्शन, एजेंटिक रनअवे, अनधिकृत टूल उपयोग, और तृतीय-पक्ष मॉडल विफलता। प्रत्येक के लिए अलग-अलग हितधारक और अलग-अलग निर्णय की आवश्यकता होती है।

एक अच्छा प्लेबुक 200-पृष्ठ का दस्तावेज नहीं होना चाहिए जो एक फोल्डर में बैठा हो। किसी संकट के दौरान कोई पेज 137 नहीं खोलता है। एक अच्छा प्लेबुक भूमिका-आधारित, सुलभ, और कार्रवाई योग्य होना चाहिए। कानूनी को पता होना चाहिए कि कानूनी को क्या करना है। इंजीनियरिंग को पता होना चाहिए कि इंजीनियरिंग को क्या करना है। संचार को पता होना चाहिए कि कब ग्राहकों, नियामकों या मीडिया को शामिल करना है। बोर्ड को पता होना चाहिए कि प्रबंधन कब बढ़ाएगा।

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

प्रतिक्रिया का अर्थ है लाइव इवेंट को अनुशासन के साथ समन्वय करना। कौन कमरे में है? कौन से तथ्य ज्ञात हैं? कौन से तथ्य अभी भी अनिश्चित हैं? कौन से निर्णय लिए गए? किसने उनकी मंजूरी दी? घंटे 12 और घंटे 48 के बीच क्या बदला?

रिपोर्ट का अर्थ है यह मान्यता देना कि एआई नियमन अधिक ठोस हो रहा है। यूरोपीय संघ के एआई अधिनियम में कुछ उच्च-जोखिम वाली एआई प्रणालियों के प्रदाताओं के लिए गंभीर घटना रिपोर्टिंग दायित्व शामिल हैं। विवरण क्षेत्राधिकार, उद्योग, और उपयोग के मामले में भिन्न हो सकते हैं, लेकिन दिशा स्पष्ट है। एआई घटनाओं के लिए एक रक्षात्मक रिकॉर्ड की आवश्यकता होगी जो बताता है कि क्या हुआ, क्या ज्ञात था, क्या कार्रवाई की गई, और कब।

एआई मदद कर सकता है, लेकिन यह निर्णय लेने की जगह नहीं ले सकता

एक प्रलोभन है कि एआई घटना प्रतिक्रिया को पूरी तरह से स्वचालित किया जाना चाहिए। मुझे लगता है कि यह गलत फ्रेमिंग है।

एआई बहुत मदद कर सकता है। यह तथ्यों को सारांशित कर सकता है। यह लापता जानकारी की पहचान कर सकता है। यह एक घटना की तुलना पिछले पैटर्न से कर सकता है। यह बाद की कार्रवाई की रिपोर्ट तैयार कर सकता है। यह नियामक दायित्वों को मैप करने में मदद कर सकता है। यह दबाव में लोगों के लिए प्रशासनिक बोझ को कम कर सकता है।

लेकिन एक गंभीर घटना में, मानव अपरिहार्य हैं।

किसी को यह तय करना होगा कि क्या तथ्य पर्याप्त हैं। किसी को ग्राहक प्रभाव का मूल्यांकन करना होगा। किसी को तय करना होगा कि क्या प्रणाली को रोकना है। किसी को यह निर्धारित करना होगा कि क्या संगठन ने एक रिपोर्टिंग सीमा पार की है। किसी को जवाबदेही और सहानुभूति के साथ संवाद करना होगा।

एआई घटना प्रतिक्रिया में एआई की सही भूमिका संकट टीम को बदलना नहीं है। यह संकट टीम को बेहतर संदर्भ, तेजी से देना है।

एनआईएसटी के एआई जोखिम प्रबंधन फ्रेमवर्क उपयोगी है क्योंकि यह एआई जोखिम प्रबंधन को चार कार्यों के आसपास फ्रेम करता है: शासन, मैप, माप, और प्रबंधन। घटना प्रतिक्रिया के लिए, मैं एक व्यावहारिक विस्तार जोड़ूंगा: अभ्यास करें।

एक योजना जिसे कभी परीक्षण नहीं किया गया है वास्तव में एक योजना नहीं है। यह एक सिद्धांत है।

बोर्ड को भी एक प्लेबुक की आवश्यकता है

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

कब बोर्ड को सूचित किया जाएगा? कौन से निर्णय बोर्ड के इनपुट की आवश्यकता है? क्या जानकारी प्रबंधन प्रदान करेगा? कैसे सामग्री, ग्राहक प्रभाव, कानूनी जोखिम, नियामक दायित्व, और संचालन व्यवधान का मूल्यांकन किया जाएगा?

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

विश्वसनीय एआई के लिए संचालन लचीलापन की आवश्यकता है

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

साइबर सुरक्षा ने इसी तरह का विकास किया। संगठनों ने वर्षों से रोकथाम में निवेश किया है, और उन्हें ऐसा करना जारी रखना चाहिए। लेकिन परिपक्व संगठनों ने अंततः सीखा कि रोकथाम पर्याप्त नहीं है। आपको लचीलापन भी चाहिए। एआई उसी चरण में प्रवेश कर रहा है।

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

प्रश्न यह है कि क्या संगठन घटना के दौरान गति, समन्वय, निर्णय, और जवाबदेही के साथ प्रतिक्रिया कर सकता है। यही एआई को प्रयोग से विश्वसनीय बुनियादी ढांचे में ले जाने का तरीका है, और यही लचीलापन संस्कृति बन जाता है।