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

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

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

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

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

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

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

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

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

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

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

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

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

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

דרכי פריסה: מתאר מקומי, ענן, היבריד

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

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

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

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

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

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

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

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

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

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

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

מה נשאר אצלכם: נהלים, מודלים, הרשאות, תיעוד

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

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

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

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

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

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

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

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

נקודת הבקרה עברה מהעברת נתונים לבדיקת חריגים: אנליטיקאי סוגר 5-7 בקשות שנויות במחלוקת במשמרת במקום זרם של בקשות זהות.

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

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

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

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

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

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

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

ספקות טכניים נפוצים: ניתוח שאלות טיפוסיות

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

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

איך אתם מתמודדים עם התראות שווא ומסבירים החלטות?

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

מה קורה כשדרישות משתנות?

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

מי אחראי לעבודת המערכת אחרי ההשקה?

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

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

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

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

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