תצפיתיות לסוכני AI בביטוח: שקיפות בלי עומס קוד

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

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

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

---

למה תצפיתיות היא תשתית קריטית בביטוח ובניהול סיכונים

תשובה קצרה וברורה: כי בלי תצפיתיות, סוכני AI הופכים ל”קופסה שחורה” שמייצרת סיכונים חדשים במקום לצמצם סיכונים קיימים.

בביטוח, AI נוגע בנקודות רגישות במיוחד:

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

בכל אחד מהתהליכים האלה, השאלה החשובה היא לא רק “האם המודל עובד”, אלא:

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

זו בדיוק הנקודה שבה Observability נכנס: לא עוד לוגים—אלא יכולת להבין התנהגות פנימית של מערכת מורכבת באמצעות Traces, Metrics, Events, Logs (הרבה צוותים מסכמים את זה כ-MELT).

---

מה חייבים למדוד בסוכן AI “אמיתי” בפרודקשן

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

1) איכות תשובה (לא רק “עבר/נכשל”)

במערכות ביטוח, איכות היא רב-ממדית. סוכן יכול להיות “רלוונטי” אבל לא מדויק, או מדויק אבל ארוך ומבלבל.

מדדים שימושיים שחוזרים שוב ושוב:

• נכונות (Correctness): האם התשובה תואמת מדיניות/מסמך/כללי מוצר.
• רלוונטיות (Relevance): האם היא עונה על השאלה או מתחמקת.
• הזיות (Hallucination): האם הומצאו עובדות/כיסויים/סעיפים.
• תמציתיות (Conciseness): במיוחד בשירות לקוחות ובתפעול.
• השוואה לאמת מידה (Ground Truth Accuracy): כשיש “תשובה נכונה צפויה” בתרחישי רגרסיה.

2) התנהגות תפעולית ועלות

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

מה מודדים:

• Latency לפי שלב (ניתוב, קריאת מודל, קריאת כלי, סיכום)
• Token usage לפי סוכן/צעד (כי זה כסף)
• תקלות וכלים: קריאות API, כשלי הרשאות, timeouts
• זרימת עבודה: איזה סוכנים הופעלו בפועל ומתי

3) Drift: הסיכון השקט

בביטוח drift הוא לא תיאוריה—הוא קורה.

• מודל מתעדכן אצל ספק → תשובות משתנות.
• מסמכי מדיניות מתעדכנים → “נכונות” משתנה.
• התנהגות משתמשים משתנה (עונתיות, רגולציה, אירועים) → הפניות משתנות.

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

---

הגישה שעובדת: מינימום קוד, מקסימום קונפיגורציה

התשובה לשאלה “איך עושים את זה בלי לשרוף חודשים על אינסטרומנטציה?” היא: לבחור פלטפורמת תצפיתיות שמבוססת Configuration-first.

ברעיון המקורי שממנו הפוסט הזה שואב השראה, הפתרון בנוי כך:

1. מחברים SDK קל (כמה שורות) כדי לייצר Traces ולקבל נתוני שימוש בטוקנים/לטנטיות.
2. מגדירים הערכות איכות (Evaluators) דרך ממשק—לא בקוד.
3. מגדירים Datasets לרגרסיה וממלאים אותם גם מתוך תוצרים אמיתיים (Traces איכותיים).

למה זה חשוב בביטוח? כי רוב הארגונים לא רוצים להפוך לחברת תוכנה של “מערכת בדיקות ל-LLM”. הם רוצים להפעיל AI שמביא ערך, עם בקרות מובנות.

תצפיתיות טובה מאפשרת לצוותים להתווכח על נתונים, לא על תחושות.

---

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

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

בדוגמה הטכנית המקורית מוצג שירות לקוחות שמחולק לסוכנים:

• סוכן מיון (Triage) שמסווג פנייה לקטגוריה
• סוכן תמיכה טכנית
• סוכן תמיכה כספית/חיוב
• סוכן מסכם (Finalizer) שמאחד תשובות ומייצר ניסוח אחד נקי

עכשיו תרגמו את זה לעולם הביטוח:

• Triage → “האם זו תביעה? שינוי פוליסה? בירור כיסוי? חשד להונאה?”
• Claims Agent → שולף מסמכים, מסכם ראיות, מציע החלטה
• Billing/Policy Agent → מצב חשבון, גבייה, השתתפות עצמית
• Finalizer → ניסוח תשובה לקוח + ציון הבא בתהליך (מסמכים חסרים, SLA)

מה תצפיתיות נותנת כאן בפועל

• רואים ב-Trace איזה ענף הופעל: רק תביעות, רק גבייה, או שניהם.
• רואים בכל שלב את ה-Input/Output (עם מסכות לנתונים רגישים).
• רואים Latency וטוקנים לפי צעד—מגלים מהר מי “שורף” עלות.
• מפעילים Evaluators אוטומטיים על התשובה הסופית (למשל רלוונטיות ותמציתיות).

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

---

LLM-as-a-Judge בביטוח: מתי זה עובד ומתי זה מסוכן

תשובה חדה: LLM-as-a-Judge הוא כלי יעיל לבקרה רציפה—אבל בביטוח חייבים לתחום אותו עם כללים.

איפה זה נותן ערך מהר

• בדיקות תמציתיות ורלוונטיות לתשובות שירות לקוחות.
• איתור הזיות (למשל “כיסוי מלא” כשאין כזה בפוליסה).
• בדיקות רגרסיה כשיש Ground Truth: תרחישים נפוצים עם תשובה צפויה.

איפה אני לא סומך עליו לבד

• החלטות כיסוי/דחייה “על הקצה” עם ניסוח משפטי.
• תהליכים רגולטוריים שבהם צריך נימוק פורמלי וקונסיסטנטי.

מה כן עושים? משלבים:

1. Evaluators אוטומטיים (Judge)
2. ספי איכות (למשל: רלוונטיות ≥ 0.9, הזיות ≤ 0.1)
3. Human-in-the-loop למדגמים/מקרים חריגים
4. דוחות מגמה חודשיים (מזכיר מאוד תהליכי איכות בבריאות דיגיטלית)

החיבור לסדרת הבריאות והביוטק טבעי: כמו שב-AI רפואי לא מסתפקים ב”דיוק מודל” אלא בולידציה, ניטור ו-Post-market surveillance—ככה גם בביטוח צריך ניטור רציף של איכות והטיות.

---

רגרסיה ו-Datasets: הדרך הכי מהירה לתפוס Drift לפני שהעסק מרגיש

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

הטריק שעובד טוב (והרבה צוותים מפספסים) הוא לייצר Dataset מתוך Traces מוצלחים:

• נציג/מומחה מסמן Trace “טוב”
• מוסיפים את הקלט והפלט ל-Dataset
• מגדירים Ground Truth (או גרסה מאושרת של תשובה)
• מריצים ניסוי אחרי שינוי מודל/פרומפט/חוק עסקי

בביטוח זה מייצר תשתית שמסוגלת לענות על שאלות ניהוליות קשות:

• האם השינוי האחרון שיפר איכות או רק האריך תשובות?
• האם העלות לטוקנים עלתה ב-20% בלי סיבה עסקית?
• האם סוכן ההונאות “נרגע” ומפספס תרחישים?

דוגמה מספרית ריאלית לניהול: אם מדד ה-GT Accuracy יורד מ-0.86 ל-0.78 אחרי עדכון—זה דגל אדום שמצדיק rollback או חקירה, עוד לפני שמופיע אירוע שירות.

---

צ’ק ליסט הטמעה בארגון ביטוח (ב-30 יום)

תשובה תכל’ס: אל תתחילו בדשבורד. תתחילו בהגדרות איכות ובתרחישים.

1. שבוע 1 – הגדרת מטרות וסיכונים

   • אילו החלטות הסוכן מקבל?
   • מה אסור שיקרה? (הזיות כיסוי, חוסר עקביות, חשיפת מידע)

2. שבוע 2 – חיבור Tracing בסיסי (MELT)

   • Latency, טוקנים, נתיב סוכנים
   • מדיניות מסכות ל-PII

3. שבוע 3 – Evaluators ראשונים

   • Relevance + Conciseness לכל Trace חדש
   • Hallucination לתשובות שמכילות מספרים/סעיפים/כיסויים

4. שבוע 4 – Dataset רגרסיה

   • 30–100 תרחישים נפוצים
   • הרצה שבועית/חודשית קבועה
   • ספים שמפעילים התראה

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

---

מה עושים עכשיו (בלי להפוך את זה לפרויקט אינסופי)

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

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

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