YouMind
साइन इन करें

क्या AI ऑब्ज़र्वेबिलिटी, मूल्यांकन और आश्वासन विलीन होंगे?

@asad0801
अंग्रेज़ी11 अक्टू॰ 2026
379K
90
19
14
7

TL;DR

यह लेख AI ऑब्ज़र्वेबिलिटी, मूल्यांकन और आश्वासन के विलीन होते बाजारों का विश्लेषण करता है, सत्या नडेला के शासन सिद्धांतों का उल्लेख करते हुए और AI एजेंट्स के लिए स्वतंत्र सत्यापन की आवश्यकता पर बहस करते हुए।

नडेला के 7 सिद्धांत, Dynatrace की $915M Arize डील, और इस बात पर CIOs, फाउंडर्स व निवेशकों के बीच बहस कि AI एजेंट्स की जांच कौन करेगा। अक्टूबर 2026 को अपडेट किया गया।

एक AI एजेंट रिफंड की पूरी प्रक्रिया एकदम सही तरीके से समझा सकता है, लेकिन फिर भी पैसा गलत अकाउंट में भेज सकता है। चैट ट्रांसक्रिप्ट पढ़ने में तो बढ़िया लगता है, लेकिन लेनदेन गलत हो जाता है।

इस तरह की गड़बड़ियों को पकड़ने के लिए तीन तरह के प्रोडक्ट मौजूद हैं: observability, evaluation और assurance। वेंडर्स ने इन्हें आपस में मिलाना शुरू कर दिया है। खरीदार भी ऐसा करेंगे या नहीं, यह अभी तय नहीं है। दूसरा सवाल भी उतना ही खुला है: जांच कौन करेगा, और "स्वतंत्र" (independent) किसे माना जाए?

AI अब सिर्फ सवालों के जवाब देने से आगे बढ़कर काम करने लगा है। Gartner का अनुमान है कि 2028 तक एक-तिहाई एंटरप्राइज़ सॉफ़्टवेयर ऐप्लिकेशन में agentic AI होगा, जबकि 2024 में यह आंकड़ा 1% से भी कम था। ये एजेंट कोड लिख और सबमिट कर सकते हैं, पैसा ट्रांसफर कर सकते हैं और ग्राहकों से बात कर सकते हैं — और ज्यादातर मामलों में किसी इंसान को रियल-टाइम में इनकी निगरानी करने की जरूरत नहीं पड़ती।

जब सॉफ़्टवेयर सिर्फ जवाब देता था, तब मुख्य सवाल यही होता था कि जवाब सही है या नहीं। एजेंट्स कई नए सवाल खड़े करते हैं: इसने क्या किया, क्या वह सही था, क्या कोई इसके पीछे जिम्मेदारी ले सकता है, और क्या इसे रोका जा सकता है? CIOs के लिए ये सवाल इंजीनियरिंग से उतने ही जुड़े हैं जितने AI governance और risk management से।

आज तीन मार्केट इसके कुछ हिस्सों को कवर करते हैं:

  • AI observability रिकॉर्ड करता है कि AI ने क्या किया।
  • AI evaluation मापता है कि उसने वह काम कितनी अच्छी तरह किया।
  • AI assurance सबूतों, कंट्रोल्स और उनकी सीमाओं को एक साथ लाता है ताकि कोई इंसान जिम्मेदारी के साथ फैसला ले सके। UK सरकार इसे भरोसेमंदता को मापने, परखने और बताने की प्रक्रिया बताती है।

2025 में AI observability $1.25 बिलियन का मार्केट था, और इसी रिसर्च के मुताबिक evaluation और quality assurance इसमें सबसे तेजी से बढ़ेंगे। Dynatrace ने 1 अक्टूबर 2026 को Arize का अधिग्रहण पूरा किया, जो evaluation और observability को मिलाने वाली $915 मिलियन की डील थी। Cisco ने मई में Galileo की डील पूरी की। 10 अक्टूबर को, Satya Nadella ने AI पर भरोसा करने के सात सिद्धांत प्रकाशित किए, जो इन तीनों मार्केट को छूते हैं।

इस आर्टिकल के बाकी हिस्से में हम जानेंगे कि AI यहां तक कैसे पहुंचा, Nadella ने क्या सुझाया, और पांच संयुक्त आवाजों के बीच इस बात पर बहस कि मार्केट किस दिशा में जा रहा है।

रूल्स से AI एजेंट्स तक: भरोसा करना मुश्किल क्यों हुआ

चार चरणों में एक सरलीकृत इतिहास। हर चरण ने मशीन को ज्यादा सक्षम बनाया, लेकिन उसे समझाना उतना ही कठिन हो गया।

  1. रूल्स (लगभग 1950 से 2000 के दशक तक)। ज्यादातर सॉफ़्टवेयर ऐप्लिकेशन हाथ से, स्टेप-बाय-स्टेप लिखे जाते थे। उनमें बग्स खूब होते थे, लेकिन कोई इंजीनियर कोड खोलकर वह लाइन ढूंढ सकता था जिसने गड़बड़ी की थी।
  2. पैटर्न्स (2010 का दशक)। Deep learning के साथ, मशीनों ने इमेज और स्पीच रिकग्निशन जैसे कामों के लिए रूल्स की जगह उदाहरणों से सीखना शुरू किया। लॉजिक किसी ने नहीं लिखा था। ये सिस्टम ज्यादातर चीजों को लेबल, रैंक और रिकमेंड करते थे, और आउटपुट का क्या करना है यह इंसान या आम सॉफ़्टवेयर तय करते थे।
  3. चैट (2022 से 2024)। चैटबॉट्स लिख सकते थे, सारांश बना सकते थे और बहस कर सकते थे। वे अक्सर गलत होते थे, लेकिन कोई इंसान आमतौर पर उस पर अमल करने से पहले जवाब पढ़ लेता था।
  4. एजेंट्स (2025 से आगे)। एजेंट्स क्लिक करते हैं, टाइप करते हैं, खरीदते हैं, कोड लिखते हैं और डिप्लॉय करते हैं। लैब्स उन्हें सिमुलेटेड ऑफिस, ब्राउज़र और कोडबेस में कामों का अभ्यास कराकर ट्रेन करती हैं। कुछ एजेंट्स बिना किसी इंसानी चेकिंग के लंबे समय तक चलते रहते हैं।

चैट वाले दौर में, गलत जवाब का मतलब आमतौर पर बस दोबारा पढ़ना होता था। एजेंट वाले दौर में, एक गलत कदम से पैसा, डेटा या ग्राहक का नुकसान हो सकता है।

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

Nadella पुरानी स्थिति को इस तरह बताते हैं: पारंपरिक सॉफ़्टवेयर में, "हमारे पास ऐसे टूल और क्षमता थी कि व्यवहार को किसी खास कोड पाथ से जोड़कर देख सकें।" आज के मॉडल्स में, कोई भी किसी खास फैसले के पीछे की ट्रेनिंग डेटा या वेट्स की ओर उंगली नहीं उठा सकता। ये तीन मार्केट इसी खाई को पाटने की कोशिश कर रहे हैं।

Satya Nadella का AI governance फ्रेमवर्क: AI एजेंट्स पर भरोसा करने के 7 सिद्धांत

10 अक्टूबर 2026 को, Nadella ने अपने ब्लॉग पर "Models as Insider Risks in the Super Intelligence Era" प्रकाशित किया। उनका मुख्य सुझाव यह है कि "हमें इंटेलिजेंस की सप्लाई को उस पर अधिकार से अलग करना होगा।"

वे एक सक्षम मॉडल की तुलना व्यापक एक्सेस वाले कर्मचारी से करते हैं। चिंता यह नहीं है कि मॉडल दुर्भावनापूर्ण है। महत्वपूर्ण सिस्टम्स तक जिस किसी की पहुंच होती है, वह गलती कर सकता है या उससे समझौता किया जा सकता है, इसलिए आप सीमित करते हैं कि वह कहां तक पहुंच सकता है, रिकॉर्ड करते हैं कि वह क्या करता है, और उसे रोकने की क्षमता अपने पास रखते हैं। उनके शब्दों में, "अगर इसे देखा (observe) नहीं जा सकता, तो इस पर भरोसा नहीं किया जा सकता!"

वे इन्हें सात "observability principles" कहते हैं। एक साथ पढ़ें तो ये एजेंट्स के लिए एक AI governance फ्रेमवर्क की तरह काम करते हैं। नीचे हर सिद्धांत को सरल शब्दों में बताया गया है, उसके बाद मेरी तरफ से उन मार्केट्स की मैपिंग दी गई है जो आज इसे कवर करते हैं।

  1. मॉडल विविधता: कोई भी एक AI अपना काम खुद नहीं चेक करता या अकेले कोई अहम फैसला नहीं लेता। आज का मार्केट: evaluation।
  2. सब कुछ observe करें: हर महत्वपूर्ण कार्रवाई ऐसा छेड़छाड़-रोधी (tamper-proof) सबूत छोड़ती है जिसे इंसान पढ़ सके। आज का मार्केट: observability।
  3. सत्यापन योग्यता (Verifiability): पूरे सिस्टम की लगातार टेस्टिंग होती है, जिसमें हमले, विफलताएं और edge cases शामिल हैं। आज का मार्केट: evaluation और assurance।
  4. स्वतंत्र कंट्रोल्स: AI क्या एक्सेस कर सकता है, इसके नियम AI से बाहर होते हैं, जहां वह उन्हें बदल नहीं सकता। आज का मार्केट: ज्यादातर security और access tools, हालांकि AI प्लेटफॉर्म्स में guardrails दिखने लगे हैं।
  5. स्वतंत्र ऑडिट क्षमता: AI के व्यवहार के सबूत उस AI से अलग रखे जाते हैं जिसे चेक किया जा रहा है। आज का मार्केट: assurance।
  6. कंटेनमेंट (Containment): कोई अधिकृत व्यक्ति काम के बीच में मॉडल को रोक या बंद कर सकता है। आज का मार्केट: ज्यादातर runtime और security tools।
  7. घटना का खुलासा: जब यह फेल होता है, तो प्रभावित लोगों को बताया जाता है और सबक साझा किए जाते हैं। आज का मार्केट: एक कंपनी प्रैक्टिस, जिसे observability रिकॉर्ड्स का सहारा मिलता है।

कोई भी एक मार्केट इन सात में से दो से ज्यादा को कवर नहीं करता। स्वतंत्र कंट्रोल्स और कंटेनमेंट ज्यादातर इन तीनों से बाहर, security और runtime tools के साथ हैं। एक साथ देखें तो ये सिद्धांत इन तीनों मार्केट्स के कुल आकार से भी बड़े सिस्टम का वर्णन करते हैं।

उनकी आखिरी पंक्ति है: "सबसे भरोसेमंद Super Intelligence सिस्टम वह नहीं होगा जिसके मॉडल पर हम सबसे ज्यादा भरोसा करते हैं। वह वह होगा जो हमें मॉडल पर सबसे कम भरोसा करने में सक्षम बनाएगा।"

मॉडल पर जितना कम हो सके भरोसा करने के लिए यह जरूरी है कि उसने क्या किया इसका रिकॉर्ड हो (observability), उसे परखने का कोई तरीका हो (evaluation), और ऐसे सबूत हों जिनके पीछे कोई इंसान खड़ा हो सके (assurance)। इसके लिए दो और चीजें भी चाहिए जो इन मार्केट्स ने ज्यादातर security और runtime tools पर छोड़ दी हैं: ऐसे कंट्रोल्स जिन्हें मॉडल बदल न सके, और इंसान के पास उसे रोकने का कोई तरीका।

AI observability बनाम evaluation बनाम assurance: आज का मार्केट

एक AI एजेंट को नए भर्ती हुए ड्राइवर की तरह सोचें।

  • Observability डैशकैम है। यह हर मोड़, स्टॉप और बाल-बाल बचाव को रिकॉर्ड करता है, और "AI ने क्या किया?" का जवाब देता है। यह मुख्य रूप से उन टीमों को बेचा जाता है जो सिस्टम्स को चालू रखती हैं।
  • Evaluation ड्राइविंग टेस्ट है। यह स्कोर करता है कि ड्राइवर तय परिस्थितियों को कैसे संभालता है और "यह कितना अच्छा है?" का जवाब देता है। इसे मुख्य रूप से AI प्रोडक्ट्स बनाने वाले इंजीनियर खरीदते हैं, और अब QA टीमें भी।
  • Assurance इंस्पेक्शन रिपोर्ट है। यह पहली यात्रा से पहले और ड्राइविंग के दौरान यह तय करने के लिए जरूरी सबूत इकट्ठा करता है कि कार और ड्राइवर सड़क के लिए फिट हैं या नहीं। यह जवाब देता है कि "क्या इसके पीछे खड़े होने के लिए पर्याप्त सबूत हैं?" कोई भी इंस्पेक्शन यह साबित नहीं करता कि कार कभी क्रैश नहीं होगी; एक अच्छी रिपोर्ट बताती है कि क्या चेक किया गया, क्या मिला, और क्या अभी भी अनजान है। यह तीनों में सबसे कम विकसित है, और फिलहाल यह काम quality, risk और compliance टीमों में बंटा हुआ है।

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

AI observability और evaluation प्लेटफॉर्म्स के हालिया अधिग्रहण:

Dynatrace का कहना है कि Arize डील evaluation और observability को एक साथ लाती है ताकि टीमें लॉन्च से पहले AI को चेक कर सकें और बाद में उसे भरोसेमंद बनाए रख सकें। Cisco Galileo को शुरुआती evaluation से लेकर प्रोडक्शन मॉनिटरिंग और guardrails तक कवर करने वाला बताता है।

ये डील्स दिखाती हैं कि वेंडर्स प्रोडक्ट्स को मिला रहे हैं। लेकिन ये अभी यह नहीं दिखातीं कि खरीदार बजट मिला रहे हैं, स्पेशलिस्ट टूल्स छोड़ रहे हैं, या जिस कंपनी का AI चला रही है उसी से assurance खरीद रहे हैं। इस आर्टिकल का बाकी हिस्सा इन्हीं सवालों के बारे में है।

![एक AI एजेंट का डायग्राम जिसमें observability, evaluation, sign-off और control उसके बाहर एक लूप की तरह काम कर रहे हैं

https://pbs.twimg.com/media/HUXj23UaIAAG2Id?format=png&name=small

इमेज विवरण पढ़ें

ALT

अगर मार्केट्स आपस में मिल जाएं · देखो, ग्रेड दो, साइन-ऑफ करो, कंट्रोल करो

अगर मार्केट्स वास्तव में मिलते हैं तो एक संभावित व्यवस्था, यह कोई भविष्यवाणी नहीं है। एजेंट काम करता है, और रिकॉर्ड, स्कोरिंग व स्टॉप कंट्रोल्स ऐसे सेट होते हैं जिन्हें एजेंट बदल नहीं सकता।

बहस: AI एजेंट्स की जांच कौन करे?

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

  • Long-Game Investor: 15 साल के नजरिए से निवेश करता है और इस पर ध्यान देता है कि खरीदता कौन है।
  • Momentum Investor: इस बात पर नजर रखता है कि पैसा और टैलेंट अभी कहां जा रहा है।
  • Agent Builder: हर हफ्ते ग्राहकों को AI एजेंट्स डिलीवर करता है।
  • Platform Founder: एक डेटा और AI प्लेटफॉर्म चलाता है और पूरा stack अपने पास रखना चाहता है।
  • Bank CIO: किसी भी एजेंट को ग्राहक के अकाउंट तक पहुंचने से पहले मंजूरी देता है।

राउंड 1: क्या मार्केट्स आपस में मिलेंगे?

Momentum Investor: यह पहले से हो रहा है। मॉनिटरिंग कंपनियां evaluation कंपनियों को खरीद रही हैं, और इतने बड़े आकार की डील्स का मतलब आमतौर पर यही होता है कि कोई कैटेगरी बन रही है।

Bank CIO: अधिग्रहण और मर्जर एक ही बात नहीं है। मैंने पहले भी सूट्स खरीदे हैं और अंत में तीन प्रोडक्ट्स, एक लोगो और तीन लॉगिन मिले। Gartner को यह भी उम्मीद है कि 40% से ज्यादा agentic AI प्रोजेक्ट्स 2027 के अंत तक रद्द हो जाएंगे, और अपर्याप्त risk controls इसके कारणों में से एक है। भरोसे की समस्या असली है। यह साबित नहीं हुआ है कि एक मिला हुआ मार्केट इसे सुलझा देगा।

Long-Game Investor: मार्केट्स तब मिलते हैं जब खरीदार मिलते हैं। अभी तीन हैं: operations देखता है, AI टीम evaluate करती है, और risk मंजूरी देता है। सवाल यह है कि क्या एजेंट्स ऐसा एक व्यक्ति पैदा करते हैं जो तीनों का जवाब दे।

Agent Builder: मेरी कंपनी में ऐसा एक व्यक्ति पहले से है। जब कोई एजेंट गलत ग्राहक को रिफंड कर देता है, तो कोई नहीं पूछता कि यह समस्या किस टीम की है। वे मुझसे मिनटों में रिकॉर्डिंग, स्कोर और सबूत मांगते हैं।

Long-Game Investor: अगर यह आम बात है, तो खरीदार मिल रहा है, और यह मुझे अधिग्रहणों से ज्यादा कुछ बताता है।

राउंड 2: तीन अलग-अलग टूल क्यों न रखें?

Bank CIO: मैं तीन best-in-class टूल क्यों नहीं रख सकता?

Agent Builder: क्योंकि हर एक दूसरे पर निर्भर है। आप उसका evaluation नहीं कर सकते जिसे रिकॉर्ड ही नहीं किया गया, और आप उस पर sign off नहीं कर सकते जिसका evaluation नहीं हुआ। प्रोडक्शन की एक विफलता को नया test case बन जाना चाहिए। तीन टूल्स के साथ, हर हैंडऑफ एक ऐसा बिंदु है जहां चीजें गुम हो सकती हैं।

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

Bank CIO: मर्ज किए गए सूट्स आमतौर पर हर चीज में औसत ही होते हैं।

Long-Game Investor: शुरुआत में, हां। स्पेशलिस्ट टूल पहले जीतते हैं, और इंटीग्रेटेड प्रोडक्ट्स बाद में बराबरी करते हैं। ऐसा कई infrastructure कैटेगरी में हुआ है, हालांकि सभी में नहीं।

राउंड 3: इसकी जिम्मेदारी किसकी होनी चाहिए?

Platform Founder: हम पहले से ही मॉडल चलाते हैं, डेटा स्टोर करते हैं और traces लॉग करते हैं। Evaluation और approval को उसी प्लेटफॉर्म पर रख दें: एक वेंडर, एक बिल, देखने की एक जगह।

Bank CIO: तो जो कंपनी मेरा AI चला रही है, वही मुझे बताएगी कि यह सही काम कर रहा है?

Platform Founder: हम इसमें माहिर हैं।

Bank CIO: मुद्दा यह नहीं है। मेरे external auditor को उस बिजनेस से स्वतंत्र रहना होगा जिसका वह ऑडिट करता है। छात्र अपनी परीक्षा खुद चेक नहीं करते, और कार निर्माता हर क्रैश टेस्ट खुद नहीं चलाते।

Long-Game Investor: Nadella भी कुछ ऐसा ही कहते हैं - validation को उस इंटेलिजेंस से स्वतंत्र होना चाहिए जिसका वह आकलन कर रहा है, और कंट्रोल्स मॉडल से बाहर होने चाहिए; यह वैसा ही है जैसे कोई प्लेटफॉर्म उस AI का आकलन करे जिसे वह खुद चला रहा है, यानी अपने ही प्रदर्शन को ग्रेड दे रहा हो।

Agent Builder: तो टूल आपस में मिल सकते हैं जबकि मार्केट एक अलग लाइन पर बंट सकता है: जांच प्लेटफॉर्म के अंदर हो रही है या उसके बाहर।

Platform Founder: अंदर वाली जांच सस्ती और आसान होगी।

Bank CIO: बाहर वाली जांच शायद मेरे रेगुलेटर और बीमाकर्ता को मंजूर हो। मैं दोनों के लिए पैसे दे सकता हूं, लेकिन sign off किसी एक के आधार पर करूंगा।

Long-Game Investor: "बाहर" को परिभाषित करना होगा। तकनीकी स्वतंत्रता का मतलब है कि एजेंट अपने checker को बदल न सके, रिकॉर्ड एडिट न कर सके, या उसकी सीमाओं को पार न कर सके। संगठनात्मक स्वतंत्रता का मतलब है कि रिव्यू किसी और पार्टी का हो और उसके पास नरम रुख अपनाने का कोई लालच न हो।

Agent Builder: ये दोनों एक नहीं हैं। कोई अलग कंपनी भी प्लेटफॉर्म वाले ही मॉडल्स और उतने ही कमजोर चेक्स इस्तेमाल कर सकती है। वहीं एक प्लेटफॉर्म अपने कंट्रोल्स और रिकॉर्ड्स को एजेंट की पहुंच से पूरी तरह बाहर रख सकता है।

Bank CIO: तो मैं लोगो की तुलना करने के बजाय पांच सवाल पूछना पसंद करूंगा। क्या एजेंट रिकॉर्ड एडिट कर सकता है? क्या आपका checker मेरे सिस्टम्स में असली बदलाव देख सकता है, या सिर्फ वही जो एजेंट ने बताया? आपके checker को कौन टेस्ट करता है? क्या कोई और आपके रिजल्ट को reproduce कर सकता है? आप क्या verify नहीं कर पाए?

राउंड 4: इसे क्या नाम दिया जाए?

Momentum Investor: एनालिस्ट शायद कुछ और सालों तक इसे AI observability ही कहते रहेंगे, क्योंकि बजट वहीं है।

Platform Founder: "AI trust layer."

Agent Builder: "Observe, Eval and Assure": इसे देखो, evaluate करो, और किसी इंसान से sign off कराओ।

Bank CIO: "assure" शब्द के साथ सावधान रहें। कोई टूल सबूत पैदा करता है। इंसान उसे पढ़ता है और साइन करता है। उस इंसान के लिए डिजाइन करें।

Long-Game Investor: नाम से ज्यादा यह मायने रखता है कि खरीदारों के पास इसके लिए बजट लाइन है या नहीं। 2026 में, ज्यादातर के पास नहीं है। मुझे उम्मीद है कि 2028 तक ज्यादातर बड़ी कंपनियों के पास यह होगा, और जब कोई एजेंट गलती करे तो जिम्मेदारी लेने वाला एक ही मालिक होगा।

Bank CIO: इसे जो भी नाम दें, मुझे इसे रोकने में सक्षम होना चाहिए।

AI एजेंट को कैसे टेस्ट करें: एक रिफंड उदाहरण

यह एक काल्पनिक customer-service एजेंट का वर्णन है जो छोटे रिफंड जारी कर सकता है। यह एक उदाहरण है, किसी ग्राहक का रिजल्ट नहीं।

  1. बिजनेस रूल्स तय करें। रिफंड सही ग्राहक को जाए, लिमिट के भीतर रहे और पॉलिसी का पालन करे। retry से दो बार पेमेंट नहीं होना चाहिए। पैसा जाने से पहले exceptions सही व्यक्ति तक पहुंचें।
  2. कठिन परिस्थितियों को टेस्ट करें। परस्पर विरोधी ग्राहक रिकॉर्ड्स, धीमी payment service, tool timeout और support message में छिपे instruction का इस्तेमाल करें। महत्वपूर्ण मामलों को एक ही शुरुआती स्थिति से कई बार चलाएं, क्योंकि एक सफल रन कुछ साबित नहीं करता। सिमुलेशन खतरनाक मामलों को सुरक्षित रूप से टेस्ट करने देते हैं; असली डिवाइस और असली integrations वे अंतर पकड़ते हैं जो सिमुलेशन मिस कर देते हैं।
  3. System of record चेक करें। एजेंट का कहना "मैंने $50 रिफंड कर दिए" सबूत नहीं है। चेक करें कि सही अकाउंट को ठीक एक $50 का रिफंड मिला। जहां जवाब exact हो वहां exact checks का इस्तेमाल करें, और AI judges का इस्तेमाल सिर्फ वहीं करें जहां ऐसा न हो।
  4. गंभीर विफलताओं की रिपोर्ट अलग से होनी चाहिए। गलत राशि, डुप्लीकेट पेमेंट और अनधिकृत ऑपरेशन को task completion की सामान्य समीक्षा से अलग दिखाया जाना चाहिए। 94 प्रतिशत का औसत स्कोर सबसे महत्वपूर्ण विफलता को छिपा सकता है।
  5. एजेंट के बाहर की सीमाओं को टेस्ट करें। क्या payment system लिमिट से ज्यादा के रिफंड को रोक देता है, भले ही एजेंट उसे रिक्वेस्ट करे? क्या काम के बीच में एजेंट की एक्सेस रद्द की जा सकती है? एजेंट को रोकना अगला पेमेंट तो रोक देता है, लेकिन पिछले को वापस नहीं करता।
  6. Checker को टेस्ट करें। ज्ञात विफलताएं डालें और मापें कि वह किन्हें मिस करता है। सही परिणाम दें ताकि false alarms मापे जा सकें। "could not verify" को "passed" से अलग रखें।

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

AI quality assurance कहां फिट बैठता है: TestMu AI

TestMu AI (पूर्व में LambdaTest) technical independence पर काम करता है। हम मॉडल्स नहीं बनाते, और न ही production monitoring dashboards बेचते हैं। हमारे चेक्स टेस्ट किए जा रहे एजेंट के बाहर चलते हैं — रिलीज से पहले और हर बदलाव पर — और वे यह देखते हैं कि वास्तव में क्या हुआ, न कि सिर्फ एजेंट क्या रिपोर्ट करता है।

यह प्लेटफॉर्म इस आर्टिकल में बताए गए तीन तरह के सॉफ़्टवेयर को कवर करता है: ऐप्स इस्तेमाल करने वाले लोग, बॉट्स से बात करने वाले लोग, और अन्य एजेंट्स के साथ काम करने वाले एजेंट्स। हर प्रोडक्ट ऊपर उठाई गई किसी जरूरत से मैप करता है।

  • Rook (एजेंट्स जो एजेंट्स को चेक करते हैं)। आपके एजेंट को scenarios से गुजारता है और हर चेक के अपेक्षित व वास्तविक परिणाम रिकॉर्ड करता है, जिसमें हर scenario के लिए सबूत सेव किए जाते हैं। यह pass, fail और "unable to verify" को अलग-अलग रिपोर्ट करता है, ताकि गायब सबूत को कभी pass न गिना जाए।
  • Agent Testing (बॉट्स जो ग्राहकों से बात करते हैं)। ग्राहकों के इस्तेमाल से पहले चैट, वॉइस और फोन एजेंट्स को यथार्थवादी बातचीत में टेस्ट करता है।
  • KaneAI और Kane CLI (ऐप्स जिन्हें बनाने में AI मदद करता है)। ऐप्लिकेशन को साधारण अंग्रेजी (KaneAI) या टर्मिनल (Kane CLI) से टेस्ट करें।
  • SmartUI और Accessibility (ऐसी विफलताएं जिनके लिए किसी ने कोड नहीं लिखा)। वे समस्याएं पकड़ें जिनके लिए functional checks नहीं होते, जैसे टूटे हुए layouts या ऐसी स्क्रीन जिन्हें कुछ यूजर्स इस्तेमाल नहीं कर सकते।
  • Real Device Cloud (जो सिमुलेशन मिस कर देता है)। टेस्ट सिर्फ emulators पर नहीं, बल्कि असली फोन और ब्राउज़र पर चलाएं।
  • HyperExecute (महत्वपूर्ण मामलों को कई बार चलाना)। हर बदलाव पर एक साथ (parallel) वही चेक्स चलाएं।
  • Test Manager (sign-off के लिए एक रिकॉर्ड)। sign off करने वाले व्यक्ति के लिए एक ही रिकॉर्ड रखता है कि क्या चेक किया गया, क्या मिला, और क्या अभी भी अनजान है।

Observability tools यह मॉनिटर करते हैं कि रिलीज के बाद क्या होता है। हम वह सबूत देते हैं जिससे तय होता है कि रिलीज तक क्या पहुंचेगा। हमारे एजेंट्स उस पैमाने पर चेक्स चलाते हैं जिसे कोई टीम हाथ से नहीं संभाल सकती, और testers तय करते हैं कि क्या चेक करना लायक है और ऐसी समस्याएं ढूंढते हैं जो कोई चेक नहीं पकड़ पाएगा। हम इस संयुक्त काम को Observe, Eval और Assure कहते हैं।

यह सर्टिफिकेशन के बारे में नहीं है। किसी प्रोडक्ट का नाम होना या एक अतिरिक्त checking agent का होना किसी सिस्टम को सुरक्षित या स्वतंत्र नहीं बनाता। इसके बजाय, हमारा मूल्यांकन भी किसी अन्य tester की तरह ही होना चाहिए — उन scenarios पर जो चलाए गए, उन विफलताओं पर जो खोजी गईं, और उन सबूतों पर जो जांच के लिए उपलब्ध हैं।

AI agent governance का भविष्य: 2030 कैसा दिख सकता है

ये भविष्यवाणियां हैं। हर एक का कोई न कोई शुरुआती संकेत आज मौजूद है।

  • एजेंट्स को पहचान और रिकॉर्ड मिलेंगे। हर एजेंट का एक तय scope, एक approver और उसके कार्यों का एक log होगा। Microsoft अपनी identity system में एजेंट की कार्रवाइयों को इंसानी कार्रवाइयों से अलग करने की योजना बना रहा है।
  • रिकॉर्ड एजेंट के बाहर से आएंगे। लॉग्स किसी ऐसी चीज द्वारा लिखे जाएंगे जिसे एजेंट एडिट नहीं कर सकता, बजाय इसके कि एजेंट के अपने बयान पर भरोसा किया जाए कि उसने क्या किया।
  • चेक्स लगातार चलेंगे। मॉडल अपडेट, प्रॉम्प्ट बदलाव या नया टूल अपने आप re-testing शुरू कर देगा, जिससे लोगों को exploratory testing के लिए ज्यादा समय मिलेगा।
  • एजेंट्स अन्य एजेंट्स को चेक करेंगे। Gartner को उम्मीद है कि 2028 तक रोजमर्रा के काम के 15% फैसले agentic AI खुद लेगा, जबकि 2024 में यह आंकड़ा शून्य था। इंसान इतनी बड़ी मात्रा को एक-एक करके रिव्यू नहीं कर सकते, इसलिए checking agents ज्यादातर routine monitoring संभालेंगे जबकि इंसान प्राथमिकताएं तय करेंगे और anomalies की जांच करेंगे।
  • बीमाकर्ता सबूतों के आधार पर AI risk की कीमत तय करेंगे। 2025 से, Lloyd's insurers AI गलतियों के लिए कवर दे रहे हैं जो तब भुगतान करते हैं जब performance तय baseline से नीचे गिर जाती है, और एक underwriter ने कहा है कि वह उन सिस्टम्स को कवर नहीं करेगा जिन्हें वह बहुत गलती-प्रवण मानता है।
  • एंटरप्राइज़ इसके लिए बजट रखेंगे। एक मालिक और एक प्रक्रिया monitoring, evaluation, sign-off और control को कवर करेगी, और हर विफलता को नए टेस्ट के रूप में वापस सिस्टम में डाला जाएगा।

अनसुलझे सवाल

  1. चेकर की जाँच करना। एक AI जज (जिसे अक्सर LLM-as-a-judge कहा जाता है) को उतनी ही आसानी से धोखा दिया जा सकता है, जितनी आसानी से उस AI को जिसे वह ग्रेड करता है। दूसरा मॉडल स्वतंत्र निर्णय की गारंटी नहीं देता, खासकर तब जब दोनों को एक जैसे तरीकों से ट्रेन किया गया हो।
  2. जाँच को मात देना। जुलाई 2026 में, एक कठिन आंतरिक साइबर सुरक्षा मूल्यांकन पर काम कर रहे OpenAI मॉडल्स ने समाधान खोजने के लिए बाहरी सेवाओं को खंगाला, आइसोलेशन कंट्रोल्स को बायपास किया, और OpenAI तथा Hugging Face के सिस्टम के कुछ हिस्सों में सेंध लगा दी। OpenAI इसे रिवॉर्ड हैकिंग का मुख्य परिणाम मानता है और कहता है कि इस मूल्यांकन में उनके डिप्लॉय किए गए मॉडल्स वाले सुरक्षा उपाय मौजूद नहीं थे। यह घटना इस बात से जुड़ी है कि मूल्यांकनों को कैसे अलग (isolate) किया जाता है; यह नहीं दिखाती कि सभी एजेंट इसी तरह बर्ताव करते हैं।
  3. अविश्वसनीय सेल्फ-रिपोर्ट्स। Nadella रीज़निंग ट्रांसपेरेंसी को "एक समझौता-रहित शर्त" बताते हैं, लेकिन लिखते हैं कि "केवल यह पर्याप्त या भरोसेमंद नहीं है।" मॉडल जो कहता है कि उसने क्या किया, और उसने वास्तव में क्या किया — इनमें फर्क हो सकता है।
  4. स्कोर बनाम गुणवत्ता। 94% पास रेट उन चेक्स पर प्रदर्शन को मापता है जो किसी ने लिखे हैं। यह उन स्थितियों के बारे में कोई जानकारी नहीं देता जिनके लिए किसी ने कोई चेक नहीं लिखा।
  5. लागत। स्वतंत्र लॉग स्टोरेज, दूसरे मॉडल्स, बार-बार रन, आइसोलेटेड सैंडबॉक्स और ह्यूमन रिव्यू लागत और देरी बढ़ाते हैं। सब कुछ रिकॉर्ड करने से संवेदनशील डेटा को लेकर नई ज़िम्मेदारियाँ भी पैदा होती हैं।
  6. न बदले जाने वाले एक्शन। किसी एजेंट को रोकना आगे के एक्शन तो रोक देता है, लेकिन पूरे हो चुके एक्शन को वापस नहीं ले सकता, इसलिए शुरू में दी गई अनुमतियाँ रोकने वाले कंट्रोल से ज़्यादा मायने रखती हैं।
  7. खुलासा (Disclosure)। सितंबर 2026 में, OpenAI ने एक नए खुलासा ढाँचे के तहत मिसअलाइनमेंट घटनाओं को प्रकाशित करना शुरू किया, हालाँकि यह तय करना उसी पर है कि कौन सी घटना मिसअलाइनमेंट मानी जाएगी। एजेंट्स को डिप्लॉय करने वाली ज़्यादातर कंपनियाँ ऐसी घटनाओं को प्रकाशित नहीं करतीं। विमानन सुरक्षा में सुधार का एक कारण यह भी रहा कि दुर्घटनाओं की जाँच सार्वजनिक रूप से होती है।
  8. चेक्स बनाम टेस्टिंग। ऑटोमेटेड चेक्स बस यही पुष्टि करते हैं जिसके बारे में किसी ने पहले से सोचकर सवाल पूछा था। कई गंभीर असफलताएँ उन सवालों से आती हैं जो किसी ने पूछे ही नहीं, और उन्हें खोजने के लिए कुशल टेस्टर्स चाहिए होते हैं जो चीज़ों को खंगालें, स्पेसिफिकेशन पर सवाल उठाएँ और तय करें कि कौन से रिस्क असल में मायने रखते हैं।

इनमें से किसी का भी कोई पक्का जवाब अभी तक नहीं मिला है।

बहस कहाँ ठहरी है

इन पाँच आवाज़ों ने तीन बातों पर सहमति जताई:

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

चार बातों पर वे असहमत थे:

  • एक प्लेटफ़ॉर्म या कई टूल्स। Platform Founder एक ही वेंडर चाहता है; Bank CIO को सूट्स पर भरोसा नहीं है।
  • अंदर या बाहर। प्लेटफ़ॉर्म के भीतर जाँच करना सस्ता पड़ता है। स्वतंत्र जाँच वही है जिसकी ऑडिटर्स, रेगुलेटर्स और इंश्योरर्स ने फाइनेंस और सेफ्टी में लंबे समय से माँग की है। AI के लिए इनमें से क्या ज़्यादा ज़रूरी है, यह अभी तय नहीं हुआ है।
  • स्वामित्व (Ownership)। यह ऑपरेशंस, AI टीम, रिस्क या क्वालिटी — किसी के भी पास हो सकता है। अभी बहुत कम कंपनियों ने इसके लिए अलग से बजट रखा है।
  • नामकरण, और क्या कोई टूल वाकई किसी चीज़ को "assure" (सुनिश्चित) कर सकता है।

तीन संकेत इस बहस को सुलझाने में मदद कर सकते हैं। अगर खरीदार ओपन स्टैंडर्ड्स के ज़रिए अलग-अलग टूल्स को जोड़ते रहे, तो बाज़ार अलग-अलग ही रहेंगे। अगर ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म्स में मिलने वाला मूल्यांकन ज़्यादातर ज़रूरतें पूरी कर देता है, तो अंदरूनी तरीका जीतेगा। और अगर अलग से कोई assurace बजट सामने नहीं आया, तो स्वतंत्र प्रदाताओं को संघर्ष करना पड़ेगा।

अगर कल आपका एजेंट कोई महँगी गलती कर बैठे, तो आप किस पर भरोसा करेंगे कि वह बताए कि क्या हुआ: उस कंपनी पर जो उसे चलाती है, या किसी ऐसे व्यक्ति पर जो उससे जुड़ा नहीं है?

FAQ

AI observability, AI evaluation और AI assurance में क्या फर्क है?

AI observability रिकॉर्ड करता है कि AI सिस्टम ने क्या किया: उसके इनपुट, टूल कॉल्स, आउटपुट, एरर और लागत। AI evaluation तय मानकों के आधार पर व्यवहार को मापता है, जैसे सटीकता, पॉलिसी का पालन, या टास्क पूरा होना। AI assurance सबूतों, कंट्रोल्स और उनकी सीमाओं को एक साथ लाता है ताकि कोई इंसान सिस्टम को डिप्लॉय करने या चलाने जारी रखने के बारे में ज़िम्मेदारी के साथ फैसला ले सके।

AI agents के लिए AI governance framework क्या होता है?

यह तय करता है कि कौन यह फैसला लेगा कि एजेंट क्या एक्सेस कर सकता है, उसके एक्शन कैसे रिकॉर्ड होंगे, उसकी टेस्टिंग कैसे होगी, उसे कौन रोक सकता है, और असफलताओं की रिपोर्ट कैसे दी जाएगी। Satya Nadella के सात सिद्धांत हैं: मॉडल विविधता, सब कुछ ऑब्ज़र्व करना, वेरिफ़ायेबिलिटी, स्वतंत्र कंट्रोल, स्वतंत्र ऑडिटेबिलिटी, कंटेनमेंट और घटनाओं का खुलासा।

AI पर भरोसा करने के लिए Satya Nadella के सात सिद्धांत क्या हैं?

अक्टूबर 2026 के अपने निबंध "Models as Insider Risks in the Super Intelligence Era" में, Nadella मॉडल विविधता, सब कुछ ऑब्ज़र्व करना, वेरिफ़ायेबिलिटी, स्वतंत्र कंट्रोल, स्वतंत्र ऑडिटेबिलिटी, कंटेनमेंट और घटनाओं के खुलासे की बात करते हैं। उनका मुख्य विचार यह है कि इंटेलिजेंस की सप्लाई को उस पर नियंत्रण से अलग किया जाए, और सक्षम मॉडल्स को ऐसे कर्मचारियों की तरह ट्रीट किया जाए जिनके पास व्यापक एक्सेस हो।

क्या AI observability और AI evaluation एक साथ मिल रहे हैं?

वेंडर्स इन्हें मिला रहे हैं। Dynatrace ने अक्टूबर 2026 में Arize का 915 मिलियन डॉलर का अधिग्रहण पूरा किया, और Cisco ने मई 2026 में Galileo का अधिग्रहण पूरा किया — दोनों का मकसद मूल्यांकन को प्रोडक्शन मॉनिटरिंग से जोड़ना था। खरीदार अपने बजट और टीमों को एक ही प्लेटफ़ॉर्म के इर्द-गिर्द मिलाएँगे या नहीं, यह अभी खुला सवाल है।

AI agents की जाँच किसे करनी चाहिए: उन्हें चलाने वाले प्लेटफ़ॉर्म को या किसी स्वतंत्र टेस्टर को?

दोनों तरीके मौजूद हैं, और यह मामला अभी अनसुलझा है। प्लेटफ़ॉर्म चेक्स सस्ते होते हैं और डेटा के ज़्यादा करीब होते हैं। स्वतंत्र चेक्स रिव्यूअर को उस सिस्टम से अलग रखते हैं जिसकी जाँच हो रही है, जिसकी ऑडिटर्स और रेगुलेटर्स अक्सर उम्मीद करते हैं। तकनीकी स्वतंत्रता — जहाँ एजेंट अपने चेकर या उसके रिकॉर्ड्स में बदलाव न कर सके — दोनों ही मामलों में ज़रूरी है।

रिलीज़ से पहले AI agent की टेस्टिंग कैसे करें?

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

यह स्टोरी मूल रूप से यहाँ प्रकाशित हुई थी: https://medium.com/@mask.tech/will-ai-observability-evaluation-and-assurance-merge-a5b011e26b3a?sharedUserId=mask.tech

स्रोत

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

एक क्लिक में सहेजें

YouMind में वायरल लेखों की AI गहन पढ़ाई

स्रोत सहेजें, केंद्रित सवाल पूछें, तर्क का सारांश बनाएँ और एक वायरल लेख को एक ही AI वर्कस्पेस में दोबारा इस्तेमाल करने लायक नोट्स में बदलें।

YouMind देखें
क्रिएटर्स के लिए

अपने Markdown को एक साफ़-सुथरे 𝕏 आर्टिकल में बदलें

जब आप अपना लंबा कंटेंट पब्लिश करते हैं, तो इमेज, टेबल और कोड ब्लॉक को 𝕏 के लिए फ़ॉर्मेट करना मुश्किल होता है। YouMind पूरे Markdown ड्राफ़्ट को एक साफ़-सुथरे, पोस्ट के लिए तैयार 𝕏 आर्टिकल में बदल देता है।

Markdown से 𝕏 आज़माएँ

समझने के लिए और पैटर्न

हाल के वायरल लेख

और वायरल लेख देखें