आज तुम्ही वापरत असलेले प्रत्येक सॉफ्टवेअर एकाच गृहितकावर आधारित आहे. बोटांसह कोणीतरी समोर बसले आहे

आज तुम्ही वापरत असलेले प्रत्येक सॉफ्टवेअर एकाच गृहितकावर आधारित आहे. स्क्रीनसमोर बोटांसह कोणीतरी बसले आहे. बटणे हे हेतू दर्शवतात. विझार्ड्स (Wizards) गुंतागुंत हाताळतात. फॉर्म्स मानवी विचारांना एक रचना देतात. ही आर्किटेक्चर दशकानुदशके उत्पादन डिझाइनवर राज्य करत आहे कारण, अलीकडेपर्यंत फक्त मानवांनीच क्लिक केले होते.

ते गृहितक आता मोडीत निघाले आहे. AI एजंट्स इंटरफेस वाचत नाहीत. त्यांना उपयुक्त टूलटिप्स (tooltips) किंवा कन्फर्मेशन डायलॉग्स (confirmation dialogs) पासून काहीही फायदा होत नाही. जेव्हा एखाद्या स्वायत्त प्रणालीला (autonomous system) वापरकर्त्याच्या वतीने काम करायचे असते, तेव्हा UI घटक (chrome) अडथळा ठरतात. याचा परिणाम म्हणजे उत्पादने कशी बनवली जातात आणि आधुनिक कॉलर्स (callers) प्रत्यक्षात कसे वागतात, यामध्ये वाढती विसंगती निर्माण होत आहे.

क्लिक पॅराडाइम (The Click Paradigm)

पारंपारिक सॉफ्टवेअर एका दृश्य करारावर (visual contract) अवलंबून असते. माणूस बटण पाहतो, लेबल समजून घेतो आणि ते दाबायचे की नाही याचा निर्णय घेतो. वर्कफ्लोमध्ये (workflows) मुद्दामहून काही अडथळे (friction) ठेवले जातात. मल्टी-स्टेप विझार्ड्स यासाठी असतात कारण लोक चुका करतात आणि त्यांना मार्गदर्शनाची (guardrails) गरज असते. ड्रॉपडाउन आणि रेडिओ बटणे इनपुट मर्यादित करतात कारण मुक्त मजकूर (freeform text) गोंधळ निर्माण करू शकतो.

जेव्हा ऑपरेटर माणूस असतो तेव्हा हे चांगले काम करते. परंतु जेव्हा ऑपरेटर एक एजंट असतो, तेव्हा हे व्यवस्था कोसळते. सबस्क्रिप्शन रद्द करण्यासाठी किंवा रेकॉर्डमध्ये बदल करण्यासाठी मशीनला पाच-टप्प्यांच्या विझार्डची गरज नसते. त्याला कोणत्या ऑपरेशन्स उपलब्ध आहेत याचे स्पष्ट विधान आणि ती करण्याची परवानगी आहे की नाही याचे निश्चित उत्तर हवे असते. जेव्हा टीम्स याकडे दुर्लक्ष करतात, तेव्हा ते सहसा दोन शॉर्टकटचा वापर करतात.

पहिले म्हणजे, ते एजंटला API की (API key) देतात. दुसरे म्हणजे, ते विद्यमान युजर इंटरफेस चॅटबॉटमध्ये गुंडाळतात आणि इंटिग्रेशन पूर्ण झाले असे मानतात. यापैकी कोणताही दृष्टिकोन मूळ समस्या सोडवत नाही.

API की या प्रश्नाचे उत्तर देते की, “ही विनंती विश्वसनीय स्त्रोताकडून आली आहे का?” पण ती महत्त्वाच्या प्रश्नाचे उत्तर कधीच देत नाही: “हा विशिष्ट कॉलर हा विशिष्ट रेकॉर्ड वाचू शकतो का?” की (key) ही एका 'स्केलेटन की' (skeleton key) सारखी असते. एकदा ती दिली की, ती सहसा विविध रिसोर्सेस आणि संदर्भांमध्ये व्यापक प्रवेश देते. तुमच्या सिस्टममधील वैयक्तिक कृतींचे नियमन करणाऱ्या पॉलिसीबद्दल तिला काहीही माहिती नसते.

GUI ला चॅटबॉटमध्ये गुंडाळणे हे अधिक नाजूक आहे. इंटरफेसमध्ये समाविष्ट असलेले प्रत्येक मानवकेंद्रित गृहितक एजंटला वारसा म्हणून मिळते. ते स्वायत्त लॉजिकसाठी नाही, तर मानवी डोळ्यांसाठी डिझाइन केलेल्या मोडाल्स (modals) आणि फॉर्म्सद्वारे क्लिक्सचे अनुकरण करते. चॅटबॉट क्रोममध्ये यशस्वीरित्या नेव्हिगेट करू शकेल, पण ते समजून न घेता करते. हे केवळ 'ऑटोमेशन थिएटर' (automation theater) आहे. प्रत्यक्षात, काय परवानगी आहे याबद्दल कोणताही मशीन-रीडेबल करार (machine-readable contract) तिथे नसतो.

एजंट्सना मुख्य दरवाजाची आणखी एक चावी नको आहे. त्यांना 'गेट्स' (gates) हवे आहेत.

गेट्स प्रत्यक्षात काय करतात

गेट हे एक नियंत्रित एक्झिक्यूशन लेअर (governed execution layer) आहे. केवळ क्रेडेंशियलवर (credential) विश्वास ठेवून आणि कॉलर नीट वागेल अशी आशा करण्याऐवजी, गेट्स असलेली प्रणाली प्रत्येक विनंतीची घोषित नियमांनुसार तपासणी करते. हे नियम कोणत्याही इंटरफेसपासून (मानवी किंवा अन्य) स्वतंत्रपणे अस्तित्वात असतात.

एक योग्य गेट चार गोष्टी परिभाषित करते. ते उत्पादनामध्ये कोणत्या कृती उपलब्ध आहेत हे घोषित करते. कोण कोणत्या परिस्थितीत त्या कृती करू शकते हे सांगते. 'साइड इफेक्ट्स' (side effects) निर्माण करण्यापूर्वी कॉलरने कधी थांबून स्पष्ट संमती (explicit consent) मागितली पाहिजे, हे ते निर्दिष्ट करते. आणि प्रणाली प्रत्येक निर्णय एका संरचित (structured), क्वेरी करण्यायोग्य (queriable) ट्रेलमध्ये नोंदवते याची ते खात्री करते.

हे पारंपारिक ॲक्सेस कंट्रोलपेक्षा (access control) मूलभूतपणे वेगळे आहे. रोल-बेस्ड सिस्टम्स (Role-based systems) अनेकदा दरवाजावर “तुम्ही ॲडमिन आहात का?” असे विचारतात आणि नंतर तुम्हाला इमारतीत फिरू देतात. गेट्स प्रत्येक वळणावर विचारतात, “तुम्हाला आत्ताच हा विशिष्ट स्विच चालू करण्याची परवानगी आहे का?” येथे ओळख (identity) ही वर्तनापेक्षा (behavior) दुय्यम ठरते. पॉलिसी ही कृतीसोबत प्रवास करते.

हे अधिक स्पष्ट करण्यासाठी, एका ग्राहकाला रिफंड देण्याची गरज असलेल्या एजंटची कल्पना करा. की-बेस्ड दृष्टिकोन (key-based approach) जर एंडपॉइंट उपलब्ध असेल, तर की धारण करणाऱ्या कोणालाही रिफंड प्रक्रिया करण्याची परवानगी देऊ शकतो. गेट-बेस्ड दृष्टिकोन उपलब्ध कृतींची यादी (manifest) तपासतो, विशिष्ट ग्राहक रेकॉर्डच्या संदर्भात एजंटच्या परवानगीची पडताळणी करतो, आर्थिक साइड इफेक्टसाठी वापरकर्त्याची स्पष्ट मंजुरी घेतो आणि संपूर्ण प्रक्रिया ऑडिट लॉगमध्ये (audit log) नोंदवतो. गेट केवळ ओळख नाही, तर पॉलिसी लागू करते.

Whistler वर याची चाचणी

आम्ही हे मॉडेल Whistler वर वापरून पाहिले. मानव आणि मशीनसाठी वेगळी पाइपलाइन्स (pipelines) तयार करण्याऐवजी, आम्ही एकच पॉलिसी लेअर (policy layer) लिहिला आणि त्यावर दोन वेगवेगळ्या कॉलर्सची चाचणी घेतली.

एक कॉलर एम्बेडेड Shell वापरणारा माणूस होता. दुसरा आमच्या टीमच्या बाहेर विकसित केलेला थर्ड-पार्टी एजंट होता. दोन्ही एकाच मॅनिफेस्टशी (manifest) जोडले गेले होते. दोन्हीला प्रत्येक टप्प्यावर समान परवानगी तपासणीचा (permission checks) सामना करावा लागला. जेव्हा कोणत्याही कॉलरने डेटा बदलणे किंवा बाह्य इव्हेंट ट्रिगर करणे यांसारख्या साइड इफेक्ट्स असलेल्या कृती करण्याचा प्रयत्न केला, तेव्हा सिस्टमने स्पष्ट मंजुरीची आवश्यकता दर्शवली. प्रत्येक विनंती, मंजुरी आणि नकारामुळे एकच संरचित ऑडिट ट्रेल (audit trail) तयार झाला.

कोणत्याही कॉलर्सनी मास्टर API की वापरली नाही. कोणताही बॅकडोअर नव्हता, किंवा धोरण (policy) बायपास करणारी कोणतीही उच्च दर्जाची क्रेडेंशियल नव्हती. पासवर्ड आणि ब्राउझर असल्यामुळे मानवाला कमी निर्बंध मिळाले नाहीत. मानवी फिंगरप्रिंट नसल्यामुळे एजंटला अनियंत्रित अडथळ्यांचा सामना करावा लागला नाही. गेटने कृती, संदर्भ आणि नियमांचे मूल्यमापन केले. तो संपूर्ण व्यवहार होता.

परिणामी अशी एक प्रणाली तयार झाली जिथे नवीन कॉलर्सना (मानव किंवा मशीन) जोडण्यासाठी ॲक्सेस लॉजिकच्या रिफॅक्टरिंगची (refactoring) गरज नव्हती. तुम्ही फक्त पॉलिसी अपडेट केली आणि गेटने त्याची अंमलबजावणी केली.

प्रॉडक्टच्या प्रश्नावर पुनर्विचार

जर तुमची टीम सध्या मानवाकडून तयार केलेल्या प्रॉडक्टमध्ये AI एजंट्स कसे जोडायचे याचा विचार करत असेल, तर तुम्ही कदाचित चुकीच्या प्रश्नापासून सुरुवात करत आहात. टीम्स सहसा आपोआप विचारतात की त्यांनी API उपलब्ध करून द्यावा का. त्याऐवजी त्यांनी हे विचारले पाहिजे की त्यांच्याकडे प्रत्येक कॉलर्ससाठी एक नियंत्रित एक्झिक्यूशन लेअर (governed execution layer) आहे का.

गेटशिवाय असलेला API म्हणजे केवळ एक मोठा दरवाजा आहे. जर तुमची अंतर्गत धोरणे केवळ विझार्ड लॉजिक, फॉर्म व्हॅलिडेशन आणि मानवाला वाचता येईल अशा हेल्प टेक्स्टमध्ये मर्यादित असतील, तर तुम्ही प्रकाशित केलेला कोणताही एंडपॉइंट स्वायत्त कॉलर्ससाठी सुरक्षित नसेल. एजंट एकतर की (key) द्वारे खूप जास्त विश्वास प्राप्त करेल किंवा चॅटबॉट रॅपरद्वारे नाजूक कठपुतळी खेळण्यासारखे (brittle puppetry) काम करेल.

प्रथम गेट्स तयार करणे म्हणजे तुमच्या प्रॉडक्टमधील प्रत्येक अर्थपूर्ण कृतीला एक 'घोषित ऑपरेशन' (declared operation) म्हणून सूचीबद्ध करणे. याचा अर्थ युजर इंटरफेसपासून परवानगी तपासणी (permission check) वेगळी करणे, जेणेकरून शेल युजर आणि बाह्य एजंट या दोघांनाही समान रनटाइम अंमलबजावणीचा सामना करावा लागेल. याचा अर्थ विनाशकारी क्रियांसाठी (destructive operations) त्यांची गरज पडण्यापूर्वीच 'संमती हुक्स' (consent hooks) समाविष्ट करणे, एजंटने चुकीचा डेटासेट पुसून टाकल्यानंतर नाही. आणि याचा अर्थ असे ऑडिट ट्रेल्स तयार करणे ज्याची सुरक्षा आणि अनुपालन (compliance) टीम्स तपासू शकतील, मग कॉलर्स कार्बन (मानव) असो वा सिलिकॉन (मशीन).

यासाठी खऱ्या अर्थाने आर्किटेक्चरल बदलाची आवश्यकता आहे. मानव-केंद्रित डिझाइन लॉजिकला सहानुभूती आणि 'फ्रिक्शन'मध्ये गुंडाळते. एजंट-रेडी डिझाइन स्पष्ट, मशीन-रीडेबल कॉन्ट्रॅक्ट्सद्वारे लॉजिक उघड करते. इंटरफेस हे धोरण (policy) राहणे थांबते; मॅनिफेस्ट हे धोरण बनते.

हा बदल मानवांना बदलण्याबद्दल नाही. तर तुमचे सॉफ्टवेअर आता एकापेक्षा जास्त प्रकारचे कॉलर्स वापरत आहे हे मान्य करण्याबद्दल आहे. प्रत्येकाला समान शिस्तीची (rigor) गरज आहे.

मुख्य निष्कर्ष

क्लिकसाठी डिझाइन करणे थांबवा. नियमासाठी डिझाइन करण्यास सुरुवात करा. जर तुमची प्रणाली घोषित कृती, संदर्भातील परवानग्या, संमती तपासणी आणि सामायिक ऑडिट ट्रेल्सद्वारे प्रत्येक कॉलर्सवर नियंत्रण ठेवू शकत असेल, तर दुसऱ्या टोकाला कोण किंवा काय आहे याने फरक पडत नाही. मानव असो वा एजंट, त्या सर्वांना एकाच गेटचा सामना करावा लागतो. प्रथम गेट तयार करा. API हा केवळ एक दरवाजा आहे. पॉलिसीमुळेच खोली सुरक्षित राहते.