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

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

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

מה נותנת אנליטיקה חזויה של הפסדיות תיק

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

כיול נבדק מול סטטיסטיקה אקטוארית ציבורית Банк России, כך שהתחזית תתבסס על השוק ולא רק על נתונים פנימיים של החברה.

חלק ההחלטות האוטומטיות גדל הודות להפרדת זרימות. בקשות ללא סימני הונאה, במסגרת המגבלה ועם סט מסמכים מלא נסגרות על ידי המערכת — יעד טיפוסי 60–70% מהזרימה; השאר עוברות לבדיקה ידנית, אך עם תיק שנאסף והערכת סיכון. זמן בדיקת בקשה יורד מכמה ימים לשעות.

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

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

השוואת גישות: כללים, סטטיסטיקה, למידת מכונה

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

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

גישה מתי מתאימה מגבלות
כללים מומחים תיק קטן, היסטוריה קצרה, נדרשת הסבריות לכל דחייה אינה מתרחבת: תנאים מתנגשים, התראות שווא גדלות עם מספר הכללים
מודל ניקוד מעט מאפיינים והם יציבים, נדרש סולם שקוף לחתם משקלות נקבעות ידנית, תלויות לא-לינאריות ואינטראקציות בין מאפיינים אובדות
מודל על נתונים היסטוריים נצברו עשרות אלפי חוזים עם הפסדים מאושרים ובקשות דורש תיוג ובקרת דריפט; במחלקות נדירות מתאמן יתר על המידה ו«משלים»
תכנית היברידית נדרש כיסוי ללקוחות חדשים ודיוק בפלח בוגר בו-זמנית יקר יותר בתפעול: שני מעגלים, גרסאות מאפיינים, תיאום הציון הסופי

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

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

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

  1. ביקורת נתונים. מפרקים מקורות: בקשות, טלמטריה של פוליסה, היסטוריית תשלומים, בדיקות חיצוניות. סופרים שיעור חסרים, השהיית הגעה ויציבות התפוקות בתקופות קודמות — מכך תלוי אילו מאפיינים מותר להשתמש.
  2. תכנית החלטה. מגדירים הרכב בלוקים: הערכת סיכון, כללים לזיהוי תרחישי הונאה, תור לבדיקה ידנית. קובעים נקודת השתלבות בתהליך הנפקת הפוליסה.
  3. הגדרת מאפיינים וספים. קובעים גבולות אזורים: אישור אוטומטי, בדיקה ידנית, דחייה. את הסף מחשבים מעלות שגיאות — הפסד שהוחמץ לעומת לקוח שאבד.
  4. בדיקה על מדגם מושהה. מריצים את הפתרון על תקופה שהמודל לא ראה, בודקים כיול ויציבות בעת שינוי עונה, בוחנים את שיעור הבקשות העוברות לבדיקה ידנית.
  5. מצב צל. הפתרון פועל במקביל לנוכחי, פערים נבדקים לפי פלחי התיק — כך רואים היכן הגישה החדשה מתנגשת עם ניסיון החתם.
  6. ניטור והעברה. מגדירים בקרת הטיית נתוני קלט וירידת איכות, מתארים תקנון לבחינת ספים. מלמדים את הצוות לנתח מקרים שנויים במחלוקת ולעבוד עם משוב.

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

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

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

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

מקרה בוחן: צמצום תשלומים בגין תבניות הונאה

תיק ביטוח מקיף לרכב: היכן דלפו תשלומים

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

מה שינו

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

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

מדדים לפני ואחרי

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

במה שונה ניקוד סיכונים מכללי חיתום?

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

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

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

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

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

ספקות טכניים: נתונים, הסבריות, אינטגרציה

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

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

האם יספיקו הנתונים שלנו?

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

האם ניתן להסביר מדוע בקשה עברה לבדיקה ידנית?

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

כיצד המערכת תשתלב במעגל שלנו?

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

מה יקרה למודל לאחר ההשקה?

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

מה לברר לפני תחילת העבודה על המערכת

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

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

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

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