ב־30 שניות
- זיכרון של סוכן AI צריך לכלול מקור, זמן ובעל אחריות; מידע שנשמר בעבר אינו בהכרח נכון היום.
- מתחילים במקרה שימוש אחד ומפרידים בין ידע ארגוני מאושר, העדפה אישית והקשר של שיחה.
- בודקים תרחישי שינוי, סתירה ומחיקה באמצעות שאלות שליפה, ולא רק את הצלחת פעולת השמירה.
מה חשוב להבין
הפרסום של AWS מספק את הרקע הטכנולוגי. התהליך, תרחישי הבדיקה והדוגמאות כאן הם הצעה יישומית, ולא תוצאות ניסוי או מדיניות שמירת מידע משפטית.
התשובה הישירה: לכל זיכרון צריך להיות מסלול תיקון
אל תאפשרו לסוכן לשמור כל פרט לנצח רק מפני שהאחסון זמין. הגדירו איזה מידע ראוי לשמירה, מאין הגיע, מתי נבדק ומה עושים כשהוא משתנה. כאשר אין דרך לברר את התוקף, עדיף שהסוכן יחזור למקור המאושר או יבקש הבהרה. מטרת הזיכרון היא לקצר עבודה חוזרת, ולא ליצור מאגר נוסף שאיש אינו יודע מי אחראי לנכונות שלו. זהו עיקרון תפעולי שאפשר ליישם לפני שבוחרים מוצר מסוים.
המדריך מציע תהליך עבודה לצוותי הטמעת AI בארגונים. הדוגמאות בהמשך הן תרחישים מומצאים לצורך תכנון ובדיקה, ולא תיאור של תקלה אצל לקוח. אין כאן מדיניות משפטית לשמירת מידע או הוראות התקנה של שירות ענן. צוות המוצר, בעל התהליך ואנשי המידע צריכים להתאים את הכללים למערכת שלהם, להרשאות הקיימות ולרגישות הנתונים. אפשר להתחיל בטבלה ובכמה בדיקות ידניות, בלי לבנות מיד מערכת ניקוי מורכבת.
מה מוסיף הפרסום החדש של AWS
ב־4 בספטמבר 2026 פרסמה AWS מדריך לתכנון מדיניות מחזור חיים עבור AgentCore Memory. הפרסום מתאר את הסיכון שבהצטברות מידע מיושן ומציע דפוסי הערכה, איחוד וצמצום של זיכרונות. הוא מציג מימוש לדוגמה עם שירותי AWS. אין להסיק ממנו שכל זיכרון במוצר נמחק מעצמו, שכל רכיב מגיע מוגדר מראש או שמדיניות אחת מתאימה לכל ארגון.
הנקודה המועילה גם למי שמשתמש בתשתית אחרת היא ההבחנה בין עצם השמירה לבין תחזוקת הידע. שירות יכול לזכור היטב את מה שנאמר אתמול ועדיין לתת תשובה שגויה היום. בהמשך מובאת הצעה מעשית של המערכת לתרגום הבעיה להחלטות ניהוליות ולבדיקות. היא אינה מדד ביצועים של AWS ואינה טענה שנערך כאן ניסוי השוואתי בין ספקי זיכרון.
שלב 1: ממפים מה הסוכן באמת שומר
רשמו את סוגי המידע שנכנסים לזיכרון בתהליך שבחרתם. לדוגמה: העדפת שפה של עובד, סיכום פגישה, מצב בקשת שירות או הסבר לנוהל עבודה. לכל סוג יש קצב שינוי ומשמעות אחרים. אל תערבבו באותה קטגוריה פרט שהמשתמש מסר על עצמו עם כלל ארגוני שאושר במסמך רשמי. שאלו גם אם יש צורך לשמור את המידע מעבר לשיחה הנוכחית; פעמים רבות ההקשר הזמני מספיק לביצוע המשימה.
בדקו את המסלול בפועל ולא רק את תרשים הארכיטקטורה. ייתכן שהסוכן כותב סיכום למסד נתונים, שומר היסטוריית שיחות ומוסיף קטע למנוע חיפוש נפרד. תיקון במקום אחד לא בהכרח מתקן את האחרים. בחרו דוגמת מידע לא רגישה ועקבו אחריה: מאיזו הודעה נוצרה, היכן נשמרה, מי יכול לקרוא אותה ובאיזו תשובה היא חוזרת. התוצאה צריכה להיות רשימת מקומות ומערכות שהצוות מסוגל לבדוק ולתחזק.
שלב 2: מפרידים בין זיכרון לבין מקור סמכות
בדוגמה מומצאת, נציג מכירות שאל את הסוכן על תנאי מבצע בתחילת החודש. הסוכן שמר סיכום, אך המבצע הסתיים והעמוד המאושר עודכן. אם הסיכום הישן גובר על העמוד העדכני, נוצר סיכון להצגת תנאים שגויים. הגדירו מראש מאיזה מקור מותר לענות על מחיר, זכאות או שלב בתהליך, ומתי צריך לבדוק אותו מחדש. זיכרון השיחה יכול להסביר מה הלקוח שאל, אך אינו אמור להפוך למסמך התנאים.
צרפו לכל פריט מזהה מקור, מועד יצירה, מועד בדיקה ובעל אחריות. אם אפשר, שמרו גם הפניה לגרסה שממנה נגזר הסיכום. כאשר שני מקורות סותרים זה את זה, אל תבקשו מהסוכן לבחור לפי סגנון כתיבה משכנע. קבעו כלל הכרעה מקצועי או מסלול פנייה לאדם. אם אין הכרעה, תשובה מועילה היא הסבר שיש סתירה ומה צריך לבדוק, במקום ניסוח פשרה שעלול להיות שגוי משני הצדדים.
שלב 3: קובעים תוקף לפי שימוש, ולא לפי מספר שרירותי
אין מספר ימים אחד שמתאים לכל הזיכרונות. קצב השינוי של סטטוס פנייה שונה מזה של העדפת שפה או של מדריך תפעול. הגדירו טריגרים לבדיקה מחדש: שינוי במסמך מקור, סגירת בקשה, עדכון שהמשתמש מסר או תאריך שהוגדר לתהליך. אם בחרתם גם בדיקה תקופתית, תעדו מדוע המרווח מתאים למקרה השימוש ואיזה נזק עלול להיגרם בין שתי בדיקות. אל תעתיקו ברירת מחדל טכנית כמדיניות עסקית בלי להבין אותה.
הבחינו בין הפסקת שימוש במידע לצורך תשובה לבין מחיקה שלו ממערכת. ייתכן שפריט צריך לצאת מתוצאות השליפה מיד, בעוד שהטיפול בעותקים אחרים כפוף למדיניות מידע נפרדת. המדריך אינו קובע כמה זמן מותר או חובה לשמור נתון אישי. אם הנתונים רגישים או כפופים להוראות ייעודיות, מערבים את בעלי התפקידים הרלוונטיים לפני שינוי המדיניות. בתכנון הטכני צריך להיות ברור איזה כלל חל על איזה מאגר.
שלב 4: בונים דרך לעדכון, ביטול ומחיקה
קבעו פעולה ברורה למקרה שבו עובד מדווח שהסוכן זוכר משהו שגוי. מי מקבל את הפנייה, כיצד מאתרים את הפריט ומי מוסמך לתקן אותו? אל תסתפקו בהוספת הודעה חדשה בנוסח להתעלם מהקודמת. אם שתי הגרסאות נשארות זמינות ללא כלל הכרעה, שאלה אחרת עלולה להחזיר שוב את המידע הישן. העדכון צריך להיות קשור למקור ולפריטים שנגזרו ממנו, כך שהצוות יוכל להסביר מה הוחלף ומה נשאר.
אחרי תיקון, בדקו שליפה מחדש במספר ניסוחים. נסו שאלה ישירה, ניסוח עקיף ושאלה הכוללת את הביטוי הישן. בדקו גם שיחה חדשה, כדי שלא תטעו לחשוב שתיקון בהקשר של שיחה אחת פתר את הבעיה במאגר. כאשר הבקשה היא למחיקה, הגדירו בדיקה מתאימה לכל שכבת אחסון שאתם מנהלים. היעדר תוצאה בממשק אחד אינו הוכחה לכך שכל העותקים נמחקו מכל מערכת.
שלב 5: נזהרים מסיכומים שמאבדים את התנאי החשוב
איחוד כמה זיכרונות לסיכום עשוי להקל על השליפה, אבל הוא גם משנה את ייצוג המידע. בדוגמה מומצאת, המשפט אפשר להחליף מוצר בתוך שבוע כאשר האריזה סגורה עלול להפוך לסיכום קצר שמזכיר רק שבוע. התוצאה נשמעת ברורה, אך התנאי נעלם. לפני שמאשרים מנגנון סיכום, בחרו דוגמאות שיש בהן חריגים, מספרים ותנאים, ובדקו שהמידע הדרוש להחלטה נשאר נגיש לצד הסיכום.
אל תמחקו הבחנות מקצועיות רק כדי לצמצם נפח. שני לקוחות בעלי שמות דומים אינם אותו אדם, ושתי גרסאות של נוהל אינן בהכרח כפילות. תנו למנגנון סימנים שמאפשרים להבדיל: מזהה תהליך, תחום, גרסה והרשאת גישה. כאשר אי אפשר לאחד בביטחון, שמרו את הפריטים בנפרד או העבירו לבדיקה. החיסכון בשטח אחסון אינו מצדיק אובדן הקשר שיגרום לסוכן לתת הוראה לא נכונה.
שלב 6: בודקים בעברית ובאנגלית בלי לערבב הרשאות
בצוות ישראלי, אותו מושג עשוי להופיע בעברית, באנגלית ובראשי תיבות. הכינו שאלות בדיקה בכמה ניסוחים מקובלים, כולל שמות מוצרים ומונחים פנימיים. המטרה אינה להוכיח שהמודל יודע עברית באופן כללי, אלא לבדוק שהוא מגיע לאותו מקור מאושר גם כשהעובד שואל בשפה אחרת. אם תרגום יצר זיכרון נפרד, ודאו שעדכון המקור מגיע גם למסלול השליפה הזה.
בדיקת שפה אינה מחליפה בדיקת הרשאה. התחברו עם חשבון שמייצג עובד בעל גישה רגילה ועם חשבון בעל תפקיד אחר, ובחנו מה כל אחד יכול לשלוף. זיכרון שנוצר בשיחה של מנהל אינו צריך לעבור לצוות רק משום שהנושא דומה. לפני הפיילוט הגדירו מי רשאי לראות איזה סוג מידע, ובדקו את הכלל במערכת בפועל. השתמשו בדוגמאות לא רגישות כדי לבחון את ההפרדה בלי לחשוף חומר אמיתי.
שלב 7: מודדים איכות זיכרון ומחליטים אם להרחיב
הכינו ערכת בדיקה קטנה הכוללת מידע תקין, מידע שהשתנה, סתירה ומידע שאין לסוכן רשות לראות. לכל שאלה רשמו מקור צפוי ותנאי הצלחה. מדדו כמה תשובות נשענו על גרסה ישנה, כמה תיקונים חזרו להופיע וכמה מקרים חייבו בדיקה אנושית. אפשר להוסיף זמן טיפול ועלות תחזוקה, אך אל תבחרו רק מדד של זמן תגובה: תשובה מהירה על בסיס מידע שגוי אינה שיפור.
סיימו את הפיילוט בהחלטה מוגדרת. אם הסוכן משתמש במקורות הנכונים ומסלול התיקון עובד, אפשר להוסיף סוג מידע נוסף ולבדוק אותו בנפרד. אם לא, צמצמו את מה שמותר לזכור או חזרו לשליפה ישירה ממקור מאושר. סדנת בינה מלאכותית לצוות ההטמעה יכולה להשתמש בערכת הבדיקות כדי לתרגל אחריות, שינוי נוהל והסלמה. מטרת התרגול היא שמנהלים ואנשי טכנולוגיה יסכימו מי מתקן מה לפני שהסוכן משרת קהל רחב.
מה צריך להיות מוכן בסיום הפיילוט
התוצר הרצוי אינו רק הדגמה שבה הסוכן ענה נכון פעם אחת. השאירו אחריכם רשימת סוגי מידע שמותר לשמור, מיפוי של מקורות הסמכות, בעל אחריות לכל תהליך וערכת שאלות שאפשר להריץ שוב. צרפו תיעוד קצר של תיקון אחד מתחילתו ועד סופו: איך התקבלה ההערה, איזה פריט השתנה ואיך נבדקה התשובה לאחר השינוי. אל תכללו בתיעוד דוגמאות אמיתיות עם פרטים מזהים כאשר אפשר להראות את התהליך באמצעות נתוני בדיקה.
קבעו גם תנאי עצירה. למשל, אם מתגלה שמידע ישן חוזר לאחר תיקון, אפשר להשהות את השימוש בזיכרון עבור אותו סוג מידע ולהפנות למקור המאושר עד לפתרון. זו הצעה לתכנון פיילוט, ולא תכונה שמובטחת בכל מוצר. ודאו שהצוות יודע לבצע את הפעולה בפועל ושיש מי שמוסמך לקבל את ההחלטה. כך ניהול הזיכרון הופך לאחריות שוטפת עם דרך תגובה ברורה, ולא למשימת הקמה ששוכחים מיד לאחר העלייה לאוויר.
המשמעות שמעבר לכותרת
בארגונים בישראל, אותו סוכן עשוי לשרת צוותים בעברית ובאנגלית ולעבור בין שירות, מכירות ותפעול. טעות קטנה בזיכרון יכולה להפוך להנחיה שחוזרת שוב ושוב. מדיניות תוקף ותיקון מאפשרת להרחיב שימוש בלי להתייחס לכל תשובה קודמת כאל מקור סמכות.
צעד יישומי אחד
בחרו תהליך אחד והכינו חמש שאלות על מידע שעשוי להשתנות. עדכנו את המקור המאושר, הריצו שוב את השאלות ובדקו שהסוכן משתמש בגרסה החדשה ומציג את המקור המתאים.
נבדק לאחרונה: 8 בספט׳ 2026
צפייה להעמקה
הפכו את המדריך לתהליך עבודה
להכשרות ויישום AI בארגון המשיכו ל-IIAI. לניהול השינוי והטמעתו בצוותים המשיכו למשכוכית.
מקורות ובדיקת עובדות
הנרי שטאובר
יוצר תוכן, מרצה ומוביל קהילות AI. מתמחה במעבר מרעיון לעוזר, אוטומציה או אב־טיפוס באמצעות סוכני AI, כלי No-Code ויצירת תוכן.
לכל הכתבות של הנרי שטאובר
