एंटरप्राइज़ AI,
रणनीति से शासन तक

एंटरप्राइज़ AI परामर्श सेवाएं: AI रणनीति, कस्टम AI सिस्टम, LLM एकीकरण सेवाएं, और AI शासन, एक जवाबदेह परिचालन मॉडल में।

सभी सेवाएं →
01 / सेवा
रणनीति
AI तैयारी, उपयोग-मामलों की प्राथमिकता, और कार्यकारी रोडमैप।
→
02 / सेवा
सिस्टम
कस्टम AI सिस्टम: LLM एप्लिकेशन, AI एजेंट, और RAG।
→
03 / सेवा
एकीकरण
लेगेसी एकीकरण, API ऑर्केस्ट्रेशन, और वर्कफ़्लो ऑटोमेशन।
→
04 / सेवा
शासन
सुरक्षा समीक्षा, मॉडल निगरानी, और अनुपालन संचालन।
→

प्रोडक्शन एआई,
संपूर्ण

उत्पाद, समाधान और सेवाएँ एक शासित प्लेटफ़ॉर्म पर, आपके डेटा पर आधारित, ऑडिट के लिए जवाबदेह।

सभी उत्पाद →
01 / उत्पाद
AI सहायक
आपके सिस्टम से उत्तर, कार्य लिए गए, हर प्रतिक्रिया दर्ज की गई।
→
02 / उत्पाद
सेवा प्रबंधन
IT और कर्मचारी सेवा में अधिक टिकट स्वचालित रूप से हल करें।
→
03 / उत्पाद
एंटरप्राइज़ खोज
आपके चलाने वाले हर सिस्टम में एक अनुमति-जागरूक उत्तर।
→
04 / उत्पाद
एजेंट स्टूडियो
ऐसे एजेंट बनाएं और नियंत्रित करें जो वास्तविक कार्य करते हैं, सीमाओं के भीतर।
→

AI समाधान,
टीम और परिणाम के अनुसार

टीम, परिणाम और उद्योग के अनुसार एंटरप्राइज़ AI समाधान देखें, ITSM ऑटोमेशन और स्व-सेवा से लेकर कम लागत और तेज़ ऑनबोर्डिंग तक।

सभी समाधान →
01 / उद्योग
वित्तीय सेवाएं · स्वास्थ्यसेवा · अधिक
विनियमित, उच्च-जोखिम वाले क्षेत्र प्रत्येक के साथ एक ठोस उपयोग मामला।
→
02 / उद्योग
सरकारी क्षेत्र
सुरक्षित, ऑडिट करने योग्य सार्वजनिक क्षेत्र AI।
→
EN हि ES FR AR
SOC 2 · ISO 27001 · अनुरोध पर डेटा रेजिडेंसी
संचालन

पुराने टिकटों पर ऑटोमेशन का सुरक्षित परीक्षण: कंप्यूटर सिस्टम डिज़ाइन और IT सेवा कंपनियों के लिए स्पष्ट मार्गदर्शिका

ग्राहक डेटा और चालू सिस्टम सुरक्षित रखते हुए पुराने काम पर टिकट ऑटोमेशन जाँचने की दो सप्ताह की व्यावहारिक विधि।

पुराने टिकटों की जाँच का एक स्पष्ट सवाल होना चाहिए: क्या यह ऑटोमेशन कोई रिकॉर्ड बदले या ग्राहक से संपर्क किए बिना उपयोगी और सुरक्षित सुझाव देता? यह मार्गदर्शिका नियंत्रित परीक्षण, ध्यान देने योग्य विफलताओं और लाइव पायलट पर विचार करने से पहले दो सप्ताह की समीक्षा बताती है।

1. काम की प्रक्रिया, चरण-दर-चरण

पुराने टिकटों पर ऑटोमेशन जाँचने का अर्थ है अनुमोदित पुराने अनुरोधों को प्रस्तावित प्रक्रिया में चलाना और उसके सुझावों की तुलना सेवा जानने वाले लोगों द्वारा तय परिणामों से करना। यह मूल्यांकन है, पुराने टिकट बदलने या मौजूदा ग्राहक-कार्य पर कार्रवाई की अनुमति नहीं।

  1. एक सवाल तय करें, जैसे कि क्या सिस्टम सही कतार सुझा सकता है। परीक्षण से पहले अपेक्षित परिणाम निर्धारित करें।
  2. पुष्टि करें कि टिकट का जिम्मेदार व्यक्ति मूल्यांकन की अनुमति देता है। ग्राहक की शर्तें, गोपनीयता और सुरक्षा नियम, डेटा रखने की अवधि तथा स्वीकृत परीक्षण वातावरण जाँचें।
  3. पासवर्ड और अनावश्यक निजी या ग्राहक विवरण हटाएँ। पहुँच सीमित करें, नमूने का स्रोत दर्ज करें और मिटाने की तारीख तय करें। सुरक्षित उपयोग की मंजूरी न हो तो रिकॉर्ड इस्तेमाल न करें।
  4. योग्य कर्मचारियों से दस्तावेज़ित सेवा नियमों के अनुसार अपेक्षित परिणामों के लेबल बनवाएँ। तुलना में इस्तेमाल करने से पहले असहमतियाँ सुलझाएँ।
  5. तैयार रिकॉर्ड को अलग या केवल-पढ़ने वाले वातावरण में चलाएँ। सुझावों से टिकट अपडेट, ग्राहक संदेश, पहुँच प्रदान या बदलाव लागू नहीं होने चाहिए।
  6. सुझावों की तुलना संदर्भ परिणामों से करें। असुरक्षित या अनिश्चित मामलों को दर्ज करें, फिर तय करें कि रोकना, सुधारना या एक और अनुमोदित मूल्यांकन करना है।

यह मूल्यांकन का सुझाया तरीका है, अनिवार्य उद्योग मानक नहीं। नियंत्रणों को सेवा, ग्राहक समझौते और संबंधित डेटा के अनुसार ढालें।

रिकॉर्ड के पीछे की कार्यप्रक्रिया के लिए देखें IT सेवा कंपनियों में टिकट प्रबंधन की हमारी मार्गदर्शिका। ऑटोमेशन की अन्य प्राथमिकताओं के लिए देखें पहले क्या स्वचालित करें.

2. कंप्यूटर सिस्टम डिज़ाइन और IT सेवा कंपनी के कार्यालय में यह कहाँ विफल होता है

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

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

लोगों द्वारा जाँचे गए कठिन मामलों और असहमतियों पर ध्यान रखें। मूल्यांकन पर तभी भरोसा करें जब डेटा प्रबंधन और संदर्भ परिणाम विचाराधीन निर्णय के लिए उपयुक्त हों।

3. पहले क्या स्वचालित करें और क्या कभी स्वचालित न करें

पहले मूल्यांकन में ऐसे सुझाव चुनें जिन्हें जाँचना और सुधारना आसान हो। सिस्टम को सलाह देने तक सीमित रखें ताकि कोई व्यक्ति कार्रवाई से पहले उसके परिणामों की तुलना कर सके।

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

4. दो सप्ताह तक पुराने डेटा पर सुरक्षित परीक्षण कैसे करें

इन दो सप्ताहों को सीमित समीक्षा अवधि मानें, ऑटोमेशन की उत्पादन-तैयारी का प्रमाण नहीं। नीचे की योजना APLS का व्यावहारिक सुझाव है, कोई बाहरी मानक नहीं।

  1. पहला सप्ताह , दायरा तय करें और तैयारी करें: प्रक्रिया का जिम्मेदार तय करें, एक काम चुनें, डेटा उपयोग मंजूर करें, संवेदनशील विवरण घटाएँ, परीक्षण अलग रखें और संदर्भ लेबल की समीक्षा का तरीका तय करें।
  2. दूसरा सप्ताह , डेटा चलाएँ और समीक्षा करें: नमूना स्थिर करें, बिना किसी असर के सुझाव चलाएँ, त्रुटियों और संवेदनशील कठिन मामलों को जाँचें तथा सेवा-जिम्मेदार के साथ असहमतियों पर चर्चा करें।
  3. अंत में , निर्णय दर्ज करें: परिणामों की तुलना पहले से तय स्वीकृति और रोकने की शर्तों से करें। सीमाएँ लिखें; डेटा, नियंत्रण या परिणाम भरोसेमंद न हों तो परीक्षण रोकें या सुधारें।
  4. किसी भी लाइव पायलट से पहले , अलग मंजूरी लें और पहुँच की सीमाएँ, मानवीय जिम्मेदारी, निगरानी, बदलाव वापस लेने और घटना-प्रबंधन की व्यवस्था तय करें। केवल पुराने डेटा का परीक्षण उत्पादन में कार्रवाई की अनुमति नहीं देता।

जोखिम प्रबंधन की वैकल्पिक जानकारी के लिए NIST का AI जोखिम प्रबंधन ढाँचा और उसकी कार्यान्वयन मार्गदर्शिकादेखें। दोनों स्वैच्छिक मार्गदर्शन हैं, इस प्रक्रिया के लिए प्रमाणन या पास/फेल परीक्षण नहीं।

5. कॉपी करने योग्य जाँचसूची

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

निष्कर्ष: पुराने टिकट सीमित ऑटोमेशन प्रस्ताव का मूल्यांकन करने में तभी मदद करते हैं जब डेटा उपयोग मंजूर हो, तुलना उपयोगी हो और सिस्टम कोई अतिरिक्त कार्रवाई न कर सके। परीक्षण को पलटने योग्य, समीक्षा योग्य और किसी व्यक्ति की जिम्मेदारी में रखें।

← सभी अंतर्दृष्टियाँ IT सेवा प्रबंधन देखें →