תצפיתיות ל‑AI בביטוח: שליטה בסוכנים בלי הרבה קוד

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

הבעיה היא שלאורך 2025 יותר ויותר ארגונים עוברים מצ׳אטבוט יחיד לזרימות עבודה של סוכנים מרובים (multi-agent): סוכן טריאז׳ שממיין פנייה, סוכן שמנתח מסמכים, סוכן שמחפש במערכות ליבה, וסוכן ״מסכם״ שמחזיר תשובה ללקוח או לנציג. ברגע שיש כמה סוכנים, לוגים רגילים מפסיקים להספיק. אם משהו השתבש — קשה לדעת איפה ולמה.

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

למה תצפיתיות לסוכני AI היא דרישת סף בביטוח

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

בעולמות הביטוח וניהול הסיכונים זה קריטי משלוש סיבות:

1. אמון וציות: כשלקוח מקבל תשובה שגויה על כיסוי, השתתפות עצמית או סטטוס תביעה — זה לא רק שירות לקוחות, זה פוטנציאל לתלונה, פיקוח, ואפילו תביעה.
2. הונאות ואנומליות: מודלים נוטים להשתנות בביצועים עם הזמן. בלי ניטור עקבי, התראות על דפוסי הונאה עלולות להפוך לרעש, או להפך — להיעלם.
3. עלות ותפעול: סוכני AI צורכים טוקנים, זמן תגובה ומשאבי API. אם לא מודדים Latency ועלויות — התקציב ״בורח״ בשקט.

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

מה מודדים בפועל: MELT + שיפוט אוטומטי (LLM-as-a-Judge)

כדי לנהל סוכן AI בייצור צריך שני צירים משלימים: תפעול ואיכות.

MELT: מדדים, אירועים, לוגים ועקיבות

במקום להסתפק בלוגים מפוזרים, תצפיתיות טובה מרכזת MELT:

• Metrics (מדדים): זמן תגובה (Latency), שימוש בטוקנים, עלות לפי מודל/ספק, שיעור כשלונות, זמן בכל שלב בזרימה.
• Events (אירועים): קריאות ל‑LLM, קריאות לכלים (חיפוש מסמכים, CRM, מערכות תביעות), תקלות API.
• Logs (לוגים): מה המשתמש ביקש, מה הסוכן החליט, אילו מסמכים נשלפו, מה הוחזר.
• Traces (עקיבות): המסלול המלא מקצה לקצה — מי קרא למי, באיזה סדר, ומה יצא.

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

LLM-as-a-Judge: הערכת איכות בלי להקים צוות QA אינסופי

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

בפרקטיקה, ארגונים מגדירים Evaluators מוכנים מראש שמודדים למשל:

• רלוונטיות: האם התשובה באמת עונה למה שנשאל.
• תמציתיות: האם יש עודף טקסט שמבלבל לקוח/נציג.
• הזיות (Hallucination): האם יש עובדות שלא נתמכות במידע.
• דיוק מול אמת‑מידה (Ground Truth Accuracy): האם התשובה תואמת תשובה תקנית/מאושרת.

החלק החזק בגישה ״קונפיגורציה קודם״ הוא שמגדירים את זה במערכת התצפיתיות: פרומפט הערכה, מיפוי משתנים (קלט/פלט), ומתי להריץ את ההערכה — בלי לכתוב הרבה קוד הערכה בתוך המוצר.

דוגמה שמתחברת לעולם הביטוח: זרימת סוכנים מרובים כמו ״טריאז׳ תביעה״

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

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

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

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

• האם הטריאז׳ מסווג נכון (ולמה לא)?
• האם סוכן ההונאות העלה יותר מדי false positives?
• האם התשובה הסופית הזכירה חריג פוליסה שלא קיים?
• האם שינוי מודל/גרסה גרם לירידה יציבה בציון דיוק?

בלי תצפיתיות — אתם מנחשים. עם תצפיתיות — אתם מנהלים.

איך מקימים תצפיתיות בגישת “מינימום קוד”: תהליך מומלץ לביטוח

הגישה שמוצגת במקור מבוססת על פלטפורמה פתוחה ועצמאית מסגרת (framework-agnostic) שמאפשרת חיבור קל יחסית, ואז רוב העבודה נעשית בהגדרות: דשבורדים, evaluators, ודאטהסטים.

כך הייתי ממליץ ליישם את זה בארגון ביטוח (תוך שמירה על אבטחה וציות):

1) מגדירים עקיבות ברמת “תיק” (Trace) ורמת “שלב” (Span)

• Trace = טיפול מלא בפנייה/תביעה (מזהה תיק/פנייה אנונימי, ערוץ, תוצר סופי)
• Span = שלב בזרימה (טריאז׳, שליפת מסמכים, בדיקת כיסוי, סיכום)

הכלל הפשוט: אם אי אפשר להסביר למה התקבלה החלטה — חסר לכם Span.

2) מחליטים על 3 מדדים שאפשר לנהל השבוע, לא “יום אחד”

בארגונים שאני רואה, שלושת המדדים הראשונים שכדאי לנעול הם:

1. Latency end-to-end (כולל פירוק לפי שלבים)
2. עלות לטיפול (טוקנים/קריאות/מודל)
3. ציון רלוונטיות + ציון הזיות לתשובה הסופית

אל תתחילו עם 20 מדדים. תתחילו עם 3 ותתעקשו שהדשבורד חי.

3) בונים “דאטהסט רגרסיה” מתוך מקרים אמיתיים

אחת היכולות החזקות היא לבנות מאגר בדיקות לאט אבל בטוח:

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

זה כלי פשוט שמונע ״רגרסיות שקטות״ — הסוג הכי יקר של תקלות.

4) מגדירים Evaluators לפי תפקיד, לא לפי טכנולוגיה

בביטוח, הערכה טובה נראית כך:

• דיוק מול אמת‑מידה: תואם נוסח מאושר או כלל פוליסה
• ציות: אין התחייבות כספית בלי ניסוח מסויג, אין ייעוץ משפטי, אין הבטחות
• הוגנות: אין הטיה או שפה בעייתית מול קבוצות אוכלוסייה
• בהירות: תשובה קריאה לנציג/לקוח, עם שלבים ברורים

אפשר להתחיל בשניים (רלוונטיות + הזיות) ולהתרחב.

איך מזהים Drift לפני שהוא מתפוצץ בפנים

Drift הוא לא רק ירידה דרמטית. לרוב הוא נראה כמו שחיקה איטית:

• ממוצע רלוונטיות יורד מ‑0.92 ל‑0.86 לאורך שבועיים
• סטיית התקן עולה (תשובות נהיות פחות יציבות)
• עלות לטיפול עולה ב‑18% כי הסוכן כותב יותר מדי ומבקש עוד סבבים

בתחום הביטוח זה יכול לקרות בגלל:

• שינוי ניסוחים של לקוחות (למשל סביב חידושי סוף שנה ו‑01/01)
• שינוי תהליכים פנימיים (טפסים חדשים, הנחיות חדשות)
• שינוי גרסת מודל אצל ספק

הדרך הנכונה לנהל drift היא להחזיק דאטהסט רגרסיה + מדדי MELT + ציון איכות אוטומטי — ואז להפעיל סף התרעה (למשל ירידה של 0.05 בממוצע דיוק או עלייה של 25% ב‑Latency).

משפט שאני חוזר עליו בצוותים: “אם אי אפשר למדוד איכות כל יום, אתם לא באמת בפרודקשן.”

שאלות שעולות כמעט תמיד (והתשובות שהייתי נותן)

האם אפשר לסמוך על LLM-as-a-Judge בביטוח?

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

מה לגבי פרטיות ונתונים רגישים?

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

האם זה לא מוסיף עוד מערכת לתחזק?

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

הצעד הבא: להפוך סוכני AI לכלי ניהול סיכונים, לא סיכון חדש

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

אם אתם מפעילים (או מתכננים להפעיל) סוכני AI לטיפול בתביעות, חידושי פוליסה, או ניטור סיכונים — הייתי מתחיל בשבוע הקרוב בשלושה דברים: Trace מקצה לקצה, שני Evaluators בסיסיים, ודאטהסט רגרסיה קטן של 20–50 מקרים אמיתיים. משם, ההבשלה כבר הופכת לתהליך רציף.

השאלה שכדאי להשאיר על השולחן לסוף: כשיגיע שינוי המודל הבא או גל תביעות חריג — תדעו לזהות תוך שעה שהאיכות ירדה, או שתגלו את זה אחרי שבוע דרך תלונות לקוחות?