AI Audit Logs — איך מתעדים כל החלטה ופעולה של Agent

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

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

קרה משהו לא צפוי - Agent שלח מייל שלא היה אמור לשלוח, עדכן רשומה שגויה, או פשוט נתן ללקוח תשובה שגויה. השאלה הראשונה שכולם שואלים היא "למה הוא עשה את זה?" - ולעיתים קרובות מדי, אין תשובה, כי אף אחד לא תיעד את שרשרת ההחלטות שהובילה לפעולה. עם קוד רגיל, stack trace ולוגים סטנדרטיים בדרך כלל מספיקים. עם Agent מבוסס LLM, השרשרת הרלוונטית רחבה בהרבה: איזה פרומפט הוזן, איזה הקשר נשלף (מ-RAG, מזיכרון), אילו כלים נשקלו, מה המודל "חשב" (אם יש reasoning traces), ואיזו החלטה בפועל התקבלה ולמה. AI Audit Logs הוא הבסיס לכל חקירה, כל דרישת רגולציה, וכל שיפור עתידי של המערכת.

Audit Log כבסיס לשיפור, לא רק לחקירת תקריות

יש נטייה לחשוב על Audit Log כמנגנון "ביטוח" - דבר שמתעדים ומקווים לא להזדקק לו. בפועל, לשכבת תיעוד טובה יש ערך יומיומי הרבה מעבר לחקירת תקריות: היא הבסיס לשיפור מתמשך של המערכת. ניתוח דפוסים ב-Audit Log חושף אילו כלים ה-Agent קורא בתדירות הגבוהה ביותר (מועמדים לאופטימיזציה), אילו החלטות שוליות (edge cases) חוזרות ונשנות (סימן לפער בהוראות המערכת), ואיפה שערי אישור נדרשים בתדירות גבוהה מדי (סימן שההרשאות אולי מצומצמות מדי ביחס לצרכים בפועל). במובן הזה, Audit Log הוא לא רק כלי אבטחה - הוא גם הבסיס לתהליך שיפור מתמשך של המוצר עצמו, ומספק את הנתונים הגולמיים שמזינים גם Evals עתידיים וגם החלטות עיצוב.

למה לוג רגיל לא מספיק

לוג אפליקטיבי סטנדרטי מתעד "מה קרה" - איזה endpoint נקרא, איזה status code הוחזר. עם Agent, זה חסר משמעותית: זה לא מסביר למה ה-Agent בחר לקרוא לכלי הזה ולא לאחר, מה בהקשר שלו הוביל להחלטה, ואיזה מידע ספציפי (מה-RAG, מזיכרון, מהודעת המשתמש) השפיע על התוצאה. בלי המידע הזה, חקירת תקרית הופכת לניחוש - וגרוע מכך, אי אפשר להראות לרגולטור, לקוח, או צוות אבטחה פנימי איך התקבלה החלטה ספציפית.

מי צריך גישה ללוג, ומי לא

שאלה שנוטים לפספס בעיצוב ראשוני: לא כל מי שצריך לחקור תקרית צריך לראות את כל התוכן הגולמי בלוג. תוכן שיחה מלא עשוי להכיל מידע רגיש על משתמשים, ולכן גישה ל-Audit Log המלא צריכה להיות מוגבלת (לפי אותו עיקרון של Least Privilege שחל על בני אדם באותה מידה שהוא חל על Agents), עם רמות גישה מדורגות - צוות חקירת תקריות מקבל גישה מלאה בעת הצורך, בעוד צוותי ניתוח כלליים מקבלים גרסה מסוננת או מצטברת (aggregated) בלבד. תכנון מודל ההרשאות ללוג עצמו הוא חלק בלתי נפרד מבניית שכבת ה-Audit, לא שיקול משני.

מה בדיוק צריך לתעד

• קלט מלא - הפרומפט המקורי, כולל הקשר שנוסף (מ-RAG, מזיכרון, מכלים קודמים) - לא רק "מה המשתמש הקליד" אלא כל מה שהמודל בפועל "ראה".
• החלטות ביניים - אילו כלים נשקלו ולמה נבחר כלי ספציפי, כולל reasoning traces אם המודל תומך בהם.
• כל קריאת כלי - שם הכלי, הפרמטרים המדויקים, התוצאה שהתקבלה, וזמן הביצוע. זה כולל גם קריאות שנחסמו על ידי מדיניות (ראו Policy Engines) - חסימה היא מידע חשוב לא פחות מביצוע.
• זהות - איזה Agent, באיזו גרסה, בשם איזה משתמש או תהליך, ביצע את הפעולה. פירוט בזהות ואימות ל-Agents.
• פלט סופי - מה בדיוק חזר למשתמש או למערכת הבאה בשרשרת.
• מטא-דאטה של סיכון - האם הפעולה עברה שער אישור, האם היא סווגה כבעלת סיכון גבוה, האם היא הופעלה בעקבות תוכן חיצוני לא מהימן.

ארכיטקטורה: איך בונים את זה בלי לפגוע בביצועים

1. Structured logging, לא טקסט חופשי

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

2. Correlation ID לאורך כל השרשרת

מזהה אחיד שעובר דרך כל שלב - מהבקשה המקורית, דרך כל קריאת כלי, ועד לפלט הסופי - כדי שאפשר יהיה לשחזר את כל השרשרת המלאה בקליק אחד, גם כשמדובר במערכת Multi-Agent מורכבת עם כמה Agents שמתקשרים ביניהם.

3. הפרדה בין לוג תפעולי ל-Audit Log

לוג תפעולי (לצורכי דיבוג וניטור ביצועים, ראו LLM Observability) יכול להיות שונה מ-Audit Log (לצורכי חקירה, רגולציה, וביקורת) - ל-Audit Log יש דרישות שונות: immutability (אי אפשר לערוך בדיעבד), retention ארוך יותר, ולעיתים הפרדת הרשאות גישה קפדנית יותר.

4. Immutability ואי-דחייה (Non-repudiation)

רשומות Audit צריכות להיות בלתי ניתנות לשינוי לאחר הכתיבה - append-only storage, ולעיתים חתימה קריפטוגרפית - כדי שאפשר יהיה לסמוך עליהן כראיה, גם אם המערכת עצמה נפגעה בהמשך.

5. סינון מידע רגיש מהלוג עצמו

אירוני אך חשוב: הלוג עצמו לא צריך לשמור Secrets בטקסט גלוי (ראו ניהול Secrets), ונתונים אישיים רגישים בו צריכים לעמוד בדרישות פרטיות (מיסוך, retention מוגבל) בדיוק כמו כל מקום אחר שבו הם נשמרים.

{
  "trace_id": "req-8f21a",
  "timestamp": "2026-08-09T09:14:22Z",
  "agent": { "name": "support-agent", "version": "3.2.1" },
  "actor": { "type": "user", "id": "usr_884" },
  "input_context": { "prompt_hash": "...", "rag_sources": ["kb-4471"] },
  "decision": { "tool_selected": "update_ticket_status", "confidence": null },
  "tool_call": { "params": { "ticket_id": "t-991", "status": "closed" }, "result": "success" },
  "policy_check": { "risk_level": "low", "approval_required": false },
  "output_returned": true
}

Trade-offs: היקף התיעוד מול עלות ופרטיות

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

דוגמה מהשטח: שימוש ב-Audit Log לחקירת תקרית

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

Audit Logs במערכות Multi-Agent - אתגר נוסף

כשמדובר במערכת עם כמה Agents שמתקשרים ביניהם, שחזור שרשרת אירועים הופך למורכב משמעותית. פעולה סופית יכולה להיות תוצאה של שרשרת ארוכה: Agent A קיבל בקשה, האציל חלק ממנה ל-Agent B, ש"שאל" את Agent C משהו, וקיבל בחזרה תשובה ששינתה את ההחלטה הסופית. בלי correlation ID אחיד שעובר דרך כל הקפיצות האלה, ובלי שכל Agent מתעד את הקלט שקיבל מה-Agent הקודם באופן מלא, שחזור שרשרת כזו בדיעבד כמעט בלתי אפשרי. ארכיטקטורות Multi-Agent בשלות מטמיעות שכבת תיעוד מרכזית (לא מבוזרת ללוג נפרד לכל Agent) בדיוק כדי לפתור את זה - כל Agent כותב לאותו מאגר תיעוד, עם אותו מזהה שרשרת, כדי שאפשר יהיה לראות את כל התמונה ממקום אחד.

עלות אחסון לעומת ערך: איך לא להיסחף

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

שילוב עם דרישות רגולטוריות

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

טעויות נפוצות

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

שאלות נפוצות

מה ההבדל בין Audit Log ל-Observability רגיל?

Observability מתמקד בביצועים, latency, ואיכות תשובות לצורכי שיפור מוצר. Audit Log מתמקד בשרשרת אחריות מלאה לצורכי חקירה, ביקורת ורגולציה - immutable, עם retention ארוך יותר, ולרוב עם דרישות גישה מחמירות יותר.

כמה זמן צריך לשמור Audit Logs?

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

איך זה עוזר במקרה של תקיפה כמו Prompt Injection?

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

איך זה משתלב עם תגובה לאירועים?

Audit Log הוא התשתית שעליה נשען כל תהליך תגובה לאירועים ב-AI - בלי נתונים מהימנים ומלאים, שלב האבחון בתגובה לאירוע נעצר מיד.

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

תגיות: AI Audit Logs · audit trail · AI compliance · incident investigation · structured logging · agent observability

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