TL;DR. Агентичний ШІ перейшов від пілотування до виробництва в глобальному банківському секторі. Сімдесят відсотків фінансових установ певною мірою використовують його; лише кожна п'ята має зрілу модель управління. Тим часом автономні супротивники діють на швидкості машин, застаріле середовище COBOL, з яким мають взаємодіяти нові системи, було створено з урахуванням пакетної обробки 1960-х років, а до крайнього терміну впровадження високого ризику EU AI Act у серпні 2026 року залишилося дванадцять тижнів. Це інженерна позиція та позиція управління, якої повинен дотримуватися банк.

Ключові висновки

Рік, коли агентична інженерія стала неминучою. Дискусії навколо ШІ у фінансових послугах донедавна зосереджувалися на двох суміжних, але відмінних речах: генеративних інтерфейсах чатів (корисних, але обмежених) та шаблонах генерації з доповненням пошуку (RAG),…
Стан впровадження у банківській сфері. Загальна картина є однозначною.
Три вектори ризику, які банки повинні усвідомити. Перед будь-якою архітектурною розмовою увага ради директорів має зосередитися на трьох ризиках, які є специфічними для агентичних систем і які виникають раніше, ніж планувала більшість банків.
Чому Vibe Coding не може бути стандартом у банківській сфері. Варто чітко пояснити, чому vibe coding — короткий промпт, перевірка результату, ітерація — не працює як стандарт BEGIN_TRANSLATION --- author: "contact@sebastienrousseau.com (Sebastien Rousseau)" banner_alt:…

Агентичний ШІ перейшов від пілотування до виробництва в глобальному банківському секторі. Сімдесят відсотків фінансових установ певною мірою використовують його; лише кожна п'ята має зрілу модель управління. Тим часом автономні супротивники діють на швидкості машин, застаріле середовище COBOL, з яким мають взаємодіяти нові системи, було створено з урахуванням пакетної обробки 1960-х років, а до крайнього терміну впровадження вимог щодо високого ризику EU AI Act залишилося дванадцять тижнів. Це інженерна позиція та позиція управління, якої повинен дотримуватися банк.

Основні висновки

Перехід від vibe coding до spec-driven розробки більше не є просто прагненням. Андрій Карпати, який увів термін «vibe coding» у лютому 2025 року, визнав рік по тому ⧉, що ця ера добігає кінця і новим стандартом для професіоналів стає агентична інженерія — оркестрація агентів відповідно до детальних специфікацій під наглядом людини.

Впровадження в банківській сфері є реальним і прискорюється. 70% банківських установ ⧉ повідомляють про використання агентичного ШІ певною мірою (16% у виробництві, 52% у пілотному режимі, EY 2026); 44% фінансових команд використовуватимуть його цього року — зростання на понад 600% порівняно з минулим роком за даними Wolters Kluwer.

Управління не встигає за темпами. Дослідження Deloitte «State of AI 2026» показує, що лише одна з п'яти компаній має зрілу модель управління автономними агентами ШІ. Аналіз Бази даних ризиків ШІ MIT від Deloitte виявив понад 350 ризиків ⧉, які можуть виникати внаслідок автономної або агентичної поведінки.

Ландшафт загроз індустріалізувався. У листопаді 2025 року компанія Anthropic повідомила, що підтримувана державою китайська група GTG-1002 зламала Claude Code для проведення автономного шпигунства проти приблизно 30 цілей, причому ШІ виконував 80–90% тактичних операцій самостійно. Flashpoint зафіксувала 1500% зростання незаконних обговорень, пов'язаних із ШІ ⧉, лише між листопадом і груднем 2025 року.

Застарілі системи є прихованим обмеженням. ІТ-бюджети фінансових послуг на 70–75% витрачаються на обслуговування застарілих систем, 63% банків досі покладаються на код, написаний до 2000 року, а більшість банків повідомляють про наявність лише одного або двох фахівців у штаті, які можуть підтримувати COBOL, на якому працюють їхні основні платформи. Агентичний ШІ зараз є домінуючим підходом для подолання цього розриву.

Стек регуляторних вимог об'єднується. Відповідно до EU AI Act, 2 серпня 2026 року починає діяти повна юридична сила для високоризикових систем ШІ (Додаток III чітко включає кредитний скоринг та оцінку платоспроможності). DORA вже діє. SR 11-7 було розширено в регуляторній практиці на великі мовні моделі (LLM) та агентичні системи. Штрафи за порушення досягають 35 мільйонів євро або 7% світового річного обороту.

Контроль з боку людини не є єдиним поняттям. Розрізнення між HITL (Human-in-the-Loop, де агент не може виконати дію без явного схвалення людиною) та HOTL (Human-on-the-Loop, де агент діє автономно під наглядом людини) тепер є робочою основою для відповідності статті 14 EU AI Act, і для кожного агента високого ризику має бути чітко визначено, яка модель застосовується.

Більшість агентів буде куплено, а не створено власноруч. Управління ризиками третіх сторін (TPRM) відповідно до DORA є найгучнішим недооціненим викликом 2026 року. Постачальники надаватимуть більшу частину агентичних можливостей, які впроваджують банки; при цьому регуляторні зобов'язання залишаються за банком, а більшість наявних контрактів із постачальниками не можуть задовольнити вимоги до документації статті 13.

Агентична інженерія — це не «ChatGPT плюс сервери MCP». Це позиція структурного володіння наскрізними процесами установи — шляхом клієнта, життєвим циклом транзакцій, площиною управління, субстратом аудиту, квантово-безпечною криптографічною основою — створена та керована власним інженерним підрозділом установи, а не делегована чат-боту.

Рік, коли агентична інженерія стала неминучою

Дискусії навколо ШІ у фінансових послугах донедавна зосереджувалися на двох суміжних, але відмінних речах: генеративних інтерфейсах чатів (корисних, але обмежених) та шаблонах генерації з доповненням пошуку (RAG), накладених на корпоративні дані (теж корисних, але обмежених). Що змінилося між кінцем 2025 та початком 2026 років, так це те, що третя категорія — автономні агенти, які планують, виконують та завершують багатоетапні робочі процеси з обмеженим контролем людини, — перейшла від технічної демонстрації до оперативної реальності, проникнувши одночасно як у підприємства, так і в середовище зловмисників.

Андрій Карпати, який увів термін «vibe coding» у лютому 2025 року ⧉, протягом наступного року спостерігав, як професійні інженери переросли цей підхід. Його нове формулювання — «агентична інженерія» — тепер є загальноприйнятим терміном в індустрії. Суть змін очевидна: у серйозній розробці програмного забезпечення у 2026 році інженери в 99% випадків не пишуть код безпосередньо. Вони оркеструють агентів, які роблять це, здійснюючи при цьому нагляд. Робота більше не полягає у введенні символів у редакторі; це створення специфікацій, що обмежують можливості генерації для агентів, проектування шлюзів перевірки, які має пройти результат, та керування архітектурними рішеннями, які реалізують агенти.

Цей зсув звучить як тема для розмови всередині інженерної команди. Але в банківській справі це не так. Це розмова на рівні ради директорів, оскільки ті самі агентичні можливості, які переписують правила створення внутрішнього коду, також змінюють методи роботи зовнішніх зловмисників, очікування регуляторів щодо контролю та визначення інституційного периметру. Банк, який не визначить власну позицію щодо агентичної інженерії до кінця 2026 року, не просто уникне цього питання. Це банк, за який відповідь на це питання вже дали його постачальники, супротивники та регулятори.

Стан впровадження у банківській сфері

Загальна картина є однозначною. Згідно з дослідженнями, зібраними за результатами кількох опитувань 2026 року, 70% банківських керівників ⧉ повідомляють, що їхні фірми вже певною мірою використовують агентичний ШІ. Gartner прогнозує ⧉, що до кінця 2026 року приблизно 40% усіх фірм у сфері фінансових послуг запускатимуть агентів ШІ в тій чи іншій формі. Витрати на ШІ у сфері фінансових послуг наближаються до 67 мільярдів доларів до 2028 року (IDC). За оцінками McKinsey, агентичний ШІ може вивільняти від 10 до 12 годин на тиждень для менеджерів по роботі з клієнтами в банках.

Картина впровадження менш обнадійлива. KPMG повідомляє ⧉, що 99% компаній планують запустити автономних агентів у виробництво, але лише 11% зробили це. EY зазначає, що 34% лідерів почали використовувати агентів ШІ, і лише 14% впровадили їх повністю. Forrester виявляє, що 57% організацій вважають, що їм бракує внутрішніх можливостей, аби скористатися перевагами агентичного ШІ. Розрив між намірами та виконанням не є маркетинговою вигадкою. Це реальне відображення інженерної, управлінської та культурної роботи, яка ще не була виконана.

Управління з фінансового нагляду Великобританії (FCA) публічно висловило занепокоєння ⧉ тим, що швидкість розгортання випереджає зрілість управління — цю напругу директор з даних FCA Джессіка Расу охарактеризувала як короткостроковий ризик для роздрібних споживачів. McKinsey окремо попередила, що банки, які не зможуть адаптувати свої бізнес-моделі ⧉ ризикують втратити до 170 мільярдів доларів глобального прибутку до 2030 року. Обидва спостереження є правильними одночасно. Питання полягає не в тому, чи варто рухатися, а в тому, як рухатися із забезпеченням операційної та управлінської цілісності, якої завжди вимагало регулювання фінансових послуг і яку агентичні системи роблять критично важливою.

Три вектори ризику, які банки повинні усвідомити

Перед будь-якою архітектурною розмовою увага ради директорів має зосередитися на трьох ризиках, які є специфічними для агентичних систем і які виникають раніше, ніж планувала більшість банків.

1. Автономний супротивник

Найбільш дезорієнтуючим фактором у 2026 році є застосування агентичного ШІ для здійснення атак. У серпні 2025 року компанія Anthropic виявила категорію активності, яку вона назвала vibe hacking ⧉: використання кіберзлочинцями агентичного ШІ для проведення складних масштабних атак із інтеграцією ШІ в процеси розвідки, збору облікових даних, проникнення в мережу та аналізу викрадених даних. У листопаді 2025 року ⧉ Anthropic повідомила, що заблокувала кампанію підтримуваної китайським урядом групи (під кодовою назвою GTG-1002), яка зламувала екземпляри Claude Code для ведення автономного шпигунства проти близько тридцяти цілей в оборонному, енергетичному та технологічному секторах. ШІ самостійно виконував 80–90% тактичних операцій на швидкості тисяч запитів за секунду — темп, недоступний для операторів-людей.

У січні 2026 року Step Finance — менеджер портфелів DeFi на базі Solana — зазнав зламу, який перетворив проникнення на пристрій у збитки на суму 27–30 мільйонів доларів через те, що торгові агенти ШІ фірми мали дозволи на виконання великих переказів без схвалення людини. Зловмисник застосував соціальну інженерію до самого ШІ, заявивши, що проводить авторизовану програму з пошуку багів (bug bounty). Урок ⧉ полягав не в тому, що ШІ за своєю суттю є небезпечним, а в тому, що агент ШІ, який приймає заявлену авторизацію без перевірки, є слабкістю периметра.

Саме цей загальний тренд банки мають усвідомити. Звіт про глобальні загрози 2026 від Flashpoint зафіксував 1500% зростання незаконних обговорень, пов'язаних із ШІ ⧉ між листопадом і груднем 2025 року, причому зловмисники активно розробляють автономні системи, які збирають дані, змінюють інфраструктуру, коригують повідомлення та вчаться на невдалих спробах без постійного контролю з боку людини. Керівник JPMorgan Джеймі Даймон публічно заявив ⧉ , що початкова перевага в цій технології належить нападу, а не захисту. Висновок є невтішним: банк, що використовує класичні методи безпеки проти агентичних супротивників, структурно перебуває у становищі шахіста, супернику якого дали комп'ютер.

2. Регресія якості коду

Другий вектор є внутрішнім і менш помітним. Код, згенерований LLM, за відсутності дисципліни специфікацій та суворої перевірки, випускається з дефектами набагато частіше, ніж код, написаний людиною. Аналіз SonarQube для п'яти провідних LLM ⧉, що генерували код на Java, показав, що понад 70% виявлених уразливостей у результатах Llama 3.2 90B мали рівень критичності BLOCKER, а близько двох третин уразливостей у GPT-4o та OpenCoder-8B мали статус BLOCKER або CRITICAL. Дослідження Пірса та ін. (IEEE S&P) виявило, що приблизно 40% програм, згенерованих LLM у контексті безпеки, містили уразливості. Ян та ін. (2025) визначили цей показник у діапазоні 9,8–42,1% для своїх тестів. Окремий каталог від Фу та ін. зафіксував 43 CWE у трьох інструментах генерації коду на основі ШІ.

Для нерегульованої галузі це податок на продуктивність. Для банку це регуляторний та операційний ризик, який накопичується. Код із високим рівнем уразливостей, який потрапляє в систему обробки платежів, розрахунків або клієнтських даних, — це не просто абстрактна проблема якості коду; це поверхня, яку супротивники класу GTG-1002 досліджуватимуть у 2027 році за допомогою тих самих агентичних інструментів, які його створили. Захист полягає не в забороні коду, згенерованого LLM (що комерційно неможливо), а в створенні навколо нього інфраструктури перевірки та специфікацій, яка забезпечує виявлення дефектів перед розгортанням. Це практична причина, чому spec-driven розробка так швидко впроваджується великими інженерними організаціями, які не є суто технологічними фірмами.

3. Застарілий якір (Legacy)

Третій вектор — це те, що банки вже розуміють найкраще, і що перехід до агентичних технологій зробив водночас більш нагальним і більш доступним для вирішення. Понад 70% компаній з Fortune 500 все ще покладаються на мейнфрейми, зазначає аналіз Computer Weekly ⧉, які часто базуються на десятиліттях переплетеного коду COBOL та RPG із кастомною бізнес-логікою. Зокрема, у сфері фінансових послуг застарілі технології поглинають 70–75% щорічних ІТ-витрат ⧉. Дослідження CIO, яке цитується в галузевому аналізі 2026 року, виявило, що 63% банків досі покладаються на код, написаний до 2000 року, і понад 75% повідомили, що мають лише одного або двох спеціалістів у компанії з навичками для його підтримки.

Що змінилося у лютому 2026 року, так це поява надійних агентичних інструментів для модернізації застарілих систем. Заява Anthropic про те, що Claude Code може відображати залежності COBOL, документувати робочі процеси та виявляти ризики ⧉ (на виявлення яких аналітикам-людям знадобилися б місяці) у поєднанні з аналогічними можливостями від Microsoft (GitHub Copilot для COBOL, Watsonx Code Assistant) та AWS (Mainframe Modernization з агентичним ШІ) суттєво скоротила криву витрат на модернізацію. Реакція ціни акцій IBM (падіння на 13% у день оголошення) стала неелегантним, але точним сигналом ринку. Зараз на ШІ припадає приблизно третина інвестицій у корпоративну модернізацію, і понад 75% підприємств використовують ШІ у своїй стратегії модернізації. Застарілий якір уперше став вирішуваною інженерною проблемою, а не викликом для зміни поколінь.

Чому Vibe Coding не може бути стандартом у банківській сфері

Варто чітко пояснити, чому vibe coding — короткий промпт, перевірка результату, ітерація — не працює як стандарт BEGIN_TRANSLATION

author: "contact@sebastienrousseau.com (Sebastien Rousseau)" banner_alt: "Діаграма архітектури агентичної інженерії для банків — spec-driven агенти ШІ, площина управління, квантово-безпечний субстрат та потоки модернізації застарілого mainframe" banner_height: "571" banner_width: "1425" banner: "https://cloudcdn.pro/stocks/images/hector-j-rivas-1FxMET2U5dU-unsplash.webp" cdn: "https://cloudcdn.pro" charset: "UTF-8" cname: "sebastienrousseau.com" copyright: "© Copyright 2007 - 2026 - Sebastien Rousseau. Усі права захищено." date: "17 May 2026" description: "Агентичний ШІ перейшов від пілотування до виробництва в глобальному банківському секторі. Сімдесят відсотків фінансових установ певною мірою використовують його; лише кожна п'ята має зрілу модель управління. Тим часом автономні супротивники діють на швидкості машин, застаріле середовище COBOL, з яким мають взаємодіяти нові системи, було створено з урахуванням пакетної обробки 1960-х років, а до крайнього терміну впровадження високого ризику EU AI Act у серпні 2026 року залишилося дванадцять тижнів. Це інженерна позиція та позиція управління, якої повинен дотримуватися банк." format-detection: "telephone=no" hreflang: "uk" icon: "https://cloudcdn.pro/clients/sebastienrousseau/v1/logos/sebastienrousseau.svg" id: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026" image_alt: "Чорно-білий портрет Себастьяна Руссо" image_height: "162" image_width: "162" image: "https://cloudcdn.pro/stocks/images/sebastienrousseau.webp" keywords: "агентична інженерія, spec-driven розробка, банки, фінансові послуги, управління ШІ, EU AI Act, DORA, SR 11-7, NIST AI RMF, ISO 42001, модернізація COBOL, mainframe, vibe coding, vibe hacking, автономні агенти, Claude Code, GitHub Spec Kit, AI Bill of Materials, AIBOM, human in the loop, HITL, human on the loop, HOTL, управління ризиками третіх сторін, TPRM, ризик постачальників, постквантова криптографія, площина управління агентами, FCA, SM&CR, план дій на 12 тижнів, Sebastien Rousseau" language: "uk-UA" layout: "report" locale: "uk_UA" logo_alt: "Логотип Себастьяна Руссо" logo_height: "44" logo_width: "44" logo: "https://cloudcdn.pro/clients/sebastienrousseau/v1/logos/sebastienrousseau.svg" menu: "" measurementID: "G-169G4ET5HQ" name: "Sebastien Rousseau" permalink: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026" rating: "general" referrer: "no-referrer" robots: "index, follow" schema: "FAQPage, Article" seo_title: "Агентична інженерія для банків: План управління ШІ на 2026 рік" short_name: "sebastienrousseau" subtitle: "Агентичний ШІ перейшов від пілоту до виробництва. 70% банків використовують його; лише один із п'яти має зрілу модель управління. Противники діють зі швидкістю машин, спадщина COBOL залишається з епохи пакетної обробки 1960-х, а дедлайн EU AI Act — за 12 тижнів." tags: "агентичний ШІ, spec-driven розробка, банки, управління ШІ, EU AI Act, DORA, модернізація COBOL, HITL, HOTL, TPRM, AIBOM, Claude Code, постквантова криптографія, ISO 20022, квантові обчислення, ШІ, Rust, відкритий код, системна інженерія" theme-color: "0, 67, 165" title: "Агентична інженерія для банків: План на 2026 рік для керівництва та інженерів, які його втілюватимуть" url: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026" viewport: "width=device-width, initial-scale=1, shrink-to-fit=no" last_reviewed: "2026-05-17"

RSS - The RSS feed front matter (YAML).

atom_link: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026/rss.xml" category: "Finance" docs: https://validator.w3.org/feed/docs/rss2.html generator: "Static Site Generator (SSG) (version 0.0.26)" item_description: "Визначальний план на 2026 рік для агентичної інженерії в банках та фінансових установах — від vibe coding до spec-driven розробки, порівняння HITL та HOTL, управління ризиками третіх сторін відповідно до DORA, нормативний стек, модернізація застарілих систем та квантово-безпечний субстрат." item_guid: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026/rss.xml" item_link: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026/rss.xml" item_pub_date: "Sun, 17 May 2026 06:06:06 +0000" item_title: "Агентична інженерія для банків: План на 2026 рік для керівництва та інженерів, які його втілюватимуть" last_build_date: "Sun, 17 May 2026 06:06:06 +0000" managing_editor: "contact@sebastienrousseau.com (Sebastien Rousseau)" pub_date: "Sun, 17 May 2026 06:06:06 +0000" ttl: "60" type: "article" webmaster: "contact@sebastienrousseau.com"

Apple - The Apple front matter (YAML).

apple_mobile_web_app_orientations: "portrait" apple_touch_icon_sizes: "192x192" apple-mobile-web-app-capable: "yes" apple-mobile-web-app-status-bar-inset: "black" apple-mobile-web-app-status-bar-style: "black-translucent" apple-mobile-web-app-title: "Агентична інженерія для банків" apple-touch-fullscreen: "yes"

MS Application - The MS Application front matter (YAML).

msapplication-navbutton-color: "0, 83, 191"

Twitter Card - The Twitter Card front matter (YAML).

twitter_card: "summary_large_image" twitter_creator: "@wwdseb" twitter_description: "Визначальний план на 2026 рік для агентичної інженерії в банках та фінансових установах — spec-driven розробка, порівняння HITL та HOTL, TPRM відповідно до DORA, нормативний стек, модернізація застарілих систем та квантово-безпечний субстрат." twitter_image: "https://cloudcdn.pro/clients/sebastienrousseau/v1/logos/sebastienrousseau.svg" twitter_image_alt: "Логотип Себастьяна Руссо" twitter_site: "@wwdseb" twitter_title: "Агентична інженерія для банків: План управління ШІ на 2026 рік" twitter_url: "https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026"

Humans.txt - The Humans.txt front matter (YAML).

author_website: "https://sebastienrousseau.com" author_twitter: "@wwdseb" author_location: "London, UK" thanks: "Дякую за читання!" site_last_updated: "2026-05-17" site_standards: "HTML5, CSS3, RSS, Atom, JSON, XML, YAML, Markdown, TOML" site_components: "Kaishi, Kaishi Builder, Kaishi CLI, Kaishi Templates, Kaishi Themes" site_software: "Static Site Generator, Rust"

excerpt: "Агентичний ШІ перейшов від пілотування до виробництва в глобальному банківському секторі. Сімдесят відсотків фінансових установ певною мірою використовують його; лише кожна п'ята має зрілу модель управління. Тим часом..."

Агентична інженерія для банків: План на 2026 рік для керівництва та інженерів, які його втілюватимуть

Основні висновки

Перехід від vibe coding до spec-driven розробки більше не є просто прагненням. Андрій Карпати, який увів термін «vibe coding» у лютому 2025 року, визнав рік по тому ⧉, що ця ера добігає кінця і новим стандартом для професіоналів стає агентична інженерія — оркестрація агентів відповідно до детальних специфікацій під наглядом людини.

Впровадження в банківській сфері є реальним і прискорюється. 70% банківських установ ⧉ повідомляють про використання агентичного ШІ певною мірою (16% у виробництві, 52% у пілотному режимі, EY 2026); 44% фінансових команд використовуватимуть його цього року — зростання на понад 600% порівняно з минулим роком за даними Wolters Kluwer.

Управління не встигає за темпами. Дослідження Deloitte «State of AI 2026» показує, що лише одна з п'яти компаній має зрілу модель управління автономними агентами ШІ. Аналіз Бази даних ризиків ШІ MIT від Deloitte виявив понад 350 ризиків ⧉, які можуть виникати внаслідок автономної або агентичної поведінки.

Ландшафт загроз індустріалізувався. У листопаді 2025 року компанія Anthropic повідомила, що підтримувана державою китайська група GTG-1002 зламала Claude Code для проведення автономного шпигунства проти приблизно 30 цілей, причому ШІ виконував 80–90% тактичних операцій самостійно. Flashpoint зафіксувала 1500% зростання незаконних обговорень, пов'язаних із ШІ ⧉, лише між листопадом і груднем 2025 року.

Застарілі системи є прихованим обмеженням. ІТ-бюджети фінансових послуг на 70–75% витрачаються на обслуговування застарілих систем, 63% банків досі покладаються на код, написаний до 2000 року, а більшість банків повідомляють про наявність лише одного або двох фахівців у штаті, які можуть підтримувати COBOL, на якому працюють їхні основні платформи. Агентичний ШІ зараз є домінуючим підходом для подолання цього розриву.

Стек регуляторних вимог об'єднується. Відповідно до EU AI Act, 2 серпня 2026 року починає діяти повна юридична сила для високоризикових систем ШІ (Додаток III чітко включає кредитний скоринг та оцінку платоспроможності). DORA вже діє. SR 11-7 було розширено в регуляторній практиці на великі мовні моделі (LLM) та агентичні системи. Штрафи за порушення досягають 35 мільйонів євро або 7% світового річного обороту.

Контроль з боку людини не є єдиним поняттям. Розрізнення між HITL (Human-in-the-Loop, де агент не може виконати дію без явного схвалення людиною) та HOTL (Human-on-the-Loop, де агент діє автономно під наглядом людини) тепер є робочою основою для відповідності статті 14 EU AI Act, і для кожного агента високого ризику має бути чітко визначено, яка модель застосовується.

Більшість агентів буде куплено, а не створено власноруч. Управління ризиками третіх сторін (TPRM) відповідно до DORA є найгучнішим недооціненим викликом 2026 року. Постачальники надаватимуть більшу частину агентичних можливостей, які впроваджують банки; при цьому регуляторні зобов'язання залишаються за банком, а більшість наявних контрактів із постачальниками не можуть задовольнити вимоги до документації статті 13.

Агентична інженерія — це не «ChatGPT плюс сервери MCP». Це позиція структурного володіння наскрізними процесами установи — шляхом клієнта, життєвим циклом транзакцій, площиною управління, субстратом аудиту, квантово-безпечною криптографічною основою — створена та керована власним інженерним підрозділом установи, а не делегована чат-боту.

Рік, коли агентична інженерія стала неминучою

Стан впровадження у банківській сфері

Три вектори ризику, які банки повинні усвідомити

1. Автономний супротивник

2. Регресія якості коду

3. Застарілий якір (Legacy)

Третій вектор — це те, що банки вже розуміють найкраще, і що перехід до агентичних технологій зробив водночас більше нагальним і більше доступним для вирішення. Понад 70% компаній з Fortune 500 все ще покладаються на мейнфрейми, зазначає аналіз Computer Weekly ⧉, які часто базуються на десятиліттях переплетеного коду COBOL та RPG із кастомною бізнес-логікою. Зокрема, у сфері фінансових послуг застарілі технології поглинають 70–75% щорічних ІТ-витрат ⧉. Дослідження CIO, яке цитується в галузевому аналізі 2026 року, виявило, що 63% банків досі покладаються на код, написаний до 2000 року, і понад 75% повідомили, що мають лише одного або двох спеціалістів у компанії з навичками для його підтримки.

Чому Vibe Coding не може бути стандартом у банківській сфері

Варто чітко пояснити, чому vibe coding — короткий промпт, перевірка результату, ітерація — не працює як стандартний робочий процес у регульованому середовищі. Збій відбувається не через очевидну річ (коли LLM час від часу галюцинує). Режим відмови є структурним і виявляється одночасно в чотирьох аспектах.

Перший — це відсутність єдиних стандартів. Кілька інженерів, які працюють через чат-промпти, створять п'ять різних способів зробити одне й те саме в одній кодовій базі протягом одного кварталу. У нерегульованому середовищі це просто технічний борг. У регульованому — це поверхня, яка руйнується під час аудиту.

Другий — це деградація контексту. Агенти ШІ не зберігають стан (вони є stateless). У великому проекті розмови перевищують вікна контексту, і логіка попередніх архітектурних рішень втрачається. Той самий агент через два тижні прийме протилежне рішення в новому чаті, тому що ніде не зберігається обґрунтування першого. Для систем, які потребують аудиторського сліду для регуляторів, це структурно несумісно.

Третій — це невидиме накопичення дефектів. Результати досліджень Пірса, Яна та SonarQube, про які йшлося вище, не є поодинокими випадками. Це базовий показник, з яким LLM генерують вразливий код за відсутності дисципліни специфікацій та ретельного тестування. Банк, який використовує процеси vibe-coding у промисловому середовищі, накопичує ці дефекти з тією ж швидкістю, не маючи візуального контролю над тим, що саме було випущено.

Четвертий — це проблема відповідності регуляторним вимогам щодо простежуваності. Стаття 12 EU AI Act вимагає автоматичного логування вхідних і вихідних даних для високоризикових систем ШІ. SR 11-7 вимагає документування ролей власника та валідатора моделі, управління змінами для оновлень моделей та звітності раді директорів про ризики моделей ШІ. DORA вимагає комплексного управління ризиками ІКТ із задокументованими доказами. Жодне з цих зобов'язань не може бути виконане за допомогою процесу, де основним артефактом є історія чату, яку ніхто не зберігає.

Висновок не в тому, що LLM непридатні для банківської сфери. Висновок у тому, що робочий процес навколо них повинен створювати специфікації, аудиторські сліди та шлюзи перевірки як першокласні результати розробки, а не як щось другорядне. Саме цим і є spec-driven розробка з операційної точки зору.

Spec-Driven розробка в регульованому середовищі

Spec-driven розробка (SDD) перевертає порядок роботи. Замість того, щоб переходити безпосередньо до втілення та ітерувати разом із агентом, команда спочатку створює специфікацію — архітектурні рішення, вимоги, інтерфейсні контракти, критерії успіху, обмеження безпеки, — а агент генерує код, який відповідає цій специфікації. Перевірка є структурованою: специфікація визначає, що має робити результат, а окремий процес (генерація тестів, перевірка коду, формальна верифікація, де це можливо) контролює виконання.

Практичний інструментарій консолідувався наприкінці 2025 та на початку 2026 років. Spec Kit від GitHub ⧉ (випущений наприкінці 2025 року) формалізує наміри перед генерацією коду. AWS вбудовує процеси spec-first безпосередньо у свою Kiro IDE. JetBrains та Cursor впровадили режими планування, які структурують взаємодію з ШІ. Такі фреймворки, як BMAD (Breakthrough Method for Agile AI-Driven Development), йдуть далі зі спеціалізованими командами агентів ШІ, які виконують ролі аналітика, архітектора, розробника та фахівця з тестування протягом життєвого циклу розробки ПЗ (SDLC). Конституційна SDD (Constitutional SDD), формалізована в статті на arXiv у лютому 2026 року, вбудовує чіткі обмеження безпеки з відображенням уразливостей CWE безпосередньо у саму специфікацію.

Для банку важливим варіантом є те, що аналіз Augment Code називає розробкою на основі специфікацій (spec-anchored development), — специфікації створюються першими, ШІ генерує код з урахуванням їхніх обмежень, а додаткові рівні управління (конституційні обмеження, контрольні точки нагляду, шлюзи схвалення людиною) розташовані між генерацією та злиттям коду. Це єдиний варіант, який створює журнал аудиту (аудиторський слід), якого очікує стаття 12 EU AI Act, задокументовану роль валідатора, яку вимагає SR 11-7, та дисципліну управління змінами, якої вимагає DORA.

Необхідні інвестиції є реальними, але вони є цілком посильними. Установи, які успішно реалізують це, перевели щоденну роботу інженерів від написання символів до створення двох артефактів: специфікації, яку має виконати агент, та середовища верифікації, через яке має пройти результат. Когнітивне навантаження на інженера в деяких аспектах є вищим (чіткість наміру має більше значення, ніж будь-коли), а в інших — нижчим (механічна робота з написання шаблонного коду зникла). Установи, які ще не здійснили цей перехід, все ще працюють у режимі, коли LLM — це просто швидший друкар. Така позиція є неприйнятною для виживання в регульованій сфері на горизонті понад наступні дванадцять місяців.

Регуляторний стек, який діє зараз

Регуляторний периметр навколо ШІ в банківській сфері у 2026 році більше не є просто списком завдань; це стек взаємопов'язаних зобов'язань, які необхідно аналізувати комплексно. Найбільш значуща дата — 2 серпня 2026 року, коли зобов'язання щодо систем високого ризику EU AI Act стануть повністю обов'язковими до виконання ⧉. Додаток III прямо класифікує кредитний скоринг, оцінку кредитоспроможності, оцінку ризиків у страхуванні життя та здоров'я, а також оцінку чи класифікацію фінансового стану фізичних осіб як системи високого ризику. Зобов'язання, які випливають із цієї класифікації, включають оцінку відповідності, системи управління якістю, рамки управління ризиками, технічну документацію, реєстрацію в базі даних ЄС, надійне управління даними, контроль з боку людини та кібербезпеку. Штрафи за порушення зобов'язань щодо високого ризику становлять до 35 мільйонів євро або 7% річного світового обороту, залежно від того, яка сума є більшою.

Поруч із AI Act діють такі вимоги:

DORA (Регламент про цифрову операційну стійкість) діє з січня 2025 року та визначає 22 зобов'язання з управління ризиками ІКТ, які прямо поширюються на системи ШІ, що використовуються у важливих фінансових функціях. Управління ризиками ІКТ, нагляд за третіми сторонами, звітування про інциденти та тестування операційної стійкості застосовуються до компонентів ШІ так само, як і до будь-яких інших активів ІКТ.
SR 11-7 — керівництво Федеральної резервної системи та OCC з управління ризиками моделей, спочатку написане у 2011 році, було поширене у практиці регуляторів ⧉ на LLM та агентичні системи. Перевірки FFIEC тепер прямо включають сферу управління ШІ. Установи, які не можуть надати інвентаризаційну відомість моделей ШІ та оцінку ризиків на запит, уже сьогодні отримують відповідні приписи про порушення.
NIST AI RMF (1.0, січень 2023 року) є добровільним у США, але використовується як база федеральними регуляторами. Його чотири функції (Govern, Map, Measure, Manage — Керувати, Відображати, Вимірювати, Організовувати) чітко узгоджуються зі структурними вимогами EU AI Act.
ISO/IEC 42001 (опублікований у грудні 2023 року) — це перший сертифікований стандарт системи управління ШІ, структурований подібного до ISO/IEC 27001 для інформаційної безпеки. Попит на сертифікацію 42001 різко зріс протягом першого кварталу 2026 року, оскільки вимоги до закупівель почали посилатися на нього.
Режим старших менеджерів та сертифікації Великобританії (SM&CR) та споживчі обов'язки (Consumer Duty) — режим SM&CR тепер вимагає персональної відповідальності за кожну систему ШІ високого ризику. Обов'язки Consumer Duty були розширені у нещодавніх настановах FCA ⧉ на результати обслуговування роздрібних клієнтів за участю ШІ.
Дорожня карта G7 з постквантового переходу (січень 2026 року), трифазна структура міграції NCSC та висновки Project Leap від BIS діють разом із цим стеком. Точка перетину має велике значення: система ШІ, яка навчена або працює на криптографічному субстраті, що не переживе постквантового переходу, — це система ШІ, чий аудиторський слід та заяви про цілісність мають період напіврозпаду менше десятиліття. Дискусія про агентичну інженерію та розмова про постквантову криптографію все частіше стають однією й тією ж розмовою. (Детальніше про криптографічний аспект див. у матеріалі за травень 2026 року про постквантову міграцію у корпоративних фінансах.)

Порівняння трьох режимів розробки за допомогою ШІ

Критерій	Vibe Coding	Spec-Driven розробка	Агентична інженерія
Основні вхідні дані	Короткий промпт	Формальна специфікація	Специфікація + план оркестрації агентів
Роль інженера	Ітератор промптів	Автор специфікації	Оркестратор та верифікатор
Принцип генерації	Пряма генерація коду	Код з обмеженнями специфікації	Багатоагентні процеси, що створюють код, тести, доки
Аудиторський слід	Історія чату (не зберігається)	Специфікація + згенерований код + тести	Специфікація + сліди агентів + артефакти верифікації
Рівень дефектів (лише LLM)	10–40% рівень уразливості (базовий показник літератури)	Суттєво знижений обмеженнями специфікації	Найнижчий завдяки шлюзам верифікації
Регуляторна простежуваність	Недостатня для ШІ високого ризику	Сумісна зі статтею 12 EU AI Act	Розроблена для статті 12 + SR 11-7 + DORA
Підходить для банків?	Ні, для промислового використання	Так, за умови контролю (управління)	Так, за наявності зрілої моделі управління
Межа можливостей	Обмежена одноразовим написанням промптів	Обмежена якістю специфікації	Обмежена якістю оркестрації

Джерело: синтез коментарів Карпати (2026), аналізу SDD від Augment Code ⧉, аналізу Spec-Driven розробки від CGI ⧉ та наукової літератури щодо рівня вразливостей коду, згенерованого LLM (Пірс та ін., Ян та ін., Фу та ін., 2023–2025 рр.).

Створення агентичного банку: архітектурний погляд

Стратегічна позиція за цими робочими процесами — це те, що керівництво компанії має контролювати особисто. Агентична інженерія в банківській сфері не є ініціативою з підвищення продуктивності розробників. Це інституційна спроможність, яка зачіпає наскрізні шляхи клієнта, весь життєвий цикл транзакцій, а також криптографічний та аудиторський субстрат, що лежить в основі обох процесів. Чотири рівні цієї спроможності заслуговують на безпосередню увагу керівництва зверху вниз:

Рівень 4 — Площина управління агентами Управління, аудит, аварійні вимикачі, виявлення аномалій поведінки, ручне втручання людини. Конфігурації нагляду HITL та HOTL для кожного класу агентів.

Рівень 3 — Агентичні робочі процеси Клієнтські шляхи, внутрішні операції, конвеєр розробки. За замовчуванням на основі специфікацій (spec-driven) для потоків високого ризику.

Рівень 2 — Рівень даних та моделей AIBOM (AI Bill of Materials — відомість матеріалів ШІ), реєстр моделей, субстрат пошуку, контроль версій шаблонів промптів, походження тонкого налаштування (fine-tune).

Рівень 1 — Квантово-безпечний фундамент ML-KEM, ML-DSA, гібридна інфраструктура відкритих ключів (PKI), криптографічна гнучкість (crypto-agility). Субстрат, на який спираються заяви про цілісність кожного вищого рівня.

Рівень 1 — Квантово-безпечний фундамент. Кожен рівень вище цього передбачає цілісність криптографічного субстрату. Зважаючи на дорожню карту G7, трифазний план NCSC та результати Project Leap від BIS, які вже є публічно задокументованими, це більше не є вузькоспеціалізованою проблемою. Агентичні системи, чиї аудиторські сліди підписані за допомогою класичного ECDSA або чиє встановлення ключів залежить від RSA чи ECDH, побачать, як їхні заяви про цілісність втрачають силу разом із криптографією. Установи, які роблять це правильно, переносять постквантову роботу на ранні етапи та розглядають ML-KEM, ML-DSA та гібридний PKI як субстрат, на якому тримаються гарантії аудиту та цілісності кожного вищого рівня.

Рівень 2 — Рівень даних та моделей. Це місце, де живе відомість матеріалів ШІ (AIBOM — AI Bill of Materials). Подібно до криптографічної відомості матеріалів (CBOM), що використовується при плануванні постквантової міграції, AIBOM — це реєстр кожної моделі, набору даних, шаблону промпту, індексу пошуку, тонкого налаштування та сторонньої залежності ШІ, з якими працює установа. Це артефакт, якого фактично вимагає стаття 49 EU AI Act, інвентаризаційний перелік, який зараз вимагають перевірки SR 11-7, і основа будь-якої надійної системи управління. Більшість установ його не мають. Він знадобиться їм до серпня.

Рівень 3 — Агентичні робочі процеси. Це рівень, який зараз створює більшість установ, часто без належної уваги до рівнів 1, 2 та 4. Самі робочі процеси варіюються від внутрішніх (генерація коду, підготовка нормативних документів, маршрутизація запитів клієнтів) до тих, що орієнтовані на клієнтів (помічники для менеджерів, онбординг, оркестрація KYC, моніторинг транзакцій, оптимізація FX), та повністю автономних (казначейські операції, певні функції торгівлі та управління ризиками, де це дозволяє регулятор). Стратегічне завдання на цьому рівні полягає в тому, щоб ставитися до нього як до системної інженерії, а не просто як до розробки прикладних програм — шаблони оркестрації, правила ескалації, шлюзи контролю людини (human-in-the-loop) та випуск аудиторських даних є першочерговими завданнями проектування.

Рівень 4 — Площина управління агентами. Це те, що Deloitte охарактеризувала як «кімнату управління агентами» ⧉: інфраструктура аудиту в реальному часі, логування дій, виявлення поведінкових аномалій, аварійні вимикачі та ручне втручання людини, що охоплює кожного агента у промисловому середовищі. Втрати Step Finance не були, за своєю суттю, збоєм самого ШІ. Це був збій площини управління: агенти мали дозволи, яких не повинні були мати, а поведінкова аномалія, яка мала призвести до зупинки, не спрацювала. Установи, які створюють площину управління першою — перед розгортанням масштабної мережі агентів, — це ті установи, які уникнуть інцидентів класу Step-Finance у 2027 році.

Важливе питання для вищого керівництва полягає не в тому, «чи впроваджуємо ми більше ШІ, ніж наші конкуренти?». Воно полягає в тому, чи володіє установа всіма чотирма рівнями, чи один або кілька з них непомітно делеговані сторонньому постачальнику без контрактної можливості задовольнити вимоги до документації статті 13 EU AI Act. Останній варіант виглядає цілком нормально, поки регулятор не поставить це питання руба.

Практика нагляду з боку людини: HITL проти HOTL

Єдиною відмінністю всередині Рівня 4, на якій регулятори найбільше зосереджені у 2026 році, є різниця між двома моделями нагляду. Обидві є формами нагляду людини; вони відрізняються часом затримки реакції, масштабом та припущеннями, які регулятор готовий зробити щодо поведінки агента.

Human-in-the-Loop (HITL) — це модель, у якій агент не може виконати важливу дію без явного схвалення людиною. Агент готує рішення, пропонує його і чекає. Прикладом HITL є агент фінансового моніторингу/KYC, який позначає рахунок для закриття, але не може закрити його без згоди комплаєнс-офіцера. Тут є операційний компроміс: модель HITL є безпечнішою та створює чіткий аудиторський слід відповідно до статті 14, але вона погано масштабується для високооб'ємних процесів із низькою затримкою.

Human-on-the-Loop (HOTL) — це модель, у якій агент діє автономно в межах визначених параметрів, тоді як люди контролюють телеметрію та зберігають за собою право зупинити агента в будь-який момент. Прикладом HOTL є агент для виявлення шахрайства в реальному часі, який автоматично блокує транзакції відповідно до певних шаблонів ризику, поки операційна команда людей відстежує обсяг сповіщень та реагує на аномалії. Тут компроміс зворотний: модель HOTL масштабується, але вона покладається на правильність налаштування параметрів агента та на виявлення поведінкових аномалій, які вловлюють відхилення до накопичення негативних наслідків.

Стаття 14 EU AI Act не вказує на обов'язковість саме HITL чи HOTL; вона вимагає, щоб нагляд з боку людини був ефективним та змістовним. Практичний висновок полягає в тому, що кожен агент високого ризику, якого використовує банк, повинен мати чітку, задокументовану позицію щодо того, яка модель застосовується, чому і яким є шлях ескалації, коли агент стикається із ситуаціями за межами визначених параметрів. Більшість банків, які запускали пілотні проекти у 2025 році, не мали такої документації. Більшості банків, які запустять промислових агентів до серпня 2026 року, вона знадобиться.

Правило прийняття рішень просте. Для важливих, низькооб'ємних та незворотних дій — відмова в кредиті фізичній особі, закриття рахунку, авторизація великого грошового переказу, подача регуляторної звітності — модель HITL є надійним стандартом за замовчуванням. Для високооб'ємних, зворотних дій із обмеженими параметрами — сповіщення про моніторинг транзакцій, класифікація документів, рутинна маршрутизація клієнтських запитів — підходить модель HOTL, за умови зрілості систем виявлення поведінкових аномалій та інфраструктури аварійних вимикачів. Банки, які розглядатимуть кожен робочий процес як HITL, не зможуть отримати операційну вигоду від агентичних систем. Банки, які розглядатимуть кожен робочий процес як HOTL, рано чи пізно матимуть ситуацію, схожу на Step Finance.

Купівля проти створення власноруч: проблема сторонніх агентів

Реальність 2026 року, з якою зіткнулася більшість банків, полягає в тому, що вони переважно не будуть створювати агентичні спроможності власноруч. Вони будуть їх купувати. Ринок постачальників — платформа агентичного банкінгу від Oracle, випущена в лютому 2026 року, IBM Watsonx, пакет Microsoft Copilot, AWS Bedrock Agents, Salesforce Agentforce, ServiceNow NowAssist та хвиля фінтех-стартапів, що пропонують спеціалізованих агентів — розвивається швидше, ніж внутрішні інженерні команди банків. Стратегічним наслідком є те, що більшість агентів, які працюватимуть у банках у 2027 році, будуть написані сторонніми розробниками, і питання управління вже не стоятиме так: «чи можемо ми довіряти нашим агентам?», а швидше: «чи можемо ми довіряти придбаним агентам і чи можемо ми довести це регулятору?».

Це найгучніший недооцінений виклик у межах DORA. Статті 28–30 регламенту роблять управління ризиками ІКТ третіх сторін активною сферою нагляду з чіткими вимогами до умов контрактів, поточного моніторингу, оцінки ризику концентрації та стратегій виходу. Європейські наглядові органи ведуть реєстр критично важливих сторонніх постачальників ІКТ-послуг із прямими повноваженнями нагляду за тими, хто отримав такий статус. Нова операційна реальність полягає в тому, що постачальники ШІ 2026 року — розробники передових моделей, постачальники платформ агентів, SaaS із підтримкою ШІ — все частіше виявляються саме тими третіми сторонами в ІКТ, для регулювання яких і було створено DORA.

Для банку в позиції покупця діють три практичні вимоги:

Вимагайте AIBOM від постачальника. Будь-який продукт із агентами, придбаний для використання у високоризикових процесах, має постачатися із задокументованою відомістю матеріалів ШІ (AIBOM), що охоплює базові моделі, походження та обмеження навчальних даних, застосовані тонкі налаштування, індекси пошуку, версії шаблонів промптів та ланцюжок залежностей нижчих компонентів агента. Це артефакт, який знадобиться банку для виконання вимог щодо документації статті 13 EU AI Act. Банк не зможе створити його заднім числом, якщо постачальник не взяв на себе відповідних контрактних зобов'язань.

Тестуйте «чорну скриньку», а не брошуру. Закупівлі у постачальників історично зосереджені на порівнянні характеристик та відгуках інших клієнтів. Для агентичних систем цього недостатньо. Установа повинна провести поведінкове тестування агента в умовах, аналогічних до планованого промислового впровадження, включаючи змагальне тестування (adversarial probing) на предмет ін'єкцій промптів, стійкості до соціальної інженерії (вектор Step Finance), відхилення (drift) при зміні розподілу даних, а також перевірку часу затримки та режимів відмови для каналів аварійного вимикача та ручного втручання. Більшість поточних контрактів із постачальниками не дозволяють таку глибину тестування без додаткових переговорів; ці переговори мають відбутися до підписання контракту, а не після.

Перегляньте контракти відповідно до вимог статті 13. Більшість чинних угод із постачальниками ШІ не містять жодних положень щодо надання документації, прав на аудит, повідомлень про зміни в моделях, звітності про інциденти або розкриття інформації про субпідрядників, яких разом вимагають EU AI Act та DORA. Аналіз Regulativ щодо британських фірм ⧉ чітко вказує на це: юридичний аналіз контрактів із постачальниками триває тижнями, і більшість установ не можуть задовольнити вимоги статті 13 щодо моделей, внутрішню логіку роботи яких постачальник ніколи не мав контрактних зобов'язань розкривати. Регуляторна відповідальність лежить на тому, хто впроваджує (deployer), а не на постачальнику. Команди із закупівель мають знати про це до наступного циклу продовження контрактів, а не після запиту регулятора.

Загальний висновок для ради директорів полягає в тому, що відносини з постачальниками перейшли від звичайних закупівель до передачі ризику — причому сам ризик фактично не передається. Банк залишається впроваджувачем (deployer). Банк залишається відповідальним. Банку потрібні договірні інструменти та дисципліна тестування, які роблять цю відповідальність контрольованою, а не просто формальною.

Що це означає для різних типів банків

Правильна реакція залежить від типу банку. Наведений нижче розподіл є приблизною сегментацією, а не обов'язковим приписом.

Універсальні банки першої групи (Tier-One)

Установи з балансом понад 1 трильйон доларів та глобальною присутністю є водночас найбільш вразливими (найширший регуляторний периметр, найбільша кількість застарілих систем, найдорожчі цілі для автономних супротивників) та найкраще забезпеченими ресурсами. Стратегічним пріоритетом є створення перш за все площини управління — Рівня 4 архітектури, наведеної вище, — та впровадження дисципліни spec-driven розробки у внутрішній інженерній службі перед подальшим масштабуванням використання агентів. Конкурентні переваги від правильного втілення цього підходу є значними; наслідки помилки є екзистенційними, зважаючи на ризик накладення штрафів згідно з EU AI Act та операційну вразливість до атак класу GTG-1002.

Середні та регіональні банки

Конкурентні виклики перед банками другого ешелону є гострішими, ніж перед лідерами. Вони стикаються з тим самим регуляторним периметром, але не мають такого ж бюджету на управління, мають ту саму поверхню загроз без аналогічних оборонних ресурсів і базу клієнтів, яка все частіше порівнює їх із ШІ-орієнтованими фінтех-компаніями. Практичне рішення полягає в суворій стандартизації на невеликому колі перевірених постачальників (із контрактами, що задовольняють вимоги статті 13 щодо документації), інвестуванні в дисципліну spec-driven розробки замість кастомної платформної інженерії та використанні агентичних інструментів для скорочення термінів модернізації COBOL, який був стратегічним тягарем протягом двох десятиліть. Установи, які почнуть діяти раніше, зможуть суттєво скоротити технологічний розрив із банками першої групи вперше за ціле покоління.

Фінтех-компанії, платіжні провайдери та криптоінституції

Сегмент фінтех- та платіжних установ має протилежну проблему: гнучкість є високою, проте рівень управління та контролю часто нижчий, ніж у традиційних банків, а штрафи за порушення EU AI Act можуть бути екзистенційними для середнього фінтеху. Стратегічне завдання полягає в тому, щоб ставитися до управління ШІ як до обов'язкового етапу готовності продукту, а не просто як до комплаєнс-надбудови — створюючи AIBOM, субстрат аудиту та spec-driven робочі процеси в межах інженерної культури з самого початку, а не переробляючи їх під тиском регуляторів. Для установ, чия платіжна інфраструктура перетинається з дедлайном SWIFT CBPR+ щодо структурованих адрес у листопаді 2026 року, інвестиції в агентичну інженерію також є природним механізмом для індустріалізації робіт із виправлення структурованих адрес — правила валідації, контроль якості даних та інтеграція в CI-конвеєр є саме тими шаблонами, які полегшують spec-driven робочі процеси.

Внутрішні інженерні підрозділи

Для інженерів та дослідників, які читають це, робоча дисципліна, яка має значення, є щоденною. Перенесіть центр ваги роботи з простого написання символів на створення специфікацій та засобів верифікації коду. Ставтеся до слідів роботи агентів, проміжних планів та шлюзів схвалення як до першокласних артефактів у вашій системі контролю версій. Інвестуйте в інструменти — Spec Kit, Kiro, режим планування Cursor, Claude Code із файлами навичок на рівні проекту (skill files), — які роблять специфікацію довговічним артефактом, а згенерований код — тимчасовим (одноразовим). Зсув у ергономіці роботи є реальним. Професійна вигода полягає в тому, що дисципліна, яка впроваджується на передньому краї технологій, також є тією дисципліною, яка успішно проходить перевірки регуляторів.

12-тижневий план дій до серпня 2026 року

Для виконавчого спонсора, який керує програмою агентичної інженерії з цього моменту і до дати набрання чинності EU AI Act, робота стискається в дванадцятитижневу послідовність. Наведений нижче план не є вичерпним; це мінімум, виконання якого рада директорів повинна очікувати від надійної програми до 2 серпня 2026 року.

Тижні 1–2 — Створення AIBOM. Створення централізованого реєстру кожної системи ШІ, моделі, набору даних, шаблону промпту, індексу пошуку, тонкого налаштування та сторонньої залежності ШІ, що перебувають у промисловому використанні або в розробці. Співвіднесення кожного запису з класифікацією Додатка III EU AI Act. Кінцевим результатом є єдине джерело істини, до якого можуть звертатися CRO, CCO, CISO та CTO.

Тижні 3–4 — Класифікація моделі нагляду для кожної системи. Для кожного високоризикового та критично важливого агента необхідно чітко задокументувати, яка модель нагляду застосовується (HITL чи HOTL), обґрунтування цього вибору, шлях ескалації та призначену відповідальну особу відповідно до вимог SM&CR (Великобританія) або аналогічного національного режиму. Якщо відповідь неоднозначна, за замовчуванням встановлюйте модель HITL до завершення аналізу.

Тижні 5–6 — Створення або зміцнення площини управління агентами. Забезпечення роботи логування дій у реальному часі, виявлення аномалій поведінки, каналів аварійного вимикача та ручного втручання для кожного промислового агента. Якщо площина управління для системи ще не створена, ця система переводиться в статус обмеженого розгортання до вирішення питання.

Тижні 7–8 — Перегляд контрактів із постачальниками. Юридичний відділ та відділ закупівель перевіряють кожен активний контракт із постачальниками ШІ на предмет наявності прав на отримання документації згідно зі статтею 13, повідомлень про зміни в моделях, звітності про інциденти, прав на аудит та розкриття інформації про субпідрядників. Результатом є структурований список: відповідає вимогам, потребує виправлення, потребує заміни постачальника. Рішення про заміну мають прийматися вже зараз, щоб мати хоч якийсь шанс завершити процес цього року.

Тижні 9–10 — Тестове проведення оцінки відповідності. Для кожної високоризикової системи згідно з Додатком III необхідно виконати процес оцінки відповідності так, ніби уповноважений орган має прийти наступного тижня. Це виявить недоліки, які виглядають незначними на папері, але є операційно критичними під час реальної перевірки. Виправте те, що можна виправити; задокументуйте решту.

Тижні 11–12 — Валідація перед запуском та затвердження радою директорів. Фінальний огляд AIBOM, класифікацій HITL/HOTL, доказів роботи площини управління, статусу врегулювання контрактів із постачальниками та результатів оцінки відповідності. Підтвердження персональної відповідальності старших менеджерів. Фіксація позиції у протоколі засідання ради директорів. Повідомлення регулятора, де цього вимагають правила попереднього інформування.

Установи, які завершать цю дванадцятитижневу послідовність, не вирішать усіх питань агентичної інженерії. Але вони створять базовий рівень, необхідний для надійної програми. Установи, які не розпочали роботу на момент публікації цієї статті, не є унікально недбалими, як зазначалося в аналізі Regulativ щодо SWIFT. Вони становлять більшість. Питання, на яке кожен CCO, CRO та CTO має відповісти у найближчі два тижні, полягає в тому, чи почне фірма діяти в травні, чи буде гарячково метушитися в липні.

Висновок

Суворий висновок, який сформувався в індустрії за останні шість місяців, полягає в тому, що старі методи роботи корпоративного масштабу витісняються не новою технологією, а новим підходом до організації праці. Агентичні інструменти виявили — іноді у промисловому середовищі, іноді у звітах про інциденти — недоліки та прогалини в застарілих системах, які непомітно накопичувалися роками. Ті самі інструменти надали зловмисникам ресурси, які раніше потребували підтримки на державному рівні. Ці самі інструменти, за умови їх дисциплінованого внутрішнього використання, є найвідповіднішим шляхом для подолання проблеми застарілих систем, виконання вимог регулятора до серпня 2026 року та виходу на операційну швидкість, якої вимагають очікування клієнтів та конкурентна реальність.

Установи, які приймуть це рішення всередині компанії — які розглядатимуть агентичну інженерію як структурну спроможність банку, а не просто як надбудову продуктивності, придбану у постачальника, — проведуть наступні два роки, накопичуючи конкурентні переваги. Установи, які цього не зроблять, проведуть наступні два роки, дізнаючись зі звітів про інциденти та приписів регуляторів про те, що саме їм слід було побудувати. Вибір між цими двома результатами є рішенням на рівні ради директорів у 2026 році, а не вибором технології в 2028 році.

Для глибшого розуміння контексту на цьому сайті: у матеріалі за квітень 2026 року про квантові пороги розглянуто апаратну траєкторію, що лежить в основі Рівня 1 архітектури вище; у матеріалі за травень 2026 року про постквантову міграцію для корпоративних фінансів детально досліджено криптографічний субстрат; у травневому аналізі дедлайну pacs.008 щодо структурованих адрес описaно нормативну та інженерну дисципліну, яку спрощує spec-driven валідація; а робота над відкритим кодом на Rust для KyberLib, pain001 та pacs008 є частиною ширших зусиль з надання промислових примітивів — квантово-безпечних, сумісних із платіжними стандартами та готових до аудиту — до рук інженерних команд, які створюватимуть агентичний банк. Зв'язок між цими публікаціями не є випадковим. Це відображення характеру роботи, якої вимагатимуть наступні два роки.

Часті запитання

У чому різниця між генеративним ШІ, агентичним ШІ та агентичною інженерією?

Генеративний ШІ створює контент у відповідь на запит (промпт); він є реактивним. Агентичний ШІ автономно переслідує визначені цілі, отримуючи доступ до даних, використовуючи інструменти та здійснюючи дії у багатоетапних робочих процесах без потреби в промптах від людини на кожному кроці. Агентична інженерія — термін, який Карпати прийняв у 2026 році ⧉, — це робоча дисципліна оркестрації агентів відповідно до детальних специфікацій під наглядом людини. Для банківської справи це розрізнення є важливим, оскільки регуляторний периметр, модель загроз та інженерна дисципліна різняться для кожної категорії. Інтерфейс чату та повністю автономний торговий агент належать до абсолютно різних регуляторних класів, і ставлення до них як до одного класу створює ризики в обох напрямках.

Чому крайній термін EU AI Act у серпні 2026 року є настільки важливим для банків?

Додаток III до AI Act прямо класифікує кілька основних банківських сценаріїв використання ШІ як високоризикові: оцінка кредитоспроможності та кредитний скоринг фізичних осіб, оцінка ризиків та визначення тарифів у страхуванні життя та здоров'я, а також оцінка або класифікація фінансового стану фізичних осіб. З 2 серпня 2026 року організації, які впроваджують такі системи, мають продемонструвати відповідність вимогам щодо систем управління якістю, структур управління ризиками, технічної документації, оцінки відповідності, реєстрації в базах даних ЄС, надійного управління даними, людського нагляду та кібербезпеки. Стаття 12 вимагає автоматичного логування вхідних та вихідних даних. Стаття 14 вимагає ефективного нагляду з боку людини (HITL або HOTL, відповідно до типу системи). Штрафи за порушення сягають 35 мільйонів євро або 7% річного світового обороту. Робота для виконання цих зобов'язань є суто інженерною, а не просто веденням документації, і саме з цієї причини впровадження spec-driven розробки прискорилося в першому кварталі 2026 року.

У чому полягає практична різниця між HITL та HOTL і коли слід застосовувати кожну з моделей?

HITL (Human-in-the-Loop) означає, що агент не може виконувати важливі дії без явного затвердження людиною. HOTL (Human-on-the-Loop) означає, що агент виконує дії автономно в межах визначених параметрів, тоді як люди контролюють телеметрію та зберігають за собою право зупинити його в будь-який момент. Стаття 14 EU AI Act вимагає, щоб нагляд був змістовним, але не визначає конкретну модель. Правило вибору полягає в тому, щоб застосовувати HITL там, де дія є важливою, низькооб'ємною та незворотною (відмова в кредиті, закриття рахунку, авторизація великого переказу, подача звітності), і HOTL — там, де дії є високооб'ємними, зворотними та обмеженими параметрами (сповіщення системи моніторингу транзакцій, класифікація документів, стандартна маршрутизація запитів клієнтів). Обидві моделі вимагають наявності робочої та перевіреної інфраструктури аварійних вимикачів та ручного втручання; різниця полягає в тому, чи перебуває людина перед процесом виконання (HITL), чи поруч із ним (HOTL).

Більшість наших агентів будуть від сторонніх постачальників. Як задовольнити вимоги DORA та EU AI Act для систем, які ми не створювали?

Регуляторні зобов'язання лежать на тому, хто впроваджує (deployer), а не на постачальнику. Практична відповідь складається з трьох частин. По-перше, вимагайте задокументований AIBOM від постачальника перед підписанням контракту — походження моделі, походження навчальних даних, тонкі налаштування, шаблони промптів, індекси пошуку, ланцюжок залежностей. По-друге, проведіть поведінкове тестування агента в умовах, близьких до промислових, включаючи змагальне тестування (adversarial probing) на предмет ін'єкцій промптів та стійкості до соціальної інженерії. По-третє, перегляньте контракти з постачальниками, щоб включити права на документацію відповідно до статті 13, повідомлення про зміни в моделях, звітність про інциденти, права на аудит та розкриття субпідрядників — більшість поточних контрактів не містять нічого з цього. Статті 28–30 регламенту DORA охоплюють управління ризиками ІКТ третіх сторін і є відповідним регуляторним стандартом з європейського боку; настанови FFIEC є еквівалентом на ринку США. Ця робота є критично важливою і не може бути відкладена.

Наскільки сильно банки мають хвилюватися через агентичних супротивників?

Чесна відповідь полягає в тому, що загроза є реальною та операційно відрізняється від попередніх кіберзагроз. Оприлюднений Anthropic у листопаді 2025 року звіт про діяльність GTG-1002 є класичним прикладом: агентичний ШІ виконував 80–90% тактичних операцій у межах спонсорованої державою шпигунської кампанії проти близько тридцяти цілей в оборонній, енергетичній та технологічній сферах на швидкості тисяч запитів за секунду. Інцидент зі Step Finance в січні 2026 року — збитки на суму 27–30 мільйонів доларів через дії торгових агентів ШІ з надмірними правами доступу — є хрестоматійним прикладом того, як внутрішній ШІ може стати вектором атаки. Звіт Flashpoint GTIR за 2026 рік зафіксував 1500% зростання незаконних обговорень ШІ лише за один місяць. Це не гіпотетичні сценарії, а реальні інциденти 2025–2026 років. Банки, які ведуть класичну оборону проти агентичних супротивників, структурно мають асиметричну вразливість, і правильною відповіддю є створення оборонних систем класу «ШІ проти ШІ», а не сповільнення переходу до використання агентів ШІ на стороні захисту.

Чи є агентичний ШІ просто «ChatGPT плюс сервери MCP»?

Ні, і це одна з найбільш суттєвих помилок на сучасному ринку. Інтерфейс чату, розширений за допомогою серверів MCP, є корисним шаблоном для отримання та обробки даних у межах обмеженої сесії. Агентична інженерія — це структурна спроможність установи: AIBOM, площина управління агентами, spec-driven конвеєр розробки, субстрат аудиту, квантово-безпечна криптографічна основа та шаблони оркестрації в межах наскрізних шляхів клієнта. Це не просто функції, придбані у постачальника; це позиція інституційного володіння процесом. Банки, які розглядають це лише як рішення про купівлю, отримують переваги, які постійно зростають.

Що є найважливішим завданням для банку на найближчі дванадцять тижнів?

Три послідовні речі. По-перше, створити відомість матеріалів ШІ (AIBOM) — повний реєстр кожної системи ШІ, моделі, набору даних, шаблону промпту, індексу пошуку та сторонньої залежності ШІ, що використовуються або розробляються, із класифікацією кожного елемента відповідно до Додатка III EU AI Act. Установа, яка не зможе надати цей документ на запит регулятора, отримає відповідний припис про порушення. По-друге, побудувати площину управління агентами для будь-якої системи ШІ, яка зараз приймає або суттєво впливає на рішення, що стосуються клієнтів — логування аудиту, виявлення поведінкових аномалій, ручне втручання та аварійні вимикачі як базова інфраструктура, а не пункт майбутньої дорожньої карти. По-третє, перевести внутрішню інженерну культуру від vibe coding до spec-driven розробки на найважливіших напрямках — системах високого ризику, регульованих процесах та конвеєрі модернізації застарілих систем. Перші два завдання є комплаєнс-роботою, а третє — роботою на конкурентоспроможність. Установи, які виконають усі три пункти, будуть у значно виграшнішому становищі, ніж ті, що виконають один або жодного. Детальний 12-тижневий план дій описано у відповідному розділі вище.

Джерела

Sebastien Rousseau, (2026). Безпека реєстру: Посібник для ради директорів з постквантової міграції для корпоративних фінансів.
Sebastien Rousseau, (2026). Дедлайн щодо структурованих адрес pacs.008 у листопаді 2026 року: Огляд за шість місяців.
Sebastien Rousseau, (2026). Квантові пороги знову зміщуються.
Sebastien Rousseau, (2023). CRYSTALS-Kyber: Захисний алгоритм у квантову еру.
Mansurova, M. (2026). Від Vibe Coding до Spec-Driven розробки ⧉. Towards Data Science.
CGI, (2026). Spec-driven розробка: Від vibe coding до проектування намірів ⧉. CGI.
Augment Code, (2026). Що таке Spec-Driven розробка? Повний посібник ⧉. Augment Code.
BCMS, (2026). Spec-Driven розробка: Визначальний посібник 2026 року ⧉. BCMS.
Deloitte, (2026). Управління новою хвилею ризиків від агентів ШІ в банківській сфері ⧉. Deloitte Center for Financial Services.
Anthropic, (2025). Виявлення та протидія зловживанню ШІ: Серпень 2025 ⧉. Anthropic.
Anthropic, (2025). Блокування першої відомої кібершпигунської кампанії, організованої за допомогою ШІ ⧉. Anthropic.
Flashpoint, (2026). Звіт про глобальні загрози 2026 ⧉. HSToday / Flashpoint.
Beam AI, (2026). 5 реальних зламів безпеки агентів ШІ у 2026 році та їхні уроки ⧉. Beam.
Congressional Research Service, (2026). Агентичний штучний інтелект та кібератаки ⧉. Congress.gov.
Європейська Комісія, (2024). Regulation (EU) 2024/1689 on Artificial Intelligence (EU AI Act).
Knowlee, (2026). EU AI Act для фінансових послуг: Зобов'язання Додатка III для банків, фінтехів та страховиків ⧉. Knowlee.
Regulativ, (2026). Крайній термін EU AI Act у серпні 2026 року: Що тепер мають робити фірми у сфері фінансових послуг ⧉. Finextra.
AegisAI Compliance, (2026). Управління ШІ для банків: Посібник із відповідності SR 11-7 та EU AI Act ⧉. AegisAI.
The Financial Brand, (2026). Як автономні агенти ШІ насправді змінять розвиток банківської справи ⧉. The Financial Brand.
UXDA, (2026). Чи може банкінг на основі агентичного ШІ загрожувати глобальним фінансовим послугам? ⧉. UXDA.
Neurons Lab, (2026). Агентичний ШІ у фінансових послугах: Огляд досліджень за 2026 рік ⧉. Neurons Lab.
Computer Weekly, (2026). ШІ допоможе мейнфреймам залишатися критично важливими для бізнесу в 2026 році ⧉. Computer Weekly.
The Financial Revolutionist, (2026). Застарілі системи ставлять банки під загрозу ⧉. The Financial Revolutionist.
CIO Magazine, (2025). Використання ШІ для модернізації мейнфреймів: Перетворення застарілих технологій на стратегічну перевагу ⧉. CIO Magazine.
Microsoft Azure, (2025). Як ми використовуємо агентів ШІ для міграції з COBOL та модернізації мейнфреймів ⧉. Microsoft DevBlogs.
VentureBeat, (2026). Агентичне кодування на корпоративному рівні вимагає spec-driven розробки ⧉. VentureBeat.
The News (Pakistan), (2026). Чому прагнення британських банків до агентичного ШІ турбує регуляторів Великобританії ⧉. The News International.
CNBC, (2026). Mythos від Anthropic спровокував «істерію» навколо кібербезпеки ⧉. CNBC.

Останній перегляд 2026-06-23.

Останній перегляд 2026-07-18.

Перевидати цю статтю

Агентична інженерія для банків: План на 2026 рік для керівництва та інженерів, які його втілюватимуть — Sebastien Rousseau

Агентичний ШІ перейшов від пілотування до виробництва в глобальному банківському секторі. Сімдесят відсотків фінансових установ певною мірою використовують його; лише кожна п'ята має зрілу модель управління. Тим часом автономні супротивники діють на швидкості машин, застаріле середовище COBOL, з яким мають взаємодіяти нові системи, було створено з урахуванням пакетної обробки 1960-х років, а до крайнього терміну впровадження високого ризику EU AI Act у серпні 2026 року залишилося дванадцять тижнів. Це інженерна позиція та позиція управління, якої повинен дотримуватися банк.

Ця стаття поширюється за ліцензією Creative Commons Attribution 4.0 International. Перевидання вимагає посилання на канонічну URL-адресу.

Агентична інженерія для банків: План на 2026 рік для керівництва та інженерів, які його втілюватимуть — Sebastien Rousseau

Агентичний ШІ перейшов від пілотування до виробництва в глобальному банківському секторі. Сімдесят відсотків фінансових установ певною мірою використовують його; лише кожна п'ята має зрілу модель управління. Тим часом автономні супротивники діють на швидкості машин, застаріле середовище COBOL, з яким мають взаємодіяти нові системи, було створено з урахуванням пакетної обробки 1960-х років, а до крайнього терміну впровадження високого ризику EU AI Act у серпні 2026 року залишилося дванадцять тижнів. Це інженерна позиція та позиція управління, якої повинен дотримуватися банк.

Originally published at https://sebastienrousseau.com/uk/2026-05-17-ahentyna-inzheneriya-banky-blueprint-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER