observability for ai agents: לוגים נכונים: מה לשמור ומה אסור לשמור

Observability לעידן ה־AI: כש־ai agent הופך לקופסה שחורה מסוכנת

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

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

כי מצד אחד, בלי לוגים מפורטים – אין למידה, אין שיפור, אין דרך להבין למה ה־ai agent פעל בצורה מסוימת. מצד שני, אם נרשום הכול, מהר מאוד נמצא את עצמנו עם לוגים שמכילים מידע רגיש, פרטי, עסקי, לפעמים גם מסוכן משפטית. זה לא תרחיש היפותטי, זה קורה עכשיו, בזמן שאתם קוראים את זה.

למה בכלל צריך Observability ל־ai agent?

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

Observability לעולם של ai agents כולל כמה רבדים:

הרובד ההתנהגותי: מה האייג'נט עשה בפועל

זה הרובד הכי אינטואיטיבי: אילו פעולות נעשו, מול אילו מערכות, באיזו סדרה, מה הייתה התוצאה. כשמדובר ב־ai agent שפועל כאוטומציה עסקית – למשל פותח טיקטים, מייצר מיילים, מעדכן CRM – אנחנו רוצים להבין את שרשרת הפעולות שלו, לא רק את התוצאה הסופית.

הרובד המחשבתי: למה הוא עשה את זה

ב־ai agents מתקדמים, במיוחד כאלה שעובדים עם תכנון רב־שלבי (chain-of-thought, planning וכו'), נוצר רובד סמוי: ההיגיון הפנימי, תהליך החשיבה. חלק מהמערכות שומרות אותו באדיקות, או לפחות מציעות את האופציה לשמור. זה מפתה, כי זה דומה לראות לראשונה את היומנים האישיים של המערכת. אבל כאן בדיוק מתחילה הבעיה: חלק גדול מה"חשיבה" הזו עלול לכלול מידע רגיש, פרטי, כזה שלא הייתם רוצים שיישמר בדאטה־לייק לנצח.

הרובד ההקשרי: מי המשתמש, איפה הוא ומה חשוב פה

ai agent טוב לא פועל בוואקום. הוא משתמש בהקשר – פרטי משתמש, הרשאות, היסטוריית אינטראקציות, מסמכים ארגוניים. וכשההקשר הזה זורם לתוך הפרומפטים והתגובות, הוא עלול לזלוג גם ללוגים. כאן כבר מדברים לא רק על observability, אלא על פרטיות, רגולציה, ולפעמים גם על ביטחון מידע ברמה הלאומית (כן, גם בישראל).

לוגים נכונים ל־ai agent: בין "אני צריך לדעת הכול" ל"עדיף שלא נדע"

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

מה חשוב לשמור כמעט תמיד

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

1. מטא־דאטה על הבקשה, לא התוכן הגולמי

במקום לשמור את כל מה שהמשתמש כתב ל־ai agent, אפשר לשמור:

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

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

2. החלטות מרכזיות של ה־ai agent

במערכות שבהן ai agent מתכנן צעדים – נניח: קורא מייל, מנתח כוונה, פותח משימה, שולח תשובה – כדאי לשמור לוג ברמת "מה היה הפלואו" ולא בהכרח "מה היה הניסוח המדויק". למשל:

• זיהוי כוונה: "בקשת תמיכה טכנית" / "שאלת מכירה" / "תקלה דחופה"
• בחירת כלי: "בחר לבצע חיפוש במסמכים" / "בחר לשלוח מייל למנהל"
• סטטוס פעולה: בוצע / נכשל / בוטל על ידי המשתמש

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

3. שגיאות וחסימות מצד ספקי המודלים

מודלים כמו GPT, Claude או אחרים מחזירים לא מעט שגיאות, אזהרות, ולעיתים חסימות (safety filters). אלה דברים שחייבים לתעד, כולל:

• קוד שגיאה
• סוג חסימה (תוכן רגיש, אלימות, מדיניות שימוש)
• ניסיון רה־טריי (ניסיון חוזר) ומה הייתה התוצאה

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

מה אסור לשמור – גם אם "זה נורא יעזור בדיבאג"

פה כבר נכנסים לשטח הממולכד. כאשר ai agent מדבר עם משתמשים, במיוחד בהקשרים כמו בריאות, פיננסים, משפט, או אפילו HR – הטקסטים שנשלחים אליו יכולים להכיל הכול מהכול. שמות, מספרי תעודות זהות, תיאורי מצב רפואי, סודות עסקיים, ואפילו סיסמאות (כן, משתמשים עדיין עושים את זה).

1. מזהים אישיים מובהקים

אם הלוגים שלכם מכילים:

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

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

2. נתונים רפואיים או משפטיים מזהים

ai agent שמשמש כ"עוזר רפואי" או "עו"ד וירטואלי" (או סתם צ'אטבוט באתר של קופת חולים) עלול לקבל תיאורים מאוד ספציפיים: מחלות, טיפולים, תיקים משפטיים, שמות של צדדים, מסמכים משפטיים. לשמור את זה כמו שהוא בלוגים? רעיון גרוע.

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

3. Chain-of-thought מלא שמערב תוכן רגיש

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

יותר ויותר ארגונים, בארץ ובעולם, בוחרים לוגיקה של "לא שומרים chain-of-thought גולמי במערכות פרודקשן" או לפחות מפעילים אנונימיזציה אגרסיבית לפני שזה נכתב ללוג.

איפה עובר הקו? צרכי מוצר מול פרטיות ואמון

יש מתח בסיסי שבולט מאוד בכל מה שקשור ל־observability של ai agent: הצד של המוצר רוצה כמה שיותר מידע, הצד המשפטי והאבטחתי רוצה כמה שפחות. באמצע, יושבים המפתחים ואנשי הדב־אופס, ומנסים למצוא איזון שלא ישתק את כולם.

מנקודת מבט מוצרית: בלי דאטה אין שיפור

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

מנקודת מבט פרטיות: המשתמש לא התנדב להיות דאטה־סט

מהצד השני, אם נשאל משתמש ממוצע אם הוא מרגיש בנוח שכל מה שהוא כתב ל־ai agent יישמר לעד, יונגש לעשרות עובדים, ואולי גם ישמש לאימון מודלים עתידיים – רובם (בואו נהיה עדינים) לא יתלהבו. וזה עוד לפני שנכנסנו לרגולציות כמו GDPR, חקיקה ישראלית בתחום הפרטיות, והנחיות פנימיות של ארגונים רגישים.

פרקטיקה בריאה: לוגים ברמת "מהות", לא ברמת "טקסט גולמי"

אחת הגישות היותר מעניינות שצומחות היום, גם אצל חברות ישראליות, היא לעבור לשמירה של "לוגים מהותיים": לא את המילים עצמן, אלא את המאפיינים שלהם. במקום:

"המשתמש כתב: אני חייב עזרה דחופה, אמא שלי אושפזה..."

נשמור:

"כותרת: בקשת עזרה דחופה בהקשר רפואי של בן משפחה מדרגה ראשונה"

זה דורש עוד שכבה של עיבוד, עוד ai agent שמקלף את המידע הרגיש, אבל התוצאה – observability שימושי בלי להחזיק את כל הכאב של המשתמשים בטקסט גלוי – שווה את זה.

ישראל, 2026: ai agent נכנס לארגונים – והלוגים רצים לפני המדיניות

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

תרבות ה"נבדוק בלוגים" הישראלית

בואו נודה בזה: בישראל יש תרבות די חזקה של "נזרוק ללוג ונראה". מפתחים אוהבים שיהיה להם כמה שיותר מידע בדיעבד, במיוחד כשמנהל מוצר נעמד מעליהם ושואל "למה זה קרה?". אבל לוגים של ai agent הם לא עוד stack trace של מיקרו־סרוויס. הם עלולים להיות הצצה עמוקה לחיים האישיים של המשתמש.

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

דוגמה קטנה מהשטח

אחד הארגונים הגדולים בארץ (לא ננקוב בשם) הטמיע ai agent פנימי שאמור לסייע לעובדים למצוא מידע בתוך מסמכי החברה. בהתחלה, כל השאילתות נרשמו במלואן ללוגים, "כדי לשפר את החיפוש". מהר מאוד, התברר שעובדים מחפשים גם מסמכי שכר, הסכמי פרישה, סכסוכים משפטיים פנימיים. כל זה הגיע כמו שהוא ל־log management, עם גישה די רחבה לצוותי הפיתוח.

אחרי אירוע פנימי לא נעים (שכולל מייל זועם ממחלקת HR), הארגון עבר למודל אחר: הלוגים שומרים רק סוגי כוונות (intent), קטגוריות מסמכים, וזמני תגובה – אבל לא את הטקסט המלא של השאילתה. האמת? ה־observability דווקא השתפר: פחות רעש, יותר אות.

מה בכל זאת לשמור? כמה קווים מנחים לא־מושלמים

אין כאן תשובה אחת נכונה, ולכן עדיף לחשוב על "עקרונות" מאשר על רשימה קשיחה. בעיקר כשai agent אחד בארגון יכול להיות צ'אטבוט מוקדי שירות, ואחר בכלל סוכן אוטומציה שעובד על לוגים של שרתים.

עיקרון 1: ברירת המחדל – לא לשמור טקסט משתמש גולמי

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

• לפרק את זה לחלקים אנונימיים
• להריץ מנגנוני השחרת נתונים (PII masking)
• להגביל משמעותית את זמן השמירה – ימים, לא שנים

עיקרון 2: לשמור החלטות, לא מחשבות

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

עיקרון 3: להפריד בין observability לבין data labeling

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

עיקרון 4: שקיפות מול המשתמשים

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

שאלות ותשובות על לוגים ו־ai agent

האם מותר לשמור את כל שיחות ה־ai agent כדי לשפר את המוצר?

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

איך אפשר לעשות דיבאג ל־ai agent בלי לראות את כל מה שהמשתמש כתב?

אפשר לעבוד עם לוגים "מסוכמים": שמירת intent, תיוג קטגוריות, סטטוס פעולות, קודי שגיאה, ותיאור כללי של הבקשה בלי פרטים מזהים. בנוסף, בסביבות סטייג'ינג (עם דאטה סינטטי) אפשר כן לעבוד עם טקסט מלא – אבל לא להשליך את אותה פרקטיקה לפרודקשן.

האם כדאי לשמור chain-of-thought של המודל לצורכי ניתוח?

רק אם אתם יודעים בדיוק מה אתם עושים, ובטוחים שאין שם מידע רגיש – וזה כמעט אף פעם לא המצב ב־production. אפשר לשמור גרסה "מתומצתת" או "מנוקדת" של reasoning (החלטות מרכזיות), בלי הטקסט הגולמי שהמודל ייצר לעצמו במהלך החשיבה.

מי בארגון צריך גישה ללוגים של ai agent?

פחות אנשים ממה שאתם חושבים. מומלץ מאוד ליישם עקרון least privilege: למפתחים – גישה לנתוני שגיאות ותהליכים, בלי פרטי משתמש; לצוותי אבטחת מידע – גישה לפעילות חריגה; ולמוצר – גישה לסטטיסטיקות ולניתוחים, לא לטקסטים גולמיים של משתמשים.

האם אפשר להשתמש באותם כללי לוגים לכל סוגי ה־ai agents?

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

טבלה: סיכום עיקרי הדיון – מה לשמור ומה לא בלוגים של ai agent

סוג מידע	האם לשמור?	דגשים / הערות
מטא־דאטה (זמן, סטטוס, משך, אורך הודעה)	כן, בדרך כלל	מועיל ל־observability, לרוב ללא חשיפת מידע רגיש
טקסט מלא של בקשת המשתמש	רק אם יש צורך מיוחד	מומלץ השחרת נתונים, הגבלת זמן שמירה וגישה מצומצמת
החלטות ai agent (intent, בחירת כלי, סטטוס פעולה)	כן	לב לבו של observability התנהגותי, ללא צורך בכל הטקסט הגולמי
chain-of-thought גולמי	ברוב המקרים – לא בפרודקשן	עלול להכיל מידע רגיש; עדיף לשמור רק סיכום החלטות
מזהים אישיים (ת"ז, כרטיס אשראי, חשבון בנק)	לא	יש להפעיל מנגנוני masking/אנונימיזציה לפני כתיבה ללוג
נתונים רפואיים/משפטיים מזהים	לא	אם חייבים – לשמור רק תיוג כללי, לא טקסט מלא
קודי שגיאה ואזהרות מספקי מודלים	כן	קריטי לדיבאג ולניטור איכות, לא דורש טקסט משתמש מלא
סטטיסטיקות שימוש (כמה משתמשים, אילו פיצ’רים)	כן	בסיס לאנליטיקה; לשמור על אנונימיות ברמת משתמש
שיחות מלאות לצורכי אימון מודלים	רק דרך תהליך מוגן	להפריד מלוגים תפעוליים, עם בקרות, אנונימיזציה והסכמות

הזדמנות ולא רק כאב ראש: observability כחלק מה־DNA של ai agent

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

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

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

לסיום: אם אתם בונים ai agent – אל תחכו שהלוגים יהפכו לבעיה

אם יש takeaway אחד מכל זה, הוא די פשוט: observability ל־ai agent צריך להיות מתוכנן כמו כל פיצ’ר קריטי אחר, עם שאלות קשות כבר בהתחלה: מה נרשום? מי יראה? לכמה זמן? מה קורה אם יש דליפה? ואיך אנחנו שומרים על ערך מקצועי ומוצרי – בלי לוותר על פרטיות, אמון, ובואו נגיד את זה בפשטות: שקט נפשי.

אם אתם מרגישים שהארגון שלכם מתחיל לעבוד עם ai agents, אבל המדיניות סביב לוגים, פרטיות ו־observability עדיין מרגישה מאחורה – זה בדיוק הזמן לעצור, לחדד, לשאול. נשמח לסייע בייעוץ ראשוני ללא עלות, לעזור לכם לבנות גישה מאוזנת שתאפשר ל־ai agent שלכם להיות חכם, מועיל – ובעיקר, כזה שאתם יכולים לעמוד מאחוריו גם ביום שאחרי.