Every piece of software you use today was built around a single assumption. Someone with fingers is sitting in front of

இன்று நீங்கள் பயன்படுத்தும் ஒவ்வொரு மென்பொருளும் ஒரு ஒற்றை அனுமானத்தின் அடிப்படையில் உருவாக்கப்பட்டது. திரைக்கு முன்னால் விரல்களைக் கொண்ட ஒருவர் அமர்ந்திருக்கிறார் என்பதே அது. பொத்தான்கள் (Buttons) நோக்கத்தைக் குறிக்கின்றன. விஸார்டுகள் (Wizards) சிக்கல்களைக் கையாளுகின்றன. படிவங்கள் (Forms) மனிதச் சிந்தனையை முறைப்படுத்துகின்றன. சமீப காலம் வரை மனிதர்கள் மட்டுமே கிளிக் செய்ததால், இந்த கட்டமைப்பு பல தசாப்தங்களாகத் தயாரிப்பு வடிவமைப்பைக் (product design) கட்டுப்படுத்தி வருகிறது.

அந்த அனுமானம் இப்போது உடைந்துவிட்டது. AI ஏஜெண்டுகள் (agents) இடைமுகங்களை (interfaces) வாசிப்பதில்லை. பயனுள்ள டூல்டிப்கள் (tooltips) அல்லது உறுதிப்படுத்தல் விண்டோக்கள் (confirmation dialogs) அவற்றிற்குப் பயனளிக்காது. ஒரு தன்னாட்சி அமைப்பு (autonomous system) ஒரு பயனரின் சார்பாகச் செயல்பட வேண்டியிருக்கும் போது, இடைமுகத்தின் கூறுகள் (chrome) இடையூறாக அமைகின்றன. இதன் விளைவாக, தயாரிப்புகள் எவ்வாறு உருவாக்கப்படுகின்றன என்பதற்கும், நவீன அழைப்பாளர்கள் (callers) உண்மையில் எவ்வாறு செயல்படுகிறார்கள் என்பதற்கும் இடையே ஒரு இடைவெளி அதிகரித்து வருகிறது.

கிளிக் முறை (The Click Paradigm)

பாரம்பரிய மென்பொருள்கள் ஒரு காட்சி ஒப்பந்தத்தை (visual contract) நம்பியுள்ளன. ஒரு மனிதன் ஒரு பொத்தானைப் பார்க்கிறான், அதன் லேபிளைப் புரிந்துகொள்கிறான், மேலும் அதை அழுத்த வேண்டுமா வேண்டாமா என்று தீர்மானிக்கிறான். பணிப்பாய்வுகள் (Workflows) வேண்டுமென்றே சில தடைகளுடன் (friction) வடிவமைக்கப்படுகின்றன. மனிதர்கள் தவறுகள் செய்யக்கூடும் என்பதால் மற்றும் அவர்களுக்குக் கட்டுப்பாடுகள் (guardrails) தேவைப்படுவதால், பல படிநிலைகளைக் கொண்ட விஸார்டுகள் (wizards) உள்ளன. டிராப்டவுன்கள் (dropdowns) மற்றும் ரேடியோ பொத்தான்கள் (radio buttons) உள்ளீடுகளைக் கட்டுப்படுத்துகின்றன, ஏனெனில் சுதந்திரமான உரை (freeform text) குழப்பத்தை ஏற்படுத்தும்.

இயக்கி (operator) ஒரு மனிதராக இருக்கும்போது இது நன்றாகச் செயல்படுகிறது. ஆனால் இயக்கி ஒரு ஏஜெண்டாக இருக்கும்போது இது தோல்வியடைகிறது. ஒரு சந்தாவை ரத்து செய்யவோ அல்லது ஒரு பதிவைத் திருத்தவோ ஒரு இயந்திரத்திற்கு ஐந்து படிநிலைகளைக் கொண்ட விஸார்ட் தேவையில்லை. எந்தெந்தச் செயல்பாடுகள் (operations) உள்ளன என்பதற்கான தெளிவான அறிக்கை மற்றும் அவற்றைச் செய்ய அனுமதி உள்ளதா என்பதற்கான உறுதியான பதில் அதற்குத் தேவை. குழுக்கள் இதைத் தவிர்க்கும்போது, அவர்கள் பொதுவாக இரண்டு குறுக்குவழிகளைப் பயன்படுத்துகிறார்கள்.

முதலாவதாக, அவர்கள் ஏஜெண்டிற்கு ஒரு API சாவியை (API key) வழங்குகிறார்கள். இரண்டாவதாக, தற்போதுள்ள பயனர் இடைமுகத்தை (user interface) ஒரு சாட்பாட் (chatbot) உள்ளே வைத்து, ஒருங்கிணைப்பு (integration) முடிந்துவிட்டதாகக் கருதுகிறார்கள். இந்த இரண்டு அணுகுமுறைகளும் உண்மையான சிக்கலைத் தீர்ப்பதில்லை.

ஒரு API சாவி, “இந்தக் கோரிக்கை நம்பகமான மூலத்திலிருந்து வந்ததா?” என்ற கேள்விக்கு மட்டுமே பதிலளிக்கிறது. ஆனால், “இந்த குறிப்பிட்ட அழைப்பாளர் இந்த குறிப்பிட்ட பதிவைப் படிக்க முடியுமா?” என்ற முக்கியமான கேள்விக்கு அது பதிலளிப்பதில்லை. ஒரு சாவி என்பது ஒரு 'ஸ்கெலிட்டன் கீ' (skeleton key) போன்றது. ஒருமுறை வழங்கப்பட்டால், அது பொதுவாக வளங்கள் (resources) மற்றும் சூழல்களில் (contexts) பரந்த அணுகலை வழங்குகிறது. உங்கள் அமைப்பிற்குள் தனிப்பட்ட செயல்களைக் கட்டுப்படுத்தும் கொள்கையைப் (policy) பற்றி அதற்கு எதுவும் தெரியாது.

ஒரு GUI-ஐ சாட்பாட் மூலம் மூடுவது இன்னும் பலவீனமானது. இடைமுகத்தில் உள்ள ஒவ்வொரு மனித-மையக் கருத்தையும் (human-centric assumption) ஏஜெண்ட் அப்படியே எடுத்துக்கொள்கிறது. அது தன்னாட்சி தர்க்கத்திற்காக (autonomous logic) வடிவமைக்கப்படாமல், மனிதக் கண்களுக்காக வடிவமைக்கப்பட்ட மாடல்கள் (modals) மற்றும் படிவங்கள் (forms) மூலம் கிளிக் செய்வதைப் போலச் செயல்படுகிறது. சாட்பாட் இடைமுகத்தின் கூறுகளை வெற்றிகரமாகக் கையாளலாம், ஆனால் அது புரிதல் இன்றிச் செயல்படுகிறது. இது ஒரு 'ஆட்டோமேஷன் தியேட்டர்' (automation theater) போன்றது. அதன் அடியில், எதற்கு அனுமதி உண்டு என்பது குறித்த இயந்திரம் வாசிக்கக்கூடிய (machine-readable) ஒப்பந்தம் இன்னும் இல்லை.

ஏஜெண்டுகளுக்குத் தேவை முன் கதவுக்கான மற்றொரு சாவி அல்ல. அவர்களுக்குக் 'கேட்கள்' (gates) தேவை.

கேட்கள் (Gates) உண்மையில் என்ன செய்கின்றன

ஒரு கேட் என்பது ஒரு கட்டுப்படுத்தப்பட்ட செயல்பாட்டு அடுக்கு (governed execution layer) ஆகும். ஒரு சான்றை (credential) நம்பி, அழைப்பாளர் சரியாகச் செயல்படுவார் என்று எதிர்பார்ப்பதற்குப் பதிலாக, கேட்களைக் கொண்ட ஒரு அமைப்பு ஒவ்வொரு கோரிக்கையையும் அறிவிக்கப்பட்ட விதிகளின் (rules) அடிப்படையில் மதிப்பீடு செய்கிறது. இந்த விதிகள் எந்தவொரு இடைமுகத்தையும் சாராமல், மனிதர்களுக்கோ அல்லது மற்றவர்களுக்கோ இன்றித் தனித்து இயங்குகின்றன.

ஒரு சரியான கேட் நான்கு விஷயங்களை வரையறுக்கிறது. தயாரிப்பிற்குள் எந்தச் செயல்பாடுகள் உள்ளன என்பதை அது அறிவிக்கிறது. யார், எந்தச் சூழ்நிலைகளின் கீழ் அவற்றை அழைக்க முடியும் என்பதைக் கூறுகிறது. பக்கவிளைவுகளை (side effects) ஏற்படுத்தும் முன், ஒரு அழைப்பாளர் எப்போது நின்று வெளிப்படையான அனுமதியைக் (explicit consent) கேட்க வேண்டும் என்பதை அது குறிப்பிடுகிறது. மேலும், அமைப்பு ஒவ்வொரு முடிவையும் ஒரு கட்டமைக்கப்பட்ட, வினவக்கூடிய (queriable) தடயத்தில் (trail) பதிவு செய்வதை அது உறுதி செய்கிறது.

இது பாரம்பரிய அணுகல் கட்டுப்பாட்டிலிருந்து (access control) முற்றிலும் மாறுபட்டது. பங்கு அடிப்படையிலான அமைப்புகள் (Role-based systems) பெரும்பாலும் கதவில், “நீங்கள் ஒரு நிர்வாகியா (admin)?” என்று கேட்டுவிட்டு, பிறகு உங்களை கட்டிடத்திற்குள் சுற்ற அனுமதிக்கின்றன. ஆனால் கேட்கள் ஒவ்வொரு சந்திப்பிலும், “நீங்கள் இப்போது இந்த குறிப்பிட்ட சுவிட்சைத் திருப்ப அனுமதிக்கப்படுகிறீர்களா?” என்று கேட்கின்றன. இங்கே அடையாளத்தை விட நடத்தை (behavior) முக்கியத்துவம் பெறுகிறது. கொள்கை (policy) அந்தச் செயலோடு பயணிக்கிறது.

இதைத் தெளிவுபடுத்த, ஒரு வாடிக்கையாளருக்குப் பணத்தைத் திரும்பப் பெற வேண்டிய (refund) ஒரு ஏஜெண்டைக் கற்பனை செய்து பாருங்கள். ஒரு சாவி அடிப்படையிலான அணுகுமுறை, அந்த எண்ட்-பாயிண்ட் (endpoint) கிடைத்தால், சாவியை வைத்திருப்பவர் யாராக இருந்தாலும் பணத்தைத் திரும்பப் பெற அனுமதிக்கலாம். ஆனால் ஒரு கேட் அடிப்படையிலான அணுகுமுறை, கிடைக்கும் செயல்பாடுகளின் பட்டியலைச் (manifest) சரிபார்க்கிறது, குறிப்பிட்ட வாடிக்கையாளர் பதிவிற்கு எதிராக ஏஜெண்டின் அனுமதியைச் சரிபார்க்கிறது, நிதி சார்ந்த பக்கவிளைவிற்காகப் பயனரின் வெளிப்படையான அனுமதியைக் கோருகிறது மற்றும் முழுத் தொடர்வையும் ஒரு தணிக்கை பதிவில் (audit log) எழுதுகிறது. கேட் என்பது அடையாளத்தை மட்டுமல்ல, கொள்கையையும் நடைமுறைப்படுத்துகிறது.

Whistler-இல் இதைச் சோதனை செய்தல்

இந்த மாதிரியை Whistler-இல் நாங்கள் செயல்படுத்தினோம். மனிதர்களுக்கும் இயந்திரங்களுக்கும் தனித்தனி குழாய்களை (pipelines) உருவாக்குவதற்குப் பதிலாக, நாங்கள் ஒரு ஒற்றை கொள்கை அடுக்கை (policy layer) எழுதி, அதன் மூலம் இரண்டு வெவ்வேறு அழைப்பாளர்களைச் சோதித்தோம்.

ஒரு அழைப்பாளர் உட்பொதிக்கப்பட்ட (embedded) Shell-ஐப் பயன்படுத்தும் ஒரு மனிதர். மற்றொருவர் எங்கள் குழுவிற்கு வெளியே உருவாக்கப்பட்ட ஒரு மூன்றாம் தரப்பு ஏஜெண்ட் (third-party agent). இரண்டும் ஒரே மேனிஃபெஸ்ட்டுடன் (manifest) இணைக்கப்பட்டன. இரண்டும் ஒவ்வொரு படிநிலையிலும் ஒரே மாதிரியான அனுமதிச் சோதனைகளைச் சந்தித்தன. தரவைத் திருத்துதல் அல்லது வெளிப்புற நிகழ்வைத் தூண்டுதல் போன்ற பக்கவிளைவுகள் கொண்ட ஒரு செயலை ஏதேனும் ஒரு அழைப்பாளர் செய்ய முயன்றபோது, அமைப்பு வெளிப்படையான அனுமதியைக் கோரியது. ஒவ்வொரு கோரிக்கை, அனுமதி மற்றும் மறுப்பு ஆகியவையும் ஒரே மாதிரியான கட்டமைக்கப்பட்ட தணிக்கை தடயத்தை (audit trail) உருவாக்கின.

அழைப்பாளர்கள் இருவருமே மாஸ்டர் API சாவியைப் பயன்படுத்தவில்லை. கொள்கையைத் தவிர்க்கும் வகையில் எந்தப் பின்வாசல் அல்லது உயர்த்தப்பட்ட சான்றுகளும் இல்லை. கடவுச்சொல் மற்றும் உலாவியை (browser) வைத்திருந்ததால் மனிதருக்குக் குறைவான கட்டுப்பாடுகள் வழங்கப்படவில்லை. மனித அடையாளங்கள் (human fingerprint) இல்லாததால் ஏஜென்ட் தன்னிச்சையானத் தடைகளைச் சந்திக்கவில்லை. அந்த நுழைவாயில் (gate) செயல்பாடு, சூழல் மற்றும் விதிகளை மதிப்பீடு செய்தது. அதுவே முழுமையான பரிவர்த்தனையாக இருந்தது.

இதன் விளைவாக, மனிதராகவோ அல்லது இயந்திரமாகவோ ஒரு புதிய அழைப்பாளரைச் சேர்ப்பதற்கு, அணுகல் தர்க்கத்தை (access logic) மறுசீரமைக்க வேண்டிய அவசியம் இல்லாத ஒரு அமைப்பைப் பெற்றோம். நீங்கள் கொள்கையைப் புதுப்பித்தீர்கள். நுழைவாயில் அதை அமுல்படுத்தியது.

தயாரிப்பு குறித்த கேள்வியை மறுபரிசீலனை செய்தல்

உங்கள் குழு தற்போது மனிதர்களால் உருவாக்கப்பட்ட ஒரு தயாரிப்பில் AI ஏஜென்ட்களை எவ்வாறு சேர்ப்பது என்று யோசித்துக் கொண்டிருந்தால், நீங்கள் ஒருவேளை தவறான கேள்வியுடன் தொடங்குவதாகும். ஒரு API-ஐ வெளிப்படுத்த வேண்டுமா என்று குழுக்கள் இயல்பாகவே கேட்கின்றன. அதற்குப் பதிலாக, ஒவ்வொரு அழைப்பாளர்க்கும் உங்களிடம் ஒரு கட்டுப்படுத்தப்பட்ட செயல்பாட்டு அடுக்கு (governed execution layer) உள்ளதா என்று அவர்கள் கேட்க வேண்டும்.

நுழைவாயில் இல்லாத ஒரு API என்பது ஒரு அகலமான கதவு போன்றதுதான். உங்கள் உள் கொள்கைகள் விஸார்ட் லாஜிக் (wizard logic), படிவச் சரிபார்ப்பு (form validation) மற்றும் மனிதர்கள் படிக்கும் உதவி உரைகளுக்குள் மட்டுமே இருந்தால், நீங்கள் வெளியிடும் எந்தவொரு எண்ட் பாயிண்ட்டும் (endpoint) தன்னாட்சி அழைப்பாளர்களுக்குப் பாதுகாப்பானதாக இருக்காது. ஏஜென்ட் ஒரு சாவியின் மூலம் அதிகப்படியான நம்பிக்கையைப் பெறலாம் அல்லது ஒரு சாட்பாட் ரேப்பரைக் (chatbot wrapper) கொண்டு பலவீனமான பொம்மலாட்டத்தைச் செய்யலாம்.

முதலில் நுழைவாயில்களை உருவாக்குவது என்பது, உங்கள் தயாரிப்பில் உள்ள ஒவ்வொரு அர்த்தமுள்ள செயலையும் ஒரு அறிவிக்கப்பட்ட செயல்பாடாக (declared operation) பட்டியலிடுவதாகும். இது அனுமதிச் சரிபார்ப்பை பயனர் இடைமுகத்திலிருந்து (user interface) பிரிப்பதைக் குறிக்கிறது, இதனால் ஒரு Shell பயனரும் வெளிப்புற ஏஜென்ட்டும் ஒரே ரன்டைம் அமலாக்கத்தை (runtime enforcement) எதிர்கொள்வார்கள். இது அழிக்கும் செயல்பாடுகளுக்கு (destructive operations) ஏஜென்ட் தவறான தரவுத்தொகுப்பை அழிப்பதற்கு முன்பே, சம்மத ஹூக்குகளை (consent hooks) இணைப்பதைக் குறிக்கிறது. மேலும், அழைப்பாளர் கார்பன் (மனிதன்) அல்லது சிலிக்கான் (இயந்திரம்) என்பதைப் பொருட்படுத்தாமல், பாதுகாப்பு மற்றும் இணக்கக் குழுக்கள் (security and compliance teams) ஆய்வு செய்யக்கூடிய தணிக்கைப் பதிவுகளை (audit trails) உருவாக்குவதையும் இது குறிக்கிறது.

இதற்கு உண்மையான கட்டமைப்பு மாற்றம் (architectural shift) தேவைப்படுகிறது. மனித மைய வடிவமைப்பு (Human-centric design) தர்க்கத்தை பரிவு மற்றும் உராய்வுடன் (empathy and friction) போர்த்துகிறது. ஏஜென்ட்-தயார் வடிவமைப்பு (Agent-ready design) தர்க்கத்தை தெளிவான, இயந்திரம் படிக்கக்கூடிய ஒப்பந்தங்கள் (machine-readable contracts) மூலம் வெளிப்படுத்துகிறது. இடைமுகம் (interface) கொள்கையாக இருப்பதை நிறுத்துகிறது. மேனிஃபெஸ்ட் (manifest) கொள்கையாக மாறுகிறது.

இந்த மாற்றம் மனிதர்களை மாற்றுவதைப் பற்றியது அல்ல. உங்கள் மென்பொருளுக்கு இப்போது ஒன்றுக்கும் மேற்பட்ட வகையான அழைப்பாளர்கள் உள்ளனர் என்பதை அங்கீகரிப்பதைப் பற்றியது. ஒவ்வொன்றும் சமமான துல்லியத்தைப் பெறத் தகுதியானவை.

உண்மையான கருத்து

கிளிக்குகளுக்காக வடிவமைப்பதை நிறுத்துங்கள். விதிமுறைகளுக்காக வடிவமைக்கத் தொடங்குங்கள். உங்கள் அமைப்பு அறிவிக்கப்பட்ட செயல்கள், சூழல் சார்ந்த அனுமதிகள், சம்மதச் சரிபார்ப்புகள் மற்றும் பகிரப்பட்ட தணிக்கைப் பதிவுகள் மூலம் ஒவ்வொரு அழைப்பாளர்களையும் நிர்வகிக்க முடிந்தால், மறுமுனையில் யார் அல்லது எது இருந்தாலும் அது முக்கியமல்ல. மனிதராக இருந்தாலும் அல்லது ஏஜென்ட்டாக இருந்தாலும், அவர்கள் அனைவரும் ஒரே நுழைவாயிலையே சந்திக்கிறார்கள். முதலில் நுழைவாயிலை உருவாக்குங்கள். API என்பது வெறும் கதவு மட்டுமே. கொள்கையே அந்த அறையை முழுமையாகப் பாதுகாக்கிறது.