AI गव्हर्नन्स फ्रेमवर्क्स (AI governance frameworks) वाचायला उत्तम असतात. ते भूमिका निश्चित करतात, तत्त्वे सूचीबद्ध करतात आणि रिव्ह्यू बोर्ड्सची (review boards) रचना करतात. परंतु, जेव्हा एखादा कर्मचारी ग्राहकांचा फीडबॅक (customer feedback) सार्वजनिक चॅटबॉटमध्ये पेस्ट करतो, किंवा जेव्हा एखादा बॅकएंड API (backend API) शांतपणे वैयक्तिकरित्या ओळखण्यायोग्य माहिती (personally identifiable information) बाह्य मॉडेलकडे पाठवतो, तेव्हाच ते फ्रेमवर्क निरुपयोगी ठरते. गव्हर्नन्सचे खरे काम कमिटी रूममध्ये होत नाही. ते ॲक्सेस पाथ (access path) वर घडते. हा तो नेमका बिंदू आहे जिथे एखादी व्यक्ती, ॲप्लिकेशन किंवा API एंडपॉइंट (API endpoint) पहिल्यांदा AI मॉडेलशी संपर्क साधते. जर तुम्ही तिथे तुमचे नियम लागू करू शकत नसाल, तर तुमच्याकडे गव्हर्नन्स नाही. तुमच्याकडे फक्त एक 'विश लिस्ट' (wish list) आहे.
फ्रेमवर्क्स आणि वास्तव यातील तफावत
बहुतेक संस्थांनी गेल्या दोन वर्षांत AI कौन्सिल (AI councils) तयार करणे, स्वीकारार्ह-वापर धोरणे (acceptable-use policies) मसुदा करणे आणि कर्मचाऱ्यांचे प्रशिक्षण घेणे यामध्ये वेळ घालवला आहे. हे प्रयत्न महत्त्वाचे आहेत. ते अपेक्षा निश्चित करतात. तथापि, मंगळवारच्या दुपारच्या कोडिंग सेशन दरम्यान जेव्हा एखादा डेव्हलपर वेळ वाचवण्यासाठी अनसेन्सर्ड ब्राउझर एक्सटेंशनद्वारे (uncensored browser extension) मालकीचा सोर्स कोड (proprietary source code) पाठवतो, तेव्हा काय घडते हे या प्रयत्नांना दिसत नाही. फ्रेमवर्क्स कागदपत्रांमध्ये असतात. काम टर्मिनल्स, ब्राउझर्स आणि API कॉल्समध्ये (API calls) चालते.
याचा परिणाम म्हणजे एक अपेक्षित 'ब्लाईंड स्पॉट' (blind spot) तयार होतो. धोरण असे सांगत असल्यामुळे नेतृत्व मानतो की AI चा वापर नियंत्रित आहे, परंतु ऑपरेशन्स (operations) वेगळीच गोष्ट सांगतात. हा विसंवाद महागडा पडू शकतो. अनमास्क केलेले आरोग्य रेकॉर्ड्स किंवा अनरिलीज्ड आर्थिक डेटा असलेले एक सिंगल प्रॉम्प्ट (single prompt) कंप्लायन्स उल्लंघन (compliance breach), नियामक चौकशी (regulatory inquiry), किंवा अशा प्रकारची सार्वजनिक घटना घडवू शकते जी कोणत्याही माफीनामा (apology tour) ने सुधारता येणार नाही. गैरवापर शोधण्यासाठी ऑडिटची वाट पाहणे खूप उशीर झालेले असते. खऱ्या गव्हर्नन्ससाठी केवळ कागदपत्रांची गरज नसते, तर त्या परस्परसंवादातील (interaction) दृश्यमानता (visibility) आवश्यक असते.
ॲक्सेस पाथचा (Access Path) नेमका अर्थ काय आहे
ॲक्सेस पाथ ही कोणतीही अमूर्त संकल्पना नाही. जेव्हा एखादी विनंती (request) तुमच्या वातावरणातून बाहेर पडते आणि AI मॉडेलकडे जाते, तो नेमका क्षण म्हणजे ॲक्सेस पाथ. ती विनंती मंजूर केलेल्या वेब इंटरफेसचा वापर करणाऱ्या मार्केटिंग मॅनेजरकडून, कर्मचाऱ्यांच्या प्रश्नांची उत्तरे देणाऱ्या Slack बॉटकडून, किंवा सपोर्ट तिकीट सारांशित करण्यासाठी API कॉल करणाऱ्या मायक्रोसर्व्हिसकडून (microservice) येऊ शकते. प्रत्येक मार्गाला स्वतःचे धोके असतात आणि प्रत्येकासाठी स्वतःचे गार्डरेल्स (guardrails) आवश्यक असतात.
या टोकावर (edge) नियंत्रण बिंदू (control point) असल्याशिवाय, तुमच्या संस्थेकडे एखादा कर्मचारी अंतर्गत ईमेल पुन्हा लिहिण्यासाठी मॉडेलला सांगणे आणि एखादा कर्मचारी खाते क्रमांकांनी भरलेली स्प्रेडशीट अपलोड करणे, यामधील फरक ओळखण्याचा कोणताही मार्ग नसतो. दोन्ही ट्रॅफिकसारखेच दिसतात. केवळ एकालाच पुढे जाण्याची परवानगी दिली पाहिजे. जोपर्यंत तुम्ही या सीमेवर नियंत्रण मिळवत नाही, तोपर्यंत तुमच्या थेट नियंत्रणाबाहेरील प्रत्येक AI मॉडेल हे मूलतः एक अंधारलेला मार्ग (dark corridor) आहे जिथून डेटा कोणाच्याही लक्षात न येता बाहेर जाऊ शकतो.
आर्किटेक्चरने (Architecture) उत्तर द्यायला हवे असे नऊ प्रश्न
कोणताही प्रॉम्प्ट मॉडेलपर्यंत पोहोचण्यापूर्वी, तुमच्या सिस्टमला नऊ विशिष्ट प्रश्नांची उत्तरे देता आली पाहिजेत. ओळख आणि हेतूपासून (identity and intent) सुरुवात करा. विनंती कोण पाठवत आहे? बिझनेस युज केस (business use case) काय आहे? कोणता विभाग किंवा सिस्टम त्याची मालक आहे? हे तीन प्रश्न परस्परसंवाद वैध आणि शोधण्यायोग्य (traceable) आहे की नाही हे ठरवतात.
त्यानंतर डेटा आणि मॉडेल सुरक्षा (data and model safety) येते. प्रॉम्प्टमध्ये कोणता डेटा जात आहे? कोणता AI मॉडेल त्यावर प्रक्रिया करेल? ते विशिष्ट मॉडेल या विशिष्ट कार्यासाठी मंजूर आहे का? तुमच्या वातावरणातून बाहेर पडण्यापूर्वी तुम्हाला संवेदनशील डेटा (sensitive data) मास्क किंवा ब्लॉक करण्याची आवश्यकता आहे का?
शेवटी ऑपरेशनल अकाऊंटेबिलिटी (operational accountability) येते. तुम्ही ॲक्सेस रेकॉर्ड केला का