FSB пропонує 12 практик управління штучним інтелектом для фінансових установ

15 жовтня 2026 року Рада з фінансової стабільності (FSB) опублікувала фінальний звіт "Здорові практики відповідального впровадження штучного інтелекту фінансовими установами", в якому запропоновано 12 практик для фінансових установ. Звіт охоплює стратегії AI, оцінку ризиків, управління даними, людський нагляд, кібербезпеку та послуги третіх сторін, реагуючи на низку управлінських проблем, що виникли внаслідок швидкого впровадження генеративного AI та агентного AI фінансовими установами в останні роки.

Управління AI у фінансових установах пов'язує керівників бізнесу, команди ризиків та зовнішніх постачальників.

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

Чому практики повинні охоплювати так багато аспектів, таких як рада директорів, дані, моделі та постачальники? Це можна зрозуміти на прикладі поширеного проекту: банк готується використовувати AI для обробки кредитів для малих підприємств. Бізнес-команда хоче скоротити час перевірки, команда моделей стурбована точністю ідентифікації, команда комплаєнсу зосереджена на даних клієнтів і поясненнях рішень, а операційна команда повинна забезпечити, щоб кредитування продовжувалося навіть після зупинки постачальника. Перевірка лише продуктивності моделі не може відповісти на питання інших сторін. Звіт FSB намагається інтегрувати ці рішення в один управлінський процес.

1. 12 практик охоплюють весь цикл управління AI

FSB розділила 12 практик на дві групи. Перші чотири зосереджені на управлінні на рівні установи, а останні вісім охоплюють всі етапи впровадження, розробки, впровадження та постійного використання AI.

Чотири практики управління установою спочатку включають відповідальність, документацію та постійні коригування в управлінську рамку.

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

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

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

Ці чотири практики визначають, хто затверджує проект AI, хто його підтримує та хто має право його зупинити. Раді директорів не потрібно перевіряти параметри моделі по одному, але вона повинна знати, в які важливі бізнеси впроваджено AI, які очікувані вигоди та які ризики готові взяти на себе. Керівництво потім реалізує загальні вимоги в затвердженні продуктів та посадових обов'язках. Наприклад, керівник кредитного бізнесу вирішує, на якому етапі затвердження може з'явитися рекомендація AI; команда ризиків моделі розробляє тести; комплаєнс перевіряє права клієнтів; внутрішній аудит оцінює, чи дійсно працюють вищезгадані контролі. Якщо між посадами існують прогалини, необхідно призначити остаточного приймача рішень перед запуском.

Документація, про яку говорить FSB, не є просто збереженням інструкції з продукту. Кожен випадок використання повинен принаймні дозволяти відстежувати бізнес-мету, джерела даних, версії моделі, результати тестування, місця людського втручання, залежності від третіх сторін та записи значних змін. Якщо клієнт оскаржує результати затвердження, установи можуть відновити процес на основі цих матеріалів. Це ж стосується вже придбаного офісного програмного забезпечення: якщо продукт, який спочатку не містив AI, отримує функції автоматичного підсумовування або класифікації клієнтів, установи повинні повторно підтвердити напрямок і обсяг використання вхідних даних.

Останні вісім практик виходять з конкретних сценаріїв використання, охоплюючи важливість випадків використання AI та оцінку ризиків, вибір моделей і систем, управління даними, пояснюваність та прозорість. Подальші практики також стосуються продуктивності системи, людського нагляду, ризиків у сфері інформаційних та комунікаційних технологій (ICT), а також залежності від третіх сторін AI.

12 практик організовані за темами управління, багато вимог охоплюють кілька етапів використання AI. Установи можуть вирішити глибину контрольних заходів, враховуючи власний масштаб, складність бізнесу, роль у фінансовій системі та ступінь впровадження AI в критичні бізнеси.

Тут "оцінка важливості" (materiality assessment) простими словами означає визначення того, чи вплине певний застосунок AI на ключові бізнеси, права клієнтів або рішення щодо ризиків установи. Інструмент для організації протоколів засідань потребує іншого рівня перевірки, ніж система, що бере участь у затвердженні кредитів або управлінні активами клієнтів. FSB пропонує налаштувати управлінські зусилля відповідно до сценаріїв використання та ризиків, щоб установи могли зосередити більше контрольних ресурсів на більш впливових застосунках.

Ця система управління життєвим циклом вимагає від установи розглядати дані, моделі та бізнес-сценарії разом. Якість даних для навчання та роботи вплине на виходи моделі, оновлення моделі може змінити попередні результати, а способи використання клієнтів та співробітників також можуть створити нові ризики. Оцінка ризиків, отже, повинна проходити через вибір, тестування, запуск і постійне функціонування.

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

Шоста практика стосується вибору. На ринку є як власні моделі, так і зовнішні API та AI-функції, вбудовані в звичайне програмне забезпечення. Бізнес-команди зазвичай спочатку звертають увагу на ціну та функціональність, тоді як команди ризиків повинні запитати: чи може модель стабільно працювати в умовах мови, клієнтської бази та ринкових умов нашої установи? Чи буде постачальник повідомляти про оновлення? Чи будуть дані використовуватися для подальшого навчання? Якщо можна отримати лише обмежену технічну інформацію, установи можуть спочатку обмежити використання та обсяг даних, а після запуску продовжувати тестувати на своїх зразках, а не вважати демонстрацію закупівлі офіційною перевіркою.

Сьома та восьма практики пов'язані з даними та поясненнями. Якщо в історичних даних кредитування відсутні певні категорії клієнтів, модель може продовжувати давати неправильні результати для таких заявок; якщо фронтальні співробітники не можуть пояснити результати рекомендацій, обробка заперечень клієнтів буде ще складнішою. Управління даними, отже, охоплює цілісність, точність, ліцензії на джерела, доступ, безпеку. Вимоги до пояснюваності також повинні бути організовані за сценаріями: надання джерел для внутрішнього пошуку та пояснення клієнтам рішень, які впливають на їхні можливості фінансування, вимагають різного рівня ясності. FSB дозволяє установам встановлювати обмеження на використання, повторну перевірку та додаткові тести для моделей, які важко пояснити, зосереджуючи увагу на тому, щоб особа, відповідальна за рішення, мала достатню інформацію.

Дев'ята та десята практики стосуються повсякденної роботи. Установи повинні моніторити, чи змінюється продуктивність моделі відповідно до змін у бізнес-середовищі, спостерігати за рівнем помилок, скаргами, аномальними викликами та ручними змінами рішень; контрольні показники повинні бути пов'язані з початковим використанням. Людський нагляд також повинен мати реальні повноваження. Якщо перевіряючий лише натискає "згоден" на екрані, не бачачи підстав, і не має права змінювати вихід, нагляд буде важко реалізувати. Для процесів з високим ризиком можуть бути встановлені обов'язкові повторні підтвердження, вибіркові перевірки та автоматичні пороги зупинки; документування причин, чому людина прийняла або відхилила рекомендації моделі, може покращити тестування.

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

2. Відкриті думки доповнили фінальний звіт деталями операційного рівня

FSB опублікувала консультаційний документ у червні 2026 року, а збір думок завершився 22 липня. В результаті було отримано близько 160 відгуків від банків, страхових компаній, інших фінансових установ, галузевих асоціацій, постачальників технологій, академічних кіл та державного сектора. Загалом респонденти підтримали принциповий підхід, що підкреслює пропорційність; водночас були висловлені практичні труднощі в реалізації.

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

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

Залежність від третіх сторін та кібербезпека також увійшли в управління життєвим циклом AI.

Фінальний звіт, отже, ще більше розширив обговорення про третіх сторін AI, охоплюючи вбудовані AI, послуги підрядників та залежності в постачальницькому ланцюзі, підкреслюючи управління концентрацією, безперервність бізнесу та плани виходу. Щодо планів виходу з ключових послуг, простими словами, це означає, як установи можуть переключити послуги або підтримувати бізнес у разі зупинки постачальника, розірвання контракту або перевищення ризиків, які вони можуть витримати.

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

Агентний AI також став важливим об'єктом змін. Він відрізняється від звичайних інструментів генерації тексту, оскільки може виконувати кілька кроків після встановлення цілей, деякі системи також можуть викликати зовнішні інструменти або отримувати доступ до бізнес-даних. Відгуки пропонували контрольні ідеї, такі як авторизація перед виконанням, мінімальні права, незмінні записи операцій та моніторинг під час роботи. Фінальний звіт додав відповідні міркування та зазначив, що ця частина практики все ще розвивається, і в майбутньому можуть знадобитися більш глибокі вказівки.

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

3. Для фінансових установ ключовою роботою є інтеграція принципів у повсякденні процеси

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

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

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

Доступний внутрішній процес також повинен розрізняти "експерименти" та "виробництво". Експериментальне середовище може використовувати анонімні або синтетичні дані, обмежуючи користувачів і кількість викликів; перед підключенням реальних даних клієнтів та бізнес-систем, бізнес, технології, безпека та юридичні служби повинні спільно підтвердити дані та права. Затвердження запуску не повинно стати кінцевою точкою. Установи можуть встановити тригери для змін версій: при зміні основної моделі, підключенні нових зовнішніх інструментів, розширенні до нових клієнтських груп або коригуванні рівня автоматизації, автоматично запускається повторна перевірка. Багато ризиків AI виникають після розширення використання, тоді як початкові матеріали проекту залишаються на початкових низькоризикових сценаріях.

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

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

Щодо агентного AI, також потрібно чітко визначити межі авторизації: до яких даних він може отримати доступ, які інструменти може викликати, які дії повинні бути підтверджені співробітниками та як призупинити завдання у разі аномалій. Наглядові особи повинні мати реальні повноваження для втручання, достатньо часу та доступ до записів виконання.

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

На практиці ці 12 практик можна звести до чотирьох категорій результатів: принципи використання AI, затверджені радою директорів, постійно оновлюваний список застосувань та залежностей, оцінки та записи тестування для кожного важливого випадку використання, а також плани зупинки та відновлення в разі аномалій. Ці чотири категорії матеріалів взаємопов'язані. Список інформує керівництво про наявні проекти; оцінка визначає, які контролі є більш суворими; тестування підтверджує, чи є контролі ефективними; записи інцидентів знову сприяють змінам у правилах. Навіть невеликі установи можуть повторно використовувати вже існуючі процеси ризиків і закупівель, головне - забезпечити можливість відстеження відповідальності та доказів.

4. Це набір управлінських рекомендацій, реалізація яких залежить від юрисдикції

FSB позиціонує ці 12 практик як практичний інструмент, який можна адаптувати до ситуації установи. При застосуванні цієї рамки установи повинні порівнювати випадки використання AI з конкретними вимогами юрисдикції щодо захисту даних, прав споживачів, управління аутсорсингом, ризиками моделей або управління фінансовими установами.

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

З точки зору міжнародної політики, підхід FSB має ще одну цінність: різні юрисдикції можуть розглядати застосування AI фінансовими установами через схожі проблеми. Регулятори можуть не використовувати один і той же список, але всіх цікавитиме, хто несе ризики, як моделі працюють у ключових бізнесах, і чи постраждають клієнти у разі збоїв зовнішніх залежностей. Якщо установи можуть підготувати ці докази, їм буде легше пояснити свої контрольні заходи у відповідь на вимоги щодо захисту даних, прав споживачів та обережного регулювання в різних регіонах.

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