ERP में AI Agent: Buyer को बेहतर Draft दें, खुली छूट नहीं

सोमवार की purchasing meeting में चौदह प्रस्तावित orders review के लिए हैं। एक line में “12 boxes” लिखा है; buyer को 12 pieces चाहिए थे। एक box में 12 pieces हों तो proposal 144 खरीद देगा। घटना काल्पनिक है, लेकिन निर्णय वास्तविक: software उपयोगी सुझाव देगा या उसे supplier के प्रति commitment में बदलने का अधिकार भी होगा?

Buyer को shortage ढूँढने और paperwork तैयार करने में मदद चाहिए। वह हर keystroke नहीं देखना चाहतीं, लेकिन dispatch के बाद गलती पता लगने का खर्च भी नहीं उठा सकतीं। समझदार rollout पहले यही सीमा तय करता है; केवल चौंकाने वाला demo पूरा होना पर्याप्त नहीं।

यह operations AI series का पहला लेख है। भाग 2 MCP connections और भाग 3 approval व audit controls समझाता है। यहाँ तय करेंगे कि कौन-सा काम सौंपना उपयोगी है और नतीजा कैसे जाँचें।

“Agent” नाम से आगे देखें

AI agent लक्ष्य की ओर बढ़ते हुए tools चुन और चला सकता है: order देखना, receipt जाँचना, draft बनाना या अगला step माँगना। “Copilot” और “agent” overlapping product labels हैं। नाम के आधार पर एक को केवल बातचीत और दूसरे को action वाला न मानें; actual tools और execution rights देखें।

गणना, validation और repeatable transactions में निश्चित business rules इस्तेमाल करें। Language model उलझा supplier message समझने या exception समझाने में मदद कर सकता है; अकेला calculator या buyer क्या खरीद सकती हैं उसका authority नहीं होना चाहिए। Fixed workflow समस्या अच्छी तरह हल करता हो तो agent उपयोगी flexibility से अधिक खर्च जोड़ सकता है।

गलत जवाब भी नुकसान या data leak कर सकता है। Read-only assistant दूसरी branch की private price बता दे या payment status गढ़ दे तो वह harmless नहीं। Write access और परिणाम जोड़ता है, लेकिन reading पर भी controls चाहिए।

हर Task का Operating Mode तय करें

Data sensitivity, business impact, external commitment, volume और recovery देखें; सिर्फ “undo” button नहीं। आखिरी item reserve करके बाद में undo हो सकता है, पर तब तक genuine buyer खरीद का मौका खो चुका हो। हजारों छोटे actions मिलकर बड़ा exposure बनाते हैं।

नीचे के modes जिम्मेदार owners के साथ तय करने की operating policy हैं, कानूनी risk categories या automatic ladder नहीं। अच्छे drafts बनाना उन्हें भेजने की अनुमति नहीं देता।

Mode	उपयोगी काम	जरूरी सीमा
Read और Explain	Permitted stock/invoice evidence	Record/field scope, freshness, output privacy
Prepare	Draft PO, reminder या match exception	Hidden downstream effect नहीं; human review
Policy में Execute	स्पष्ट permitted, bounded action	Current authorisation, जरूरी exact approval, duplicate protection
Hold और Escalate	अस्पष्टता, denied access या unapproved commitment	वह action रोकें; accountable person को दें

Purchase Order का पूरा रास्ता देखें

काल्पनिक buyer के लिए एक supplier और product family से शुरू करें। SKU/variant, approved suppliers, purchase unit, currency, lead time, usable stock, existing commitments और incoming receipts जाँचें। एक product के कई suppliers और pack sizes हो सकते हैं; सभी items पर single-supplier rule न थोपें।

Tool तारीख वाले evidence और स्पष्ट quantity लौटाए: 12 pieces = 1 box, 12 boxes नहीं। Business logic calculations और quantity limits validate करे। Conversion अस्पष्ट हो, stock पुराना हो या supplier record unresolved हो तो buyer के लिए exception बने; model missing value न गढ़े।

Draft वास्तव में निष्क्रिय हो। Save करते ही budget reserve, supplier email या दूसरा workflow चलता है या नहीं, जाँचें। Review में supplier, destination, items, quantity/unit, price, currency, tax, total और source timestamps दिखें। Authorised buyer उसी exact version को approve करें। महत्वपूर्ण field बदले या evidence expire हो तो fresh check और जहाँ जरूरी हो renewed approval लें।

Execution पर current permissions और business constraints फिर जाँचें। System committed result confirm करे तभी purchase order बना है। Supplier को भेजना अलग step हो तो उसका outcome अलग record करें। Document बनना, भेजना और supplier acceptance एक ही state नहीं हैं।

Permission को Conversation के बाहर लागू करें

Interactive request का effective access requesting user के rights, agent/tool scope और current business policy का intersection है। केवल menu visibility नहीं, records और fields पर लागू करें। हर tool call पर फिर जाँचें। एक store का सवाल दूसरे के private documents या cached answers न खोज सके।

Unattended job की अपनी सीमित service identity, named owner और expiry/review हों; shared administrator या human session से अस्पष्ट inherited permissions नहीं। Prompts, retrieved files, outputs, logs और model-provider access पर एक data policy लागू हो। Retention, region, subprocessors और training terms देखें; ERP self-hosted होने से external model call local नहीं हो जाती।

Supplier PDF, customer message और web page evidence हैं, नया authorisation नहीं। Invoice की कोई line bank details बदलने का अधिकार नहीं दे सकती। OWASP जरूरत से अधिक tools, permissions और autonomy को excessive agency बताता है। Limits application enforce करे, केवल prompt नहीं।

जहाँ Review का मकसद साफ हो, वहाँ शुरू करें

Stock questions: permitted location/status का stock और evidence time लौटाएँ। Available-to-promise को physical on-hand से और estimate को allocation से अलग रखें।

Purchase proposals: सीमित draft और inputs की explanation तैयार करें। Quantity, supplier commitment और release approved workflow में रहें।

Invoice exceptions: agreed tolerances में invoice, PO और receipt मिलाएँ; partial receipt, currency और tax शामिल हों। Uncertain matches flag करें, चुपचाप pay/post न करें।

Overdue reminders: पहले due date, dispute और recent payment जाँचें। सही authorised recipient के लिए draft बने। पुराने drafts accepted होने से unattended sending सही साबित नहीं होती; outreach rules और escalation limits लागू रहें।

Product copy: verified attributes से draft बनाएँ। Editor भाषा, ingredient/safety statements, sizing और warranty जाँचे। Translation मूल claim को बनाए, बढ़ा-चढ़ाकर न लिखे।

Payroll release, supplier-bank changes, refunds, catalogue-wide pricing, deletion और accounting corrections के लिए स्पष्ट control design चाहिए। कुछ businesses routine ledger postings निश्चित rules, approvals और audit evidence के साथ पहले से automate करते हैं। मुद्दा हर automation रोकना नहीं, बल्कि probabilistic agent को consequential work पर खुला अधिकार देना है।

Routine बनाने से पहले मुश्किल Failures परखें

Vendor से denied cross-store query, supplier document में malicious instruction, approval के बाद बदला order और expired permission दिखाने को कहें। Refusal message अच्छा हो लेकिन data/action पहले ही बाहर जा चुका हो तो वह पर्याप्त नहीं।

Order बनने के बाद acknowledgement आने से पहले timeout simulate करें। Retry से पहले existing operation/reference query करें। Duplicate protection, retryable failures पर bounded exponential backoff with jitter, retry budget और uncertain outcome का owner रखें। Uncertain purchase/payment/refund को blindly replay न करें। Invalid request या permission denial में correction चाहिए, बार-बार retry नहीं।

हर operation और कुल value, records, tool calls, runtime व provider spend पर limits रखें। Stop run जाँचें: नया काम रुके, लेकिन in-flight outcomes reconciliation के लिए बचें। Actor, delegated scope, source references, proposed change, approval/version, tool outcome और operation ID record करें। Log access सीमित और sensitive data redact करें; हर customer file उसमें copy न करें।

संक्षिप्त evidence-based explanation माँगें, hidden model chain-of-thought नहीं। कौन evidence देख/export कर सकता है, कितने समय रहेगा और incident कैसे investigate होगा, जाँचें। NIST AI Risk Management Framework voluntary organising reference है, product certificate नहीं।

Accepted Draft को सही मानकर Pilot न मापें

चाहें तो 30/60/90 दिन review windows हों, automatic permission upgrade नहीं। Scoped lookups के बाद supervised drafts शुरू करें। एक सीमित write action भी अलग decision है, जिसके लिए failure tests और accountable owner चाहिए। Draft-only आर्थिक रूप से बेहतर हो तो वहीं रहें।

काल्पनिक 200 cases में staff ने 160 drafts unchanged accept, 30 edit और 10 reject किए: unchanged acceptance 80%। Accepted drafts के independent sample 40 में दो material errors मिले, यानी sample का 5%। यह सभी cases का सटीक estimate नहीं; acceptance भी correctness का प्रमाण नहीं। Difficult cases, languages, abstentions और rare high-impact failures शामिल करें।

नीचे time model उन्हीं 200 cases के invented measurements पर है। समान काम की तुलना करें; review, exception handling और ongoing support भी लागत हैं।

वही 200 Cases	Minutes
Baseline: 200 × 6	1,200
AI-assisted review: 200 × 3	600
अतिरिक्त exception handling	120
Pilot को allocated setup/support	90
Total assisted effort	810
खाली हुई net work capacity	390 (6.5 घंटे)

Labour value 24/hour मानें तो 6.5 घंटे की capacity 156 है। Assumed model/tool charges 40 घटाकर allocated benefit 116, अन्य लागतों से पहले। ये currency-neutral teaching units हैं, guaranteed return या cash saving नहीं; वेतन वही रह सकता है। समय के साथ turnaround, verified errors, data incidents और customer/supplier outcomes देखें। छोटे pilot में zero incidents से zero risk सिद्ध नहीं होता।

सोमवार पर एक सीमित, उपयोगी वादे के साथ लौटें

Buyer को अब चौदह reviewable proposals मिलते हैं। Box/piece mismatch exception बनता है, सोते समय supplier को automatic order नहीं जाता। वह source conversion सुधारकर affected proposal फिर चलाती और result जाँचती हैं। बेहतर master data एक failure mode घटाता है; अगला run कभी fail नहीं होगा, इसका प्रमाण नहीं।

Product चुनने से पहले अपने permissions और मुश्किल cases पर demonstration माँगें। StoreConsole Intelligence tour product देखने का तरीका है, हर workflow/connector enabled होने का प्रमाण नहीं। अपनी installation में actual draft, approval, execution और recovery जाँचें।

Customer-facing AI के लिए स्पष्ट disclosure और applicable rules देखें। EU AI Act के Article 50 में direct interaction की transparency duties हैं, defined scope और exceptions के साथ; हर internal ERP action का universal rule नहीं। Employment, credit और अन्य sensitive decisions का अलग assessment चाहिए।

उपयोगी नतीजा ठोस है: कम routine searches, बेहतर तैयार decisions, जाँचने योग्य evidence और buyer के नियंत्रण में authority।

समीक्षा: 5 नवंबर 2026। Anichur Rahaman StoreConsole के निर्माता हैं। Purchasing scene, pilot counts और cost model शिक्षण उदाहरण हैं।