מערכת תמיכה מבוססת בינה מלאכותית (AI), שנחשבה למאובטחת בשלב הפלט של המודל, דלפה נתוני לקוחות דרך "דלת צדדית" המזינה רשומות CRM לתוך הפרומפט. ניתוח האירוע (post-mortem) של היוצר מראה כי הגנה על הטקסט שהמודל מייצר בלבד אינה מספיקה – הבקשה הנכנסת, הנתונים שנשלפים מכלים פנימיים והפלט הסופי (emission) כולם זקוקים למנגנוני הגנה עצמאיים, אחרת עסק עלול לחשוף שמות, אימיילים ומזהים מבלי שאי פעם יזהה פריצה בשלב פלט המודל.

מדוע שלושת הגבולות הללו חשובים

רוב המפעילים מניחים שדליפה מתרחשת כאשר מודל השפה חוזר על סוד שהוא ראה. בפועל, החשיפה הגדולה ביותר מתרחשת עוד לפני שהמודל רואה את הנתונים. סוכן AI מקבל שלושה זרמי מידע:

  • Ingress (כניסה) – השאילתה הגולמית שהלקוח מקליד.
  • Return path (נתיב החזרה) – המידע שהסוכן שואב ממערכות המשך (downstream) כגון CRM.
  • Emission (פלט) – הטקסט שהמודל מחזיר למשתמש.

אם אחד מהזרמים הללו מכיל מזהים לא מוגנים, הסוכן עלול להטמיע אותם בטעות בתשובתו, גם כאשר שכבת הפלט מסוננת.

מדמו לשלב הייצור: לקחים שנלמדו בדרך הקשה

המעבר של אב-טיפוס לסביבת Help Desk פעילה חשף כשלים קונקרטיים שגישה פשוטה של "הסתרה ואז שליחה" (redact-then-send) פספסה.

  • Tokenize (טוקניזציה) במקום Redact (הסתרה) – מחיקת שם או אימייל לפני שהם מגיעים למודל מונעת מהמערכת לשחזר תשובה נכונה. שמרו את הערך המקורי בכספת מאובטחת, החליפו אותו ב-UUID אקראי בתוך הפרומפט, והחזירו את ה-UUID למקומו לאחר שהמודל סיים. זה שומר על הנתונים הגולמיים מחוץ להקשר (context) של המודל תוך שמירה על הפונקציונליות.

  • אימות מזהים באמצעות Checksums – ביטוי רגולרי (regular expression) מזהה מחרוזת שנראית כמו מספר חשבון; checksum מאשר אם מדובר במזהה אמיתי. מסנן checksum מונע מהסוכן להתייחס למספרים שרירותיים כאל נתונים רגישים, ובכך מפחית התראות שווא (false positives) שעלולות להוביל להסתרה מיותרת של מידע.

  • מיזוג טווחים חופפים (Overlapping spans) – רשומות לקוחות מכילות לעיתים קרובות שם שאחריו מופיעה כתובת אימייל החולקות תווים משותפים (למשל, “John Doe john.doe@example.com”). טוקניזציה של השם בלבד משאירה את שברי האימייל כטקסט גלוי, שעלול להיפלט. יש להתייחס לכל האזור החופף כאל טוקן (token) אחד.

  • בדיקת הגבול הנכון – בדיקה שעוברת רק על ידי בדיקת שכבת הפלט (emission) מעניקה תחושת ביטחון שגויה. בדיקה שנכשלת ותופסת דליפה בנתיב החזרה (return path) מחייבת תיקון. תכננו סדרות בדיקות (test suites) שמאמתות במפורש כל אחד משלושת הגבולות.

  • מעקב אחר ה-Ground Truth – כאשר אדם עורך טיוטה שנוצרה על ידי ה-AI לפני השליחה, המודל כבר ייצר תגובה שגויה. השוואה בין הטיוטה של ה-AI לבין ההודעה הסופית שאושרה על ידי האדם חושפת פערים בביטחון (confidence gaps) ומונעת מהמערכת ללמוד לחזור על טעויות.

הסיכונים עבור עסקים

סוכני AI לשירות לקוחות נמצאים בנקודת המפגש בין אינטראקציה ציבורית לבין מאגרי נתונים פנימיים.

טיעון נגד: מדוע חלק עדיין מעדיפים redaction (הסתרה)

שורה תחתונה

אבטחת סוכן שירות לקוחות מבוסס AI אינה בעיה של "דלת אחת". יש להתייחס לבקשה הנכנסת, לנתונים שנשלפים ממערכות פנימיות ולטקסט היוצא כקירות נפרדים; פריצה לאחד מהם מסכנת את השירות כולו. טוקניזציה של שדות רגישים, אימות מזהים, מיזוג טווחים חופפים, בדיקת הגבול הנכון והשוואה מתמדת בין טיוטות ה-AI להודעות אנושיות סופיות הם הצעדים המעשיים שהופכים "copilot" לשירות אמין ובעל יכולת פעולה (agentic).