מיומנויות דאטה סיינס בכירות לביטוח, בריאות וסיכון

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

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

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

1) ממפים את האקוסיסטם לפני קוד — אחרת אתם בונים צעצוע

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

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

מה ממפים בפועל (צ׳ק-ליסט קצר)

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

משפט פתיחה טוב למסמך אפיון: “המוצר הנתוני נועד לשפר את תהליך X במערכת Y, עבור משתמש Z, כך שנשיג תוצאה עסקית Q תוך שמירה על מגבלת T.”

דוגמה רלוונטית לביטוח (וגם לבריאות)

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

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

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

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

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

ארבע שאלות שחייבות תשובה

1. מה מדד ההצלחה? לדוגמה: הפחתת 20% בבדיקות ידניות תוך שמירה על שיעור טעויות תשלום מתחת לסף.
2. כמה זמן מותר לחכות? בתביעות דיגיטליות אולי שניות; בניתוח עומסים בביה״ח—דקות; במודלים אצוותיים—שעות.
3. מה התקציב? האם מותר להריץ מודל כבד לכל תביעה? או רק כשיש “טריגר”?
4. מה עושים בכשל? זו השאלה הבוגרת ביותר. בביטוח, “ברירת מחדל בטוחה” יכולה להיות:
   • מעבר לכללים שמרניים,
   • סימון לבדיקה אנושית,
   • או אישור אוטומטי רק במקרים בעלי סיכון נמוך מאוד.

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

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

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

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

מה חייב להיות בשרטוט מערכת (גם במסמך קצר)

• קלטים: מסמכים, טפסים, טקסט חופשי, היסטוריית לקוח, נתוני ספק, תיעוד רפואי/קודים.
• פלטים: ציון סיכון, קטגוריית תיעדוף, הסבר קצר, או המלצה לפעולה.
• בניית דאטה לאימון: מאיפה מגיע label? האם יש “אמת” אמינה? האם החלטות עבר מוטות?
• בדיקות ואימות: חלוקה בזמן (train על 2023–2024, test על 2025), בדיקות drift, בדיקות הטיה.
• אינטגרציה: API? תהליך אצווה? שילוב במערכת תביעות/CRM/מערכת ביה״ח.

נקודת כאב נפוצה בביטוח ובריאות: ה־Label לא נקי

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

• איזה label סביר,
• איזה רעש יש בו,
• ומה עושים כדי לצמצם נזק (למשל דגימה ידנית, adjudication כפול, או מדדים שמרניים).

4) מתחילים פשוט — ומרוויחים את הזכות להסתבך

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

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

סדר עבודה שמוכיח את עצמו

1. מבצעים את המשימה “ידנית”: מה החוקר/נציג באמת מחפש?
2. מייצרים פיצ׳רים: למשל יחס חריג בין סכומים, דפוסי תדירות, חריגות ספק.
3. בייסליין פשוט: Logistic Regression, XGBoost קל, או מודל חוקים.
4. מעלים מורכבות רק אם צריך: מודל טקסט, מודל רב־מודאלי למסמכים, או LLM למשימות סיכום/חילוץ.

דוגמה פרקטית: בהרבה תהליכי תביעות, 60–80% מהמקרים הם “שגרה”. שם האוטומציה הפשוטה נותנת החזר השקעה מהיר. את המודלים הכבדים שומרים ל־10–20% המורכבים.

5) חוקרים פלטים ומדדים — ולא מתאהבים במספר אחד

הנקודה המרכזית: בכירים מסתכלים על מאות מקרים אמיתיים לפני שהם מאמינים ל־F1.

במוצרים עם אנשים בלופ (Claims/Review/Clinical), הערכה ידנית היא חלק מהאמת התפעולית. אם הפלט לא “משכנע” את המשתמש, גם מודל עם AUC גבוה ייכשל באימוץ.

איך בוחרים מדד נכון בביטוח

• אם המטרה היא לתפוס כמה שיותר הונאות: Recall חשוב, אבל צריך לשלוט בכמות התיקים שתקפוץ לבדיקה.
• אם המטרה היא לא להציק לחוקרים: Precision גבוה כדי לצמצם אזעקות שווא.
• אם יש איזון בין השניים: F1 או מדד תועלת מותאם עלות (cost-sensitive).

כלל אצבע שאני אוהב

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

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

6) מתאימים את התוצרים לקהל: מנהל מוצר, דאטה, הנדסה—שלושה מוצרים שונים

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

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

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

מה לשים בחבילת מסירה (Deliverables) בביטוח/בריאות

• מפרט קלט/פלט ברור
• ספי החלטה (thresholds) והגיון עסקי
• תיעוד ניטור: drift, ביצועים, latency, עלויות
• “Playbook כשל”: מה עושים כשיש זינוק באזעקות שווא או שינוי בהתנהגות לקוחות/מטופלים

שאלות נפוצות (שווה לענות עליהן לפני שמתחילים)

האם חייבים LLM כדי לייצר ערך בתביעות?

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

איך מתמודדים עם רגולציה ופרטיות?

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

מה ההבדל בין מודל מחקרי למודל מוצר?

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

מה עושים מחר בבוקר: תרגיל של 60 דקות לצוות

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

1. כתבו פסקה אחת שממפה את האקוסיסטם (בעיה, משתמש, “יותר טוב”).
2. הגדירו מדד הצלחה אחד שמתרגם לשורה תקציבית.
3. שרטטו על דף את הקלטים, הפלטים, והנקודה שבה המשתמש רואה את ההמלצה.
4. החליטו מה ברירת המחדל כשיש כשל.
5. בנו בייסליין פשוט והכינו 30 דוגמאות לבדיקה ידנית עם המשתמש.

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

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

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