ऑपरेशंस में AI के गार्डरेल: मंज़ूरी, ऑडिट ट्रेल और फ़ैसले में इंसान को रखना

रात भर में 37 refund मंज़ूर हो गए, कुल 8,400 डॉलर के, और हर एक सीमा के अंदर था। 12 outlet वाले एक रिटेलर ने पिछले महीने जो support agent चालू किया, वह एक बार में 300 डॉलर तक का refund दे सकता है, और पूरे दिन की कोई हद उसकी setting में कहीं नहीं थी।

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

agent ने ठीक वही किया जिसकी उसके prompt ने इजाज़त दी थी, और prompt ही इकलौती बाड़ थी। prompt एक अनुरोध भर है, और अनुरोध को अनदेखा किया जा सकता है, ग़लत समझा जा सकता है, या किसी अजनबी के चालाक संदेश से पलटा जा सकता है। असली सुरक्षा model के बाहर लगे नियंत्रणों से आती है: permission, सीमाएँ, मंज़ूरी, rate limit और record। model ठीक चले या न चले, ये हर हाल में एक ही तरह काम करते हैं।

यह लेख उन्हीं नियंत्रणों की डिज़ाइन-गाइड है। इसमें है कि किस चीज़ की मंज़ूरी कौन दे, काम दोबारा चल जाए तब भी उसे सुरक्षित कैसे रखें, audit रिकॉर्ड में क्या-क्या होना चाहिए, नुक़सानदेह टेक्स्ट से कैसे बचें, और सितंबर 2026 की शुरुआत में EU, ISO और NIST के नियम एक आम कारोबार से क्या माँगते हैं।

यह “ऑपरेशंस में AI, 2026” श्रृंखला का तीसरा और आख़िरी भाग है। पहले भाग में था कि ERP के भीतर AI agent सुरक्षित रूप से क्या कर सकते हैं। दूसरे भाग में बताया गया कि MCP कैसे AI को कारोबारी data से सुरक्षित तरीक़े से जोड़ता है। यह आख़िरी भाग इस बारे में है कि फ़ैसले की डोर इंसान के हाथ में कैसे रहे।

नियंत्रण मॉडल के बाहर क्यों होने चाहिए

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

नियंत्रण वह है जिसे मॉडल बातों से लाँघ नहीं सकता। refund टूल ख़ुद सीमा से ऊपर की रक़म लौटा देता है। मंज़ूरी का चरण agent छोड़कर आगे नहीं जा सकता। agent के account को payroll छूने का अधिकार ही नहीं है। ये नियम नीरस, तयशुदा कोड हैं, और इसी वजह से कारगर हैं।

यह वैसा ही है जैसा आप नए कर्मचारी के साथ करते हैं: सीमित एक्सेस, ख़र्च की हद और एक मैनेजर जो बड़े फ़ैसलों पर दस्तख़त करे। आप सिर्फ़ उसकी नेकनीयती पर नहीं टिकते, और agent के मामले में भी नहीं टिकना चाहिए।

सिद्धांत 1: न्यूनतम अधिकार, हर agent की अलग पहचान

हर agent को उसके काम के नाम से अलग account दें, जैसे “purchasing-agent”। उसे किसी इंसान का login या साझा admin key कभी उधार न दें। फिर सिर्फ़ उतना permission दें जितना काम के लिए चाहिए।

• पढ़ने की सीमा: सिर्फ़ वे module और field जो ज़रूरी हैं। ख़रीद वाले agent को ग्राहकों के फ़ोन नंबर नहीं चाहिए।
• लिखने की सीमा: draft बना सकता है, ledger में post नहीं कर सकता। tag बदल सकता है, दाम नहीं।
• समय और जगह: तभी चले जब कोई इंसान या तय schedule उसे चालू करे, और जाने-पहचाने system से।
• बजट: ख़र्च की, model इस्तेमाल की और प्रति घंटा कितने काम कर सकता है, इसकी हद।

अलग पहचान का फ़ायदा बाद में भी मिलता है। कुछ अजीब लगे तो log बता देगा कि “purchasing-agent ने यह मारिया की ओर से किया”, और आप बाक़ी किसी को रोके बिना बस उसी एक पहचान को बंद कर सकते हैं।

सिद्धांत 2: मंज़ूरी इस पर निर्भर है कि काम पलटा जा सकता है या नहीं, और रक़म कितनी है

पहले भाग में agent के कामों को चार स्तरों में बाँटा गया था, जवाब देने से लेकर पैसे की ऐसी हरकत तक जिसे पलटा नहीं जा सकता। व्यवहार में एक दूसरा पैमाना भी चाहिए: काम कितना बड़ा है? 8 डॉलर का refund और 8,000 डॉलर का refund एक ही तरह के काम हैं, पर जोखिम एक जैसा नहीं।

दोनों पैमानों को मिलाकर एक मैट्रिक्स बनाइए और उसे लिख लीजिए। नीचे की रक़में सिर्फ़ उदाहरण हैं। अपनी सीमाएँ इस हिसाब से तय कीजिए कि ग़लती की क़ीमत कितनी पड़ेगी, इस हिसाब से नहीं कि तालिका कितनी सुघड़ दिखती है।

matrix तब काम करता है जब तीन आदतें हों। काम किस खाने में आएगा, यह code से तय करें, model से पूछकर नहीं कि उसे वह कितना जोखिम भरा लगता है। मंज़ूरी देने वाले के पास काम proposal बनाकर भेजें, ताकि साफ़ रहे कि अभी कुछ हुआ नहीं है। और मंज़ूरी के क्षण पर रक़म दोबारा जाँचें, क्योंकि अनुरोध और क्लिक के बीच cart या draft बदल सकता है।

matrix को एक काम के पूरे रास्ते में रख दें तो वह चार फाटकों वाला flow बन जाता है। हर निकास, इनकार समेत, एक record छोड़ता है।

सिद्धांत 3: maker-checker, preview और dry run

अकाउंटेंट पीढ़ियों से maker-checker का नियम मानते आए हैं: जो payment तैयार करता है, वह उसे जारी नहीं करता। agent पर भी यही बँटवारा लागू करें। agent हमेशा maker है। checker इंसान है, और सबसे जोखिम वाले खानों में दो इंसान। पैसे के मामले में एक agent कभी दूसरे agent के काम का checker नहीं होना चाहिए।

checker वही जाँच सकता है जो उसे दिखे, इसलिए हर प्रस्ताव के साथ साफ़ preview चाहिए:

• ठीक-ठीक क्या बदलेगा, पहले और बाद की शक्ल में।
• agent यह क्यों सुझा रहा है, दो-तीन सीधे वाक्यों में, इस्तेमाल किए गए record के link के साथ।
• इसकी लागत क्या है, और क्या वापस नहीं हो सकेगा।
• जहाँ संभव हो “dry run” का नतीजा: वही काम किसी copy पर या simulation में चलाकर, बिना save किए नतीजा दिखाना।

approval की थकान से सावधान रहें। किसी से रोज़ दो सौ item approve करने को कहेंगे तो वह बिना देखे क्लिक करता जाएगा। approval उन्हीं खानों के लिए रखें जो मायने रखते हैं, कम जोखिम वाले कामों को दिन के आख़िर की sample review में इकट्ठा करें, और देखते रहें कि approver कितनी बार बदलाव या अस्वीकार करते हैं। जो approval seal कभी अस्वीकार नहीं करती, वह कामयाबी नहीं, चेतावनी है।

हर काम को दोहराए जाने पर भी सुरक्षित बनाइए

agent दोबारा कोशिश करते हैं। network timeout हो जाता है, job restart होते हैं, और model कभी-कभी एक ही tool दो बार बुला लेता है। “purchase order बनाओ” दो बार चल गया तो आपने दो बार ख़रीद लिया।

इसका इलाज idempotency key है: हर प्रस्तावित काम के साथ जुड़ा एक अनोखा reference। system याद रखता है कि किन key का काम पूरा हो चुका है, और वही key दोबारा आए तो चुपचाप उसे छोड़ देता है। supplier के duplicate invoice, double refund और बार-बार हुए stock transfer, यह एक आदत ही सब रोक देती है।

इसके साथ तीन और brake रखें:

• rate limit: जैसे हर agent के लिए प्रति घंटा ज़्यादा से ज़्यादा 20 order edit। तब loop में फँसा agent आफ़त बनने से बहुत पहले अपने आप रुक जाता है।
• circuit breaker: अगर error या rejection की दर चढ़ने लगे, तो agent ख़ुद रुककर किसी इंसान को सूचित करे।
• kill switch: साफ़ नाम वाला एक control जो एक agent या सभी agent को तुरंत रोक दे। इसे किसी शांत दिन पर test करके रखें। यह पता चलना कि वह काम नहीं करता, ठीक उस घड़ी सबसे बुरा है जब उसकी ज़रूरत हो।

audit record: हर काम के लिए क्या दर्ज करें

कुछ ग़लत होने पर पाँच सवालों के जवाब जल्दी चाहिए: किसने माँगा, agent ने क्या देखा, क्या किया, किस model ने फ़ैसला लिया, और किसने approval दी। अगर log पाँचों का जवाब नहीं दे सकता, तो investigation नहीं हो सकती, और आप किसी customer, auditor या regulator को यह साबित भी नहीं कर सकते कि क्या हुआ था।

काम के लायक़ log और दिखावटी log में तीन बारीकियों का फ़र्क़ होता है। record काम proposal होते समय लिखें, सिर्फ़ ख़त्म होने पर नहीं, ताकि failed और rejected काम भी दिखें। model का नाम और version prompt या policy के version के साथ रखें, क्योंकि दोनों में से कुछ भी बदले तो behavior बदलता है। और record ऐसे रखें कि tampering पकड़ में आए: सिर्फ़ append-only storage, या कम से कम ऐसा नियम कि agent और उसके administrator history नहीं बदल सकते।

निजता का भी ध्यान रखें। जिस लॉग में ग्राहकों के पूरे संदेश जमा हों, वह ख़ुद संवेदनशील data है। जहाँ हो सके रेफ़रेंस और छोटे अंश रखें, रखने की अवधि तय करें, और पढ़ने का अधिकार सीमित रखें।

hostile text से बचाव

दूसरे भाग में prompt injection की बात थी: email, review या product विवरण में छिपा ऐसा लेख जो model से वह करवाए जो मालिक ने कभी चाहा नहीं। LLM application के लिए OWASP Top 10 इसे पहले jeopardy के रूप में रखता है। कोई filter इसे पूरी तरह नहीं हटाता, इसलिए यह मानकर design करें कि कुछ injection कामयाब होंगे ही।

1. बाहर से जो कुछ agent पढ़ता है, जैसे email, web page, review और upload की गई file, उसे untrusted data मानें, कभी directive नहीं।
2. बातचीत में untrusted content हो तो risky tool हटा दें या अलग से verification माँगें। customer का email पढ़ने वाले चरण में ही agent refund जारी न कर सके।
3. sensitive data और outbound channel अलग रखें। जो agent सारे customer पढ़ सकता है और किसी को भी email भी भेज सकता है, उसे बहकाकर आपकी customer list बाहर भिजवाई जा सकती है।
4. approver को proposal के बग़ल में मूल source text भी दिखाएँ, ताकि out-of-place directive इंसान की नज़र में आ जाए।
5. blocked attempt को log करें और देखते रहें। count बढ़ना बताता है कि कोई probe कर रहा है।

कुछ भी बदलने से पहले test कीजिए

model, prompt, tool और आपका अपना data, सब बदलते हैं, और इनमें से कोई भी agent का behavior चुपचाप पलट सकता है। इसलिए launch करने से पहले एक छोटा evaluation set बनाइए: पचास से कुछ सौ real या realistic case, हर एक के expected answer के साथ। उसमें tricky case भी रखें, जैसे duplicate order, missing data, angry customer और injection attempt।

model, prompt या permission बदलते ही set फिर चलाइए। पिछली बार के result से मिलान कीजिए, और change तभी deploy कीजिए जब metric वही रहें या improve हों। यह software की regression testing वाला ही विचार है, बस behavior पर लागू।

launch होने के बाद हर हफ़्ते कुछ metric देखिए: proposal acceptance rate, rejection reason, action blocked by policy, cost per action, और customer या supplier तक पहुँची error। और rollback की योजना पहले से बनाइए। हर तरह के action के लिए जानिए कि उसे कैसे undo करेंगे, कौन करेगा और कितना समय है। जवाब अगर “इसे undo नहीं किया जा सकता” हो, तो वह काम सिर्फ़ human-only खाने का है।

सितंबर 2026 में नियम आपसे क्या माँगते हैं

बढ़ते कारोबार में AI के ज़्यादातर ऑपरेशनल इस्तेमाल, जैसे stock के सवाल, ख़रीद के draft और invoice मिलान, EU AI Act में “उच्च-जोखिम” नहीं गिने जाते। इसका मतलब यह नहीं कि करने को कुछ नहीं है। सितंबर 2026 की शुरुआत में स्थिति यह है।

ढाँचा	स्थिति	आपके लिए मतलब
EU AI Act, पारदर्शिता (अनुच्छेद 50)	2 अगस्त 2026 से लागू। बाज़ार में पहले से मौजूद system के AI-निर्मित कंटेंट को चिह्नित करने के मामले में ही 2 दिसंबर 2026 तक थोड़ी अतिरिक्त मोहलत है।	जब कोई AI से बात कर रहा हो तो उसे बताइए, और जहाँ ज़रूरी हो कृत्रिम कंटेंट पर लेबल लगाइए।
EU AI Act, उच्च-जोखिम system (अनुलग्नक III)	मई 2026 में सहमत और जून 2026 में पार्लियामेंट व काउंसिल से पारित डिजिटल ओम्निबस ऑन AI ने तारीख़ 2 अगस्त 2026 से खिसकाकर 2 दिसंबर 2027 कर दी है। EU उत्पाद-सुरक्षा क़ानून के दायरे वाले उत्पादों की तारीख़ 2 अगस्त 2028।	लागू तब होता है जब AI भर्ती, कर्मचारी मूल्यांकन, क्रेडिट या ज़रूरी सेवाओं तक पहुँच पर फ़ैसला करे। इसमें लॉग, इंसानी निगरानी और रिकॉर्ड चाहिए।
ISO/IEC 42001:2023	दिसंबर 2023 में प्रकाशित। AI के लिए प्रमाणन-योग्य मैनेजमेंट-system स्टैंडर्ड।	वैकल्पिक। नीति, भूमिकाओं, जोखिम समीक्षा और सुधार के लिए उपयोगी ढाँचा, और बड़े ग्राहकों के सामने भरोसे का संकेत।
NIST AI Risk Management Framework 1.0	जनवरी 2023 में प्रकाशित, जुलाई 2024 में जेनरेटिव AI प्रोफ़ाइल के साथ। स्वैच्छिक।	उधार लेने लायक़ चार काम: govern, map, measure, manage।

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

कम जोखिम वाले इस्तेमाल को भी दो चीज़ें चाहिए: जब कोई AI से बात कर रहा हो तो उसे बताइए, और रिकॉर्ड रखिए। स्टैंडर्ड ख़ुद देखने हों तो ISO/IEC 42001 का ISO पेज और NIST AI Risk Management Framework देखें। EU के बाहर हर देश के नियम अलग हैं और बदलते रहते हैं, इसलिए जहाँ आप बेचते हैं वहाँ के नियम जाँच लें।

AI एक्शन पॉलिसी जिसे आप सीधे उठा सकते हैं

अपने नियम एक पन्ने पर रखिए, जिसे कर्मचारी, vendor और ऑडिटर सब पढ़ सकें। नीचे उदाहरण-मानों के साथ एक template है। हर संख्या अपने जोखिम के हिसाब से बदलिए।

काम	agent क्या कर सकता है	सीमा	मंज़ूरी	पलटना
stock और order के सवालों के जवाब	सिर्फ़ पढ़ना	अपनी भूमिका का data	ज़रूरी नहीं	ज़रूरत नहीं
ख़रीद order का draft	draft बनाना	रोज़ 20 draft	भेजने से पहले ख़रीदार मंज़ूर करे	draft हटाना
order पर टैग या रिज़र्व	बदलना	200 डॉलर से कम के order, प्रति घंटा 50	रोज़ सैंपल-समीक्षा	एक क्लिक में वापस
ग्राहक के जवाब का draft	draft बनाना	refund या मुआवज़े का वादा नहीं	agent अकेले कुछ नहीं भेजेगा	भेजा ही नहीं गया
refund	सिर्फ़ प्रस्ताव	1,000 डॉलर तक एक मंज़ूरीकर्ता, उससे ऊपर दो	हमेशा इंसान	payment प्रोवाइडर के ज़रिए वापसी
supplier को भुगतान, payroll, ledger पोस्टिंग, डिलीट	कुछ नहीं	अनुमति नहीं	सिर्फ़ इंसान	लागू नहीं

पॉलिसी की हर तिमाही और हर घटना के बाद समीक्षा कीजिए। सबूत साथ दें तो एक पंक्ति को एक पायदान ऊपर ले जाइए। सिर्फ़ इसलिए कभी नहीं कि किसी vendor की स्लाइड ऐसा कहती है।

launch checklist

1. हर agent के लिए अलग identity बनाइए, उतने ही narrow permission के साथ जितने में काम चल जाए।
2. approval matrix और action policy लिखिए, और owner व finance lead से sign करवाइए।
3. limit और approval prompt में नहीं, system में enforce कीजिए।
4. idempotency key, rate limit और परखा हुआ kill switch जोड़िए।
5. request, agent, model version, input, action, decision, approval, result और undo reference log में रखिए।
6. injection attempt समेत एक evaluation set बनाइए, और हर change पर उसे दोबारा चलाइए।
7. एक team के साथ pilot कीजिए, हर हफ़्ते log देखिए, और evidence मिलने पर ही access बढ़ाइए।

अब उसी मंगलवार पर लौटिए। ये नियंत्रण होते तो हर refund किसी इंसान के इंतज़ार में पड़ा प्रस्ताव होता, refund की रोज़ाना रक़म की हद पहले कुछ के बाद ही सिलसिला रोक देती, और जब प्रस्ताव एक जैसे दिखने लगते तो सर्किट ब्रेकर agent को रोक देता। फ़ाइनेंस प्रमुख को मिलता एक रोक का alert और जाँचने लायक़ छोटी-सी कतार, 8,400 डॉलर की मुसीबत नहीं। agent पहले जितना ही सक्षम है। बस उसकी सबसे बुरी रात अब एक दायरे में बँधी है।

Key takeaway

• Guardrail model के बाहर रहें: permission, सीमाएँ और approval system से enforce हों, prompt में माँगी न जाएँ।
• हर agent को अलग, narrow identity दें, और approval का फ़ैसला reversibility और amount, दोनों को साथ रखकर करें।
• साफ़ preview के साथ maker-checker अपनाइए, approval risky cell के लिए रखिए, और approval की थकान पर नज़र रखिए।
• काम idempotent बनाइए, और rate limit, circuit breaker और एक परखा हुआ kill switch जोड़िए।
• Log कीजिए कि किसने माँगा, agent ने क्या देखा, क्या किया, किस model version ने काम किया और किसने approval दी।
• Operation के ज़्यादातर इस्तेमाल EU AI Act में high-risk नहीं हैं, और high-risk की तारीख़ दिसंबर 2027 तक खिसक गई है, फिर भी transparency और good record अब भी लागू हैं।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।