פיתוח מנהל סיכונים דיגיטלי מבוסס AI (AI Risk Manager)

למה נדרש AI לניהול סיכונים כשהכללים מפסיקים לעבוד

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

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

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

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

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

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

מה נותן AI לניהול סיכונים: מהירות תגובה וכיסוי סיכונים

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

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

האפקט השני — מרשם סיכונים אחיד. אירועים ממקורות שונים ממופים לטקסונומיה משותפת (מסווגים ענפיים, כולל MITRE ATT&CK), ולכל רשומה יש בעלים, סטטוס והיסטוריית החלטות.

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

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

מצבי עבודה: כללים, מודל ותוכנית בקרה היברידית

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

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

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

השוואת גישות

כיצד בוחרים מצב

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

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

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

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

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

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

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

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

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

נקודת המוצא

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

בשיא מדובר ב-1,400 אותות ביממה, כ-70% מהם עברו לעיבוד ידני, וזמן התגובה לאירוע משמעותי נע בטווח של 6–8 שעות. חלק מהפעולות הספיקו לעבור לפני החסימה.

מה שינינו

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

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

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

זמן התגובה התקצר מ-6–8 שעות ל-4–9 דקות: ההחלטה ברוב האירועים מתקבלת בכניסה, לפני ביצוע הפעולה. שיעור ההחלטות האוטומטיות עלה ל-78%, ועוד 12% מהאותות עוברים לאנליטיקאי — אלו אירועים עם הקשר חלקי, שבהם נדרשת בדיקת השערה; השאר נחתך כרעש.

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

במה נבדלת הערכה לפי כללים נוקשים ממודל עם למידה?

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

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

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

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

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

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

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

האם נדרש לכך מעגל נפרד?

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

כיצד להסביר החלטות ולבקר את המודל לאחר ההרצה?

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

נדון במשימה: מה להבהיר לפני תחילת העבודה

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

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

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