פיתוח מערכת AI לאנדררייטינג ביטוחי

AI חיתום ביטוחי: היכן התהליך נשבר כיום

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

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

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

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

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

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

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

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

הרבעון הראשון: אחידות החלטות וניקיון נתונים

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

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

לקראת סוף הרבעון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תוצרי מסירה: כללי החלטה ותקנוני ניתוח

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

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

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

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

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

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

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

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

הבדיקה מתבצעת דרך Единый профиль клиента, לכן אי-התאמה בין נתונים מוצהרים לנתונים בפועל נראית לפני החתימה, ולא אחרי.

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

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

במה שונה מצב היברידי ממצב אוטומטי לחלוטין?

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

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

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

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

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

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

ספקות נפוצים: נתונים, דיוק, אחריות

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

כיצד אתם שולטים באיכות כבר לאחר ההפעלה?

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

כיצד מנתחים שגיאות של החלטה מסוימת?

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

מה עם מידע על לקוחות?

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

האם ניתן להפעיל זאת מבלי לעצור את התהליך הנוכחי?

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

נדון במשימה ונחזור עם תוכנית הטמעה

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

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

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