Microsoft Purview, Power Automate और Copilot Studio से AI GRC एजेंट बनाएं: अपने-आप कंप्लायंस रिपोर्ट

गवर्नेंस, रिस्क और कम्प्लायंस, यानी GRC रिपोर्टिंग हर ऑडिट के मौसम में कंप्लायंस टीमों की सबसे थकाऊ ज़िम्मेदारियों में गिनी जाती है। कहीं न कहीं कोई एनालिस्ट ऑडिट लॉग को एक्सेल में कॉपी करके कॉलम मिला रहा होता है। यह मेहनत काम तो करती है, पर इसमें समय बहुत जाता है और चूक की गुंजाइश भी रहती है।

इस लेख में हम देखेंगे कि Microsoft Purview, Power Automate और Copilot Studio को जोड़कर एक AI GRC एजेंट कैसे बनाया जा सकता है। यह एजेंट डेटा लाता है, उसका विश्लेषण करता है और उसे ऐसी भाषा में समझाता है जिसे प्रबंधन और ऑडिटर दोनों पढ़ सकें।

मैन्युअल GRC रिपोर्टिंग की समस्या

मैन्युअल GRC रिपोर्टिंग तब पनपती है, जब संगठन डॉक्यूमेंटेशन को ही जानकारी समझ लेते हैं। आम तरीका यह है कि Microsoft Purview से डेटा निकाला जाता है, एक्सपोर्ट किया जाता है और स्प्रेडशीट में चिपका दिया जाता है। फिर कोई बैठकर उसे पढ़ने की कोशिश करता है।

दिक्कत यह है कि हर एंट्री एक घना JSON ब्लॉब होती है, जिसे पढ़ना आसान नहीं। Microsoft 365 में हर यूज़र एक्शन लॉग होता है, जैसे दस्तावेज़ शेयर करना, पॉलिसी बनाना या रिटेंशन लेबल बदलना। लेकिन जब तक आप नेस्टेड JSON स्ट्रक्चर में माहिर नहीं हैं, तब तक यह जानकारी उलझी रहती है। ऊपर से मास्टर स्प्रेडशीट पर गलत कॉपी करने का जोखिम बना रहता है।

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

AI GRC एजेंट का तीन-सिर वाला ढांचा

इस एजेंट को तीन सिरों वाले प्राणी की तरह समझा जा सकता है। हर सिर प्रक्रिया के एक हिस्से का ज़िम्मेदार है:

• Microsoft Purview: कच्ची याददाश्त। यह ऑडिट लॉग रखता है और ऐसी गतिविधियाँ दर्ज करता है, जैसे असामान्य डेटा शेयरिंग या पॉलिसी सीमा से ऊपर बढ़े हुए विशेषाधिकार।
• Power Automate: तंत्रिका तंत्र और लॉजिक लेयर। यह तय करता है कि कौन सी घटनाएँ मायने रखती हैं और डेटा को कब, कैसे लाना है।
• Copilot Studio: कथावाचक की भूमिका। यह साफ़ किए गए संकेतों को पढ़ने योग्य रिपोर्ट में बदलता है।

अनुपालन का बड़ा हिस्सा फ़ैसले लेने से ज़्यादा पैटर्न पहचानने का काम है। इसीलिए विश्लेषक असल में गतिविधि के प्रकार और परिणाम की स्थिति जैसे चुनिंदा बॉक्स देखता है। यही काम ऑटोमेशन को सौंपा जा सकता है।

अब तक कई टीमों ने यह रास्ता इसलिए नहीं अपनाया क्योंकि वे ऑटोमेशन को बहुत कठोर और AI को अनिश्चित मानती रहीं। लेकिन यहाँ हर चरण स्पष्ट नियमों पर चलता है, इसलिए प्रक्रिया पूर्वानुमेय रहती है।

Microsoft Purview से डेटा लाना: Power Automate कनेक्शन

पहला कदम एजेंट को "देखने की क्षमता" देना है। इसके लिए पहले तय करें कि कौन सी घटनाएँ मायने रखती हैं और डेटा कहाँ से आएगा।

कनेक्शन के विकल्प

आप Purview के इन-बिल्ट ऑडिट लॉग कनेक्टर का उपयोग कर सकते हैं, या HTTP API के ज़रिए डेटा खींच सकते हैं। Purview के भीतर Audit Log Reader भूमिका की ज़रूरत पड़ती है। सारा डेटा बिना फ़िल्टर के खींच लेना वैसा ही है जैसे एक PDF खो जाने पर पूरे इंटरनेट का बैकअप ले लेना।

फ़िल्टर और क्रेडेंशियल

फ़िल्टर दो जगह लगाया जा सकता है। एक, API के पैरामीटर्स के साथ क्वेरी के चरण पर। दूसरा, Power Automate के भीतर कंडिशनल लॉजिक से। मक़सद यह है कि पेलोड प्रबंधनीय बना रहे। क्रेडेंशियल्स को सावधानी से साइन करें और उन्हें Azure Key Vault या कनेक्शन रेफ़रेंस में सुरक्षित रखें।

हर प्रॉपर्टी एक वेरिएबल

अगर "नेस्टेड ऐरे" शब्द परेशान करता है, तो समझ लें कि यही अनुपालन कोडिंग है। user ID, operation, workload, परिणाम की स्थिति और client IP, हर प्रॉपर्टी अपना वेरिएबल बन जाती है। इसी तरह आप भविष्य के AI एजेंट को बताते हैं कि JSON के भीतर अर्थ कहाँ खोजना है।

यहाँ एक छोटी सी टाइपिंग की गलती भी बाद में बड़ी गड़बड़ी पैदा कर सकती है। इसलिए प्रॉपर्टी एक्सट्रैक्शन को पहले छोटे सैंपल रन के साथ परखें। फ़्लो को डीबग करना भले ही आकर्षक काम न लगे, पर ज़रूरी है।

स्टोरेज का चुनाव

कल की घटनाएँ आज के विश्लेषण को सूचित करती हैं, इसलिए डेटा को सहेजना ज़रूरी है। SharePoint आसान विकल्प है। लेकिन अगर आपको डेटा सेट के बीच संबंध या ज़्यादा क्षमता चाहिए, तो Dataverse, Power Automate के साथ बेहतर काम करता है।

इस चरण के बाद आपके पास एक जीवित पाइपलाइन होती है। Purview का डेटा Power Automate के रास्ते आपके चुने हुए स्टोरेज तक पहुँचता है, और अनुपालन की निरंतरता इंसानी उत्साह पर निर्भर नहीं रहती।

Power Automate लॉजिक: डुप्लिकेट हटाना, जोखिम आँकना, फ़ेल्योर सँभालना

Power Automate खुद AI नहीं है। वह न अनुमान लगाता है, न निष्कर्ष निकालता है। उसकी ताकत यह है कि वह वही काम बिना चूके दोहराता है।

Recurrence ट्रिगर से शुरुआत

Recurrence ट्रिगर इंसानी भूलने की आदत का सभ्य जवाब है। तय समय पर फ़्लो चलता है, Purview ऑडिट लॉग कनेक्टर या HTTP API को कॉल करता है, डेटा साफ़ होता है और पैटर्न खोजे जाते हैं।

डुप्लिकेट हटाना

कई लॉग स्ट्रीम एक जैसी घटनाएँ दोहराती हैं। एक सरल union या लूप तुलना से डुप्लिकेट हटाए जा सकते हैं। जो बचता है, वही असली संकेत है।

जोखिम स्तर तय करना

सिस्टम को आपकी परिभाषित थ्रेशोल्ड के हिसाब से जोखिम का अनुमान लगाने दें। उदाहरण के लिए, अगर privilege escalation की संख्या तीन है तो जोखिम स्तर High रखें। अगर external share एक है तो उसे Medium रखें।

जब कुछ भी असामान्य न मिले, तो चुप रहने के बजाय "कोई findings नहीं" का संदेश लॉग करें। डेटा की कमी और डेटा का न होना, दोनों में अनुपालन के लिहाज़ से बड़ा अंतर है।

रीट्राई और हेल्थ लॉग

थ्रेशोल्ड ट्रिगर होने के बाद आप चाहें तो चरणों को ऐसे स्कोप कंटेनर में लपेट सकते हैं जिसमें तीन प्रयास और exponential back-off हो। विफलता की स्थिति में एरर मैसेज, टाइमस्टैम्प और फ़्लो रन ID को SharePoint लिस्ट या Dataverse टेबल में "Automation Health" नाम से लॉग करें। इस तरह हर फ़्लो अपने निष्पादन का सबूत खुद लिखता है।

अंत में एक Append to file या Create item एक्शन जोड़ें, जो मुख्य मेट्रिक्स समेटे:

• कुल प्रोसेस की गई घटनाएँ
• सबसे अधिक जोखिम वाला यूज़र
• रन टाइम की अवधि

इस बिंदु पर ऑटोमेशन वर्गीकरण कर सकता है और जान लेता है कि जोखिम स्तर कब नीति का उल्लंघन करते हैं। फिर भी वह कुछ कहता नहीं, और इंसानों को यह चुप्पी अजीब लगती है। यहीं Copilot Studio की भूमिका आती है।

Copilot Studio से रिपोर्ट की भाषा: सारांश, परिशिष्ट और सिफ़ारिश

Copilot Studio को कोड और समिति की बैठकों के बीच फँसे एक द्विभाषी वार्ताकार की तरह देखें। वह कहानियाँ नहीं गढ़ता, वह वास्तविकता को ऐसे वाक्यों में लिखता है जिन्हें इंसान समझ सकें। पहले तय करें कि आप किस तरह का संवाद चाहते हैं। आम तौर पर तीन रूप होते हैं, और हर एक अलग पाठक के लिए है:

1. कार्यकारी सारांश: प्रबंधन को सिर्फ़ एक पैराग्राफ़ चाहिए।
2. तकनीकी परिशिष्ट: सभी उच्च जोखिम वाली घटनाओं की सूची, तालिका के रूप में।
3. सिफ़ारिश: हर श्रेणी के लिए सुझाई गई कार्रवाई।

Power Automate को Copilot Studio से जोड़ना

फ़्लो में एक HTTP एक्शन का उपयोग करें, जो संरचित JSON और रिपोर्ट का टेक्स्ट Copilot Studio तक पहुँचाए। साथ में ऐसे निर्देश दें कि परिणामों को संक्षिप्त अनुपालन रिपोर्ट में प्रस्तुत किया जाए, गंभीरता के आधार पर वर्गीकृत किया जाए, और हर श्रेणी के लिए कार्रवाई की सिफ़ारिश दी जाए। यह जनरेटिव अटकलबाज़ी नहीं है। यह निर्धारक संकेतों पर आधारित संरचित सारांश है, जो प्रॉम्प्ट का पालन करता है।

निर्देशों में टोन और प्लेसहोल्डर

निर्देशों में ही पेशेवर, तटस्थ लहजा तय कर दें और सट्टेबाज़ी वाली भाषा से बचने को कहें। मात्रात्मक मेट्रिक्स शामिल करने को कहें। इमोजी वाली ऑडिट रिपोर्ट केवल अराजकता के काम आती है। तारीख और रिकॉर्ड की संख्या के लिए प्लेसहोल्डर रखें। फ़्लो जब Copilot को कॉल करता है, तो वेरिएबल अपने-आप भर जाते हैं और रिपोर्ट के शीर्षक में सही तारीख आ जाती है।

दो शाखाओं में प्रकाशन

आउटपुट के लिए दो समानांतर शाखाएँ रखी जा सकती हैं। एक शाखा Copilot का सारांश सीधे Teams चैनल में पोस्ट करती है। दूसरी SharePoint में पूरा HTML संस्करण लॉग करती है। प्रबंधन Teams की पोस्ट पढ़ता है और ऑडिटर दस्तावेज़ीकरण के लिए आर्काइव खोलता है।

पूरा प्रवाह इस तरह दिखता है: Extract, Analyze, Summarize, Narrate, Publish। जब भी अनुपालन की शब्दावली बदले, सिस्टम प्रॉम्प्ट को नया संस्करण दे दें। रिपोर्ट की भाषा बदल जाएगी और बाकी ढाँचा वैसा ही चलता रहेगा।

आम गलतियाँ और स्टोलपरस्टाइन

• सारा डेटा खींच लेना: बिना फ़िल्टर के पूरा लॉग लाने से पेलोड भारी हो जाता है। पहले तय करें कि कौन सी घटनाएँ मायने रखती हैं।
• प्रॉपर्टी के नाम में टाइपिंग की गलती: एक छोटी चूक बाद में बड़ी गड़बड़ी बनती है। हमेशा छोटे सैंपल रन से शुरू करें।
• डुप्लिकेट को न हटाना: अलग-अलग लॉग स्ट्रीम एक ही घटना दोहराती हैं, जिससे गिनती और जोखिम स्कोर बिगड़ सकते हैं।
• "कोई findings नहीं" को लॉग न करना: चुप्पी से पता नहीं चलता कि डेटा था ही नहीं या जाँच हुई ही नहीं।
• API थ्रॉटलिंग की अनदेखी: Purview का API बहुत अधिक अनुरोधों पर रुकावट डाल सकता है। इसलिए रीट्राई और error tolerance कॉन्फ़िगर करें। ऑडिटर गलतियों पर नहीं, उन्हें दस्तावेज़ित न करने पर दंडित करते हैं।
• क्रेडेंशियल की लापरवाही: इन्हें सुरक्षित तरीके से साइन करें और Azure Key Vault या कनेक्शन रेफ़रेंस में रखें।
• रिपोर्ट में अनौपचारिक भाषा: इमोजी और अटकलों वाली भाषा से बचें, वरना रिपोर्ट की विश्वसनीयता घटती है।

व्यावहारिक सीख

• पहले तय करें कि कौन सी Purview घटनाएँ अनुपालन के लिए मायने रखती हैं, फिर डेटा लाएँ।
• API पैरामीटर्स या कंडिशनल लॉजिक से शुरुआत में ही डेटा फ़िल्टर करें।
• user ID, operation, workload, परिणाम की स्थिति और client IP को अलग-अलग वेरिएबल बनाएँ।
• Recurrence ट्रिगर से रिपोर्टिंग को नियमित समय पर चलाएँ।
• जोखिम की थ्रेशोल्ड साफ़ परिभाषित करें और डुप्लिकेट हटाएँ।
• रीट्राई और "Automation Health" लॉग रखें, ताकि हर रन का सबूत मौजूद रहे।
• Copilot Studio के निर्देशों में पेशेवर लहजा, मेट्रिक्स और तारीख-रिकॉर्ड के प्लेसहोल्डर शामिल करें।
• सारांश Teams में और पूरा HTML संस्करण SharePoint में रखें।

निष्कर्ष

Purview, Power Automate और Copilot Studio का मेल GRC रिपोर्टिंग को हाथ के काम से ऑर्केस्ट्रेशन में बदल देता है। Purview याददाश्त देता है, Power Automate नियमित और भरोसेमंद लॉजिक देता है, और Copilot Studio नतीजों को पढ़ने योग्य भाषा देता है। इससे अनुपालन किसी की मेहनत या याददाश्त का मोहताज नहीं रहता। रिपोर्टें तय अंतराल पर Teams में दिखती हैं, और ऑडिटर के लिए पूरा रिकॉर्ड आर्काइव में तैयार रहता है। मैन्युअल GRC रिपोर्टिंग टाइपराइटर जैसी है, जबकि यह एजेंट एक हमेशा सक्रिय प्रणाली है जो अनुपालन की निगरानी करती है और उसकी रिपोर्ट भी खुद तैयार करती है।