איך חשבון בנק מתחבר ל-ChatGPT? הטכנולוגיה מאחורי החיבור של ONE ZERO ומה עסקים קטנים ובינוניים יכולים ללמוד ממנו

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

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

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

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

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

הטכנולוגיה המרכזית כאן היא ככל הנראה קונקטור המבוסס על MCP, או לכל הפחות פועל באותו דפוס. MCP, קיצור של Model Context Protocol, הוא תקן פתוח שמגדיר כיצד יישום AI יכול לגלות כלים, לשלוח אליהם בקשות מובנות ולקבל מהם תשובות מובנות. התיעוד הרשמי משווה אותו לחיבור USB-C: בונים ממשק תקני פעם אחת, ואז לקוחות תואמים כמו ChatGPT ו-Claude יכולים להשתמש בו.

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

OAuth: הרשאה במקום מסירת סיסמה

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

בתשתיות MCP מודרניות, ChatGPT פועל כלקוח, שרת ה-MCP הוא המשאב המוגן, וזרימת OAuth מחברת ביניהם. OpenAI מתעדת שימוש ב-Authorization Code Flow עם PKCE, שנועד לצמצם את הסיכון ליירוט ושימוש חוזר בקוד ההרשאה. מבחינת בעל עסק, הפרט החשוב אינו ראשי התיבות אלא העיקרון: לכל משתמש ולכל אינטגרציה צריכה להיות גישה מזוהה, מוגבלת וניתנת לביטול.

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

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

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

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

ELLA וה-LLM: מי באמת עושה מה?

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

מודעת גיוס ארכיונית של ONE ZERO מתארת תהליכי retrieval ו-RAG, מסגרות לסוכני AI וכלים כמו LangChain ו-LangGraph. זהו רמז לאופן שבו הבנק בונה AI באופן כללי, ולא תרשים ארכיטקטורה רשמי של הקונקטור. ובכל זאת, הוא מציג דפוס הגיוני: הבקשה אינה נשלחת ישירות למודל אחד ומקבלת תשובה קסומה; היא עוברת מסלול שבו מזהים כוונה, אוספים נתונים, בודקים אותם ורק אז מנסחים תשובה.

מה משתנה כשהמערכת עוברת מקריאה לביצוע?

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

זהו Human in the Loop אמיתי, לא חלון קופץ סמלי. בפעולות רגישות צריך להציג למאשר את הסכום, היעד וההשפעה לפני הביצוע; לתעד מי ביקש, מי אישר ומה בוצע; ולאפשר עצירה או ביטול כשאפשר. OpenAI ממליצה לאמת את כל הקלט בצד השרת ולדרוש אישור אנושי לפעולות בלתי הפיכות, בין השאר בגלל סיכוני Prompt Injection.

אז איפה DNS-AID כן נכנס?

MCP עונה על השאלה ״איך מדברים עם השירות?״. OAuth עונה על ״מי המשתמש ומה מותר לו?״. DNS-AID עונה על שאלה אחרת: ״איפה נמצא השירות הרשמי של הארגון?״.

לפי טיוטת ה-IETF, DNS-AID משתמש במרחב שמות מובנה וברשומות DNS קיימות ולא בסוגי רשומות חדשים. רשומת SVCB היא רשומת הגילוי המרכזית, והיא נושאת את נקודת הקצה ואת הפרמטרים התפעוליים שלה. רשומת TXT משמשת כחלופה כאשר SVCB אינה זמינה. רשומת TLSA היא אופציונלית ותומכת באימות זהות ב-TLS, ו-DNSSEC מגן על שלמות נתוני הגילוי שפורסמו. הטיוטה מדגישה שזהו מנגנון bootstrap לגילוי, לא פרוטוקול שמגדיר כיצד לקרוא מידע בנקאי או לאשר פעולה.

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

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

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

1. מתחילים בשאלה עסקית אחת, לא ב״בואו נוסיף AI״. למשל: אילו חשבוניות עברו את מועד התשלום, אילו קריאות שירות תקועות או אילו רישיונות Microsoft 365 אינם בשימוש.
2. מסדרים מקור נתונים מוסמך. AI שמחובר ל-CRM מבולגן פשוט מסביר את הבלגן בביטחון רב יותר.
3. חושפים מספר קטן של כלים לקריאה בלבד באמצעות API או MCP. כל כלי צריך להחזיר תשובה ברורה ומצומצמת, לא dump של מסד הנתונים.
4. מוסיפים OAuth או SSO, הרשאות לפי תפקיד, תוקף מוגבל לאסימונים ותהליך ביטול גישה.
5. רק אחרי שהקריאה יציבה מוסיפים פעולות. ניסוח טיוטת מייל יכול להיות אוטומטי; שליחה ללקוח, שינוי מחיר או תשלום לספק צריכים אישור.
6. מתעדים, מנטרים ובודקים. צריך לדעת איזה כלי הופעל, אילו נתונים הוחזרו, האם התשובה הייתה נכונה ומה קורה כשהמערכת אינה בטוחה.

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

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