सुशिल कुमार, Cyara के सीईओ – साक्षात्कार श्रृंखला

Sushil Kumar, Cyara के सीईओ, एक अनुभवी एंटरप्राइज़ सॉफ़्टवेयर कार्यकारी और उद्यमी हैं जिनके पास कृत्रिम बुद्धिमत्ता, DevOps, क्लाउड इन्फ्रास्ट्रक्चर, उत्पाद रणनीति और सॉफ़्टवेयर परीक्षण में 25 से अधिक वर्षों का नेतृत्व अनुभव है। उन्होंने दिसंबर 2025 में Cyara में सीईओ के रूप में शामिल हुए, इसके बाद उन्होंने RelicX.ai के सह‑संस्थापक और सीईओ के रूप में कार्य किया, जहाँ उन्होंने एक जनरेटिव AI‑संचालित, इंटेंट‑आधारित टेस्ट ऑटोमेशन प्लेटफ़ॉर्म बनाया जिसे Harness ने अधिग्रहित किया। इसके बाद उन्होंने RelicX की तकनीक को Harness में एकीकृत करने का नेतृत्व किया और उसकी AI टेस्ट ऑटोमेशन रणनीति को आकार देने में मदद की। अपने करियर के शुरुआती चरण में, कुमार ने Broadcom में DevOps के जनरल मैनेजर, CA Technologies में प्रोडक्ट्स के सीनियर वाइस प्रेसिडेंट के रूप में कार्य किया, और Oracle में 16 से अधिक वर्षों तक वरिष्ठ उत्पाद नेतृत्व भूमिकाएँ निभाई, जहाँ उन्होंने प्रमुख एंटरप्राइज़ सॉफ़्टवेयर व्यवसायों को स्केल करने में मदद की। इन सभी भूमिकाओं में उन्होंने बड़े उद्यमों के लिए AI, क्लाउड, DevOps और ऑटोमेशन प्लेटफ़ॉर्म बनाना और स्केल करना केंद्रित किया है। Cyara में उनका नियुक्ति कंपनी की AI‑संचालित ग्राहक अनुभव आश्वासन क्षमताओं और वैश्विक पहुंच को विस्तारित करने पर केंद्रित है।

Cyara एक ग्राहक अनुभव आश्वासन कंपनी है जो उद्यमों को आवाज़, डिजिटल, मैसेजिंग और संवादात्मक AI चैनलों में ग्राहक इंटरैक्शन का परीक्षण, मॉनिटरिंग और वैधता सुनिश्चित करने में मदद करती है। इसका Cyara Agentic Platform AI‑ड्रिवेन ग्राहक अनुभवों द्वारा उत्पन्न बढ़ती चुनौतियों को संबोधित करने के लिए डिज़ाइन किया गया है, जिसमें गैर‑निर्धारित AI एजेंटों का परीक्षण, भ्रम (हैलुसिनेशन) और व्यवहारिक ड्रिफ्ट का पता लगाना, अनुपालन की वैधता, उत्पादन प्रणालियों की मॉनिटरिंग, और अंत‑से‑अंत ग्राहक यात्राओं का मूल्यांकन शामिल है। यह प्लेटफ़ॉर्म AI एजेंट परीक्षण, उत्पादन मॉनिटरिंग, आवाज़ और टेलीकॉम आश्वासन, डिजिटल‑चैनल परीक्षण, और CX अवलोकन को संयोजित करता है, और वार्षिक रूप से 350 मिलियन से अधिक ग्राहक यात्राओं को 140 से अधिक देशों में फैले वैश्विक पदचिह्न के साथ समर्थन देता है। जैसे ही उद्यम अधिक स्वायत्त AI एजेंटों को ग्राहक‑सम्पर्क कार्यप्रवाहों में तैनात करते हैं, Cyara अपनी तकनीक को एक आश्वासन परत के रूप में स्थापित कर रहा है ताकि यह मूल्यांकन किया जा सके कि ये सिस्टम तैनाती से पहले और बाद में विश्वसनीय, सुरक्षित और सुसंगत रूप से व्यवहार करते हैं।

आपने अपने करियर का अधिकांश भाग एंटरप्राइज़ सॉफ़्टवेयर बनाते और स्केल करते हुए बिताया है, Oracle और CA/Broadcom से लेकर Relicx की स्थापना और अब Cyara का नेतृत्व करने तक। इस अनुभव ने आपके इस विचार को कैसे आकार दिया कि AI एजेंटों का प्रबंधन पारंपरिक सॉफ़्टवेयर की तरह नहीं, बल्कि कार्यबल के सदस्य की तरह किया जाना चाहिए?

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

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

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

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

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

AI एजेंटों के लिए “HR‑जैसा” संचालन मॉडल वास्तव में उद्यम के भीतर कैसा दिखता है, और कंपनियों को पहले कौन से तत्व लागू करने चाहिए?

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

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

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

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

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

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

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

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

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

अब एआई एजेंट बनाना आसान है। कठिन हिस्सा यह साबित करना है कि वह स्वायत्तता के योग्य है।

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

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

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

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

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

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

इसलिए आप परिणाम का मूल्यांकन करते हैं, न कि प्रतिक्रिया का। क्या एजेंट ने समझा कि ग्राहक क्या हासिल करना चाहता था? क्या उसने सही जानकारी का उपयोग किया? क्या उसने यात्रा पूरी की? क्या वह अपनी सीमाओं के भीतर रहा और जब आवश्यक हो तो एस्केलेट किया?

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

गणित को समझने के लिए समय निकालना चाहिए। मूल्यांकन में 99% स्कोर उत्कृष्ट लगता है। यदि एक वर्ष में एक मिलियन वार्तालाप हों, तो यह दस हजार विफल वार्तालाप बनता है।

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

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

विश्वास और शासन को एजेंटिक एआई को स्केल करने में प्रमुख बाधाओं के रूप में बढ़ते हुए उल्लेख किया जा रहा है। क्या आप मानते हैं कि प्रौद्योगिकी उद्यमों की निगरानी क्षमता से तेज़ी से आगे बढ़ रही है, और इससे कौन‑से जोखिम उत्पन्न होते हैं?

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

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

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

जब एक स्वायत्त एजेंट खराब निर्णय लेता है, तो अंततः उत्तरदायित्व किसका होना चाहिए: डेवलपर, वह व्यवसाय इकाई जो इसे लागू कर रही है, मॉडल प्रदान करने वाला विक्रेता, या उपयोग को मंजूरी देने वाला कार्यकारी?

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

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

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

AI एजेंट उन स्थितियों में अप्रत्याशित व्यवहार कर सकते हैं जो परीक्षण के दौरान अनुमानित नहीं थीं। कंपनियों को इन किनारी मामलों का परीक्षण कैसे करना चाहिए इससे पहले कि एजेंट को ग्राहकों, वित्तीय प्रणालियों, या संवेदनशील डेटा तक पहुंच दी जाए?

आपको मान लेना चाहिए कि एजेंट अंततः ऐसी स्थिति का सामना करेगा जिसके लिए वह डिज़ाइन नहीं किया गया था। सवाल यह है कि जब ऐसा होता है तो क्या होता है।

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

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

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

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

जैसे कंपनियां निर्धारक सॉफ़्टवेयर से उन प्रणालियों की ओर बढ़ रही हैं जो तर्क, योजना, संचार और कई अनुप्रयोगों में कार्रवाई करती हैं, आप AI परीक्षण को कैसे विकसित होते देखते हैं?

परीक्षण को यह पूछने से बदलना चाहिए कि क्या सिस्टम ने अपेक्षित उत्तर दिया, से यह पूछने तक कि क्या उसने सही परिणाम हासिल किया।

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

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

जो बदलता है वह यह है कि लॉन्च से पहले का परीक्षण अब प्रक्रिया का अंत नहीं है। उत्पादन ऐसी स्थितियों को उजागर करता है जिन्हें नियंत्रित वातावरण पूरी तरह से दोहर नहीं सकता, और उत्पादन जो दिखाता है वह अगली रिलीज़ से पहले एजेंट के लिए एक परीक्षण बन जाता है। लॉन्च से पहले प्रमाण, उत्पादन में सतर्कता, और दोनों एक-दूसरे को पोषित करते हैं। महीने के छठे में चल रहा एजेंट लॉन्च किए गए एजेंट से मापने योग्य रूप से बेहतर होना चाहिए।

आगे देखते हुए, कौन सी बातें उन संगठनों को अलग करेंगी जो सफलतापूर्वक भरोसेमंद AI कार्यबल बनाते हैं, बनाम वे जो छोटे एजेंटिक AI पायलट चलाते रहने में फंसे रहते हैं?

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

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

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

इनमें से कुछ भी विदेशी नहीं है। यह उसी तरह है जैसे कोई कंपनी पहले से ही उन लोगों का प्रबंधन करती है जिन पर वह वास्तविक जिम्मेदारी के साथ भरोसा करती है।

एक पायलट संगठन के विश्वास पर चल सकता है। स्केल के लिए साक्ष्य की आवश्यकता होती है।

बहुत अच्छा साक्षात्कार देने के लिए धन्यवाद, जो पाठक अधिक जानना चाहते हैं उन्हें Cyara पर जाना चाहिए।