זרימת עבודה בכירה ל-AI בביטוח ובניהול סיכונים

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

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

הפוסט הזה לוקח את הרעיון של “6 שלבים שמבדילים בין Junior ל‑Senior” ומתרגם אותו לפרקטיקה של AI בביטוח וניהול סיכונים, תוך שמירה על הקשר לסדרה שלנו על בינה מלאכותית בתחום הבריאות והביוטכנולוגיה: כי הרבה מהבעיות דומות—רגולציה, רגישות נתונים, והצורך להסביר החלטות לבני אדם.

1) מיפוי האקוסיסטם: לפני שמריצים מודל

תשובה ישירה: הטמעת AI בביטוח מתחילה בהבנה עמוקה של התהליך העסקי והקליני/תפעולי—לא בבחירת אלגוריתם.

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

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

• מה הבעיה המדויקת? “להפחית זמן טיפול בתביעה” זה לא בעיה; “להפחית מ‑12 ימים ל‑6 ימים את זמן הטיפול בתביעות אשפוז מורכבות” זו בעיה.
• מה הבייסליין? איך התהליך עובד היום, כמה זה עולה, ואיפה צוואר הבקבוק.
• מי המשתמש האמיתי? בודק תביעות? שמאי? רופא יועץ? מוקדן? כל אחד צריך פלט אחר.
• מה זה ‘יותר טוב’? פחות טעויות תשלום? פחות תביעות שמגיעות לערעור? יותר תביעות שנפתרות בלי פנייה חוזרת?

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

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

2) לחשוב על מוצרי דאטה כמו “אופרטורים” בתהליך תביעה

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

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

• “תן ציון חשד להונאה”
• “חלץ נתונים מטפסים וסכם חריגות”
• “הצע מסלול טיפול בתביעה (אוטומטי/ידני/מומחה)”
• “התרע על חוסר במסמכים”

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

מטריקת הצלחה שמשרתת החלטה

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

זמן תגובה (Latency)

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

תקציב אמיתי

ביטוח אוהב ROI ברור. אם כל בדיקה ידנית עולה 25–60 ₪ (זמן עובד + תפעול), ואפשר לחסוך 30% מהבדיקות בתיק מסוים—יש כבר כלכלת מוצר. בלי זה, הדיון נשאר “טכנולוגי” מדי.

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

כשמודל לא בטוח, מה עושים?

• שולחים לבדיקה ידנית
• מבקשים מסמך חסר
• מחזירים החלטה “לא ניתן לקבוע” במקום לנחש

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

3) תכנון מקצה לקצה “בעט ונייר”: מערכת, לא מחברת

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

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

• קלט: מסמכים (PDF), טפסים, נתוני פוליסה, היסטוריית תביעות, קודי ICD/פרוצדורות, תמונות נזק.
• עיבוד: חילוץ טקסט (OCR), נירמול, התאמות זהות, אנונימיזציה במידת הצורך.
• פלט: ציון/סיווג/המלצה + הסבר קצר + “ראיות” (למשל סעיפים במסמך שהובילו להחלטה).
• לופ אימון: איך בונים סט אימון אמין מתביעות היסטוריות בלי “ללמוד” טעויות עבר.
• לופ הערכה: לא רק AUC, אלא גם מדדים תפעוליים: זמן טיפול, שיעור ערעורים, עומס על צוותים.
• בקרות: ניטור דריפט, בדיקות איכות נתונים, יומני החלטה לצורכי ביקורת.

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

4) להתחיל פשוט, ואז “להרוויח” מורכבות

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

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

1. פתרון ידני מוגדר: איך עובד בודק תביעות מצוין? אילו דגלים הוא מחפש?
2. פיצ’רים חכמים: חריגות מול קבוצת השוואה, תדירות תביעות, עקביות בין מסמכים, התאמות בין קוד רפואי לתיאור.
3. מודל בסיס: רגרסיה לוגיסטית/Random Forest/Gradient Boosting.
4. רק אם צריך: מודלי טקסט מתקדמים, מודלי תמונה, או LLM לסיכום מסמכים והפקת תובנות.

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

• שלב 1: LLM קטן/בינוני רק לסיכום אחיד של המסמכים (לא להחלטה).
• שלב 2: מודל סיכון “קלאסי” על נתונים מובנים + אינדיקטורים מהסיכום.
• שלב 3: תור עבודה שמכבד את קיבולת הצוות ומקטין עומס.

כך מקבלים ערך מהר—ומורכבות רק כשיש הצדקה.

5) חקירת מדדים ופלטים: “לקרוא תביעות” כמו בודק

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

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

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

אחרי הבדיקה הידנית מגיע הצד הכמותי—אבל בביטוח המדד “הנכון” הוא בדרך כלל שילוב:

• Precision / Recall / F1 בהתאם למטרת התהליך
• עלות לטעות (Cost-sensitive evaluation): כמה עולה false positive וכמה עולה false negative
• מדדי תפעול: קיצור זמן טיפול, ירידה בבדיקות ידניות, ירידה בערעורים

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

6) להתאים את הפלט לקהלים: אמון הוא פיצ’ר

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

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

כך נראה סט מסירות (deliverables) נכון:

• להנהלה/מנהלי מוצר: תוצאה עסקית, KPI, סיכונים, ותוכנית הטמעה הדרגתית.
• לאקטוארים/ניהול סיכונים: התנהגות המודל לאורך זמן, יציבות, Bias/Fairness, ספי החלטה.
• למהנדסים: חוזי API, פורמטים, זמני תגובה, ניטור, תרחישי כשל.
• לבודקי תביעות/רופאים יועצים: מסך פשוט עם: המלצה, רמת ביטחון, 3–5 סיבות קצרות, וקישור לראיות במסמכים.

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

מיני-תבנית עבודה לפרויקט AI בביטוח (שאפשר להעתיק)

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

1. הגדרת החלטה ותוצאה: מה בדיוק משתנה בתהליך?
2. מדד הצלחה עסקי: זמן טיפול, עלות, שיעור ערעורים, loss ratio בתת-מקטע.
3. ברירת מחדל בטוחה: מה קורה כשאין ודאות?
4. תכנון נתונים: מקורות, איכות, בעלות, פרטיות.
5. מודל בסיס + ניסוי מבוקר: פיילוט עם קבוצת בקרה.
6. תוכנית הטמעה: הדרכה, UX, ניטור, ושגרות שיפור.

אם חסר סעיף אחד—הסיכון לפרויקט “להיתקע” קופץ.

מה עושים מכאן: הצעד הבא שמייצר לידים בצורה נקייה

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

אני ממליץ להתחיל בפרויקט אחד ממוקד—למשל סיווג תביעות למסלולי טיפול, סיכום מסמכים רפואיים לבודק, או דירוג חשד להונאה—ולמדוד ערך תוך 6–10 שבועות, עם פיילוט מבוקר.

האם בארגון שלכם הבעיה הגדולה היא באמת איכות המודל, או שהחסם האמיתי הוא תהליך, נתונים ואמון משתמשים?