‘एआई जादू है’ वाली सोच से आगे बढ़ना: एआई मॉडल कैसे काम करते हैं, यह सीखना कंपनी-व्यापी प्राथमिकता क्यों होना चाहिए

बेकाबू एआई एजेंटों को लेकर चेतावनियों के बीच, हाल ही में एक डेवलपर ने एक कोडिंग एजेंट को ऐसी मशीन पर पूरी छूट दे दी जिसका कोई रिमोट बैकअप नहीं था। उसने 48,000 फ़ाइलें मिटा दीं—वह भी दो मिनट से भी कम समय में।

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

संगठनों को उन मौकों की पहचान बेहतर ढंग से करनी चाहिए जब मानवीय विवेक सचमुच मायने रखता है—खासकर तब, जब किसी कार्रवाई का बड़ा असर हो सकता हो या उसे पलटना मुश्किल हो। और जब एजेंटों से ग़लतियाँ हों, तो परिवेश को उनके प्रभाव का दायरा सीमित करना चाहिए।

एआई नियतात्मक नहीं, बल्कि संभाव्यतामूलक है

सबसे पहले और सबसे अहम बात यह है कि सॉफ़्टवेयर विकास से प्रत्यक्ष या अप्रत्यक्ष रूप से जुड़े हर कर्मचारी को यह बुनियादी समझ होनी चाहिए कि एआई मॉडल जानकारी को कैसे संसाधित करते हैं। यह कोई छोटा काम नहीं है; इसके लिए टीमों को शिक्षित करने की प्रतिबद्धता चाहिए और अंततः इसे कंपनी-व्यापी लक्ष्य बनना चाहिए।

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

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

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

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

सुरक्षा-सीमाएँ मॉडल में नहीं, बुनियादी ढाँचे में होनी चाहिए

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

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

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

इसीलिए AI सुरक्षा का सार पहुँच और नियंत्रणों में है—ऐसे नियंत्रण जिन्हें मॉडल के सही व्यवहार करने के बजाय परिवेश लागू करे। मानकर चलें कि एजेंट हर दरवाज़ा खोलने की कोशिश करेगा, और सिर्फ़ वही दरवाज़े खुले छोड़ें जिनकी उसे ज़रूरत है। जिस एजेंट ने 48,000 फ़ाइलें मिटाई थीं, उसे प्रतियों पर काम करने और मूल फ़ाइलों को न छूने के लिए कहा गया था। फिर भी उसने मूल फ़ाइलें मिटा दीं। निर्देश नियंत्रण नहीं होते।

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

आख़िरकार, आज जिस अहम मुद्दे पर ध्यान देना ज़रूरी है, वह है डेवलपर के लैपटॉप पर परदे के पीछे क्या होता है। पहले, काम के तरीके का पता लगाना आसान था। डेवलपर कोड लिखते, उसकी समीक्षा करते और उसे जारी करते थे, इसलिए यह पता लगाने का स्पष्ट रास्ता था कि गड़बड़ी किस समय हुई। अब कोई डेवलपर एजेंट को काम का टिकट देकर कह सकता है, ‘इसे ठीक करो।’ अगर यह काम नज़र से ओझल होकर होता है, तो उसका पता लगाने के लिए कुछ नहीं होता। हर कदम का पूरा रिकॉर्ड होना चाहिए: कौन-सा एजेंट चला, उसने कौन-सा मॉडल इस्तेमाल किया, उसे कौन-से प्रॉम्प्ट दिए गए, उसने किन टूल का इस्तेमाल किया और उस समय उसके पास कौन-सी अनुमतियाँ थीं। अलग-अलग लैपटॉप पर चलाने के बजाय एजेंटों को एक केंद्रीय जगह से चलाना, इस लक्ष्य तक पहुँचने का एक तरीका है। अहम बात यह है कि पूरा रिकॉर्ड मौजूद हो।

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

AI ने दुनिया को बड़े पैमाने पर बदल दिया है और कारोबारी प्रक्रियाओं को भी इसके अनुरूप बदलना होगा। उचित सुरक्षा उपाय तय करने के लिए AI प्रक्रियाओं, परीक्षण, समीक्षा चक्रों और ऑडिट चक्रों की बेहतर समझ ज़रूरी है—डेवलपर टीमों के भीतर भी और पूरी कंपनी में भी।