एजेंट अब सिर्फ़ सवालों के जवाब नहीं देते, बिज़नेस सिस्टम में काम भी करते हैं। चार स्तरों की जोखिम सीढ़ी, पाँच सुरक्षित शुरुआती इस्तेमाल, वेंडर चेकलिस्ट और 90 दिन के पायलट से तय करें कि क्या सौंपना है।
Author
Anichur Rahaman
सोचिए, दस outlet वाले एक रिटेलर का purchasing हेड सोमवार सुबह 8:40 पर दफ़्तर पहुँचता है। weekend पर vendor की default setting पर चल रहे एक AI agent ने ऐसी stock report पढ़ी, जिसमें एक table में डिब्बा 1 पीस गिना गया था और दूसरी में 12 पीस। नतीजा: उसने 14 purchase order बना दिए, हर एक में ज़रूरत से बारह गुना माल, और पहला order सुबह 6:15 पर supplier को email भी हो गया। (यह एक काल्पनिक उदाहरण है, किसी असली ग्राहक की घटना नहीं।)
वही agent अलग ढंग से सेट होता, तो ये 14 order draft बनकर कतार में रखे रहते। बाहर कुछ नहीं जाता, ख़रीदार एक मिनट में मात्रा देखकर पकड़ लेता, और सोमवार अपनी रफ़्तार से चलता। फ़र्क़ AI की अक़्ल में नहीं था; फ़र्क़ इसमें था कि बीच में इंसान के बिना agent कितना कुछ कर सकता था।
दो साल पहले "ERP में AI" का मतलब था एक chat box, जो आपके data के बारे में सवालों के जवाब दे दे। 2026 में software कंपनियाँ agent बेच रही हैं: ऐसा AI जो सिर्फ़ बात नहीं करता, जानकारी खोजता है, फ़ैसले लेता है और आपके बिज़नेस system के अंदर काम भी कर डालता है। वह purchase order बना सकता है, payment का reminder भेज सकता है, यहाँ तक कि दाम भी बदल सकता है।
यह काम की बात है, लेकिन यहीं से ग़लतियों का स्वभाव बदल जाता है। chatbot का ग़लत जवाब आपका एक मिनट बर्बाद करता है। agent अगर supplier को ग़लत order भेज दे, तो माल का पूरा पैलेट बर्बाद होता है।
इस लेख में एक व्यावहारिक ढाँचा है, जिससे आप तय कर सकें कि आज आपके ERP में AI agent कौन-सा काम ख़ुद कर सकता है, कौन-सा सिर्फ़ draft करे, और किसे अभी हाथ भी न लगाए। अंत में vendor परखने की एक चेकलिस्ट और 30-60-90 दिन का पायलट प्लान है, जिसे आप अगले हफ़्ते ही शुरू कर सकते हैं।
यह "ऑपरेशंस में AI" पर तीन हिस्सों की सीरीज़ का पहला भाग है। दूसरे भाग में बताया गया है कि MCP कैसे AI को बिज़नेस data से सुरक्षित तरीक़े से जोड़ता है: MCP explained। तीसरे भाग में अप्रूवल, audit ट्रेल और human-in-the-loop डिज़ाइन की बात है: AI guardrails।
copilot तभी जवाब देता है जब आप पूछते हैं। वह data पढ़ता है और शब्दों में उत्तर देता है। जवाब ग़लत हो तो आप पहले ही पकड़ लेते हैं, क्योंकि कुछ होने से पहले कोई इंसान उसे पढ़ता है।
agent को एक goal, कुछ tool और उन्हें चलाने की इजाज़त मिलती है। कौन-सा tool कब चलाना है, यह वह ख़ुद तय करता है, चलाता है, नतीजा देखता है और goal पूरा होने तक आगे बढ़ता रहता है। असली मामला ये tool ही हैं: "draft order बनाओ", "stock अपडेट करो", "email भेजो", "refund जारी करो"।
इससे जोखिम की जगह ही बदल जाती है। copilot में जोखिम ग़लत जवाब का है। agent में जोखिम ग़लत कार्रवाई का है — जो तेज़ी से, बड़े पैमाने पर और अक्सर बिना किसी के हर क़दम देखे, बार-बार हो सकती है।
शुरुआती अनुमान भी यही कहते हैं। जून 2025 में Gartner ने अनुमान लगाया कि 2027 के अंत तक agentिक AI के 40% से ज़्यादा प्रोजेक्ट रद्द हो जाएँगे — बढ़ती लागत, अस्पष्ट बिज़नेस वैल्यू और नाकाफ़ी जोखिम-नियंत्रण की वजह से (Gartner की प्रेस release)। उसी release में "agent washing" को लेकर भी चेतावनी है, यानी आम chatbot और automation पर "agent" का नया लेबल चिपका देना। Gartner के अनुमान से, agentिक feature का दावा करने वाले हज़ारों vendorों में असली सिर्फ़ 130 के आसपास थे।
सुरक्षित रहने का सबसे आसान तरीक़ा है "क्या AI यह कर सकता है?" पूछना छोड़कर यह पूछना कि "अगर यह ग़लत हुआ तो क्या होगा?" इस सवाल से agent की कार्रवाइयाँ चार पायदानों की एक सीढ़ी पर बैठ जाती हैं — बेनुक़सान से लेकर पलटने में मुश्किल तक।
| स्तर | agent क्या करता है | ERP में उदाहरण | 2026 में कहाँ फ़िट बैठता है |
|---|---|---|---|
| 1. जवाब | data पढ़ता है, समझाता है, सार बताता है | "अगले 10 दिनों में कौन-से SKU ख़त्म हो जाएँगे?" | सिर्फ़-पढ़ने की पहुँच के साथ खुलकर चलाया जा सकता है |
| 2. draft | ऐसा दस्तावेज़ तैयार करता है जिसे इंसान जाँचता है | purchase order का draft, product विवरण, reminder email | सुरक्षित, बशर्ते इंसान के अप्रूव करने तक कुछ भेजा या पोस्ट न हो |
| 3. पलटी जा सकने वाली कार्रवाई | ऐसा data बदलता है जो साफ़-साफ़ पहले जैसा किया जा सके | order पर टैग लगाना, stock रिज़र्व करना, किसी काम की तारीख़ बदलना | सीमित और अच्छी तरह परखे मामलों में चलेगा — लॉग और अनडू के साथ |
| 4. पैसा या न पलटने वाला | भुगतान, refund, डिलीट, बाहर के लोगों को भेजना | supplier को payment, refund, रिकॉर्ड डिलीट | फ़िलहाल हर बार फ़ैसला इंसान करेगा |
सीढ़ी दो वजहों से काम करती है। पहली, स्तर कार्रवाई से तय होता है, AI से नहीं। "email भेजना" स्तर 2 है अगर इंसान ख़ुद सेंड दबाता है, और स्तर 4 है अगर agent अपने आप आपके ग्राहकों को भेज दे। दूसरी, agent को एक पायदान ऊपर तभी चढ़ने देना चाहिए जब वह नीचे वाले पायदान पर आँकड़ों के साथ अपनी क़ाबिलियत साबित कर चुका हो।
तीन सवाल क्रम से पूछते ही सीढ़ी एक रूटिंग नियम बन जाती है। जो जवाब सबसे पहले लागू हो, काम वहीं पहुँच जाता है।
सबसे अच्छी शुरुआत स्तर 1 और 2 पर होती है। इनमें समय सचमुच बचता है, इंसान प्रक्रिया में बना रहता है और चूक की क़ीमत छोटी होती है। छोटे और मझोले कारोबारों के लिए ये पाँच अच्छे चलते हैं।
"सारे outlet मिलाकर यह आइटम कितना बचा है?" "कल के कौन-से order का पैसा अभी तक नहीं आया?" ऐसे जवाबों के लिए screen और एक्सेल खँगालने में स्टाफ़ के हर हफ़्ते घंटों निकल जाते हैं। लाइव data से पूछने वाला सिर्फ़-पढ़ने वाला agent यह खोजबीन ख़त्म कर देता है। जोखिम कम है, क्योंकि वह कुछ बदल ही नहीं सकता।
agent बिक्री की रफ़्तार, मौजूदा stock और supplier के लीड टाइम देखकर हर supplier के लिए purchase order का draft बनाता है। ख़रीदार मात्रा देखता है, ज़रूरत हो तो बदलता है, फिर अप्रूव करता है। हिसाब और टाइपिंग agent की; समझदारी और पैसे पर पकड़ इंसान की।
supplier का invoice आते ही agent उसे purchase order और माल की प्राप्ति के रिकॉर्ड से मिलाता है, फिर गड़बड़ियाँ चिह्नित करता है: यूनिट प्राइस ज़्यादा, मात्रा मिली नहीं, या एक ही invoice दोबारा आ गया। agent सुझाव देता है, फ़ैसला अकाउंटेंट का। यही जाना-माना थ्री-वे मैच है — थकाऊ काम, जो मशीन के लिए ही बना है।
agent बक़ाया invoice की सूची बनाता है और ग्राहक की भाषा में एक विनम्र reminder का draft लिखता है — भुगतान कितना लेट है और आप ग्राहक को कितने समय से जानते हैं, उसी हिसाब से लहजा तय करता है। कोई पढ़कर भेजता है। जब कई हफ़्तों तक draft बिना बदलाव के मंज़ूर होते रहें, तो पहला नरम reminder agent को ख़ुद भेजने दे सकते हैं।
सैकड़ों product के टाइटल, विवरण और मेटा टेक्स्ट हाथ से लिखना धीमा काम है। agent product की ख़ूबियों (एट्रिब्यूट) से draft बनाता है, और एडिटर एक नज़र डालकर पब्लिश करता है। जिस लिखे हुए का क़ानूनी वज़न हो — जैसे सामग्री की सूची, साइज़ के दावे या वारंटी की शर्तें — वहाँ इंसान को रखें।
कुछ काम इसलिए लुभाते हैं कि वे बार-बार दोहराए जाते हैं। इन्हें फ़िलहाल इंसानों के पास ही रखें, या agent को सिर्फ़ draft की भूमिका दें:
वजह दर्ज है। OWASP प्रोजेक्ट ने LLM एप्लिकेशन के अपने Top 10 में excessive agency को — यानी ज़रूरत से ज़्यादा फ़ंक्शन, अनुमतियाँ या स्वायत्तता पाए AI system को — अलग जोखिम के रूप में दर्ज किया है, और दिसंबर 2025 में एक अलग Top 10 for Agentic Applications जारी किया, जिसमें goal hijacking, tool का दुरुपयोग और बेक़ाबू agent शामिल हैं। ग्राहक का लिखा संदेश, supplier का email या अपलोड किया गया PDF — इनमें agent को निशाना बनाकर निर्देश छिपे हो सकते हैं। agent पैसा हिला सकता हो, तो ये निर्देश ख़तरनाक बन जाते हैं।
agent उतना ही भरोसेमंद है जितना सटीक data वह पढ़ता है और जितने अधिकार उसके पास हैं। दोनों को चालू करने से पहले सुधारना आसान है।
stock की गिनती ग़लत हो तो purchase order का draft भी ग़लत बनेगा — पूरे आत्मविश्वास और शिष्टता के साथ। पायलट से पहले बुनियादी बातें जाँच लें:
agent को उसका अपना account दें — कभी साझा admin login नहीं। कम से कम अधिकार दें: जिन module की ज़रूरत है सिर्फ़ उनमें पढ़ने का हक़, जहाँ draft बनाना है सिर्फ़ वहाँ draft बनाने का हक़, और कुछ नहीं। अगर ERP agent को उसे चलाने वाले user से अलग सीमित नहीं कर सकता, तो इसे गंभीर कमी मानें। आदर्श स्थिति में agent पूछने वाले इंसान की अनुमतियों के साथ काम करता है, ताकि वह उस इंसान से ज़्यादा न कुछ देख सके, न कर सके।
इस सीरीज़ का तीसरा भाग अप्रूवल और audit ट्रेल पर और गहराई से जाता है। फ़िलहाल यह नियम याद रखें: जिस काम की इजाज़त किसी इंसान को नहीं, उसके agent को भी नहीं।
agent washing के दौर में एक शानदार डेमो लगभग कुछ साबित नहीं करता। नीचे के सवाल पूछें, और स्लाइड नहीं, ठोस जवाब माँगें।
अगर आपके ग्राहक सीधे किसी AI से बात करते हैं, तो जहाँ आप बेचते हैं वहाँ के नियम देख लें। यूरोपीय संघ में AI Act की पारदर्शिता संबंधी बाध्यताएँ 2 अगस्त 2026 से लागू हैं; इनके तहत लोगों को बताना होगा कि वे इंसान से नहीं, किसी AI system से बात कर रहे हैं।
पहले दो स्तर असली product में कैसे दिखते हैं, यह देखने के लिए ERP के भीतर बने एक AI असिस्टेंट का यह छोटा टूर देखें, जो लाइव बिज़नेस data से सवालों के जवाब देता है और draft तैयार करता है।
पूरी कंपनी में एक साथ agent न उतारें। एक छोटा, नपा-तुला चक्र चलाएँ और हर अगला क़दम आँकड़ों से तय होने दें।
एक टीम और एक प्रक्रिया चुनें, जैसे purchasing। ऊपर गिनाई data की दिक़्क़तें ठीक करें। सिर्फ़ स्तर 1 चालू करें: सवाल और सार। नापें कि कितना समय बचा, और उससे भी ज़रूरी, कि जवाब कितनी बार ग़लत निकले। स्टाफ़ से हर जवाब पर सही या ग़लत का निशान लगवाएँ।
एक इस्तेमाल के लिए स्तर 2 जोड़ें, जैसे purchase order के draft। हर draft किसी इंसान से होकर गुज़रे। तीन आँकड़े रखें: बिना बदलाव मंज़ूर हुए draft का हिस्सा, बदले गए draft का हिस्सा, और ख़ारिज हुए draft का हिस्सा। ख़ारिज होने की वजहें लिखते जाएँ; वही आपके नियम बनेंगी।
अगर मंज़ूरी की दर ऊँची है और ग़लतियाँ कम, तो एक सीमित मामले में स्तर 3 की एक कार्रवाई की इजाज़त दें — जैसे एक तय रक़म से कम के order पर stock अपने आप रिज़र्व करना। audit लॉग खुला रखें, अनडू को आज़माएँ और किसी भी असामान्य बात पर अलार्म लगाएँ। 90वें दिन ईमानदारी से समीक्षा करें। अगर आँकड़े अच्छे नहीं हैं, तो जहाँ हैं वहीं रुकें। यह भी एक नतीजा है, नाकामी नहीं।
एक सीधा-सा स्कोरकार्ड समीक्षा को ईमानदार रखता है:
अब उसी सोमवार पर लौटें। सीढ़ी लागू हो तो weekend के रन से 14 order supplierों तक नहीं पहुँचते, ख़रीदार की कतार में 14 draft पड़े मिलते हैं। ख़रीदार देखता है कि हर मात्रा बिक्री के इतिहास से बारह गुना है, कुछ ही मिनटों में पूरा batch ख़ारिज करता है और आइटम मास्टर में माप की इकाई ठीक कर देता है। ख़ारिज होने की वजह नियमों में जुड़ जाती है, और अगले weekend का रन साफ़ निकलता है।
agent बेहतर होंगे और सीढ़ी भी खिसकेगी: जिस काम में आज इंसान चाहिए, वह दो साल बाद रोज़मर्रा का होगा, बशर्ते लॉग, अनडू और अप्रूवल के चरण भरोसा जीत चुके हों। सबसे ज़्यादा फ़ायदा उन कारोबारों को होगा जिनका data साफ़ है, अनुमतियाँ सीमित हैं और जिन्हें नापने की आदत है। यही बुनियाद तय करती है कि agent आपके data तक कितनी सुरक्षित तरह पहुँच सकता है — और यही दूसरे भाग का विषय है: Model Context Protocol।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
