Refund example से समझें exact approval, shared limits, duplicate protection और outcome reconciliation AI workflow को accountable कैसे बनाते हैं।
लेखक
Anichur Rahaman
भाग 3 / 3
ऑपरेशंस में AI, 2026रात में 37 refunds हो गए, कुल 8,400। हर refund assistant की per-action limit 300 से नीचे था; कुल सीमा किसी ने नहीं रखी। यह काल्पनिक failure है, सभी amounts एक ही अनिर्दिष्ट currency में। लेकिन कमी परिचित है: एक request जाँचना पूरे run को control नहीं करता।
Finance lead को पता करना है क्या हुआ और नया exposure रोकना है, साथ में legitimate customers के cases समय पर देखने हैं। “Model को सावधान रहने को कहें” ऐसा control नहीं देता। Assistant message गलत समझे तब भी permissions, approvals और transaction rules काम करें।
यह series का अंतिम लेख है। भाग 1 agent का काम चुनता है, भाग 2 MCP connection समझाता है। अब proposed action को ऐसे process से ले जाएँगे जिसे inspect और test कर सकें।
हर task का owner, permitted records/fields, operation, financial/customer impact और recovery path तय करें। Conversational agent user rights, delegated tool scope और current policy के intersection में काम करे। Unattended service की limited identity, owner और review हों। कोई shared administrator login न ले।
Controls application और downstream services में हों। Menu छिपाना या model से एक sentence मानने को कहना पर्याप्त नहीं। हर tool call, retrieved context, cache, output और log पर access checks लगाएँ। Internal notes और external messages में hostile instructions हो सकती हैं; उनसे नया authority नहीं मिलता।
Realistic loss और legal/business obligations के अनुसार limits चुनें, blog के साफ-सुथरे numbers copy करके नहीं। Per-action और aggregate value, action count, concurrency, data export, runtime और model spend शामिल करें। Technical reversibility एक factor है; reservation बाद में cancel करने से खोई sale वापस नहीं आती।
इस example में agent refund proposal बना सकता है, money release नहीं। Authorised finance reviewer original payment, eligible remaining amount, currency, customer remedy, destination, reason, evidence और proposed change देखता है। Required separation of duties enforce हो; दूसरी AI उस human approval की जगह नहीं ले सकती जिसे policy माँगती है।
Approval को exact action, target, amount, currency, destination और version से validity conditions सहित बाँधें। Relevant change उसे invalid करे। Execute करते समय access, payment eligibility, remaining refundable balance और policy फिर जाँचें, दूसरे pending refunds भी गिनें। अलग draft पुराना approval reuse न करे।
Preview और dry run मदद करते हैं, पर simulation payment result नहीं और future state lock नहीं करता। Reviewer को permitted evidence और unresolved uncertainty दिखाएँ। Queue owner, deadlines, escalation और staffing तय करें। Cap पर owed refund रुके तो timely authorised handling को भेजें, customer rights चुपचाप deny न करें।
Review quality, sampled correctness और delays देखें। High acceptance good judgement का प्रमाण नहीं; zero rejection भी अकेले rubber stamping सिद्ध नहीं करता। Policy अनुमति दे तो unnecessary approvals घटाएँ, लेकिन required approval को बाद के sample check से replace न करें।
मानें declared period और currency में illustrative execution cap 500 है। Committed या reserved exposure 340 है। A और B अलग-अलग approved proposals हैं, हर एक 100 माँगता है। दोनों update से पहले “160 बाकी” पढ़ लें तो pass होकर exposure 540 कर सकते हैं।
Business system shared allowance check और reserve atomically करे। A पहले reserve करे तो exposure 440, शेष 60; B से total 540 होगा, cap पार है, इसलिए authorised exception queue में जाए। Approval execution rule को override नहीं करता।
कौन confirmed, in-flight और uncertain operations गिने जाएँ, period/timezone, जरूरी currency conversion और limits बदलने का अधिकार स्पष्ट हों। Uncertain exposure reconciliation तक reserved रखें; verified failure/cancellation पर policy के अनुसार release करें। A का duplicate retry वही reservation reuse करे, नया 100 न ले। Rate limit अकेली financial cap नहीं है।
Response खोने से पहले provider refund accept कर सकता है। Operation reference store करें और नया request बनाने से पहले existing result query करें। Provider status, amount और local record reconcile करें; submitted, pending, succeeded, failed और unknown अलग outcomes हैं।
Idempotency key एक logical operation के same intended payload वाले retries पहचानती है। Durable local tracking, atomic duplicate protection और सही provider support चाहिए। वही business request fresh key से आए तो key अकेली नहीं पकड़ती; provider retention भी हमेशा permanent नहीं। Stripe idempotency documentation एक provider example है, universal contract नहीं।
केवल eligible transient failures को bounded exponential backoff, jitter, attempt/time budgets और unresolved status owner के साथ retry करें। Permission denial, invalid input और changed proposals में correction या renewed approval चाहिए। Response धीमा हो तो चुपचाप नया payment reference न बनाएँ।
Completed refund one-click undo नहीं है। Cancellation provider, method और state पर निर्भर है; accounting reversal customer से पैसे वापस नहीं खींचता। Stripe refund guidance limited cancellation cases बताती है। गलत completed refund का authorised resolution चाहिए, unapproved नया charge नहीं।
Requester/acting identity, delegated scope, source references/times, proposal/version, policy decision, approver, operation ID, provider reference, result transitions और correction links record करें। उपलब्ध हों तो model/tool/prompt/policy versions रखें; model alias अकेला पुराना response reproduce न कर सके। Concise evidence-based explanation माँगें, hidden chain-of-thought नहीं।
Execution से पहले attempt record और बाद में confirmed outcome जोड़ें; refusals/failures भी रहें। High-impact action से पहले logging unavailable हो तो क्या होगा, design करें। Unauthorised edits रोकें, privileged changes audit करें और जरूरी tamper-evident/retention controls test करें। Append-only नाम से storage unchangeable सिद्ध नहीं होता।
Readers/exports सीमित करें, sensitive content redact करें और retention/deletion policy तय करें। जरूरी evidence के साथ reference पूरा message copy करने से सुरक्षित हो सकता है। अधिक logs हमेशा बेहतर नहीं। Blocked attempts बढ़ना testing/configuration errors भी हो सकता है, हर बार malicious customer नहीं।
Kill switch defined scope में नया काम रोकता है; bank की accepted operation वापस नहीं खींचता। Stop, queued work drain/cancel, relevant access revoke और in-flight outcomes पहचानना test करें। Circuit breaker में explicit signals, accountable responder और controlled recovery हों; alert खुद investigation नहीं करता।
Representative/adverse cases लें: दूसरी store का record ID, supplier file में instruction, stale approval, changed destination, concurrent budget requests, duplicates, provider timeout और unavailable audit। Synthetic या authorised protected data लें। एक injection test pass होने से immunity नहीं मिलती।
Expected permissions और business outcomes compare करें, केवल fluent text नहीं। Languages, partial refunds, abstentions, false blocks और customer deadlines शामिल हों। Sample size risk/rare events पर चुनें; “50 cases” universal standard नहीं। Model, tool, prompt, policy या material data change पर rerun करें; better average critical regression न छिपाए।
एक team, named reviewers और tested stop/recovery process से rollout करें। Verified errors, unauthorised disclosures, unknown outcomes, review turnaround, aggregate exposure और total cost देखें। Provider fail हो तो human-led fallback रखें। Version rollback जहाँ संभव हो software behaviour लौटाता है; business action compensate करना अलग decision है।
NIST AI RMF voluntary risk-management reference है। ISO/IEC 42001 organisational AI management system पर है। Framework का नाम या vendor badge हर answer/workflow safe होने का प्रमाण नहीं; actual scope और evidence देखें।
Legal duties use, jurisdiction और role पर निर्भर हैं। EU AI Act के Article 50 में defined transparency obligations/exceptions हैं; employment/credit का अलग classification चाहिए। हर ordinary ERP action का समान legal logging/disclosure duty न मानें। Deadline पर भरोसा करने से पहले current applicable text जाँचें।
नीचे policy शुरुआती structure है, ready-made legal या spending authority नहीं। Finance, operations और security owners actual limits, reviewers, deadlines और recovery responsibility तय करें।
| Task | Execution से पहले | Recovery की जिम्मेदारी |
|---|---|---|
| Stock answer | Permitted record/field और evidence time | Answer सुधारें; disclosure हो तो investigate |
| Purchase draft | Hidden send/reservation नहीं; buyer exact version जाँचे | Policy से withdraw; actual side effects सँभालें |
| Refund proposal | Eligibility, authorised approval और shared execution limit | Finance provider status reconcile करे; assumed undo नहीं |
| Internal tag/reservation | Downstream effect, scope, volume और permitted reversal | Owner actual recovery confirm करे; one-click promise नहीं |
| Payroll, bank change या accounting correction | अलग approved process; open-ended agent authority नहीं | Named accountable owner और controlled correction |
Goal explainable queue है: proposed, approved, held, executed या uncertain requests; remaining exposure; अगले step का owner। Example में A reconcile होते समय cap B को hold कर सकता है। यह सही implementation और testing पर निर्भर है, हर similar message पर alarm की guarantee पर नहीं।
Agent उपयोगी preparation कर सकता है। Business के पास bounded approval, actual outcome देखने और customer/evidence खोए बिना exception सँभालने का रास्ता रहता है।
समीक्षा: 5 नवंबर 2026। Anichur Rahaman StoreConsole के निर्माता हैं। Retailer, refund totals और allowance example काल्पनिक teaching scenarios हैं।
सीरीज़
ऑपरेशंस में AI, 2026लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
