आपके एआई एजेंटों को बेहतर प्रॉम्प्ट नहीं, कार्य-विवरण चाहिए

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

उसी कंपनी से पूछिए कि उसका नया इनवॉइस एजेंट क्या-क्या कर सकता है, तो अक्सर आपको किसी प्रॉम्प्ट का स्क्रीनशॉट दिखाया जाएगा।

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

प्रॉम्प्ट काम क्यों नहीं कर सकता

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

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

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

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

रद्द होती परियोजनाएँ प्रबंधन की समस्या लगती हैं

Gartner का अनुमान है कि 2027 के अंत तक एजेंटिक एआई परियोजनाओं में से 40% से अधिक रद्द कर दी जाएँगी; इसके कारणों में बढ़ती लागत, अस्पष्ट व्यावसायिक मूल्य और अपर्याप्त जोखिम नियंत्रण शामिल हैं।

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

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

प्रबंधन के पुराने औज़ारों को एजेंटों पर लागू करना

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

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

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

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

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

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

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

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

घटना की समीक्षा में क्या सवाल पूछे जाएँगे

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

अगर ईमानदार जवाब हों—“एक प्रॉम्प्ट”, “किसी को याद नहीं”, “घंटों” और “स्पष्ट नहीं”—तो बेहतर मॉडल भी आपको नहीं बचा पाता।

फ़ायदा आख़िरकार कहाँ मिलता है

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

अंतर मॉडल के इर्द-गिर्द बनी प्रबंधन प्रणाली का है। यह प्रणाली धीरे-धीरे बनती है और इसे ज़्यादातर वे लोग तैयार करते हैं जिन्हें पहले संगठन चलाने का अनुभव रहा हो।

अगर आपका सबसे नया एजेंट कल अपने अधिकार-क्षेत्र से बाहर चला जाए, तो क्या आपकी कंपनी में किसी को इसका पता चलेगा? और क्या आप किसी ऑडिटर को लिखित रूप में दिखा पाएँगे कि उसकी सीमा कहाँ तय थी?