Агентний 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 року.
Разом із впровадженням змінилися дві речі.
По-перше, регулятори перестали ставитися до LLM як до новинки. ФРС роз'яснила, що SR 11-7 ⧉ поширюється на прийняття рішень на основі LLM незалежно від того, чи внутрішньо класифікується LLM як модель. SS1/23 ⧉ PRA від початку був достатньо широким, щоб охопити їх. Класифікація високого ризику в Законі ЄС про AI охоплює більшість випадків використання LLM у фінансових послугах. Аргументу "ми не впевнені, чи це підпадає" більше немає.
По-друге, реальність бенчмарків наздогнала очікування. Звіт Stanford HAI AI Index 2026 фіксує OSWorld — найближчий доступний бенчмарк до реального корпоративного використання інструментів — на рівні 66,3 % точності (Stanford HAI ⧉). Одне з трьох структурованих завдань і досі провалюється. Це число встановлює технічну стелю автономії у 2026 році. Достатньо високу, щоб виправдати обмежені розгортання Рівня 3 під наглядом HITL; недостатньо високу, щоб виправдати неконтрольоване виконання щодо будь-якого API, який торкається коштів клієнтів.
Індекс агентного AI для банків має зробити для прийняття рішень на основі LLM те, що Базельський фреймворк зробив для капіталу: перетворити заяви "у нас є контролі" на вимірювані, аудитовані докази на кожен робочий процес.
Архітектура індексу 2026 #
| Шар індексу | Як виглядає "готовність" | Метрика готовності | Сценарій збою |
|---|---|---|---|
| Рівень автономії | Кожен продуктивний робочий процес позначений Рівнем 0–4; жодного Рівня 5 у продакшні | % робочих процесів за рівнем; частка на Рівні 3+ | Продуктивний агент відправляє pacs.008 на галюцинований BIC отримувача, оскільки жоден статичний allow-list не перевіряє вантаж до SWIFTNet |
| Виставлення дозволів API | Кожен агент відображається на один сервісний обліковий запис із мінімальними привілеями OAuth-областей (наприклад, card-freeze:write:lt-5000usd); MTLS до застарілого ядра |
% агентів із мінімальними привілеями; кількість зайвих дозволів | Агент повторно використовує надмірно широкий сервісний обліковий запис; ітерує облікові записи, які не мав права читати; інцидент за статтею 33 GDPR подано протягом 72 годин |
| Детерміновані запобіжники | Кожен виклик інструмента маршрутизується через семантичний маршрутизатор (NeMo Guardrails / LangChain Guardrails) плюс валідатор JSON-схеми до API | % перехоплених викликів інструмента; частка відхилення за категорією | LLM видає виклик transfer з amount: 0; нижчий API не валідує; сповіщення про звірку реєстру надходить за 18 годин в іншому часовому поясі |
| Покриття людиною в контурі | Кожне виконання Рівня 3 виводить UI затвердження з жорстким таймаутом; автозатвердження вимкнено політикою | Пропускна здатність затверджень; частка "штамповки" (затверджено менш ніж за 2 секунди) | Оператор клікає "затвердити" по 200 сповіщеннях за 4 хвилини; SAR поданий проти законного клієнта; скарга регулятора протягом тижня |
| Повнота аудиту | Незмінний журнал WORM фіксує системний промпт + отриманий контекст + вихід LLM + виклик інструмента + результат інструмента + UID затверджувача; криптографічно підписано при записі | % викликів із повним трасуванням | Перевіряючий SR 11-7 запитує, чому агент #4421 затвердив переказ 4,8 млн доларів; банк має квитанцію переказу та картку моделі; жодних доказів на рівні промпта; видається зауваження |
| Юніт-економіка | Вартість виконаного рішення відстежується з урахуванням вартості реверсії та виправлення; позитивна порівняно з ручною базою | Чиста вартість рішення; частка реверсії | Витрати на токени для агентів граничних випадків перевищують вартість ручного слідчого, якого вони замінили; CFO закриває програму у 3-му кварталі |
Поточні сигнали для відстеження #
| Сигнал | Що це означає для банків | Джерело |
|---|---|---|
| 52 % активного впровадження | Агентний AI пройшов стадію пілота; інституційне врядування запізнюється | Cambridge CCAF ⧉ |
| 23 % масштабують або трансформують | Помітна меншість вийшла за межі театру proof-of-concept | 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, забезпеченим політикою allow-list; агент не може заморозити картку, прив'язану до балансів вище цього порогу, без ескалації Рівня 2. Обмеження живе у політиці як код, а не в промпті — промпти не є межею безпеки. - Рівень 4 — Оркестрація з кількома інструментами та обов'язковими контрольними точками. Виконує послідовність дій у системах; кожен перехід стану журналюється; контрольні точки вимагають затвердження людиною перед наступним викликом інструмента. Приклад: робочий процес ремонту платежу — витягнути невдалий
pacs.008з черги недоставлених повідомлень → знайти правильного отримувача через SWIFT KYC Registry → згенерувати виправлене повідомлення → записати у вихідну чергу → людина затверджує повторне надсилання. Якщо будь-який крок не проходить валідатор схеми, робочий процес зупиняється та створює кейс винятку. - Рівень 5 — Самоорганізація. Агент планує та виконує без затвердження у контрольній точці. Жоден продуктивний банківський робочий процес не повинен бути на Рівні 5 у 2026 році. Це твердження не про зрілість, а про надійність. OSWorld на рівні 66,3 % складається на ланцюжку викликів API. Три виклики інструмента по 66 % — це 29 % успіху наскрізь. П'ять — 13 %. Не робіть.
Площина контролю агента #
Площина контролю — це інженерний шар між LLM та вашими продуктивними системами. П'ять компонентів, усі — рантайм, жоден з них не написаний у документі політики.
1. Ідентичність та дозволи #
Кожен агент відображається рівно на один сервісний обліковий запис. Цей обліковий запис тримає токени OAuth client_credentials, обмежені до мінімальної необхідної поверхні API. Токен агента заморозки картки може викликати POST /accounts/{id}/freeze з amount-at-risk: 0..5000 usd. Він не може викликати GET /accounts/{id}/balance для інших клієнтів. Він не може викликати нічого у кастоді, казначействі чи трейдингу. Секрети сервісного облікового запису ротуються щотижня; довгоживучі облікові дані — найпоширеніший збій площини контролю у продуктивних розгортаннях.
2. Детерміновані запобіжники на викликах інструмента #
Кожен виклик інструмента LLM проходить через детермінований семантичний маршрутизатор (NeMo Guardrails, LangChain Guardrails або еквівалент) до того, як виклик потрапить до продуктивного API. Маршрутизатор класифікує намір за скінченним allow-list; виклики поза списком відхиляються та журналюються. Потім валідатор JSON-схеми перевіряє вантаж — обов'язкові поля присутні, доларові суми в межах, ISO-коди країн валідні, BIC отримувача у попередньо затвердженому списку контрагентів банку. Валідатор має бути параноїдальним: pacs.008 з amount: 0 — це збій моделі, а не легітимна транзакція. Так само як і переказ до країни, яку ваш фільтр санкцій не схвалив наперед для сегмента клієнта-відправника.
3. Політика як код #
Open Policy Agent (або еквівалент) сидить між валідатором та API. Політики версіонуються в Git; рішення про відхилення журналюються; той самий рушій політики, який пропускає виклики між мікросервісами на вашій існуючій платформі, пропускає виклики інструмента агента. Розглядати агентів як особливий клас із кастомним пропусканням — це шлях, яким банки приходять до тіньових площин контролю, яких через шість місяців ніхто на платформенній команді не розуміє.
4. Журналювання аудиту #
Незмінне сховище WORM — S3 Object Lock, незмінність Azure Blob або journaled-база даних. Кожен виклик фіксує: позначку часу, ID агента, ID сервісного облікового запису, хеш системного промпта, отриманий контекст, провайдера LLM плюс модель плюс версію, сирий вихід LLM, розпарсений виклик інструмента, рішення OPA, відповідь API, низхідний ефект і UID затверджувача, де застосовно. Записи криптографічно підписуються при записі. Саме цей журнал запитуватимуть перевіряючі SR 11-7 та SS1/23. Якщо ви не можете відтворити повне трасування для будь-якого рішення, у вас немає агента, керованого з точки зору модельного ризику.
5. Аварійний вимикач #
API "червоної кнопки", що скасовує всі активні виклики агентів у межах класу дозволів менш ніж за 60 секунд. Тестується щоквартально на штабних навчаннях. Аварійний вимикач — це єдине, що рятує вас від релізу вендорської моделі, який тихо погіршується, від вектора promt-injection, якого ви не передбачили, або від події дрейфу, яка штовхає частоту хибнопозитивних результатів вище вашого операційного порогу. Неперевірені аварійні вимикачі не працюють; заплануйте час на навчання.
Управління модельними ризиками #
Банки, які стверджують "LLM не є моделлю за SR 11-7", вже програли. ФРС неодноразово роз'яснювала, що будь-яка система "вхід-вихід", що використовується у робочому процесі прийняття рішень, потрапляє у сферу застосування. SS1/23 PRA ще ширша. Правильна позиція: ставтеся до кожного продуктивного агента як до моделі SR 11-7 / SS1/23 з першого дня. Вартість ретроактивного оформлення розгорнутого агента як моделі кратно перевищує вартість його проєктування як такої з самого початку.
Три лінії захисту, застосовані до агентів:
- Перша лінія (власник моделі). Документує цільове використання агента, походження даних навчання та оцінювання, схему системного промпта, allow-list викликів інструмента, результати тестування аварійного вимикача. Відповідає за моніторинг дрейфу в продакшні.
- Друга лінія (команда MRM). Валідує агента перед продакшном. Звіт валідації охоплює бали оцінювання, опубліковані вендором (MMLU, HumanEval, HellaSwag корисні, але недостатні), бали оцінювання, специфічні для банку (ваш власний відкладений набір оцінювання, побудований з операційних прикладів — це робота, у яку більшість банків недоінвестує), результати red-team з prompt-injection, аналіз упередженості та справедливості, де робочий процес впливає на клієнта, і кількісно виражене твердження про залишковий ризик.
- Третя лінія (внутрішній аудит). Тестує шлюзи площини контролю та повноту журналу аудиту на вибірці продуктивних рішень. Цикл аудиту 2027 виглядатиме зовсім інакше, ніж цикл 2025; закладайте бюджет уже зараз.
Безперервний моніторинг важить більше за валідацію в окремий момент часу. Специфічні для банку набори оцінювання, що перезапускаються щотижня, ловлять регресії оновлень моделей, які не вийдуть на поверхню в бенчмарках вендора. Темп релізів OpenAI, Anthropic та Google швидший за ваш темп валідації; або розрив закривається тим, що ви запускаєте безперервні оцінювання, або він закривається зауваженням перевіряючого.
Вимірювання бізнес-впливу #
Загальні заяви про продуктивність не витримують розмови з CFO. Вимірюйте агентів так само, як ви вимірюєте інші операційні зміни:
- Вартість виконаного рішення, включно з вартістю реверсії та виправлення невдалих рішень. Агент підготовки SAR, який скорочує час офіцера BSA на 40 %, але генерує 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 для оператора.
Фінтехи, PSP та провайдери інфраструктури #
Продуктове питання для вендорів не "чи ваш AI-агент працює краще за людей". Воно — "чи виробляє ваша платформа SR 11-7-сумісне трасування аудиту з коробки". Вендори, які можуть відповісти "так", закриватимуть корпоративні угоди. Вендори, які не можуть, застрягнуть у циклах proof-of-concept, поки команда 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. Число OSWorld 66,3 % — це попередження. Незахищені виклики інструмента за такої частоти відмов щодо SWIFT MT103 або API клієнтських коштів напишуть заголовок найгіршого сценарію наступного регуляторного циклу.
Чи поширюється SR 11-7 на агентів на основі LLM?
Так. ФРС роз'яснила, що будь-яка система "вхід-вихід", що використовується у робочих процесах прийняття рішень, підпадає під SR 11-7. SS1/23 PRA охоплює ту саму площину у Великій Британії. Класифікація високого ризику Закону ЄС про AI охоплює більшість випадків використання у фінансових послугах. Дискусія "чи це модель" завершена; дійте відповідно.
Як звітувати про агентний AI правлінню?
Чотири числа на робочий процес: рівень автономії, повнота трасування аудиту, частка реверсії, чиста вартість рішення. Плюс топ-5 залишкових ризиків. Пропустіть слайди карток моделей.
Джерела #
- Stanford HAI, (2026). Звіт 2026 AI Index ⧉.
- Stanford HAI, (2026). Розділ Technical Performance ⧉.
- Cambridge Centre for Alternative Finance, (2026). Глобальний звіт 2026 AI у фінансових послугах ⧉.
- Federal Reserve, (2011). SR 11-7: керівництво з управління модельними ризиками ⧉.
- Prudential Regulation Authority, (2023). Наглядова заява SS1/23: принципи управління модельними ризиками для банків ⧉.
- European Commission, (2024). Регламент (ЄС) 2024/1689 — Закон про AI ⧉.
- NVIDIA, (2024). Фреймворк NeMo Guardrails ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
Востаннє переглянуто .
Останній перегляд .