सफल AI पायलट उत्पादन के लिए तैयार होने का प्रमाण नहीं है। उसे रोज़मर्रा के काम में लाने के लिए भरोसेमंद डेटा कनेक्शन, स्पष्ट जिम्मेदारियां, सीमित अनुमतियां और रिकवरी की योजना चाहिए। रिटेलर का ग्राहक सेवा सहायक पहले सिर्फ सवालों के जवाब दे सकता है; लेन देन की अनुमति उसे चरणों में दें—पहले केवल पढ़ने की, फिर कार्रवाई...
प्रकाशितकर्ताGPT-6 Luna से संपादितGPT Image 2 से चित्र बनाए गए
शोध उत्तर

Create a landscape editorial hero image for this Studio Global article: In light of Acting Minister for Manpower Jasmin Lau’s remarks at Singapore’s inaugural SG AI Xchange in September that the country has close. Article summary: Singapore companies should treat a successful AI pilot as evidence of potential—not proof of production readiness—and invest in the data, integrations, controls and operating model that make it dependable. This is the pr. Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
सिंगापुर के पहले SG AI Xchange में कार्यवाहक जनशक्ति मंत्री जस्मिन लाउ ने AI के लिए एक व्यावहारिक कसौटी रखी: क्या यह रोज़मर्रा के कामकाज का भरोसेमंद हिस्सा बन सकता है? देश में करीब 100 AI Centres of Excellence हैं, लेकिन सफल प्रदर्शन केवल शुरुआत है। असली चुनौती तब आती है जब सिस्टम को अधिक डेटा, उपयोगकर्ताओं और जुड़े हुए अनुप्रयोगों के बीच काम करना हो—और जब किसी कार्रवाई को प्रयोग खत्म होने पर बस रीसेट न किया जा सके।1
किसी रिटेलर के लिए इसका मतलब हो सकता है कि ग्राहक-सेवा सहायक को चुनी हुई जानकारी से जवाब देने के आगे बढ़ाकर लाइव ग्राहक, ऑर्डर, भुगतान, रिफंड और लॉयल्टी रिकॉर्ड तक पहुंच दी जाए। अगला कदम उस सहायक से पता बदलवाना, ऑर्डर रद्द करवाना या रिफंड जारी करवाना हो सकता है। यह कहीं बड़ी जिम्मेदारी है। नीचे दिए गए कदम अपनाने की एक सुझाई गई रूपरेखा हैं—यह दावा नहीं कि किसी खास रिटेलर ने इन्हें लागू कर लिया है।
सबसे पहले तय करें कि सिस्टम क्या कर सकता है और उसका जवाबदेह कौन होगा। तीन क्षमताओं को अलग-अलग रखें: सामान्य सवालों के जवाब देना, प्रमाणित ग्राहक के रिकॉर्ड देखना और लेन-देन करना। ग्राहक-सेवा के नतीजों, मूल डेटा, सिस्टम कनेक्शन, सुरक्षा और घटना-प्रतिक्रिया के लिए जिम्मेदार लोग तय करें।
पायलट के दौरान लिए गए अस्थायी रास्ते भी दर्ज करें—जैसे कॉपी किए गए डेटासेट, अस्थायी कनेक्शन, सिस्टम में रखे गए क्रेडेंशियल और हाथ से की जाने वाली जांच। हर एक के लिए तय करें कि उसे हटाना है, मजबूत करना है या बदलना है; साथ में जिम्मेदार व्यक्ति और लागत भी तय करें। वरना पायलट किफायती दिख सकता है, जबकि उसकी वास्तविक लागत छिपी हुई मानवीय निगरानी या बाद में किए जाने वाले जरूरी काम में छिपी हो।
लाइव ग्राहक-सेवा सहायक को उन सिस्टमों तक भरोसेमंद पहुंच चाहिए जहां ग्राहक और लेन-देन के अद्यतन रिकॉर्ड रखे जाते हैं। डेटा का मालिक कौन है, उसकी परिभाषा क्या है और वह कितनी बार ताज़ा होना चाहिए—यह साफ करें। विभागों और पुराने सिस्टमों को समर्थित API या नियंत्रित एकीकरण सेवाओं के जरिए जोड़ें। हर AI ऐप में अलग-अलग, एकबारगी कनेक्शन बनाने से बचें, जहां दोबारा इस्तेमाल होने वाली सेवा काम कर सकती हो।
रिफंड की पात्रता या ऑर्डर रद्द करने की समय-सीमा जैसे व्यावसायिक नियम अधिकृत सिस्टम में रखें, केवल मॉडल के निर्देशों में नहीं। कार्रवाई से पहले उन नियमों की स्वतंत्र जांच संबंधित सिस्टम को करनी चाहिए।
यह सोच-समझकर तय करें कि कौन-सा डेटा सीधे मूल सिस्टम से देखा जाए और किस डेटा की कॉपी—यदि कोई हो—प्रदर्शन या विश्लेषण के उचित कारण से बनाई जाए। हर कॉपी, कैश या सर्च इंडेक्स के लिए रखरखाव और सिंक्रोनाइज़ेशन के नियम तय करें। रिकॉर्ड में सुधार, उसे मिटाने का अनुरोध या सहमति में बदलाव संबंधित कॉपियों तक भी पहुंचना चाहिए। अगर ऐसा नहीं हुआ है, तो सहायक को चुपचाप पुराने डेटा पर निर्भर नहीं होना चाहिए।
सहायक की एक पहचानी जा सकने वाली सेवा पहचान हो और उसे केवल उसी काम के लिए जरूरी पहुंच मिले। ऑर्डर देखने की अनुमति और उसमें बदलाव करने की अनुमति अलग रखें। पहुंच को प्रमाणित ग्राहक और संबंधित लेन-देन तक सीमित करें।
मिसाल के तौर पर, सिस्टम पता बदलने का प्रस्ताव तभी दे सकता है जब ऑर्डर पूरा करने की प्रक्रिया शुरू न हुई हो और ग्राहक ने बदलाव की पुष्टि की हो। असाधारण रद्दीकरण या तय व्यावसायिक सीमा से अधिक के रिफंड के लिए किसी कर्मचारी की मंजूरी जरूरी हो सकती है। ये नियम मॉडल के प्रॉम्प्ट से बाहर लागू करें, और कार्रवाई से ठीक पहले अनुमतियों तथा लेन-देन की स्थिति दोबारा जांचें।
ऑडिट रिकॉर्ड से कंपनी यह पता लगा सके कि क्या हुआ: कौन-सा एजेंट और ग्राहक शामिल थे, कौन-सा डेटा और कौन-सी अनुमतियां लागू थीं, किन सिस्टमों से संपर्क हुआ, किसी व्यक्ति ने मंजूरी दी या नहीं और नतीजा क्या रहा। एक साझा ट्रेस पहचान (trace ID) इन रिकॉर्ड को आपस में जोड़ सकती है। लॉग सुरक्षित रखें, लेकिन संवेदनशील जानकारी को जरूरत से ज्यादा समय तक न रखें।
गलतियों और सिस्टम की विफलता के लिए भी तैयारी जरूरी है। एक ही अनुरोध दो बार लागू होने से रोकने के उपाय, रिकॉर्ड मिलान की प्रक्रिया, आपातकाल में पहुंच रद्द करने का तरीका और जांचे हुए रिकवरी कदम रखें। कुछ पूरी हो चुकी कार्रवाइयां सचमुच वापस नहीं ली जा सकतीं। ऐसे मामलों में सुधार की वैकल्पिक प्रक्रिया और आगे किससे संपर्क करना है, यह तय करें—जैसे गलत रिफंड को बस ‘अनडू’ मानने के बजाय उसका सही समायोजन करना।
दक्षिण-पूर्व एशिया में हर तैनाती के लिए देखें कि रिकॉर्ड, प्रॉम्प्ट, एम्बेडिंग, लॉग और बैकअप कहां रखे और प्रोसेस किए जाते हैं। सेवा प्रदाता के उप-ठेकेदारों और विदेश से मिलने वाली सहायता की पहुंच को भी इस समीक्षा में शामिल करें। कानूनी और सुरक्षा टीमें हर देश तथा क्षेत्र पर लागू नियमों की पुष्टि करें। यह न मानें कि सिंगापुर में मंजूरी मिलना—या डेटा को स्थानीय स्तर पर होस्ट करना—हर दूसरे बाजार की आवश्यकताएं भी पूरी कर देता है।
व्यावसायिक योजना में सिस्टम कनेक्शन दोबारा बनाने, मॉडल इस्तेमाल, डेटा खोज, सिंक्रोनाइज़ेशन, स्टोरेज, निगरानी, सुरक्षा, मानव-अनुमोदन, सहायता और आपदा-पुनर्प्राप्ति की लागत जोड़ें। ट्रैफिक, डेटा की मात्रा और अपवादों के बढ़ने पर लागत और प्रदर्शन की जांच करें। केवल मॉडल कॉल की लागत नहीं, बल्कि सही ढंग से सुलझाए गए हर मामले या पूरे किए गए हर लेन-देन की लागत की तुलना मौजूदा सेवा से करें।
मॉडल प्रदाता के इंटरफेस को डेटा कनेक्टर, पहचान और पहुंच नियंत्रण, नीति लागू करने वाली सेवाओं तथा ऑडिट से अलग रखें। स्थिर टूल कॉन्ट्रैक्ट और संस्करण-नियंत्रित नीतियां मॉडल या पहुंच नियम बदलते समय हर कनेक्शन को फिर से बनाने की जरूरत घटा सकती हैं। नया मॉडल इस्तेमाल करने से पहले उसे गुणवत्ता, सुरक्षा और लेन-देन से जुड़े वही परीक्षण पास करने चाहिए।
पायलट में ही उत्पादन की समस्याएं परखें: पुराने रिकॉर्ड, वापस ली गई सहमति, अनुपलब्ध सिस्टम, दोहराए गए अनुरोध, एक ही ऑर्डर में एक साथ होने वाले बदलाव और खोजी गई सामग्री में छिपे दुर्भावनापूर्ण निर्देश। इस्तेमाल को चरणों में बढ़ाएं—पहले केवल पढ़ने की पहुंच, फिर कार्रवाई के सुझाव, उसके बाद मानव-अनुमोदित लेन-देन और अंत में सीमित दायरे का स्वचालन।
व्यापक तैनाती तभी करें जब जिम्मेदार लोग तय हों, लागत लंबे समय तक उठाई जा सके, रिकवरी की जांच हो चुकी हो और नियंत्रण कारगर साबित हों। सफलता का असली पैमाना प्रभावशाली डेमो नहीं, बल्कि ऐसी नियंत्रित सेवा है जो कम निगरानी, बढ़ते काम के बोझ, सिस्टम की विफलता और प्रदाता में बदलाव के बावजूद उपयोगी बनी रहे।1
Studio Global AI
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
सफल AI पायलट उत्पादन के लिए तैयार होने का प्रमाण नहीं है। उसे रोज़मर्रा के काम में लाने के लिए भरोसेमंद डेटा कनेक्शन, स्पष्ट जिम्मेदारियां, सीमित अनुमतियां और रिकवरी की योजना चाहिए।
सफल AI पायलट उत्पादन के लिए तैयार होने का प्रमाण नहीं है। उसे रोज़मर्रा के काम में लाने के लिए भरोसेमंद डेटा कनेक्शन, स्पष्ट जिम्मेदारियां, सीमित अनुमतियां और रिकवरी की योजना चाहिए। रिटेलर का ग्राहक सेवा सहायक पहले सिर्फ सवालों के जवाब दे सकता है; लेन देन की अनुमति उसे चरणों में दें—पहले केवल पढ़ने की, फिर कार्रवाई का सुझाव देने की, उसके बाद मानव अनुमोदन वाली और अंत में सीमित स्वचालित कार्रवाई।
पुराने डेटा, कनेक्शन की विफलता, दोहराए गए अनुरोध और सहमति में बदलाव जैसे जोखिमों को पहले ही परखें। व्यापक इस्तेमाल तभी बढ़ाएं जब जिम्मेदारियां साफ हों और सुरक्षा उपायों की जांच हो चुकी हो।
सफल AI पायलट उत्पादन के लिए तैयार होने का प्रमाण नहीं है। उसे रोज़मर्रा के काम में लाने के लिए भरोसेमंद डेटा कनेक्शन, स्पष्ट जिम्मेदारियां, सीमित अनुमतियां और रिकवरी की योजना चाहिए। रिटेलर का ग्राहक सेवा सहायक पहले सिर्फ सवालों के जवाब दे सकता है; लेन देन की अनुमति उसे चरणों में दें—पहले केवल पढ़ने की, फिर कार्रवाई...
प्रकाशितकर्ताGPT-6 Luna से संपादितGPT Image 2 से चित्र बनाए गए
शोध उत्तर

Create a landscape editorial hero image for this Studio Global article: In light of Acting Minister for Manpower Jasmin Lau’s remarks at Singapore’s inaugural SG AI Xchange in September that the country has close. Article summary: Singapore companies should treat a successful AI pilot as evidence of potential—not proof of production readiness—and invest in the data, integrations, controls and operating model that make it dependable. This is the pr. Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
सिंगापुर के पहले SG AI Xchange में कार्यवाहक जनशक्ति मंत्री जस्मिन लाउ ने AI के लिए एक व्यावहारिक कसौटी रखी: क्या यह रोज़मर्रा के कामकाज का भरोसेमंद हिस्सा बन सकता है? देश में करीब 100 AI Centres of Excellence हैं, लेकिन सफल प्रदर्शन केवल शुरुआत है। असली चुनौती तब आती है जब सिस्टम को अधिक डेटा, उपयोगकर्ताओं और जुड़े हुए अनुप्रयोगों के बीच काम करना हो—और जब किसी कार्रवाई को प्रयोग खत्म होने पर बस रीसेट न किया जा सके।1
किसी रिटेलर के लिए इसका मतलब हो सकता है कि ग्राहक-सेवा सहायक को चुनी हुई जानकारी से जवाब देने के आगे बढ़ाकर लाइव ग्राहक, ऑर्डर, भुगतान, रिफंड और लॉयल्टी रिकॉर्ड तक पहुंच दी जाए। अगला कदम उस सहायक से पता बदलवाना, ऑर्डर रद्द करवाना या रिफंड जारी करवाना हो सकता है। यह कहीं बड़ी जिम्मेदारी है। नीचे दिए गए कदम अपनाने की एक सुझाई गई रूपरेखा हैं—यह दावा नहीं कि किसी खास रिटेलर ने इन्हें लागू कर लिया है।
सबसे पहले तय करें कि सिस्टम क्या कर सकता है और उसका जवाबदेह कौन होगा। तीन क्षमताओं को अलग-अलग रखें: सामान्य सवालों के जवाब देना, प्रमाणित ग्राहक के रिकॉर्ड देखना और लेन-देन करना। ग्राहक-सेवा के नतीजों, मूल डेटा, सिस्टम कनेक्शन, सुरक्षा और घटना-प्रतिक्रिया के लिए जिम्मेदार लोग तय करें।
पायलट के दौरान लिए गए अस्थायी रास्ते भी दर्ज करें—जैसे कॉपी किए गए डेटासेट, अस्थायी कनेक्शन, सिस्टम में रखे गए क्रेडेंशियल और हाथ से की जाने वाली जांच। हर एक के लिए तय करें कि उसे हटाना है, मजबूत करना है या बदलना है; साथ में जिम्मेदार व्यक्ति और लागत भी तय करें। वरना पायलट किफायती दिख सकता है, जबकि उसकी वास्तविक लागत छिपी हुई मानवीय निगरानी या बाद में किए जाने वाले जरूरी काम में छिपी हो।
लाइव ग्राहक-सेवा सहायक को उन सिस्टमों तक भरोसेमंद पहुंच चाहिए जहां ग्राहक और लेन-देन के अद्यतन रिकॉर्ड रखे जाते हैं। डेटा का मालिक कौन है, उसकी परिभाषा क्या है और वह कितनी बार ताज़ा होना चाहिए—यह साफ करें। विभागों और पुराने सिस्टमों को समर्थित API या नियंत्रित एकीकरण सेवाओं के जरिए जोड़ें। हर AI ऐप में अलग-अलग, एकबारगी कनेक्शन बनाने से बचें, जहां दोबारा इस्तेमाल होने वाली सेवा काम कर सकती हो।
रिफंड की पात्रता या ऑर्डर रद्द करने की समय-सीमा जैसे व्यावसायिक नियम अधिकृत सिस्टम में रखें, केवल मॉडल के निर्देशों में नहीं। कार्रवाई से पहले उन नियमों की स्वतंत्र जांच संबंधित सिस्टम को करनी चाहिए।
यह सोच-समझकर तय करें कि कौन-सा डेटा सीधे मूल सिस्टम से देखा जाए और किस डेटा की कॉपी—यदि कोई हो—प्रदर्शन या विश्लेषण के उचित कारण से बनाई जाए। हर कॉपी, कैश या सर्च इंडेक्स के लिए रखरखाव और सिंक्रोनाइज़ेशन के नियम तय करें। रिकॉर्ड में सुधार, उसे मिटाने का अनुरोध या सहमति में बदलाव संबंधित कॉपियों तक भी पहुंचना चाहिए। अगर ऐसा नहीं हुआ है, तो सहायक को चुपचाप पुराने डेटा पर निर्भर नहीं होना चाहिए।
सहायक की एक पहचानी जा सकने वाली सेवा पहचान हो और उसे केवल उसी काम के लिए जरूरी पहुंच मिले। ऑर्डर देखने की अनुमति और उसमें बदलाव करने की अनुमति अलग रखें। पहुंच को प्रमाणित ग्राहक और संबंधित लेन-देन तक सीमित करें।
मिसाल के तौर पर, सिस्टम पता बदलने का प्रस्ताव तभी दे सकता है जब ऑर्डर पूरा करने की प्रक्रिया शुरू न हुई हो और ग्राहक ने बदलाव की पुष्टि की हो। असाधारण रद्दीकरण या तय व्यावसायिक सीमा से अधिक के रिफंड के लिए किसी कर्मचारी की मंजूरी जरूरी हो सकती है। ये नियम मॉडल के प्रॉम्प्ट से बाहर लागू करें, और कार्रवाई से ठीक पहले अनुमतियों तथा लेन-देन की स्थिति दोबारा जांचें।
ऑडिट रिकॉर्ड से कंपनी यह पता लगा सके कि क्या हुआ: कौन-सा एजेंट और ग्राहक शामिल थे, कौन-सा डेटा और कौन-सी अनुमतियां लागू थीं, किन सिस्टमों से संपर्क हुआ, किसी व्यक्ति ने मंजूरी दी या नहीं और नतीजा क्या रहा। एक साझा ट्रेस पहचान (trace ID) इन रिकॉर्ड को आपस में जोड़ सकती है। लॉग सुरक्षित रखें, लेकिन संवेदनशील जानकारी को जरूरत से ज्यादा समय तक न रखें।
गलतियों और सिस्टम की विफलता के लिए भी तैयारी जरूरी है। एक ही अनुरोध दो बार लागू होने से रोकने के उपाय, रिकॉर्ड मिलान की प्रक्रिया, आपातकाल में पहुंच रद्द करने का तरीका और जांचे हुए रिकवरी कदम रखें। कुछ पूरी हो चुकी कार्रवाइयां सचमुच वापस नहीं ली जा सकतीं। ऐसे मामलों में सुधार की वैकल्पिक प्रक्रिया और आगे किससे संपर्क करना है, यह तय करें—जैसे गलत रिफंड को बस ‘अनडू’ मानने के बजाय उसका सही समायोजन करना।
दक्षिण-पूर्व एशिया में हर तैनाती के लिए देखें कि रिकॉर्ड, प्रॉम्प्ट, एम्बेडिंग, लॉग और बैकअप कहां रखे और प्रोसेस किए जाते हैं। सेवा प्रदाता के उप-ठेकेदारों और विदेश से मिलने वाली सहायता की पहुंच को भी इस समीक्षा में शामिल करें। कानूनी और सुरक्षा टीमें हर देश तथा क्षेत्र पर लागू नियमों की पुष्टि करें। यह न मानें कि सिंगापुर में मंजूरी मिलना—या डेटा को स्थानीय स्तर पर होस्ट करना—हर दूसरे बाजार की आवश्यकताएं भी पूरी कर देता है।
व्यावसायिक योजना में सिस्टम कनेक्शन दोबारा बनाने, मॉडल इस्तेमाल, डेटा खोज, सिंक्रोनाइज़ेशन, स्टोरेज, निगरानी, सुरक्षा, मानव-अनुमोदन, सहायता और आपदा-पुनर्प्राप्ति की लागत जोड़ें। ट्रैफिक, डेटा की मात्रा और अपवादों के बढ़ने पर लागत और प्रदर्शन की जांच करें। केवल मॉडल कॉल की लागत नहीं, बल्कि सही ढंग से सुलझाए गए हर मामले या पूरे किए गए हर लेन-देन की लागत की तुलना मौजूदा सेवा से करें।
मॉडल प्रदाता के इंटरफेस को डेटा कनेक्टर, पहचान और पहुंच नियंत्रण, नीति लागू करने वाली सेवाओं तथा ऑडिट से अलग रखें। स्थिर टूल कॉन्ट्रैक्ट और संस्करण-नियंत्रित नीतियां मॉडल या पहुंच नियम बदलते समय हर कनेक्शन को फिर से बनाने की जरूरत घटा सकती हैं। नया मॉडल इस्तेमाल करने से पहले उसे गुणवत्ता, सुरक्षा और लेन-देन से जुड़े वही परीक्षण पास करने चाहिए।
पायलट में ही उत्पादन की समस्याएं परखें: पुराने रिकॉर्ड, वापस ली गई सहमति, अनुपलब्ध सिस्टम, दोहराए गए अनुरोध, एक ही ऑर्डर में एक साथ होने वाले बदलाव और खोजी गई सामग्री में छिपे दुर्भावनापूर्ण निर्देश। इस्तेमाल को चरणों में बढ़ाएं—पहले केवल पढ़ने की पहुंच, फिर कार्रवाई के सुझाव, उसके बाद मानव-अनुमोदित लेन-देन और अंत में सीमित दायरे का स्वचालन।
व्यापक तैनाती तभी करें जब जिम्मेदार लोग तय हों, लागत लंबे समय तक उठाई जा सके, रिकवरी की जांच हो चुकी हो और नियंत्रण कारगर साबित हों। सफलता का असली पैमाना प्रभावशाली डेमो नहीं, बल्कि ऐसी नियंत्रित सेवा है जो कम निगरानी, बढ़ते काम के बोझ, सिस्टम की विफलता और प्रदाता में बदलाव के बावजूद उपयोगी बनी रहे।1
Studio Global AI
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
सफल AI पायलट उत्पादन के लिए तैयार होने का प्रमाण नहीं है। उसे रोज़मर्रा के काम में लाने के लिए भरोसेमंद डेटा कनेक्शन, स्पष्ट जिम्मेदारियां, सीमित अनुमतियां और रिकवरी की योजना चाहिए।
सफल AI पायलट उत्पादन के लिए तैयार होने का प्रमाण नहीं है। उसे रोज़मर्रा के काम में लाने के लिए भरोसेमंद डेटा कनेक्शन, स्पष्ट जिम्मेदारियां, सीमित अनुमतियां और रिकवरी की योजना चाहिए। रिटेलर का ग्राहक सेवा सहायक पहले सिर्फ सवालों के जवाब दे सकता है; लेन देन की अनुमति उसे चरणों में दें—पहले केवल पढ़ने की, फिर कार्रवाई का सुझाव देने की, उसके बाद मानव अनुमोदन वाली और अंत में सीमित स्वचालित कार्रवाई।
पुराने डेटा, कनेक्शन की विफलता, दोहराए गए अनुरोध और सहमति में बदलाव जैसे जोखिमों को पहले ही परखें। व्यापक इस्तेमाल तभी बढ़ाएं जब जिम्मेदारियां साफ हों और सुरक्षा उपायों की जांच हो चुकी हो।