सपन पांड्या, वरिष्ठ सॉफ्टवेयर इंजीनियर और IEEE के वरिष्ठ सदस्य – साक्षात्कार शृंखला

Sapan Pandya न्यू जर्सी में कार्यरत वरिष्ठ सॉफ्टवेयर इंजीनियर और IEEE के वरिष्ठ सदस्य हैं। उन्हें भरोसेमंद वितरित लेन-देन प्रणालियों में दस साल से अधिक का अनुभव है। उनका काम लेन-देन की अखंडता, सॉफ्टवेयर और भौतिक उपकरणों के बीच एकीकरण, उत्पादन संबंधी समस्याओं का निवारण और विनियमित परिवेशों में तैनाती के सत्यापन तक फैला है। उन्होंने Stevens Institute of Technology से कंप्यूटर विज्ञान में स्नातकोत्तर डिग्री हासिल की है और विद्वतापूर्ण समीक्षा तथा तकनीकी अनुसंधान में योगदान देते हैं।

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

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

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

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

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

इस अनुभव ने प्रणालियों के बीच की सीमाओं में मेरी खास दिलचस्पी जगाई है। हर घटक क्या जानता है? वह क्या मानकर चल रहा है? जब वे मान्यताएँ सही नहीं रहतीं, तो क्या होता है?

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

मैं चाहता हूँ कि एआई किसी समस्या की जाँच में लगने वाली मेहनत कम करे, लेकिन उसे सुलझाने के लिए ज़रूरी साक्ष्यों के मानक को कम न करे।

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

50 डॉलर के एक काल्पनिक भुगतान पर विचार करें। अनुप्रयोग एक अनुरोध भेजता है, भुगतान सेवा उसे सफलतापूर्वक दर्ज कर लेती है, लेकिन प्रतिक्रिया अनुप्रयोग तक पहुँचने से पहले खो जाती है।

भुगतान हो जाने के बावजूद ग्राहक को समय-सीमा समाप्त होने का संदेश दिखता है। यदि अनुप्रयोग भुगतान का नया अनुरोध भेजता है, तो ग्राहक से दोबारा पैसे लिए जा सकते हैं।

समय-सीमा समाप्त होने का मतलब है कि प्रतिक्रिया समय पर नहीं पहुँची। इससे यह पता नहीं चलता कि मूल लेन-देन सफल हुआ या नहीं।

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

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

जब नतीजा अनिश्चित हो, तो पुनर्प्राप्ति प्रक्रिया को तुरंत उसकी जगह नया लेन-देन शुरू करने के बजाय मौजूदा लेन-देन की जाँच करनी चाहिए और संबंधित अभिलेखों का मिलान करना चाहिए।

मैं पुनःप्रयासों की संख्या पर भी सीमा तय करूँगा और यह स्पष्ट करूँगा कि जब स्वचालित पुनर्प्राप्ति नतीजे का पता न लगा सके, तब क्या होगा। ग्राहक को स्पष्ट रूप से दिखना चाहिए कि लेन-देन लंबित है, साथ ही समाधान पाने का रास्ता भी मिलना चाहिए—न कि बार-बार पैसे कटें या प्रक्रिया की स्क्रीन अनिश्चित समय तक चलती रहे।

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

हाँ, उत्पादन संबंधी मेरे काम में लेन-देन की स्थिति से जुड़ी विसंगतियों की जाँच करना शामिल रहा है। कार्यस्थल की किसी घटना पर चर्चा किए बिना अपनी सोच समझाने के लिए मैं एक काल्पनिक उदाहरण दूँगा।

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

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

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

स्थायी सुधार में केवल किसी एक रिकॉर्ड को ठीक करने के बजाय यह भी दूर करना ज़रूरी है कि ऐसी विसंगति संभव क्यों हुई।

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

जैसे-जैसे AI एजेंट उत्पादन संबंधी घटनाओं का निदान करने से आगे बढ़कर सुधारात्मक कार्रवाइयों की सिफारिश करने या उन्हें अंजाम देने लगते हैं, AI सिस्टम को किसी लेन-देन का पुनः प्रयास करने, उसे उलटने या उसमें बदलाव करने की अनुमति देने से पहले कौन-से सुरक्षा उपाय होने चाहिए? इडेम्पोटेंसी कुंजियों, लेन-देन लॉग और मिलान तंत्र जैसे नियतात्मक नियंत्रण AI को अतिरिक्त विफलताएँ पैदा करने से कैसे रोक सकते हैं?

मैं किसी कार्रवाई का सुझाव देने, उसे अधिकृत करने और उसे अंजाम देने की प्रक्रियाओं को अलग रखूँगा।

AI एजेंट दोबारा प्रयास करने की सिफारिश कर सकता है, लेकिन एक अलग नियंत्रण को तय करना चाहिए कि उस पुनः प्रयास की अनुमति है या नहीं। उसे लेन-देन की मौजूदा स्थिति, कार्रवाई की पहचान, एजेंट की अनुमतियाँ और वे परिस्थितियाँ जाँचनी चाहिए जिनमें वह कार्रवाई सुरक्षित है।

यह जाँच कार्रवाई के समय होनी चाहिए, न कि केवल तब जब मॉडल ने पहली बार घटना की जाँच की थी। इस बीच कोई दूसरी प्रक्रिया लेन-देन पूरा कर चुकी हो सकती है।

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

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

मैं इस्तेमाल किए गए साक्ष्यों, सिफारिश, प्राधिकरण संबंधी निर्णय और वास्तविक परिणाम का भी रिकॉर्ड रखूँगा। इससे बाद में हस्तक्षेप की समीक्षा करना संभव होगा।

इन नियंत्रणों को मॉडल के बाहर ऐसे सॉफ़्टवेयर के ज़रिए लागू किया जाना चाहिए जिसकी जाँच की जा सके। एजेंट को सावधानी बरतने का निर्देश देना उपयोगी मार्गदर्शन है, लेकिन यह प्राधिकरण देने की व्यवस्था नहीं है।

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

सिस्टम में “परिणाम अज्ञात” की वास्तविक स्थिति होनी चाहिए। अन्यथा, वह जानकारी की कमी को गलत तरीके से विफलता का निर्णय मान सकता है।

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

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

इससे AI के आत्मविश्वास के अंक लेन-देन के साक्ष्य की जगह नहीं ले पाएँगे। अधूरी जानकारी के आधार पर तैयार किए गए स्पष्टीकरण पर भी मॉडल को पूरा भरोसा हो सकता है।

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

इसलिए, पुनर्प्राप्ति प्रक्रिया में यह कहने की क्षमता होनी चाहिए: “मैं अभी इस लेन-देन में बदलाव करने को उचित नहीं ठहरा सकता” और “इसे सुलझाने के लिए यह करना होगा।”

अनिश्चितता को पहचानना तभी उपयोगी है, जब सिस्टम के पास उससे निपटने का व्यावहारिक तरीका भी हो।

स्वायत्त एआई से जुड़े सबसे अहम सवालों में से एक यह तय करना है कि किन परिस्थितियों में मानवीय मंज़ूरी ज़रूरी बनी रहती है। आपके विचार से, उत्पादन परिवेश में पुनर्बहाली की कौन-सी कार्रवाइयाँ एआई को स्वतंत्र रूप से करने की अनुमति दी जानी चाहिए और किनके लिए हमेशा मानवीय स्वीकृति आवश्यक होनी चाहिए? वित्तीय लेन-देन, नियामकीय अनुपालन या ग्राहकों का भरोसा दाँव पर हो, तो संगठनों को ये सीमाएँ कैसे तय करनी चाहिए?

मैं सीमा इस आधार पर तय करूँगा कि गलती होने के क्या परिणाम होंगे, न कि इस आधार पर कि किसी कार्रवाई को “एआई” नाम दिया गया है या नहीं।

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

कुछ पूर्वनिर्धारित पुनर्बहाली प्रक्रियाओं को स्वचालित करना भी उपयुक्त हो सकता है, जब उनकी शर्तों की स्वतंत्र रूप से पुष्टि की गई हो और उनके प्रभाव सीमित हों।

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

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

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

तैनाती से पहले ही इन सीमाओं पर सहमति हो जानी चाहिए। किसी स्वचालित प्रणाली को कितना अधिकार दिया जाना चाहिए, यह तय करने के लिए सेवा बाधित होने का समय सही नहीं है।

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

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

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

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

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

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

इसके बाद इंजीनियरों को परिणामकारी सुझावों की पुष्टि मूल रिकॉर्ड से करनी चाहिए, न कि केवल एजेंट के सारांश पर भरोसा करना चाहिए। यह तब विशेष रूप से महत्त्वपूर्ण है, जब सारांश घटनाओं के लंबे या परस्पर विरोधी इतिहास को संक्षिप्त कर देता है।

मेरे लिए कसौटी सीधी है: क्या कोई दूसरा इंजीनियर साक्ष्यों का अनुसरण करके ऐसे निष्कर्ष पर पहुँच सकता है जिसका बचाव किया जा सके? यदि यह व्याख्या इस कसौटी पर खरी नहीं उतरती, तो उसके आधार पर उत्पादन परिवेश में बदलाव करने का समय नहीं आया है।

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

मैं केवल पहचान से आगे बढ़कर लचीलेपन की जाँच करना चाहता था: टर्मिनल परिवेश किसी हमले को कैसे सीमित कर सकता है, उसकी पहचान कैसे कर सकता है और जो कुछ हुआ उसके साक्ष्य सुरक्षित रखते हुए उससे कैसे उबर सकता है।

इसके परिणामस्वरूप बने Resilient Security Framework में निवारक नियंत्रण, एआई-सहायता प्राप्त विसंगति पहचान और परिभाषित प्रतिक्रिया तथा पुनर्बहाली तंत्र शामिल थे। एआई का उपयोग संदिग्ध व्यवहार की पहचान करने तक सीमित था। यह ऐसा प्रयोग नहीं था जिसमें किसी भाषाई मॉडल एजेंट को वित्तीय लेन-देन में स्वतंत्र रूप से बदलाव करने दिया गया हो।

मूल्यांकन में 72 घंटे के अनुकरण के दौरान 500 कियोस्क का प्रतिनिधित्व करने वाला एक कृत्रिम परिवेश इस्तेमाल किया गया। इसमें रैनसमवेयर हमलों के व्यवहार का अनुकरण किया गया था, न कि 500 भौतिक टर्मिनलों पर तैनाती की गई थी।

अध्ययन में केवल एंटीवायरस वाले आधार-स्तर की तुलना में, पहचान का औसत समय 52 मिनट से घटकर 31 मिनट और पुनर्बहाली का औसत समय 120 मिनट से घटकर 56 मिनट रह गया।

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

इन सीमाओं को ध्यान में रखना महत्वपूर्ण है। अनुकरण किए गए कार्यभार, नेटवर्क की परिस्थितियाँ, हमले के व्यवहार और आधारभूत सुरक्षा व्यवस्थाएँ हर परिचालन परिवेश का प्रतिनिधित्व नहीं करते। अलग-अलग उपकरणों और अनुप्रयोगों के लिए नए सिरे से सत्यापन करना होगा।

उत्पादन में इस्तेमाल से पहले, मैं प्रतिनिधि हार्डवेयर पर परीक्षण, स्वतंत्र सुरक्षा आकलन, लंबी अवधि के मूल्यांकन और गलत अलर्ट तथा प्रसंस्करण पर पड़ने वाले अतिरिक्त भार की सावधानीपूर्वक माप करना चाहूँगा।

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

यह अध्ययन आगे के परीक्षणों के लिए आधार देता है। वास्तविक परिचालन परिवेश में सुरक्षित व्यवहार का प्रदर्शन करना एक अलग कदम है।

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

मेरे उत्पादन संबंधी कार्य में सॉफ़्टवेयर विकास और एकीकरण, लेनदेन सत्यापन, समस्या निवारण, परीक्षण और रिलीज़ सत्यापन शामिल रहे हैं।

प्रकाशित शोध मेरे काम का एक अलग हिस्सा है और प्रत्येक अध्ययन को उसमें बताए गए तरीकों और सीमाओं के संदर्भ में समझना चाहिए।

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

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

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

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

मैं अपने उत्पादन अनुभव और शोध को एक-दूसरे का पूरक मानता हूँ: एक से उन परिचालन समस्याओं की पहचान होती है जिन्हें मैं समझता हूँ, जबकि दूसरा उन तरीकों की पड़ताल करता है जिन्हें सत्यापन के बाद ही अपनाया जाना चाहिए।

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

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

इससे लोगों को उन फैसलों के लिए अधिक समय मिलेगा जिनमें प्रणाली की ज़िम्मेदारियों और उसमें बदलाव के परिणामों को समझना ज़रूरी है।

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

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

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

स्वचालन बेहतर होने से मानवीय ज़िम्मेदारी खत्म नहीं होती। किसी को संचालन के नियमों, बदलाव के लिए ज़रूरी प्रमाणों और विफलताओं की जाँच की प्रक्रिया की ज़िम्मेदारी लेनी ही होगी।

मेरे विचार से, इंजीनियर जानकारी जुटाने में कम और उन परिस्थितियों को तय करने, परखने तथा बनाए रखने में अधिक समय देंगे जिनके पूरा होने पर स्वचालित कार्रवाई उचित मानी जा सकती है।

इस बेहतरीन साक्षात्कार के लिए धन्यवाद। जो पाठक वितरित लेन-देन की विश्वसनीयता और जिम्मेदार एआई-सहायता प्राप्त पुनर्प्राप्ति पर उनके काम को जानना चाहते हैं, वे Sapan Pandya से जुड़ सकते हैं।