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

מאת שרון גילר

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

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

סוכן שרואה את החשבון עדיין לא מחזיק בו

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

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

מה הבנקאות הפתוחה באמת מאפשרת

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

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

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

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

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

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

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

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

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

איפה סוכן פיננסי יכול לעזור כבר היום

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

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

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

הרשאה טובה היא מוגבלת, ברורה וניתנת לביטול

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

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

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

מה קורה כשהמידע חסר או שהסוכן טועה

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

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

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

מה בנקים ופינטקים צריכים לבנות לפני אוטונומיה

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

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

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

העתיד הוא פעולה עם גבולות ואחריות

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

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

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

שרון גילר הוא מומחה לצמיחה בפינטק, אינשורטק ו-B2C ב-KSG Consulting.

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

אודות שרון גילר ותחומי המומחיות שלו.