סוכני AI אוטונומיים בבנקאות הם כיום בעיה הנדסית המחופשת לבעיית AI. המודל ניתן להחלפה; מישור הבקרה אינו ניתן להחלפה. האתגר של 2026 אינו אימוץ — Cambridge CCAF כבר מעמיד אותו על 52% — אלא האם המערכות האוטונומיות שהבנק שלכם מפעיל היום יעמדו בבדיקת SR 11-7 ברבעון הבא. מרביתן לא יעמדו.
תקציר מנהלים / נקודות מפתח
- הפסיקו לקרוא להם צ'אטבוטים. יחידת הייצור היא תהליך עבודה תחום עם הרשאות קריאה לכלי קפדניות. העבודה מתרחשת בתוך תהליך העבודה, לא בתוך ה-LLM.
- OSWorld ב-66.3% הוא תקרת האמינות. אמת המידה הקרובה ביותר של Stanford HAI לשימוש כלים ארגוני עדיין נכשלת באחת מכל שלוש משימות מובנות. זהו מספר המצדיק פריסה אגרסיבית של אדם בלולאה; הוא אינו מצדיק ביצוע ללא פיקוח על כל דבר שנוגע בכספי לקוחות.
- סווגו לפי הרשאות, לא לפי אינטליגנציה. סולם האוטונומיה רץ מרמה 0 (חילוץ סעיפי ISDA לקריאה בלבד) עד רמה 4 (תיקון תשלומים רב-כלי עם נקודות ביקורת חובה). רמה 5 — ביצוע אוטו-מתזמר ללא נקודות ביקורת — אינה אמורה להתקיים בבנקאות בייצור ב-2026.
- מישור הבקרה של הסוכן מורכב מחמישה רכיבים הנדסיים, לא ממסמך מדיניות. חשבונות שירות מוגבלי-OAuth, ניתוב סמנטי דטרמיניסטי, שערי Open Policy Agent, רישום ביקורת WORM ומתג חירום נבדק. כל רכיב חסר הוא ממצא.
- SR 11-7 ו-PRA SS1/23 כבר חלים. הפדרל ריזרב הבהיר שוב ושוב שכל מערכת קבלת החלטות מקלט-לפלט נכללת בתחולה. בנקים הטוענים ש-LLM אינו מודל הפסידו את הוויכוח הרגולטורי לפני שפתחו בו.
מדוע 2026 היא השנה שבה המדד הזה משמעותי #
המעבר מצ'אט לתהליכי עבודה תחומים הוא הדבר היחיד שמשמעותי בסוכני AI אוטונומיים בבנקים השנה. צ'אטבוט המנסח אימייל ללקוח ניתן לבדיקה. סוכן הקורא ל-POST /accounts/{id}/freeze כנגד פלטפורמת הכרטיסים שלכם בייצור הוא ראיה הניתנת לביקורת. הייצור השיג את המסגרת המושגית: סקר Cambridge CCAF לשנת 2026 מדווח על 52% אימוץ פעיל של סוכנים ועל 23% בבשלות של הרחבה או טרנספורמציה (Cambridge CCAF ⧉). סף "הפיילוט המבודד" נחצה אי-שם בסוף 2025.
שני דברים השתנו במקביל לאימוץ.
ראשית, הרגולטורים הפסיקו להתייחס ל-LLMs כחידוש. הפדרל ריזרב הבהיר ש-SR 11-7 ⧉ חל על קבלת החלטות מבוססת-LLM ללא קשר לסיווג הפנימי של ה-LLM כמודל. ה-SS1/23 ⧉ של ה-PRA היה תמיד רחב מספיק כדי לכלול אותם. סיווג הסיכון הגבוה של חוק ה-AI של האיחוד האירופי מכסה את רוב השימושים ב-LLM בשירותים פיננסיים. אין יותר טיעון של "אנחנו לא בטוחים אם זה נספר".
שנית, מציאות אמות המידה הגיעה. מדד ה-AI של Stanford HAI לשנת 2026 מדווח על OSWorld — אמת המידה הזמינה הקרובה ביותר לשימוש כלים ארגוני אמיתי — בדיוק של 66.3% (Stanford HAI ⧉). אחת מכל שלוש משימות מובנות עדיין נכשלת. מספר זה קובע את התקרה הטכנית לאוטונומיה ב-2026. גבוה מספיק כדי להצדיק פריסות מוגבלות של רמה-3 תחת פיקוח HITL; לא גבוה מספיק כדי להצדיק ביצוע ללא פיקוח כנגד כל API שנוגע בכספי לקוחות.
מדד סוכני ה-AI לבנקים צריך לעשות עבור קבלת החלטות מבוססת-LLM את מה שמסגרת Basel עשתה עבור הון: להמיר טענות של "יש לנו בקרות" לראיות מדידות הניתנות לביקורת לכל תהליך עבודה.
ארכיטקטורת המדד לשנת 2026 #
| שכבת מדד | איך נראה "מוכן" | מדד בשלות | אופן כשל |
|---|---|---|---|
| דרגת אוטונומיה | כל תהליך עבודה בייצור מתויג ברמה 0–4; אין רמה 5 בייצור | % תהליכי עבודה לפי דרגה; חלק ברמה 3+ | סוכן בייצור משדר pacs.008 ל-BIC מוטב הזוי כי שום רשימת היתר סטטית לא מסננת את המטען לפני SWIFTNet |
| הרשאות API | כל סוכן ממופה לחשבון שירות אחד עם היקפי OAuth של הרשאה מינימלית (לדוגמה, card-freeze:write:lt-5000usd); MTLS לליבה מדור קודם |
% סוכנים בהרשאה מינימלית; ספירת הרשאות יתומות | סוכן עושה שימוש חוזר בחשבון שירות עם היקף עודף; משייט בחשבונות שאסור היה לו לקרוא; אירוע סעיף 33 של GDPR מדווח תוך 72 שעות |
| מעקפי בטיחות דטרמיניסטיים | כל קריאה לכלי מנותבת דרך נתב סמנטי (NeMo Guardrails / LangChain Guardrails) בתוספת מאמת JSON-schema לפני ה-API | % קריאות לכלי שיורטו; שיעור דחייה לפי קטגוריה | LLM משדר קריאת transfer עם amount: 0; ה-API במורד הזרם לא מאמת; התראת הצלבת ספרים נוחתת 18 שעות אחר כך באזור זמן אחר |
| כיסוי אדם בלולאה | כל ביצוע ברמה-3 מציג ממשק אישור עם תפוגת זמן קשיחה; אישור אוטומטי מבוטל על ידי מדיניות | תפוקת אישורים; שיעור אישור חתימה אוטומטית (אושר תוך פחות מ-2 שניות) | מפעיל לוחץ "אשר" על 200 התראות ב-4 דקות; SAR מוגש כנגד לקוח לגיטימי; תלונת רגולטור תוך שבוע |
| שלמות ביקורת | יומן ביקורת WORM בלתי-משתנה לוכד system prompt + הקשר שאוחזר + פלט LLM + קריאה לכלי + תוצאת כלי + UID מאשר; חתום קריפטוגרפית בזמן הכתיבה | % הפעלות עם עקבה מלאה | בוחן SR 11-7 שואל מדוע סוכן #4421 אישר העברה של $4.8M; לבנק יש את אישור ההעברה ואת כרטיס המודל; אין ראיה ברמת ה-prompt; ממצא הוגש |
| כלכלת יחידה | עלות להחלטה מושלמת נמדדת כולל עלות היפוך ותיקון; חיובית מול קו בסיס ידני | עלות נטו להחלטה; שיעור היפוך | הוצאה לטוקן על סוכני מקרי קצה עולה על עלות החוקר הידני שהחליפו; ה-CFO סוגר את התוכנית ברבעון 3 |
אותות נוכחיים למעקב #
| אות | המשמעות עבור בנקים | מקור |
|---|---|---|
| 52% אימוץ פעיל | סוכני AI אוטונומיים עברו את שלב הפיילוט; ממשל ברמת מוסד מתעכב | Cambridge CCAF ⧉ |
| 23% בהרחבה או טרנספורמציה | מיעוט משמעותי עבר את התיאטרון של הוכחת היתכנות | Cambridge CCAF ⧉ |
| OSWorld ב-66.3% | שיעור כשל של אחת מכל שלוש בשימוש כלים מובנה. ביצוע ללא פיקוח כנגד ממשקי API של כספי לקוחות אינו בר-תמיכה ברמת אמינות זו | Stanford HAI ⧉ |
| 55% מצטטים אובדן פיקוח אנושי כסיכון מוביל | תכן בקרה הוא הדאגה ההנדסית העיקרית, לא דאגת ציות במורד הזרם | Cambridge CCAF ⧉ |
| 76% ממוסדות פיננסיים גדולים מתקשים למדוד ערך | טענות פרודוקטיביות גנריות לא שורדות שיחה עם CFO. מדדו לכל תהליך עבודה, לא לכל תוכנית | Cambridge CCAF ⧉ |
סולם האוטונומיה #
סווגו סוכנים לפי מה שמותר להם לעשות, לא לפי חוכמת המודל שמתחת. אותו מופע של GPT-5 / Claude 4 / Gemini 3 יכול לשבת בכל דרגה; העטיפה היא מה שמשתנה.
- רמה 0 — תצפית. גישת קריאה בלבד ליומנים, עקבות או עסקאות. הסוכן מאתר דפוסים או חריגות; ללא כתיבה לשום מקום. דוגמה: זיהוי סחיפה בשיעורי דחיית
pacs.008לפי מסדרון והתראה לצוות התפעול. - רמה 1 — אחזור לקריאה בלבד. קורא ממערכות תפעוליות; משדר פלט מובנה לצריכה אנושית. דוגמה: חילוץ וריאציות סעיף CSA מהסכם ISDA Master Agreement של צד נגדי וסימון סטיות מהתבנית הסטנדרטית של הבנק. הסוכן לעולם לא כותב חזרה למאגר החוזים.
- רמה 2 — טיוטה להגשה אנושית. מייצר תוכן שאדם בודק ומגיש. דוגמה: ניסוח Suspicious Activity Report מהתראת מערכת הונאה בתוספת רשומת KYC ועקבה של עסקאות; קצין ה-BSA קורא, עורך אם צריך, ומגיש. מערכת הרשומה רואה רק את הגרסה שאושרה על ידי אדם.
- רמה 3 — ביצוע תחום. קורא ל-API ייצור עם מגבלות קשיחות דטרמיניסטיות הנאכפות על ידי העטיפה. דוגמה: קריאת API להקפאת כרטיס עם
max-amount-at-risk: 5000 USDהנאכפת על ידי מדיניות רשימת היתר; הסוכן לא יכול להקפיא כרטיס המקושר ליתרות מעל סף זה ללא הסלמה לרמה-2. המגבלה חיה במדיניות כקוד, לא ב-prompt — prompts אינם גבול אבטחה. - רמה 4 — תזמור רב-כלי עם נקודות ביקורת חובה. מריץ רצף על פני מערכות; כל מעבר מצב נרשם; נקודות ביקורת דורשות אישור אנושי לפני הקריאה הבאה לכלי. דוגמה: תהליך עבודה לתיקון תשלומים — חילוץ
pacs.008שנכשל מתור המכתבים המתים → איתור מוטב נכון דרך SWIFT KYC Registry → ייצור הודעה מתוקנת → כתיבה לתור היוצא → אדם מאשר את שליחה מחדש. אם צעד כלשהו נכשל במאמת הסכימה, תהליך העבודה נעצר ויוצר מקרה חריג. - רמה 5 — אוטו-תזמור. הסוכן מתכנן ומבצע ללא אישור נקודת ביקורת. שום תהליך עבודה בנקאי בייצור לא אמור להיות ברמה 5 ב-2026. זו אינה הצהרת בשלות; זו הצהרת אמינות. OSWorld ב-66.3% מצטבר על פני קריאות API מקושרות. שלוש קריאות לכלי ב-66% כל אחת זה 29% הצלחה מקצה לקצה. חמש זה 13%. אל.
מישור הבקרה של הסוכן #
מישור הבקרה הוא השכבה ההנדסית בין ה-LLM למערכות הייצור שלכם. חמישה רכיבים, כולם בזמן ריצה, אף אחד מהם לא כתוב במסמך מדיניות.
1. זהות והרשאות #
כל סוכן ממופה לחשבון שירות אחד בדיוק. אותו חשבון מחזיק בטוקני client_credentials של OAuth המוגבלים למשטח ה-API המינימלי הנדרש. הטוקן של סוכן הקפאת הכרטיסים יכול לקרוא ל-POST /accounts/{id}/freeze עם amount-at-risk: 0..5000 usd. הוא לא יכול לקרוא ל-GET /accounts/{id}/balance עבור לקוחות אחרים. הוא לא יכול לקרוא לכלום במשמורת, באוצר או במסחר. סודות חשבון השירות מתחלפים שבועית; אישורים ארוכי-טווח הם הכשל הנפוץ ביותר במישור הבקרה בפריסות ייצור.
2. מעקפי בטיחות דטרמיניסטיים על קריאות לכלי #
כל קריאה לכלי של LLM עוברת דרך נתב סמנטי דטרמיניסטי (NeMo Guardrails, LangChain Guardrails או מקבילו) לפני שהקריאה פוגעת ב-API הייצור. הנתב מסווג את הכוונה כנגד רשימת היתר סופית; קריאות מחוץ לרשימה נדחות ונרשמות. לאחר מכן מאמת JSON-schema בודק את המטען — שדות נדרשים נוכחים, סכומי דולר בתוך גבולות, קודי מדינה ISO תקפים, BIC מוטב ברשימת הצדדים הנגדיים שאושרה מראש של הבנק. המאמת אמור להיות פרנואיד: pacs.008 עם amount: 0 הוא כשל מודל, לא עסקה לגיטימית. כך גם העברה למדינה שמסנן הסנקציות שלכם לא אישר מראש עבור פלח הלקוח המקורי.
3. מדיניות כקוד #
Open Policy Agent (או מקבילו) יושב בין המאמת ל-API. מדיניות מנוהלת בגרסאות ב-Git; החלטות דחייה נרשמות; אותו מנוע מדיניות שמסנן קריאות בין-מיקרושירותים בפלטפורמה הקיימת שלכם מסנן קריאות לכלי של סוכנים. התייחסות לסוכנים כמחלקה מיוחדת עם סינון מותאם היא הדרך שבה בנקים מסיימים עם מישורי בקרה צל שאף אחד בצוות הפלטפורמה לא מבין שישה חודשים לאחר מכן.
4. רישום ביקורת #
אחסון WORM בלתי-משתנה — S3 Object Lock, אי-שינוי Azure Blob, או מסד נתונים מוגדר ספר. כל הפעלה לוכדת: חותמת זמן, מזהה סוכן, מזהה חשבון שירות, hash של system-prompt, הקשר שאוחזר, ספק LLM בתוספת מודל בתוספת גרסה, פלט LLM גולמי, קריאה לכלי מנותחת, החלטת OPA, תגובת API, השפעה במורד הזרם, ו-UID מאשר כאשר רלוונטי. הרשומות חתומות קריפטוגרפית בזמן הכתיבה. יומן זה הוא מה שבוחני SR 11-7 ו-SS1/23 יבקשו. אם אינכם יכולים להפיק עקבה מלאה לכל החלטה נתונה, אין לכם סוכן מנוהל-סיכון-מודל.
5. מתג חירום #
API של כפתור אדום שמבטל את כל הפעלות הסוכן בתעבורה בתוך מחלקת הרשאה תוך פחות מ-60 שניות. נבדק רבעונית בתרגיל שולחני. מתג החירום הוא הדבר היחיד שמשחזר אתכם משחרור מודל של ספק שמתדרדר בשקט, מווקטור הזרקת prompt שלא צפיתם, או מאירוע סחיפה הדוחף שיעורי חיוב-שגוי מעבר לסף התפעולי שלכם. מתגי חירום שלא נבדקו לא עובדים; תקצבו את זמן התרגיל.
ניהול סיכוני מודל #
בנקים הטוענים ש-"LLM אינו מודל תחת SR 11-7" כבר הפסידו. הפדרל ריזרב הבהיר שוב ושוב שכל מערכת מקלט-לפלט המשמשת בתהליך עבודה של קבלת החלטות נכללת בתחולה. ה-SS1/23 של ה-PRA רחב עוד יותר. העמדה הנכונה: התייחסו לכל סוכן בייצור כמודל SR 11-7 / SS1/23 מהיום הראשון. עלות המסגור הרטרואקטיבי של סוכן שנפרס כמודל היא כפולות רבות מעלות התכנון שלו כך מלכתחילה.
שלוש שורות הגנה, החלות על סוכנים:
- שורה ראשונה (בעל המודל). מתעד את השימוש המיועד של הסוכן, שושלת נתוני אימון והערכה, סכימת system prompt, רשימת היתר של קריאות לכלי, תוצאות בדיקת מתג החירום. בעלים על ניטור סחיפה בייצור.
- שורה שנייה (צוות MRM). מאמת את הסוכן לפני הייצור. דוח האימות מכסה ציוני הערכה שפורסמו על ידי הספק (MMLU, HumanEval, HellaSwag שימושיים אך לא מספיקים), ציוני הערכה ספציפיים לבנק (סט הערכה משלכם שנשמר בצד, שנבנה מדוגמאות תפעוליות — זו העבודה שבנקים רבים לא משקיעים בה מספיק), תוצאות red-team של הזרקת prompt, ניתוח הטיה והוגנות שבו לתהליך העבודה יש השפעה על לקוחות, והצהרת סיכון שיורי כמותית.
- שורה שלישית (ביקורת פנים). בודקת את שערי מישור הבקרה ושלמות יומן הביקורת כנגד מדגם של החלטות בייצור. מחזור הביקורת של 2027 ייראה שונה מאוד מזה של 2025; תקצבו אותו עכשיו.
ניטור רציף חשוב יותר מאימות בנקודת זמן. סוויטות הערכה ספציפיות לבנק שרצות מחדש שבועית תופסות רגרסיות עדכוני מודל שאמות מידה של ספקים לא יחשפו. קצב השחרור של OpenAI, Anthropic ו-Google מהיר יותר מקצב האימות שלכם; או שהפער נסגר על ידי כך שאתם מריצים הערכות רציפות, או שהוא נסגר על ידי ממצא של בוחן עבורכם.
מדידת השפעה עסקית #
טענות פרודוקטיביות גנריות לא שורדות שיחה עם CFO. מדדו סוכנים כפי שאתם מודדים שינויים תפעוליים אחרים:
- עלות להחלטה מושלמת, כולל עלות ההיפוך והתיקון של החלטות שנכשלו. סוכן ניסוח SAR שחותך 40% מזמן קצין ה-BSA אך מייצר 12% הגשות חיוב-שגוי הרס ערך, לא יצר אותו.
- נגיעות ידניות שנמנעו, נספרות נטו מנגיעות חדשות שנוצרו על ידי פיקוח מישור הבקרה וטיפול בחריגים. הנקודה אינה למזער תשומת לב אנושית; היא להפנות אותה להחלטות בעלות מנוף גבוה יותר.
- שיעור היפוך — אחוז הפעולות שביצע הסוכן שנהפכו תוך 24 שעות. שיעור היפוך מעל 2% בתהליך עבודה ברמה-3 הוא בעיית אמינות. מעל 5% היא בעיית מישור בקרה.
- שלמות עקבת ביקורת — אחוז ההחלטות עם פרובננס מלא הניתן לשחזור מיומן ה-WORM. צריך להיות 100% בתהליכי עבודה ברמה-3 וברמה-4. כל פחות מכך הוא כשל מדיניות שיצוץ בביקורת.
אם תהליך עבודה נעשה מהיר יותר אך פחות בר-הסבר, המדד צריך להעניש אותו. הדרך הזולה ביותר להיכשל בבחינה רגולטורית היא לאופטם תפוקה ולאבד את העקבה.
מה זה אומר לפי סוג בנק #
בנקים בעלי חשיבות מערכתית גלובלית #
הבעיה הקשה היא ממשל בקנה מידה: מאות סוכנים על פני קווי עסק, לכל אחד בעל מודל משלו, כל אחד ממצא ביקורת פוטנציאלי. ההשקעה אינה פיילוט נוסף. זה מישור הבקרה המרכזי, תשתית יומן הביקורת המאוחדת, וספסל MRM המסוגל לאמת 50+ סוכנים ברבעון. ללא קיבולת זו, סוכנים נוחתים מהר יותר ממה שניתן לנהל אותם והמוסד צובר חשיפת SR 11-7 בשקט.
בנקי תשלומים וקורפורייט #
תהליכי העבודה בעלי ה-ROI הגבוה ביותר הם תיקון תשלומים, חילוץ מסמכי KYC, הסחת FAQ של שירותי אוצר ושברי הצלבה. כולם רמה-2 או רמה-3 תחומה. הלקוח הקורפורייט לא מתעניין שסוכן עשה את העבודה; מעניין אותו שה-SLA השתפר ושיעור המחלוקות נשאר שטוח. הובילו עם המדדים, לא עם הטכנולוגיה.
בנקים אזוריים #
קנו, אל תבנו. בחרו ספק שפלטפורמת הסוכנים שלו כבר כוללת את פרימיטיבי מישור הבקרה — היקפי OAuth, אינטגרציית OPA, רישום ביקורת WORM, מתג חירום נבדק — ואמתו את הפלטפורמה הזו כנגד מסגרת ה-MRM שלכם. בניית מישור בקרה מותאם היא השקעה רב-שנתית שאינה מבדלת בקנה מידה אזורי. השקיעו את קיבולת ההנדסה בתכן תהליכי עבודה וב-UX של מפעיל במקום.
פינטקים, PSPs וספקי תשתית #
שאלת המוצר לספקים אינה "האם סוכן ה-AI שלך מבצע טוב יותר מבני אדם." היא "האם הפלטפורמה שלך מייצרת עקבת ביקורת תואמת SR 11-7 מהקופסה." ספקים שיוכלו לענות על כך בכן יסגרו עסקאות ארגוניות. ספקים שלא יוכלו ייתקעו בלולאות הוכחת היתכנות בעוד צוות ה-MRM של הבנק מוצא סיבות להכשיל את האימות.
מסקנה #
סוכני AI אוטונומיים בבנקים ב-2026 הם בעיה הנדסית. העבודה המעניינת היא במישור הבקרה, לא במודל. המודל ניתן להחלפה; היקפי ה-OAuth, הנתב הסמנטי הדטרמיניסטי, שערי מדיניות OPA, יומן הביקורת הבלתי-משתנה ומתג החירום — אינם ניתנים להחלפה.
המוסדות שייראו אמינים לרגולטורים בעוד 18 חודשים הם אלו המתייחסים לכל סוכן בייצור כמודל SR 11-7 / SS1/23 מהיום הראשון, עם סוויטות הערכה ספציפיות לבנק שרצות ברציפות ומישור בקרה המהונדס לכשול בבטחה. המוסדות שלא יעשו זאת יגלו אם ספסל ה-MRM שלהם יכול לגדול לטיפול ב-50+ ממצאי תיקון ברבעון.
מדדו סוכנים כפי שאתם מודדים כל שינוי תפעולי: עלות, אמינות, יכולת היפוך, ראיות. OSWorld ב-66.3% הוא תקרת האמינות שלכם. תכננו בהתאם.
שאלות נפוצות #
מהם סוכני AI אוטונומיים בבנקאות?
תהליך עבודה תחום המשלב LLM עם קריאות לכלי למערכות ייצור, מעקפי בטיחות בזמן ריצה, ונקודות ביקורת של אדם בלולאה. העבודה מתרחשת בתוך תהליך העבודה, לא בתוך המודל. אם שמעתם את המילה "צ'אטבוט", אתם בקטגוריה הלא נכונה.
איפה בנקים צריכים להתחיל?
תהליכי עבודה ברמה 1 ורמה 2 שבהם הערך מדיד ופוטנציאל הנזק תחום: חילוץ סעיפי ISDA, ניסוח SAR, מיון תיקון תשלומים, אחזור ידע פנימי, סיוע בסקירת קוד, סיווג מסמכי KYC. דלגו על רמה 3 עד שמישור הבקרה שלכם מטפל בהיקפי OAuth, ניתוב סמנטי, סינון OPA, רישום WORM ומתג חירום נבדק.
מהו הסיכון הגדול ביותר?
לתת לסוכנים לבצע כנגד ממשקי API של ייצור ללא מעקפי בטיחות דטרמיניסטיים בין פלט ה-LLM ל-API. המספר 66.3% של OSWorld הוא האזהרה. קריאות לכלי לא עטופות בשיעור כשל זה כנגד SWIFT MT103 או API של כספי לקוחות כותבות את הכותרת הגרועה ביותר של מחזור הרגולציה הבא.
האם SR 11-7 חל על סוכנים מבוססי LLM?
כן. הפדרל ריזרב הבהיר שכל מערכת מקלט-לפלט המשמשת בתהליכי עבודה של קבלת החלטות נופלת תחת SR 11-7. ה-SS1/23 של ה-PRA מכסה את אותה קרקע בבריטניה. סיווג הסיכון הגבוה של חוק ה-AI של האיחוד האירופי מכסה את רוב מקרי השימוש בשירותים פיננסיים. הוויכוח על "האם זה מודל" הסתיים; פעלו בהתאם.
איך יש לדווח על סוכני AI אוטונומיים לדירקטוריון?
ארבעה מספרים לכל תהליך עבודה: דרגת אוטונומיה, שלמות עקבת ביקורת, שיעור היפוך, עלות נטו להחלטה. בתוספת רשימת חמשת סיכוני השאריות המובילים. דלגו על שקפי כרטיס המודל.
הפניות #
- Stanford HAI, (2026). דוח מדד ה-AI לשנת 2026 ⧉.
- Stanford HAI, (2026). פרק ביצועים טכניים ⧉.
- Cambridge Centre for Alternative Finance, (2026). דוח גלובלי לשנת 2026: AI בשירותים פיננסיים ⧉.
- Federal Reserve, (2011). SR 11-7: הנחיות לניהול סיכוני מודל ⧉.
- Prudential Regulation Authority, (2023). הצהרה פיקוחית SS1/23: עקרונות ניהול סיכוני מודל לבנקים ⧉.
- European Commission, (2024). תקנה (EU) 2024/1689 — חוק ה-AI ⧉.
- NVIDIA, (2024). מסגרת NeMo Guardrails ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
נסקר לאחרונה .
נסקר לאחרונה .