הנדסת סוכנים לבנקים: תוכנית אב ל-2026 עבור ההנהלה הבכירה והמהנדסים שיבנו אותה

TL;DR. בינת סוכנים חצתה משלב הפיילוט אל הייצור ברחבי הבנקאות הגלובלית. 70% מהמוסדות משתמשים בה במידה זו או אחרת; לאחד מכל חמישה בלבד יש מודל ממשל בשל. במקביל, יריבים אוטונומיים פועלים במהירות מכונה, מערך ה-COBOL הישן שהמערכות החדשות חייבות לתקשר עמו נכתב עבור הנחות עיבוד האצווה של שנות השישים, ומועד הסיום של EU AI Act למערכות בסיכון גבוה נמצא במרחק שנים-עשר שבועות. זהו המיצב ההנדסי והממשלי שבנק צריך להחזיק.

עיקרי המסקנות

הנדסת סוכנים לבנקים: תוכנית אב ל-2026 עבור ההנהלה הבכירה והמהנדסים שיבנו אותה. בינת סוכנים חצתה משלב הפיילוט אל הייצור ברחבי הבנקאות הגלובלית.
השנה שבה הנדסת סוכנים הפכה בלתי נמנעת. השיח על AI בשירותים פיננסיים נשלט, עד לא מכבר, בידי שני דברים סמוכים אך נבדלים: ממשקי צ'אט גנרטיביים (מועילים אך תחומים), ותבניות Retrieval-Augmented Generation שהונחו על נתוני הארגון (שימושיות, גם הן תחומות).
מצב האימוץ בבנקאות. התמונה המצרפית חד-משמעית.
שלושה וקטורי סיכון שהבנקים חייבים להפנים. לפני כל שיחה ארכיטקטונית, תשומת לב הדירקטוריון צריכה לנוח על שלושה סיכונים ייחודיים למערכות סוכניות, אשר מגיעים מוקדם יותר ממה שרוב הבנקים תכננו.

הנדסת סוכנים לבנקים: תוכנית אב ל-2026 עבור ההנהלה הבכירה והמהנדסים שיבנו אותה

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

עיקרי המסקנות

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

האימוץ בבנקאות אמיתי ומאיץ. 70% מחברות הבנקאות ⧉ מדווחות על שימוש בבינת סוכנים במידה זו או אחרת (16% בייצור, 52% בפיילוט, EY 2026); 44% מצוותי הפיננסים ישתמשו בה השנה, גידול של 600%+ ביחס שנתי לפי Wolters Kluwer.

הממשל לא עמד בקצב. דוח State of AI 2026 של Deloitte מוצא שרק לאחת מכל חמש חברות יש מודל ממשל בשל לסוכני AI אוטונומיים. ניתוח Deloitte של מאגר MIT AI Risk Database מזהה יותר מ-350 סיכונים ⧉ שעלולים לנבוע מהתנהגות אוטונומית או סוכנית.

סביבת האיום עברה תיעוש. Anthropic חשפה בנובמבר 2025 שקבוצה סינית בחסות המדינה, GTG-1002, חטפה את Claude Code כדי להריץ ריגול אוטונומי כנגד כ-30 מטרות, כאשר ה-AI מטפל ב-80-90% מהפעולות הטקטיות באופן עצמאי. Flashpoint צפתה בעלייה של 1,500% בדיונים בלתי חוקיים הקשורים ל-AI ⧉ בין נובמבר לדצמבר 2025 בלבד.

מערך המערכות הישן הוא האילוץ השקט. תקציבי ה-IT של השירותים הפיננסיים נצרכים ב-70-75% בתחזוקת מערכות ישנות, 63% מהבנקים עדיין נשענים על קוד שנכתב לפני שנת 2000, ורוב הבנקים מדווחים על אדם אחד או שניים בלבד בתוך הארגון שמסוגלים לתחזק את ה-COBOL שעליו רצות פלטפורמות הליבה שלהם. בינת סוכנים היא כעת הגישה המובילה לסגירת הפער הזה.

המערך הרגולטורי מתכנס. תחת EU AI Act, 2 באוגוסט 2026 מפעיל אכיפה מלאה למערכות AI בסיכון גבוה (Annex III כולל במפורש דירוג אשראי והערכת כושר אשראי). DORA כבר בתוקף. SR 11-7 הורחב בפרקטיקה הרגולטורית כדי לכסות LLMs ומערכות סוכניות. הקנסות על הפרה מגיעים ל-35 מיליון אירו או 7% מהמחזור השנתי הגלובלי.

פיקוח אנושי אינו מושג יחיד. ההבחנה בין HITL (Human-in-the-Loop, שבו הסוכן אינו יכול לפעול בלא אישור אנושי מפורש) ל-HOTL (Human-on-the-Loop, שבו הסוכן פועל באופן עצמאי תחת ניטור אנושי) היא כעת מסגרת העבודה לעמידה ב-EU AI Act Article 14, וכל סוכן בסיכון גבוה צריך מיצב מפורש לגבי המודל שחל עליו.

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

הנדסת סוכנים אינה "ChatGPT ועוד MCP servers". זהו מיצב בעלות מבני על התהליכים מקצה-לקצה של המוסד: מסעות לקוח, מחזורי חיים של עסקאות, מישור הבקרה, תשתית הביקורת, והיסוד הקריפטוגרפי העמיד בפני קוונטים, נבנה ומופעל בידי פונקציית ההנדסה של המוסד עצמו, ולא מואצל ל-chatbot.

השנה שבה הנדסת סוכנים הפכה בלתי נמנעת

השיח על AI בשירותים פיננסיים נשלט, עד לא מכבר, בידי שני דברים סמוכים אך נבדלים: ממשקי צ'אט גנרטיביים (מועילים אך תחומים), ותבניות Retrieval-Augmented Generation שהונחו על נתוני הארגון (שימושיות, גם הן תחומות). מה שהשתנה בין סוף 2025 לתחילת 2026 הוא שהקטגוריה השלישית, סוכנים אוטונומיים שמתכננים, מבצעים ומשלימים תהליכי עבודה רב-שלביים בפיקוח אנושי מוגבל, עברה מהדגמה טכנית אל מציאות תפעולית, וחצתה בו-זמנית גם אל הארגון וגם אל גורם האיום.

Andrej Karpathy, שטבע את המונח "vibe coding" בפברואר 2025 ⧉, בילה את השנה שלאחר מכן בצפייה במהנדסים מקצועיים חורגים ממנו. התיקון שלו, "הנדסת סוכנים", הוא כעת המונח הרווח ברחבי התעשייה. מהות המעבר פשוטה: בעבודת תוכנה רצינית ב-2026, מהנדסים אינם כותבים את הקוד ישירות 99% מהזמן. הם מתזמרים סוכנים שעושים זאת, בעודם משמשים כפיקוח. העבודה אינה עוד הקלדת תווים לעורך; היא הפקת מפרטים שמגבילים את מה שהסוכנים יכולים לייצר, עיצוב שערי האימות שהתוצר חייב לעבור, וניהול ההחלטות הארכיטקטוניות שהסוכנים מיישמים.

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

מצב האימוץ בבנקאות

התמונה המצרפית חד-משמעית. על פי מחקר שנאסף מסקרים רבים של 2026, 70% מהבכירים בבנקים ⧉ מדווחים שחברותיהם כבר משתמשות בבינת סוכנים במידה זו או אחרת. Gartner צופה ⧉ שעד סוף 2026 כ-40% מכל חברות השירותים הפיננסיים יפעילו סוכני AI בצורה כלשהי. ההוצאה על AI בשירותים פיננסיים בדרך להגיע ל-67 מיליארד דולר עד 2028 (IDC). McKinsey מעריכה שבינת סוכנים יכולה להשיב 10-12 שעות בשבוע למנהלי קשרי לקוחות בבנקאות.

תמונת הביצוע מעודדת פחות. KPMG מדווחת ⧉ ש-99% מהחברות מתכננות להעביר סוכנים אוטונומיים לייצור אך רק 11% עשו זאת בפועל. EY מוצאת ש-34% מהמנהיגים החלו להשתמש בסוכני AI ורק 14% יישמו אותם במלואם. Forrester מוצאת ש-57% מהארגונים סבורים שחסרות להם היכולות הפנימיות לנצל בינת סוכנים. הפער בין הכוונה לביצוע אינו מוצר שיווקי. הוא שיקוף אמיתי של העבודה ההנדסית, הממשלית והתרבותית שטרם נעשתה.

ה-Financial Conduct Authority של בריטניה העלתה חששות בפומבי ⧉ לגבי מהירות הפריסה שעוקפת את בשלות הממשל, מתח שה-Chief Data Officer של ה-FCA, Jessica Rasu, מסגרה כסיכון קרוב-טווח לצרכן הקמעונאי. McKinsey הזהירה בנפרד שבנקים שאינם מתאימים את מודלי העסק שלהם ⧉ מסתכנים בשחיקה של עד 170 מיליארד דולר ברווחים הגלובליים עד 2030. שתי התצפיות נכונות בו-זמנית. השאלה אינה אם לנוע; אלא כיצד לנוע עם היושרה התפעולית והממשלית שהרגולציה של השירותים הפיננסיים תמיד דרשה, ושמערכות סוכניות מחדדות.

שלושה וקטורי סיכון שהבנקים חייבים להפנים

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

1. היריב האוטונומי

ההתפתחות המבלבלת ביותר של 2026 היא התפעול של בינת סוכנים בצד ההתקפה. באוגוסט 2025 חשפה Anthropic קטגוריית פעילות שכינתה vibe hacking ⧉: פושעי סייבר המשתמשים בבינת סוכנים לביצוע התקפות מתוחכמות בהיקף נרחב, כאשר ה-AI מוטמע לאורך איסוף מודיעין, קצירת אישורי גישה, חדירה לרשת וניתוח נתונים גנובים. בנובמבר 2025 ⧉ חשפה Anthropic ששיבשה מסע של קבוצה סינית בחסות המדינה (המסומנת GTG-1002) שחטפה מופעי Claude Code כדי להריץ ריגול אוטונומי כנגד כשלושים מטרות בתחומי הביטחון, האנרגיה והטכנולוגיה, כאשר ה-AI מטפל ב-80-90% מהפעולות הטקטיות ופועל ב-אלפי בקשות בשנייה, מהירויות בלתי אפשריות עבור מפעילים אנושיים.

בינואר 2026, Step Finance, מנהל תיקי DeFi מבוסס Solana, נפרצה באופן שהפך חדירה למכשיר ל-הפסד של 27-30 מיליון דולר, מכיוון שלסוכני המסחר של ה-AI של החברה היו הרשאות לבצע העברות גדולות בלא אישור אנושי. התוקף הנדס חברתית את ה-AI עצמו, בטענה שהוא מפעיל תוכנית מוסמכת של תגמול על חשיפת פרצות. הלקח ⧉ לא היה ש-AI אינו בטוח מטבעו; אלא ש-סוכן AI המקבל הרשאה נטענת ללא אימות הוא נקודת תורפה בהיקף.

המגמה המצרפית היא מה שהבנקים חייבים להפנים. דוח Global Threat Intelligence של Flashpoint ל-2026 זיהה עלייה של 1,500% בדיונים בלתי חוקיים הקשורים ל-AI ⧉ בין נובמבר לדצמבר 2025, כאשר תוקפים מפתחים באופן פעיל מערכות אוטונומיות שאוספות נתונים, מחליפות תשתית, מתאימות מסרים, ולומדות מניסיונות כושלים בלא פיקוח אנושי מתמשך. Jamie Dimon מ-JPMorgan היה מפורש בפומבי ⧉ ש-היתרון הראשוני בטכנולוגיה זו הולך להתקפה, לא להגנה. ההשלכה אינה נוחה: בנק המפעיל אבטחת סייבר קלאסית כנגד יריבים סוכניים נמצא, מבחינה מבנית, במעמד של שחקן שחמט שיריבו קיבל מחשב.

2. נסיגת איכות הקוד

הווקטור השני פנימי ושקט יותר. קוד שנוצר על ידי LLM, בהיעדר משמעת מפרט ואימות קפדני, מסופק עם פגמים בשיעור גבוה משמעותית מזה של קוד שנכתב בידי אדם. ניתוח SonarQube של חמישה LLMs מובילים ⧉ שיצרו קוד Java מצא ש-יותר מ-70% מהפרצות שזוהו בתוצר של Llama 3.2 90B סווגו בחומרת BLOCKER, כאשר כשני שלישים מהפרצות של GPT-4o ו-OpenCoder-8B סווגו כ-BLOCKER או CRITICAL. Pearce et al. (IEEE S&P) מצאו שכ-40% מתוכניות שנוצרו על ידי LLM בהקשרים רגישי-אבטחה הכילו פרצות. Yan et al. (2025) העמידו את הטווח על 9.8-42.1% לרוחב מדדיהם. קטלוג נפרד של Fu et al. זיהה 43 חולשות CWE לרוחב שלושה כלי יצירת קוד AI.

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

3. עוגן המורשת

הווקטור השלישי הוא זה שהבנקים כבר מבינים היטב, ושהמעבר הסוכני הפך אותו בו-זמנית ליותר דחוף וליותר בר-טיפול. יותר מ-70% מחברות Fortune 500 עדיין נשענות על mainframes, מציין ניתוח Computer Weekly ⧉, לרוב בנויות על עשורים של COBOL ו-RPG שזורים עם לוגיקה עסקית מותאמת. בשירותים פיננסיים בפרט, טכנולוגיות ישנות צורכות 70-75% מההוצאה השנתית על IT ⧉. מחקר CIO שצוטט בניתוח התעשייה של 2026 מצא ש-63% מהבנקים עדיין נשענים על קוד שנכתב לפני שנת 2000, ויותר מ-75% דיווחו שיש להם אדם אחד או שניים בלבד בתוך הארגון עם הכישורים לתחזק אותו.

מה שהשתנה בפברואר 2026 היה הגעתם של כלים סוכניים אמינים למודרניזציה של מורשת. הכרזת Anthropic ש-Claude Code יכול למפות תלויות COBOL, לתעד תהליכי עבודה, ולזהות סיכונים ⧉ שאנליסטים אנושיים היו זקוקים לחודשים כדי לצוף, בשילוב עם יכולות דומות מ-Microsoft (GitHub Copilot for COBOL, Watsonx Code Assistant) ומ-AWS (Mainframe Modernization עם בינת סוכנים), כיווצו את עקומת עלות המודרניזציה באופן ממשי. תגובת מחיר המניה של IBM (ירידה של 13% ביום ההכרזה) הייתה אות שוק מגושם אך מדויק. AI מהווה כעת כשליש מהשקעת המודרניזציה הארגונית, ויותר מ-75% מהארגונים משתמשים ב-AI באסטרטגיית המודרניזציה שלהם. עוגן המורשת הוא, לראשונה, בעיה הנדסית ברת-טיפול ולא בעיה בין-דורית.

מדוע vibe coding אינו יכול להיות ברירת המחדל בבנקאות

ראוי לדייק מדוע vibe coding, פרומפט קצר, תצפית בתוצר, איטרציה, נכשל כתהליך עבודה של ברירת מחדל במערך מפוקח. אופן הכשל אינו הברור מאליו (ה-LLM לעתים הוזה). אופן הכשל מבני ומופיע בארבעה מקומות בו-זמנית.

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

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

השלישי הוא הצטברות פגמים בלתי נראית. הממצאים של Pearce, Yan ו-SonarQube שצוטטו לעיל אינם מקרי קצה. הם השיעור הבסיסי שבו LLMs מייצרים קוד פגיע בהיעדר משמעת מפרט ובדיקות קפדניות. בנק המפעיל תהליכי vibe coding בייצור מצבר את הפגמים הללו באותו שיעור, בלא נראות המשטח כדי לדעת מה סופק.

הרביעי הוא בעיית העקיבות הרגולטורית. Article 12 של EU AI Act דורש רישום אוטומטי של קלטים ופלטים עבור מערכות AI בסיכון גבוה. SR 11-7 דורש תפקידי בעל מודל ומאמת מתועדים, ניהול שינויים לעדכוני מודל, ודיווח לדירקטוריון על סיכון מודל AI. DORA דורש ניהול מקיף של סיכוני ICT עם ראיות מתועדות. אף אחת מהחובות הללו אינה יכולה להתקיים בתהליך עבודה שהתוצר העיקרי שלו הוא היסטוריית צ'אט שאיש אינו משמר.

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

פיתוח מונחה-מפרט במערך מפוקח

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

הכלים המעשיים התגבשו בסוף 2025 ובתחילת 2026. Spec Kit של GitHub ⧉ (שוחרר בסוף 2025) מְפַרְמֵל את הכוונה לפני יצירת הקוד. AWS מטמיעה תהליכי עבודה מונחי-מפרט ישירות אל תוך ה-Kiro IDE שלה. JetBrains ו-Cursor הציגו מצבי תכנון שמבנים את האינטראקציה עם ה-AI. מסגרות כמו BMAD (Breakthrough Method for Agile AI-Driven Development) דוחפות רחוק יותר עם צוותים של סוכני AI מתמחים שמשקפים את תפקידי האנליסט, הארכיטקט, המפתח וה-QA לרוחב ה-SDLC. Constitutional SDD, שפורמל במאמר arXiv בפברואר 2026, מטמיע אילוצי אבטחה מפורשים עם מיפויי פרצות CWE אל תוך המפרט עצמו.

עבור בנק, הגרסה החשובה היא מה שניתוח Augment Code מכנה פיתוח מעוגן-מפרט: המפרטים באים תחילה, ה-AI מייצר קוד המוגבל על ידם, ושכבות ממשל נוספות (אילוצים חוקתיים, נקודות בקרת פיקוח, שערי אישור אנושי) יושבות בין היצירה למיזוג. זו הגרסה היחידה שמייצרת את מסלול הביקורת ש-Article 12 של EU AI Act מצפה לו, את תפקיד המאמת המתועד ש-SR 11-7 דורש, ואת משמעת ניהול השינויים ש-DORA תובעת.

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

המערך הרגולטורי החל כעת

ההיקף הרגולטורי של 2026 סביב AI בבנקאות אינו עוד רשימת תיוג; הוא מערך של חובות חופפות שיש לחשוב עליהן יחד. התאריך המשמעותי ביותר הוא 2 באוגוסט 2026, שבו חובות המערכות בסיכון גבוה של EU AI Act הופכות ניתנות לאכיפה מלאה ⧉. Annex III מסווג במפורש דירוג אשראי, הערכת כושר אשראי, הערכת סיכון בביטוח חיים ובריאות, והערכה או סיווג של מצבם הפיננסי של יחידים כבעלי סיכון גבוה. החובות הנובעות מסיווג זה כוללות הערכות התאמה, מערכות ניהול איכות, מסגרות ניהול סיכונים, תיעוד טכני, רישום במאגר הנתונים של האיחוד האירופי, ממשל נתונים חזק, פיקוח אנושי, והגנות סייבר. עונשים על הפרת חובות הסיכון הגבוה מגיעים ל-35 מיליון אירו או 7% מהמחזור השנתי הגלובלי, הגבוה מביניהם.

לצד ה-AI Act:

DORA (Digital Operational Resilience Act) בתוקף מאז ינואר 2025 ויוצר 22 חובות לניהול סיכוני ICT שמכסות במפורש מערכות AI המשמשות בפונקציות פיננסיות קריטיות. ניהול סיכוני ICT, פיקוח על צד שלישי, דיווח על אירועים, ובדיקות עמידות תפעולית חלים על רכיבי AI כמו על כל נכס ICT אחר.
SR 11-7, הנחיית ניהול סיכון המודל של ה-Federal Reserve וה-OCC, שנכתבה במקור ב-2011, הורחבה בפרקטיקה הרגולטורית ⧉ כדי לכסות LLMs ומערכות סוכניות. בחינות FFIEC כוללות כעת במפורש היקף ממשל AI. מוסדות שאינם יכולים להפיק מלאי מודלי AI והערכות סיכון לפי דרישה מקבלים ממצאים כבר היום.
NIST AI RMF (1.0, ינואר 2023) הוא וולונטרי בארצות הברית אך מוזכר כקו בסיס על ידי רגולטורים פדרליים. ארבע הפונקציות שלו (Govern, Map, Measure, Manage) ממופות בבירור אל הדרישות המבניות של EU AI Act.
ISO/IEC 42001 (פורסם בדצמבר 2023) הוא תקן מערכת ניהול AI הראשון בר-ההסמכה, מובנה כמו ISO/IEC 27001 לאבטחת מידע. הביקוש להסמכת 42001 האיץ בחדות לאורך הרבעון הראשון של 2026 כאשר דרישות רכש החלו להתייחס אליו.
UK SM&CR ו-Consumer Duty, ה-Senior Managers and Certification Regime דורש כעת אחריותיות נקובה בשם עבור כל מערכת AI בסיכון גבוה. Consumer Duty הורחב בהנחיה עדכנית של ה-FCA ⧉ כדי לכסות תוצאות ללקוח הקמעונאי המושפעות מ-AI.
מפת הדרכים הפוסט-קוונטית של G7 (ינואר 2026), מסגרת ההגירה תלת-השלבית של NCSC, וממצאי BIS Project Leap יושבים לצד מערך זה. נקודת החיתוך חשובה: מערכת AI המאומנת או מופעלת על תשתית קריפטוגרפית שאינה שורדת את המעבר הפוסט-קוונטי היא מערכת AI שלטענות מסלול הביקורת והשלמות שלה יש מחצית-חיים של פחות מעשור. השיחה על הנדסת סוכנים והשיחה על קריפטוגרפיה פוסט-קוונטית הן, יותר ויותר, אותה שיחה. (למבט מעמיק על הצד הקריפטוגרפי, ראו את כתבת מאי 2026 על הגירה פוסט-קוונטית בפיננסים תאגידיים.)

שלושה אופני פיתוח בסיוע AI, השוואה

ממד	Vibe Coding	פיתוח מונחה-מפרט	הנדסת סוכנים
קלט עיקרי	פרומפט קצר	מפרט פורמלי	מפרט + תוכנית תזמור סוכנים
תפקיד המהנדס	מבצע איטרציה על פרומפט	מחבר מפרט	מתזמר ומאמת
משמעת התוצר	יצירת קוד ישירה	קוד המוגבל על ידי מפרט	תהליכי עבודה רב-סוכניים המייצרים קוד, בדיקות, תיעוד
מסלול ביקורת	היסטוריית צ'אט (לא נשמרת)	מפרט + קוד שנוצר + בדיקות	מפרט + עקבות סוכן + תוצרי אימות
שיעור פגמים (LLM בלבד)	שיעור פרצות של 10-40% (קו בסיס בספרות)	מופחת ממשית באילוצי מפרט	הנמוך ביותר עם שערי אימות
עקיבות רגולטורית	בלתי מספקת ל-AI בסיכון גבוה	תואם EU AI Act Article 12	תוכנן ל-Article 12 + SR 11-7 + DORA
מתאים לבנקאות?	לא, לייצור	כן, עם ממשל	כן, עם ממשל בשל
תקרת יכולת	חסום על ידי פרומפט חד-פעמי	חסום על ידי איכות המפרט	חסום על ידי איכות התזמור

מקור: סינתזה של פרשנות Karpathy (2026), ניתוח SDD של Augment Code ⧉, ניתוח פיתוח מונחה-מפרט של CGI ⧉, והספרות האקדמית על שיעורי פגיעוּת בקוד שנוצר על ידי LLM (Pearce et al., Yan et al., Fu et al., 2023-2025).

בניית הבנק הסוכני: מבט ארכיטקטוני

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

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

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

שכבה 2: שכבת הנתונים והמודל AIBOM (AI Bill of Materials), רישום מודלים, תשתית אחזור, בקרת גרסאות לתבניות פרומפט, שושלת כיוונון-עדין.

שכבה 1: היסוד העמיד בפני קוונטים ML-KEM, ML-DSA, PKI היברידי, זריזות קריפטוגרפית. התשתית שעליה נשענות טענות השלמות של כל שכבה גבוהה יותר.

שכבה 1, היסוד העמיד בפני קוונטים. כל שכבה שמעליה מניחה את שלמות התשתית הקריפטוגרפית. עם מפת הדרכים של G7, התוכנית תלת-השלבית של NCSC, ו-BIS Project Leap כולם ברשומה הפומבית, זהו אינו עוד חשש נישתי. מערכות סוכניות שמסלולי הביקורת שלהן חתומים תחת ECDSA קלאסי, או שביסוס המפתחות שלהן תלוי ב-RSA או ב-ECDH, יראו את טענות השלמות שלהן פוקעות יחד עם הקריפטוגרפיה. המוסדות שעושים זאת נכון מושכים את העבודה הפוסט-קוונטית במעלה הזרם ומתייחסים ל-ML-KEM, ML-DSA ו-PKI היברידי כאל התשתית שעליה נשענות ערבויות הביקורת והשלמות של כל שכבה גבוהה יותר.

שכבה 2, שכבת הנתונים והמודל. כאן שוכן ה-AI Bill of Materials (AIBOM). באנלוגיה ל-Cryptographic Bill of Materials המשמש בתכנון הגירה פוסט-קוונטית, ה-AIBOM הוא המלאי של כל מודל, מערך נתונים, תבנית פרומפט, אינדקס אחזור, כיוונון-עדין, ותלות AI של צד שלישי שהמוסד מפעיל. זהו התוצר ש-Article 49 של EU AI Act דורש למעשה, המלאי שבחינות SR 11-7 מבקשות כעת, והבסיס לכל מיצב ממשל אמין. לרוב המוסדות אין כזה. הם יזדקקו לו עד אוגוסט.

שכבה 3, תהליכי העבודה הסוכניים. זו השכבה שרוב המוסדות בונים כעת, לעתים קרובות בלא תשומת לב מספקת לשכבות 1, 2 ו-4. תהליכי העבודה עצמם נעים מפנימיים (יצירת קוד, ניסוח מסמכים רגולטוריים, מיון פניות שירות לקוחות) דרך פונים-ללקוח (עוזרי מנהלי קשרי לקוחות, קליטה, תזמור KYC, ניטור עסקאות, אופטימיזציית FX) ועד אוטונומיים לחלוטין (תפעול אוצר, פונקציות מסוימות של מסחר וניהול סיכונים במקום שסובלנות הרגולטור מתירה). המשמעת האסטרטגית בשכבה זו היא להתייחס אליה כאל הנדסת מערכות, לא כאל פיתוח יישומים: תבניות תזמור, כללי הסלמה, שערי human-in-the-loop, ופליטת ביקורת הם שיקולי תכנון מהמעלה הראשונה.

שכבה 4, מישור בקרת הסוכן. זהו מה ש-Deloitte תיארה כ"חדר בקרת הסוכן" ⧉: תשתית הביקורת בזמן אמת, רישום הפעולות, זיהוי חריגות התנהגותיות, מתגי החירום, והעקיפה האנושית המקיפה כל סוכן בייצור. ההפסד של Step Finance לא היה, מבחינה טכנית, כשל AI. הוא היה כשל של מישור הבקרה: לסוכנים היו הרשאות שלא היו צריכות להיות להם, והחריגה ההתנהגותית שהייתה צריכה להפעיל עצירה לא הופעלה. המוסדות הבונים את מישור הבקרה תחילה, לפני הרחבת פריסת הסוכנים, הם אלה שלא יראו אירועים מסוג Step Finance ב-2027.

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

פיקוח אנושי בפועל: HITL מול HOTL

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

Human-in-the-Loop (HITL) הוא המודל שבו סוכן אינו יכול לבצע פעולה משמעותית בלא אישור אנושי מפורש. הסוכן מכין את ההחלטה, מציג אותה, וממתין. סוכן תיקון KYC המסמן חשבון לסגירה אך אינו יכול לסגור אותו בלא חתימת קצין ציות הוא HITL. הפשרה תפעולית: HITL בטוח יותר ומייצר מסלול ביקורת Article 14 חד-משמעי, אך אינו מתרחב לתהליכי עבודה בנפח גבוה והשהיה נמוכה.

Human-on-the-Loop (HOTL) הוא המודל שבו סוכן פועל באופן עצמאי בתוך פרמטרים תחומים, כאשר בני אדם מנטרים טלמטריה בזמן אמת ושומרים על הסמכות לעצור את הסוכן בכל נקודה. סוכן סינון הונאות בזמן אמת החוסם אוטומטית עסקאות התואמות דפוסי סיכון מסוימים, כאשר צוות תפעול אנושי צופה בנפח ההתראות ומתערב בחריגות, הוא HOTL. הפשרה הפוכה: HOTL מתרחב, אך הוא נשען על כך שהפרמטרים של הסוכן מוגדרים נכון ועל זיהוי חריגות התנהגותיות שתופס סחף לפני שהנזק מצטבר.

EU AI Act Article 14 אינו קובע HITL מול HOTL; הוא דורש שהפיקוח האנושי יהיה בעל משמעות. ההשלכה המעשית היא שלכל סוכן בסיכון גבוה שהבנק מפעיל חייב להיות מיצב מפורש ומתועד לגבי המודל שחל, מדוע, ומהו מסלול ההסלמה כאשר הסוכן נתקל במצבים מחוץ לפרמטרים התחומים שלו. לרוב הבנקים שהריצו פיילוטים ב-2025 לא היה תיעוד זה. רוב הבנקים שיריצו סוכנים בייצור עד אוגוסט 2026 יזדקקו לו.

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

קנייה מול בנייה: בעיית הסוכן מצד שלישי

המציאות של 2026 שהתגנבה אל רוב הבנקים היא שהם לא, בעיקר, יבנו יכולת סוכנית. הם יקנו אותה. סביבת הספקים, פלטפורמת הבנקאות הסוכנית של Oracle שהושקה בפברואר 2026, Watsonx של IBM, חבילת Copilot של Microsoft, AWS Bedrock Agents, Salesforce Agentforce, NowAssist של ServiceNow, וגל ספקי הסוכנים המתמחים בפינטק, נעה מהר יותר מכפי שהנדסת הבנק הפנימית יכולה. ההשלכה האסטרטגית היא ש-רוב הסוכנים הפועלים בתוך בנק ב-2027 ייכתבו בידי מישהו אחר, ושאלת הממשל אינה עוד "האם אנו יכולים לבטוח בסוכנים שלנו?" אלא "האם אנו יכולים לבטוח בסוכנים שרכשנו, והאם אנו יכולים להוכיח זאת לרגולטור?"

זהו האתגר הרועש והבלתי-מוכר ביותר תחת DORA. Articles 28-30 של הרגולציה הופכים את ניהול סיכוני הצד השלישי ל-ICT לתחום פיקוח פעיל, עם דרישות מפורשות המכסות הוראות חוזיות, ניטור מתמשך, הערכת סיכון ריכוזיות, ואסטרטגיות יציאה. רשויות הפיקוח האירופיות מנהלות מרשם של ספקי ICT קריטיים מצד שלישי, עם סמכויות פיקוח ישירות על אלה המוגדרים ככאלה. המציאות התפעולית החדשה היא שספקי ה-AI של 2026, ספקי המודלים המובילים, ספקי פלטפורמות הסוכנים, ו-SaaS מאופשר-AI, הם, יותר ויותר, הצדדים השלישיים של ICT ש-DORA נכתב כדי לכסות.

עבור בנק במיצב הקנייה, שלוש משמעות מעשיות חלות:

דרשו את ה-AIBOM מהספק. כל מוצר סוכן הנרכש לשימוש בתהליכי עבודה בסיכון גבוה חייב להגיע עם רשימת מרכיבים מתועדת המכסה את המודלים הבסיסיים, מקור נתוני האימון ומגבלותיהם, הכיוונונים-העדינים שהוחלו, אינדקסי האחזור הנגישים, גרסאות תבניות הפרומפט, ושרשרת התלות לרכיבי הסוכן במורד הזרם. זהו התוצר שהבנק יזדקק לו כדי לעמוד בדרישות התיעוד של Article 13 תחת EU AI Act. הבנק אינו יכול להפיק אותו רטרואקטיבית מספק שלא התחייב חוזית לספקו.

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

נהלו מחדש משא ומתן על החוזים בתנאי Article 13. רוב הסכמי ספקי ה-AI הקיימים אינם כוללים אף אחת מדרישות התיעוד, זכויות הביקורת, הודעת שינוי מודל, דיווח האירועים, או חשיפת מעבד-משנה ש-EU AI Act ו-DORA דורשים יחד. ניתוח Regulativ של חברות בריטיות ⧉ היה מפורש בנקודה זו: סקירה משפטית של הסכמי ספקים אורכת שבועות, ורוב המוסדות אינם יכולים לעמוד ב-Article 13 עבור מודל שספקם מעולם לא היה מחויב חוזית לחשוף את מנגנוניו הפנימיים. החובה הרגולטורית יושבת אצל הפורס, לא אצל הספק. צוותי הרכש צריכים לדעת זאת לפני מחזור החידוש הבא, לא אחרי בירור רגולטורי.

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

מה משמעות הדבר לפי סוג בנק

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

בנקים אוניברסליים מהדרג הראשון

מוסדות עם מאזנים של טריליון דולר ומעלה ונוכחות גלובלית הם בו-זמנית החשופים ביותר (ההיקף הרגולטורי הרחב ביותר, מערך המורשת הגדול ביותר, המטרה בעלת הערך הגבוה ביותר עבור יריבים אוטונומיים) והמתוקצבים ביותר. העדיפות האסטרטגית היא לבנות את מישור הבקרה תחילה, שכבה 4 של הארכיטקטורה לעיל, ולהכניס משמעת פיתוח מונחה-מפרט אל פונקציית ההנדסה הפנימית לפני הרחבה נוספת של פריסת הסוכנים. ההשלכה התחרותית של עשייה נכונה משמעותית; ההשלכה של עשייה שגויה קיומית, לנוכח חשיפת העונש תחת EU AI Act והחשיפה התפעולית לדפוסי איום מסוג GTG-1002.

בנקים מהדרג הבינוני ואזוריים

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

פינטקים, PSPs, ומוסדות סמוכי-קריפטו

מגזר הפינטק ומוסדות התשלומים ניצב בפני הבעיה ההפוכה: הזריזות גבוהה, הממשל לרוב נמוך מזה של בנקים עמיתים, וחשיפת העונש של EU AI Act, עבור פינטק בינוני, עלולה להיות קיומית. המשמעת האסטרטגית היא להתייחס לממשל AI כאל שער מוכנות-מוצר ולא כאל שכבת ציות: לבנות את ה-AIBOM, את תשתית הביקורת, ואת תהליכי העבודה מונחי-המפרט אל תוך תרבות ההנדסה מלכתחילה, ולא להתאים אותם בדיעבד תחת לחץ רגולטורי. עבור מוסדות שתשתית התשלומים שלהם מצטלבת עם מועד הסיום של SWIFT CBPR+ לכתובת מובנית בנובמבר 2026, ההשקעה בהנדסת סוכנים היא גם המנגנון הטבעי לתיעוש עבודת תיקון הכתובת המובנית: כללי האימות, אכיפת איכות הנתונים, ושילוב צינור ה-CI הם בדיוק הדפוסים שתהליכי עבודה מונחי-מפרט הופכים לברי-טיפול.

פונקציות הנדסה פנימיות

עבור המהנדסים והחוקרים הקוראים זאת, המשמעת החשובה היא היומיומית. העבירו את מרכז הכובד של העבודה מהקלדת תווים אל הפקת מפרטים ורתמות אימות. התייחסו לעקבות הסוכן, לתוכניות הביניים, ולשערי האישור כאל תוצרים מהמעלה הראשונה בבקרת הגרסאות שלכם. השקיעו בכלים, Spec Kit, Kiro, מצב התכנון של Cursor, Claude Code עם קובצי מיומנות ברמת הפרויקט, שהופכים את המפרט לתוצר העמיד ואת הקוד שנוצר לחד-פעמי. השינוי הארגונומי אמיתי. הגמול המקצועי הוא שהמשמעת המאומצת בחזית היא גם המשמעת ששורדת בחינה רגולטורית.

תוכנית הפעולה ל-12 שבועות עד אוגוסט 2026

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

שבועות 1-2, הפיקו את ה-AIBOM. הקימו את המלאי המרוכז של כל מערכת AI, מודל, מערך נתונים, תבנית פרומפט, אינדקס אחזור, כיוונון-עדין, ותלות AI מצד שלישי בייצור או בפיתוח. מפו כל רשומה לסיווג Annex III של EU AI Act. התוצר הוא מקור אמת יחיד שה-CRO, ה-CCO, ה-CISO וה-CTO יכולים כל אחד לתשאל.

שבועות 3-4, סווגו מודל פיקוח לכל מערכת. עבור כל סוכן בסיכון גבוה ומשמעותי, תעדו במפורש אם מודל הפיקוח הוא HITL או HOTL, את הרציונל, את מסלול ההסלמה, ואת האדם הנקוב בשם האחראי תחת SM&CR (בריטניה) או המשטר הלאומי המקביל. במקום שהתשובה אינה ברורה, ברירת המחדל היא HITL עד להשלמת הניתוח.

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

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

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

שבועות 11-12, אימות טרום-מעבר ואישור דירקטוריון. סקירה סופית של ה-AIBOM, סיווגי ה-HITL/HOTL, ראיות מישור הבקרה, מצב תיקון הספקים, ותוצרי הערכת ההתאמה. אחריותיות מנהל בכיר נקוב בשם מאושרת. הדירקטוריון מתעד את המיצב בפרוטוקול. יידעו את הרגולטור במקום שהמסגרת מצפה ליידוע מוקדם.

המוסדות שישלימו את רצף שנים-עשר השבועות הזה לא יפתרו את הנדסת הסוכנים. הם יבססו את הרצפה שתוכנית אמינה דורשת. המוסדות שלא התחילו עד למועד פרסום מאמר זה אינם, כפי שניתוח Regulativ ניסח את אותה הנקודה בצד SWIFT, רשלניים באופן ייחודי. הם הרוב. השאלה שכל CCO, CRO ו-CTO צריכים לענות עליה בשבועיים הקרובים היא אם החברה פועלת במאי או מתרוצצת ביולי.

סיכום

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

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

להקשר קודם באתר זה, כתבת אפריל 2026 על ספי הקוונטים סקרה את מסלול החומרה העומד בבסיס שכבה 1 של הארכיטקטורה לעיל, כתבת מאי 2026 על הגירה פוסט-קוונטית לפיננסים תאגידיים סקרה את התשתית הקריפטוגרפית לעומק, ניתוח מאי 2026 של מועד הסיום ל-pacs.008 לכתובת מובנית סקר את המשמעת הרגולטורית וההנדסית שאימות מונחה-מפרט הופך לברת-טיפול, והעבודה בקוד פתוח ב-Rust על KyberLib, pain001 ו-pacs008 יושבת במאמץ הרחב יותר להעמיד פרימיטיבים ברמת ייצור, עמידים בפני קוונטים, תואמי-תשלומים, מוכנים-לביקורת, בידי צוותי ההנדסה שיבנו את הבנק הסוכני. הקשר בין הכתבות הללו אינו מקרי. זו צורת העבודה שהשנתיים הקרובות דורשות.

שאלות נפוצות

מה ההבדל בין generative AI, agentic AI, והנדסת סוכנים?

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

מדוע מועד הסיום של EU AI Act באוגוסט 2026 כה משמעותי לבנקים?

Annex III של ה-AI Act מסווג במפורש כמה מקרי שימוש ליבתיים של AI בבנקאות כבעלי סיכון גבוה: הערכת כושר אשראי ודירוג אשראי של אנשים טבעיים, הערכת סיכון ותמחור בביטוח חיים ובריאות, והערכה או סיווג של מצבם הפיננסי של יחידים. מ-2 באוגוסט 2026, הפורסים של מערכות אלה חייבים להוכיח עמידה במערכות ניהול איכות, מסגרות ניהול סיכונים, תיעוד טכני, הערכות התאמה, רישומים במאגר הנתונים של האיחוד האירופי, ממשל נתונים חזק, פיקוח אנושי, והגנות סייבר. Article 12 דורש רישום אוטומטי של קלטים ופלטים. Article 14 דורש פיקוח אנושי בעל משמעות (HITL או HOTL, כמתאים למערכת). העונשים על הפרה מגיעים ל-35 מיליון אירו או 7% מהמחזור השנתי הגלובלי. העבודה לעמידה בחובות אלה היא עבודה הנדסית, לא עבודת תיעוד, וזו הסיבה המעשית לכך שמשמעת מונחית-מפרט האיצה לאורך הרבעון הראשון של 2026.

מהו ההבדל המעשי בין HITL ל-HOTL, ומתי כל אחד צריך לחול?

HITL (Human-in-the-Loop) פירושו שהסוכן אינו יכול לבצע פעולות משמעותיות בלא אישור אנושי מפורש. HOTL (Human-on-the-Loop) פירושו שהסוכן פועל באופן עצמאי בתוך פרמטרים תחומים, כאשר בני אדם מנטרים טלמטריה ושומרים על הסמכות לעצור בכל נקודה. EU AI Act Article 14 דורש שהפיקוח יהיה בעל משמעות אך אינו קובע איזה מודל. כלל ההחלטה הוא להחיל HITL במקום שהפעולה משמעותית, בנפח נמוך ובלתי הפיכה (סירוב אשראי, סגירת חשבון, אישור העברה בערך גבוה, הגשת דיווח רגולטורי); ו-HOTL במקום שהפעולה בנפח גבוה, הפיכה ותחומת-פרמטרים (התראות ניטור עסקאות, סיווג מסמכים, מיון שגרתי של שירות לקוחות). שניהם דורשים שתשתית מתג החירום והעקיפה תהיה פעילה ונבדקת; ההבדל הוא אם האדם נמצא במעלה הזרם של הביצוע (HITL) או לצדו (HOTL).

רוב הסוכנים שלנו יגיעו מספקים. כיצד נעמוד ב-DORA וב-EU AI Act עבור מערכות שלא בנינו?

החובה הרגולטורית יושבת אצל הפורס, לא אצל הספק. התשובה המעשית משולשת. ראשית, דרשו AIBOM מתועד מהספק לפני החתימה, שושלת מודל, מקור נתוני האימון, כיוונונים-עדינים, תבניות פרומפט, אינדקסי אחזור, שרשרת תלות. שנית, בצעו בדיקה התנהגותית של הסוכן תחת תנאים אנלוגיים לייצור, לרבות גישוש יריב לזריקת פרומפט ועמידות בפני הנדסה חברתית. שלישית, נהלו מחדש משא ומתן על חוזי הספקים כדי לכלול זכויות תיעוד Article 13, הודעת שינוי מודל, דיווח אירועים, זכויות ביקורת, וחשיפת מעבד-משנה, לרוב החוזים הקיימים אין אף אחד מאלה. DORA Articles 28-30 מכסים ניהול סיכוני צד שלישי ל-ICT והם העוגן הרגולטורי הרלוונטי בצד האירופי; הנחיית FFIEC היא המקבילה בצד האמריקאי. העבודה משמעותית; לא ניתן לדחות אותה.

עד כמה בנקים צריכים באמת לדאוג מיריבים סוכניים?

התשובה הכנה היא שהאיום אמיתי ונבדל תפעולית מאיומי הסייבר הקודמים. חשיפת Anthropic מנובמבר 2025 של GTG-1002 היא הדוגמה המובהקת: בינת סוכנים המטפלת ב-80-90% מהפעולות הטקטיות במסע ריגול בחסות מדינה כנגד כשלושים מטרות בתחומי הביטחון, האנרגיה והטכנולוגיה, הפועלת באלפי בקשות בשנייה. אירוע Step Finance בינואר 2026, הפסד של 27-30 מיליון דולר שהונע בידי סוכני מסחר AI עם סמכות מוגזמת, הוא הדוגמה המובהקת לאופן שבו פריסת AI פנימית יכולה להפוך למשטח התקפה. ה-GTIR של Flashpoint ל-2026 צפה בעלייה של 1,500% בדיונים בלתי חוקיים הקשורים ל-AI בחודש בודד. אלה אינם תרחישים היפותטיים; זהו חומר של דוחות אירועים מ-2025-2026. בנקים המפעילים אבטחה קלאסית כנגד יריבים סוכניים חשופים, מבחינה מבנית, באופן א-סימטרי, והתגובה הנכונה היא לבנות יכולת הגנה של AI-מול-AI ולא להאט את המעבר הסוכני בצד ההתקפה.

האם agentic AI הוא רק "ChatGPT ועוד MCP servers"?

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

מהו הדבר החשוב ביותר שבנק צריך לעשות בשנים-עשר השבועות הקרובים?

שלושה דברים, ברצף. ראשית, הפיקו את ה-AI Bill of Materials, המלאי המלא של כל מערכת AI, מודל, מערך נתונים, תבנית פרומפט, אינדקס אחזור, ותלות AI מצד שלישי בייצור או בפיתוח, כאשר כל רשומה מסווגת מול Annex III של EU AI Act. המוסד שאינו יכול להפיק זאת כאשר רגולטור מבקש הוא המוסד שיקבל ממצאים. שנית, בנו את מישור בקרת הסוכן עבור כל מערכת AI המקבלת כעת או משפיעה ממשית על החלטות הנוגעות ללקוח, רישום ביקורת, זיהוי חריגות התנהגותיות, עקיפה אנושית, ומתגי חירום כתשתית ברירת מחדל, לא כפריט במפת דרכים עתידית. שלישית, העבירו את תרבות ההנדסה הפנימית מ-vibe coding לפיתוח מונחה-מפרט בעבודה החשובה ביותר, מערכות בסיכון גבוה, תהליכי עבודה מפוקחים, וצינור מודרניזציית המורשת. השניים הראשונים הם עבודת ציות; השלישי הוא עבודה תחרותית. המוסדות שיעשו את כל השלושה יהיו במיצב חזק ממשית מאלה שיעשו אחד או אף אחד. הרצף המלא של שנים-עשר השבועות מפורט בסעיף תוכנית הפעולה לעיל.

מקורות

Sebastien Rousseau, (2026). אבטחת הפנקס: מדריך ברמת הדירקטוריון להגירה פוסט-קוונטית בפיננסים תאגידיים.
Sebastien Rousseau, (2026). מועד היעד של pacs.008 לכתובת המובנית בנובמבר 2026: מבט של שישה חודשים.
Sebastien Rousseau, (2026). Quantum Thresholds Are Moving Again.
Sebastien Rousseau, (2023). CRYSTALS-Kyber: אלגוריתם ההגנה בעידן הקוונטי.
Mansurova, M. (2026). From Vibe Coding to Spec-Driven Development ⧉. Towards Data Science.
CGI, (2026). Spec-driven development: From vibe coding to intent engineering ⧉. CGI.
Augment Code, (2026). What Is Spec-Driven Development? A Complete Guide ⧉. Augment Code.
BCMS, (2026). Spec-Driven Development: The Definitive 2026 Guide ⧉. BCMS.
Deloitte, (2026). Managing the new wave of risks from AI agents in banking ⧉. Deloitte Center for Financial Services.
Anthropic, (2025). Detecting and countering misuse of AI: August 2025 ⧉. Anthropic.
Anthropic, (2025). Disrupting the first reported AI-orchestrated cyber espionage campaign ⧉. Anthropic.
Flashpoint, (2026). 2026 Global Threat Intelligence Report ⧉. HSToday / Flashpoint.
Beam AI, (2026). 5 Real AI Agent Security Breaches in 2026 and Their Lessons ⧉. Beam.
Congressional Research Service, (2026). Agentic Artificial Intelligence and Cyberattacks ⧉. Congress.gov.
European Commission, (2024). Regulation (EU) 2024/1689 on Artificial Intelligence (EU AI Act).
Knowlee, (2026). EU AI Act for Financial Services: Annex III Obligations for Banks, Fintechs, and Insurers ⧉. Knowlee.
Regulativ, (2026). The EU AI Act's August 2026 Deadline: What Financial Services Firms Must Do Now ⧉. Finextra.
AegisAI Compliance, (2026). AI Governance for Banks: SR 11-7 & EU AI Act Compliance Guide ⧉. AegisAI.
The Financial Brand, (2026). How Autonomous AI Agents Will Really Redefine Banking Growth ⧉. The Financial Brand.
UXDA, (2026). Could Agentic AI Banking Threaten Global Financial Services? ⧉. UXDA.
Neurons Lab, (2026). Agentic AI in Financial Services: A Research Roundup for 2026 ⧉. Neurons Lab.
Computer Weekly, (2026). AI to help mainframes remain business critical in 2026 ⧉. Computer Weekly.
The Financial Revolutionist, (2026). Legacy systems are putting banks at risk ⧉. The Financial Revolutionist.
CIO Magazine, (2025). Using AI to modernize mainframes: Turning legacy tech into a strategic advantage ⧉. CIO Magazine.
Microsoft Azure, (2025). How We Use AI Agents for COBOL Migration and Mainframe Modernization ⧉. Microsoft DevBlogs.
VentureBeat, (2026). Agentic coding at enterprise scale demands spec-driven development ⧉. VentureBeat.
The News (Pakistan), (2026). Why British banks' push for agentic AI is worrying UK regulators ⧉. The News International.
CNBC, (2026). Anthropic's Mythos set off a cybersecurity 'hysteria' ⧉. CNBC.

נסקר לאחרונה 2026-08-06.

פרסום מחדש של הכתבה

הנדסת סוכנים לבנקים: תוכנית אב ל-2026 עבור ההנהלה הבכירה והמהנדסים שיבנו אותה — Sebastien Rousseau

כתבה זו מפורסמת ברישיון Creative Commons Attribution 4.0 International. פרסום מחדש מחייב ייחוס לכתובת ה-URL הקאנונית.

הנדסת סוכנים לבנקים: תוכנית אב ל-2026 עבור ההנהלה הבכירה והמהנדסים שיבנו אותה — Sebastien Rousseau

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

Originally published at https://sebastienrousseau.com/he/2026-05-17-agentic-engineering-banks-blueprint-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER