כמה מידע סוכן AI באמת זוכר על המשתמשים שלו?

מאת צוות מדיה דיל · 12.08.2026 · AI Investigation · 7 דק׳

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

השאלה נראית פשוטה: כשמשתמש מסיים שיחה עם סוכן AI ופותח שיחה חדשה למחרת, כמה מהמידע שהוא חשף אתמול "נשאר" איפשהו במערכת? כדי לבדוק את זה בפועל, בנינו תרחיש בדיקה מבוקר — עוזר AI פנימי דמה שמטפל בפניות עובדים, עם זיכרון ארוך-טווח (long-term memory) מופעל, בדיוק כמו שמוצרי סוכנים רבים מציעים כיום כברירת מחדל כדי "להכיר" את המשתמש טוב יותר עם הזמן ולחסוך לו הקלדה חוזרת של אותו הקשר.

תוך כמה ימי שימוש רגילים לגמרי — בקשות לעזרה בניסוח מייל, שאלות על מדיניות חופשה, בירור סטטוס פרויקט — הסוכן צבר פרופיל עשיר בהרבה ממה שהתכוונו. הבדיקה הזו לא עסקה בפריצה או בניצול טכני מתוחכם; היא עסקה בשימוש רגיל לחלוטין שגרר תוצאה שלא הייתה ברורה מראש לאף אחד מהמשתתפים בתרגיל, כולל צוות ה-IT שהגדיר את המערכת מלכתחילה.

מה נשאר "בזיכרון" בלי שאף אחד ביקש את זה

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

הבעיה היא שאף אחד מהמשתמשים בתרגיל לא ידע שזה קורה ברמת הפירוט הזו, ואף אחד לא אישר במפורש אילו סוגי מידע מותר לסוכן לשמר לטווח ארוך ואילו לא. זו בדיוק הדינמיקה שמתוארת במדריך שלנו על context exfiltration — לא הדלפה זדונית מכוונת, אלא הצטברות שקטה של מידע רגיש בתוך שכבת הזיכרון של הסוכן, במקום שאיש לא תכנן לפקח עליו ברמה הזו.

מעניין לציין שהסוכן עצמו, כשנשאל ישירות "מה אתה זוכר עליי", נטה לספק תשובה מצומצמת ושמרנית יותר ממה שבפועל היה שמור בשכבת הזיכרון שלו. כלומר, גם השאלה הישירה למודל לא נתנה תמונה מדויקת — פער שמעורר שאלה קשה לגבי כמה אפשר לסמוך על "שקיפות עצמית" של סוכן AI בכלל.

כשמשתמש אחד "דלף" לשיחה של משתמש אחר

התרחיש המדאיג יותר קרה כשבדקנו סביבה שבה כמה משתמשים חולקים אותו סוכן ארגוני, במופע משותף. בתצורה שבה בידוד בין הקשרים (context isolation) לא הוגדר בקפדנות, זיהינו מקרה שבו הסוכן "ייבא" בטעות פרט מהיסטוריית שיחה של משתמש אחד לתשובה שניתנה למשתמש אחר — לא במתכוון, אלא כתוצאה מ-retrieval לקוי שערבב בין וקטורי זיכרון שהיו אמורים להישאר נפרדים לחלוטין.

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

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

מה קורה כשמבקשים למחוק — והזיכרון נשאר

שלב נוסף בבדיקה בחן תרחיש מוכר מעולם הפרטיות: בקשת מחיקה. ביקשנו מהמערכת "לשכוח" משתמש מסוים, כפי שכל מדיניות פרטיות סבירה מבטיחה למשתמשים שהם יכולים לדרוש. בפועל, מחיקת הרשומה הראשית במסד הנתונים הייתה מיידית ופשוטה — אבל שכבת הזיכרון הארוך-טווח של הסוכן, שנבנתה מווקטורים ומסיכומי שיחה, לא נמחקה באותו אופן נקי. עקבות של אותו משתמש המשיכו להשפיע על תשובות עתידיות במשך זמן מה, כי מנגנון המחיקה לא היה מתוכנן לטפל בסוג הזיכרון הזה מלכתחילה.

זה חשף פער מבני שקל מאוד לפספס בתכנון ראשוני: מערכות זיכרון וקטוריות נבנות כדי לשמר ולשלוף מידע ביעילות, לא כדי למחוק רשומה בודדת בצורה מדויקת ומלאה. מחיקה אמיתית דורשת לזהות כל טביעת רגל של המשתמש — כולל סיכומים גנריים שנוצרו ממנו אך אינם מתויגים ישירות בשמו — ולא רק את הרשומה ה"רשמית" שמופיעה בטבלת המשתמשים המרכזית. ארגון שמבטיח יכולת מחיקה בפוליסת הפרטיות שלו, אך לא בדק את זה בפועל מול שכבת הזיכרון של הסוכן, עלול לגלות שההבטחה הזו לא מתקיימת במלואה כשמישהו באמת דורש אותה.

איך אפשר בכלל לדעת מה נשמר

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

הפתרון האמיתי הוא שכבת audit log נפרדת מהמודל עצמו — רישום מפורש שמתעד כל כתיבה וקריאה מהזיכרון הארוך-טווח, כולל timestamp, מקור, וסיווג רגישות. כתבנו בהרחבה על איך נראית תשתית כזו במאמר מאחורי הקלעים של Agent Audit Log, שמראה שהדרך היחידה לענות בביטחון על "מה הסוכן זוכר" היא לא לשאול את הסוכן — אלא לבדוק את היומן החיצוני שמלווה אותו לאורך כל מחזור החיים שלו.

מה משתמשים בפועל מסכימים לו — ומה לא

כשהצגנו את ממצאי הבדיקה למשתתפים בתרגיל, התגובה הכללית הפתיעה אותנו פחות משציפינו: רוב המשתמשים לא התנגדו לכך שהסוכן "זוכר" הקשר עבודה שוטף כמו פרויקטים פתוחים או העדפות ניסוח. מה שהטריד אותם היה חוסר השקיפות — העובדה שאיש לא הראה להם מה בדיוק נשמר, לכמה זמן, ומי עוד יכול לגשת לזה בעתיד, כולל תרחיש שבו הארגון עצמו יחליט לבדוק את היסטוריית השיחות למטרות אחרות מהמקוריות.

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

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

מה עושים עם זה בפועל

המלצת המפתח מהתרגיל היא לבנות מדיניות שימור מפורשת: לא כל אינטראקציה צריכה להפוך לזיכרון קבוע, ורוב המידע צריך ברירת מחדל של TTL קצר אלא אם המשתמש בחר במפורש לשמר אותו. בנוסף, כל ארגון שמפעיל זיכרון סוכני צריך יכולת "תראה לי מה אתה זוכר עליי" נגישה למשתמש עצמו, ולא רק לצוות ה-IT שמריץ את המערכת מאחורי הקלעים.

לבסוף, בדיקות אבטחה תקופתיות שמדמות בדיוק את התרחיש שבדקנו — ניסיון לחלץ מידע צבור מהזיכרון של הסוכן, או לגרום לו לערבב בין הקשרים של משתמשים שונים — צריכות להיות חלק קבוע ממחזור הבדיקות, לא אירוע חד-פעמי שנעשה פעם בשנה. הרחבנו את הגישה הזו במדריך על AI red teaming, שמתאר איך בונים תוכנית בדיקות שתופסת בדיוק את סוג הדליפה השקטה שגילינו כאן, לפני שמשתמש אמיתי מגלה אותה במקרה.

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

תגיות: AI memory · context exfiltration · multi-tenant isolation · פרטיות סוכני AI · audit log

← חזרה לבלוג · צור קשר