AI गवर्नेंस फ्रेमवर्क पढ़ने में बहुत अच्छे लगते हैं। वे भूमिकाएं सौंपते हैं, सिद्धांतों को सूचीबद्ध करते हैं और समीक्षा बोर्डों का खाका तैयार करते हैं। लेकिन एक फ्रेमवर्क उसी क्षण उपयोगी होना बंद हो जाता है जब कोई कर्मचारी किसी सार्वजनिक चैटबॉट में ग्राहक का फीडबैक पेस्ट कर देता है, या जब कोई बैकएंड API चुपचाप व्यक्तिगत रूप से पहचान योग्य जानकारी (PII) को किसी बाहरी मॉडल पर भेज देता है। गवर्नेंस का असली काम किसी कमेटी रूम में नहीं होता है। यह एक्सेस पाथ (access path) पर होता है। यह वही सटीक बिंदु है जहाँ कोई व्यक्ति, एप्लिकेशन या API एंडपॉइंट पहली बार किसी AI मॉडल तक पहुँचता है। यदि आप वहां अपने नियमों को लागू नहीं कर सकते, तो आपके पास गवर्नेंस नहीं है। आपके पास केवल एक इच्छा सूची (wish list) है।
फ्रेमवर्क और वास्तविकता के बीच का अंतर
अधिकांश संगठनों ने पिछले दो साल AI काउंसिल बनाने, स्वीकार्य-उपयोग नीतियों (acceptable-use policies) का मसौदा तैयार करने और कर्मचारियों को प्रशिक्षण देने में बिताए हैं। ये प्रयास महत्वपूर्ण हैं। वे अपेक्षाएं निर्धारित करते हैं। हालाँकि, वे यह नहीं देख पाते कि मंगलवार की दोपहर के कोडिंग सत्र के दौरान क्या होता है जब एक डेवलपर समय बचाने के लिए किसी अनसेंसर्ड ब्राउज़र एक्सटेंशन के माध्यम से मालिकाना सोर्स कोड (proprietary source code) भेज देता है। फ्रेमवर्क दस्तावेजों में रहते हैं। काम टर्मिनल्स, ब्राउज़रों और API कॉल्स में होता है।
इसका परिणाम एक अनुमानित ब्लाइंड स्पॉट (blind spot) के रूप में निकलता है। नेतृत्व को लगता है कि AI का उपयोग नियंत्रित है क्योंकि नीति ऐसा कहती है, जबकि ऑपरेशन्स एक अलग कहानी बताते हैं। यह विसंगति महंगी पड़ती है। बिना मास्क किया हुआ स्वास्थ्य रिकॉर्ड या अनरिलीज़्ड वित्तीय डेटा वाला एक सिंगल प्रॉम्प्ट अनुपालन उल्लंघन (compliance breach), नियामक जांच, या उस तरह की सार्वजनिक घटना को ट्रिगर कर सकता है जिसे कोई भी माफीनामा ठीक नहीं कर सकता। दुरुपयोग का पता लगाने के लिए ऑडिट का इंतज़ार करना बहुत देर हो चुकी होती है। वास्तविक गवर्नेंस के लिए केवल कागजी कार्रवाई की नहीं, बल्कि स्वयं इंटरैक्शन में दृश्यता (visibility) की आवश्यकता होती है।
एक्सेस पाथ (Access Path) का वास्तव में क्या अर्थ है
एक्सेस पाथ कोई अमूर्त अवधारणा नहीं है। यह वह सटीक क्षण है जब कोई अनुरोध आपके वातावरण से निकलता है और एक AI मॉडल की ओर बढ़ता है। वह अनुरोध एक स्वीकृत वेब इंटरफेस का उपयोग करने वाले मार्केटिंग मैनेजर से, कर्मचारियों के सवालों के जवाब देने वाले Slack बॉट से, या सपोर्ट टिकटों का सारांश निकालने के लिए API को कॉल करने वाली एक माइक्रोसर्विस से आ सकता है। प्रत्येक पाथ के अपने जोखिम होते हैं, और प्रत्येक को अपने स्वयं के गार्डरेल्स (guardrails) की आवश्यकता होती है।
इस किनारे (edge) पर नियंत्रण बिंदु के बिना, आपके संगठन के पास एक कर्मचारी द्वारा मॉडल से आंतरिक ईमेल को फिर से लिखने के लिए कहने और एक कर्मचारी द्वारा अकाउंट नंबरों से भरी स्प्रेडशीट अपलोड करने के बीच अंतर करने का कोई तरीका नहीं है। दोनों ट्रैफ़िक की तरह दिखते हैं। केवल एक को ही आगे बढ़ने की अनुमति दी जानी चाहिए। जब तक आप इस सीमा (boundary) पर नियंत्रण नहीं पाते, तब तक आपके प्रत्यक्ष नियंत्रण से बाहर का प्रत्येक AI मॉडल अनिवार्य रूप से एक अंधेरी गलियारा है जहाँ डेटा बिना किसी की नज़र में आए बाहर जा सकता है।
नौ प्रश्न जिनका उत्तर आर्किटेक्चर को देना चाहिए
किसी भी प्रॉम्प्ट के मॉडल तक पहुँचने से पहले, आपके सिस्टम को नौ विशिष्ट प्रश्नों के उत्तर देने में सक्षम होना चाहिए। पहचान और इरादे (identity and intent) से शुरुआत करें। अनुरोध कौन भेज रहा है? व्यावसायिक उपयोग का मामला (business use case) क्या है? कौन सा विभाग या सिस्टम इसका मालिक है? ये तीन प्रश्न यह स्थापित करते हैं कि क्या इंटरैक्शन वैध और पता लगाने योग्य (traceable) है।
इसके बाद डेटा और मॉडल सुरक्षा आती है। प्रॉम्प्ट में कौन सा डेटा जा रहा है? कौन सा AI मॉडल इसे प्रोसेस करेगा? क्या वह विशिष्ट मॉडल इस विशिष्ट कार्य के लिए स्वीकृत है? क्या आपको अपने वातावरण से बाहर जाने से पहले संवेदनशील डेटा को मास्क या ब्लॉक करने की आवश्यकता है?
अंत में परिचालन जवाबदेही (operational accountability) आती है। क्या आपने एक्सेस को रिकॉर्ड किया