மாடல்-வெளியீடு (model-output) நிலையில் பாதுகாக்கப்பட்டதாகக் கருதப்பட்ட ஒரு AI-அடிப்படையிலான ஆதரவு அமைப்பு, CRM பதிவுகளைத் தூண்டுதலுக்குள் (prompt) வழங்கும் "பக்கவாட்டு வழி" (side door) மூலம் வாடிக்கையாளர் தரவை கசியவிட்டுள்ளது. இதன் ஆய்வறிக்கை (post-mortem), மாடல் உருவாக்கும் உரையை மட்டும் பாதுகாப்பது போதுமானதல்ல என்பதைக் காட்டுகிறது – உள்ளே வரும் கோரிக்கை (inbound request), உள் கருவிகளிலிருந்து பெறப்படும் தரவு மற்றும் இறுதி வெளியீடு (final emission) ஆகிய அனைத்திற்கும் தனித்தனி பாதுகாப்பு நடவடிக்கைகள் தேவை. இல்லையெனில், ஒரு நிறுவனம் மாடல்-வெளியீடு மீறலை (model-output breach) காணாமலேயே பெயர்கள், மின்னஞ்சல்கள் மற்றும் ஐடிக்களை (IDs) வெளிப்படுத்தக்கூடும்.

மூன்று எல்லைகளும் ஏன் முக்கியம்

பெரும்பாலான செயல்பாட்டாளர்கள், ஒரு மொழி மாடல் (language model) தான் பார்த்த ரகசியத்தை மீண்டும் சொல்லும்போது தரவு கசிவு ஏற்படுகிறது என்று கருதுகின்றனர். நடைமுறையில், மாடல் தரவைப் பார்ப்பதற்கு முன்பே மிகப்பெரிய பாதிப்பு ஏற்படுகிறது. ஒரு AI ஏஜென்ட் மூன்று வகையான தகவல்களைப் பெறுகிறது:

  • Ingress – வாடிக்கையாளர் தட்டச்சு செய்யும் மூலக் கேள்வி (raw query).
  • Return path – CRM போன்ற கீழ்நிலை அமைப்புகளிலிருந்து (downstream systems) ஏஜென்ட் எடுக்கும் தகவல்.
  • Emission – மாடல் பயனருக்குத் திருப்பி அனுப்பும் உரை.

இந்தத் தொடர்களில் ஏதேனும் ஒன்றில் பாதுகாப்பற்ற அடையாளங்கள் (identifiers) இருந்தால், வெளியீட்டு அடுக்கு (output layer) வடிகட்டப்பட்டிருந்தாலும் கூட, ஏஜென்ட் அவற்றை அறியாமலேயே தனது பதிலில் இணைத்துவிடக்கூடும்.

டெமோவிலிருந்து தயாரிப்புக்கு: கடினமாகப் பெற்ற பாடங்கள்

ஒரு முன்மாதிரியை (prototype) நேரடி உதவி மையத்திற்கு (live help desk) மாற்றியபோது, ஒரு எளிய "மறைத்துவிட்டு-அனுப்பு" (redact-then-send) அணுகுமுறையால் கண்டறிய முடியாத தோல்விகள் வெளிப்பட்டன.

  • மறைப்பதற்குப் பதிலாக டோக்கனாக்குங்கள் (Tokenize instead of redact) – ஒரு பெயர் அல்லது மின்னஞ்சலை மாடலுக்குச் செல்லும் முன்பே நீக்குவது, சரியான பதிலைத் தொகுக்கும் திறனைத் தடுக்கிறது. அசல் மதிப்பை ஒரு பாதுகாப்பான வோல்ட்டில் (secure vault) சேமித்து, தூண்டுதலில் (prompt) அதற்குப் பதிலாக ஒரு ரேண்டம் UUID-ஐப் பயன்படுத்தி, மாடல் வேலையை முடித்த பிறகு அந்த UUID-ஐ மீண்டும் மாற்றவும். இது மாடலின் சூழலில் (context) மூலத் தரவு சேராமல் தடுக்கும் அதே வேளையில் செயல்பாட்டையும் தக்கவைக்கும்.

  • செக்சம் மூலம் அடையாளங்களைச் சரிபார்க்கவும் (Validate identifiers with checksums) – ஒரு ரெகுலர் எக்ஸ்பிரஷன் (regular expression) கணக்கு எண் போன்ற ஒரு சரத்தைக் (string) கண்டறியும்; ஒரு செக்சம் (checksum) அது உண்மையான ஐடி தானா என்பதை உறுதிப்படுத்தும். ஒரு செக்சம் வடிகட்டி, ஏஜென்ட் தன்னிச்சையான எண்களைத் முக்கியமான தரவாகக் கருதுவதைத் தடுத்து, தேவையற்ற மறைப்புகளைத் தவிர்க்க உதவும்.

  • ஒன்றையொன்று பாதிக்கும் பகுதிகளை இணைக்கவும் (Merge overlapping spans) – வாடிக்கையாளர் பதிவுகளில் பெரும்பாலும் ஒரு பெயருக்கு அடுத்து மின்னஞ்சல் முகவரி இருக்கும், அவை சில எழுத்துக்களைப் பகிர்ந்து கொள்ளலாம் (உதாரணமாக, “John Doe john.doe@example.com”). பெயரை மட்டும் டோக்கனாக்குவது மின்னஞ்சல் பகுதியைத் தெளிவான உரையாக (clear text) விட்டுவிடும், இது வெளியீட்டில் வரக்கூடும். அந்த முழுப் பகுதியையும் ஒரே டோக்கனாகக் கருதவும்.

  • சரியான எல்லையைச் சோதிக்கவும் (Test the right boundary) – வெளியீட்டு அடுக்கை (emission layer) மட்டும் சரிபார்க்கும் ஒரு சோதனை தவறான பாதுகாப்பு உணர்வைத் தரும். திரும்பப் பெறும் பாதையில் (return path) கசிவைக் கண்டறியும் ஒரு தோல்வியுற்ற சோதனை, திருத்தத்தை உறுதி செய்யும். மூன்று எல்லைகளையும் வெளிப்படையாகச் சரிபார்க்கும் சோதனைத் தொகுப்புகளை (test suites) வடிவமைக்கவும்.

  • உண்மைத் தரவைக் கண்காணிக்கவும் (Track ground truth) – ஒரு மனிதர் AI உருவாக்கிய வரைவை அனுப்பும் முன் திருத்தும்போது, மாடல் ஏற்கனவே தவறான பதிலை அளித்துவிட்டது என்று அர்த்தம். AI-ன் வரைவை இறுதி மனித அங்கீகாரம் பெற்ற செய்தியுடன் ஒப்பிடுவது, நம்பிக்கைப் இடைவெளிகளைக் (confidence gaps) கண்டறிய உதவும் மற்றும் தவறுகளைத் திரும்பச் செய்யாமல் தடுக்கும்.

வணிகங்களுக்கான பாதிப்புகள்

வாடிக்கையாளர் சேவை AI ஏஜென்ட்கள், பொதுத் தொடர்பு மற்றும் உள் தரவுச் சேமிப்புகளின் சந்திப்பில் அமைகின்றன.

எதிர்வாதம்: ஏன் சிலர் இன்னும் மறைத்தலையே (redaction) விரும்புகிறார்கள்

முக்கியக் கருத்து (Takeaway)

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