Пояснюваність моделі: чому регулятор питає «чому саме так»

Ви впровадили систему скорингу ризиків, яка за секунди сортує тисячі контрагентів і транзакцій. Регулятор або банк ставить одне просте запитання: чому саме цю компанію модель позначила як ризикову? І раптом виявляється, що прямої відповіді у вас немає.

Чому регулятор питає «чому саме так»?

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

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

Що таке пояснюваність моделі і чим вона відрізняється від точності?

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

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

Як зміна методики оцінки ризику показує проблему пояснюваності на практиці?

Показовий приклад — зміна підходу до розрахунку ступеня ризику в лотерейній сфері, про яку писала ЛІГА:ЗАКОН у вересні 2026 року. Попередня модель вимагала одночасного збігу чотирьох ознак ризику, тому оператор із системними порушеннями, але капіталом понад 130 млн грн у високий ризик не потрапляв ніколи — формула технічно працювала, але результат суперечив здоровому глузду (ЛІГА:ЗАКОН, 2026).

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

Ця ж логіка стосується визначення контролю над компанією: формальна частка власності часто не показує, хто реально ухвалює рішення, і саме тому регулятори наполягають на аналізі механізмів контролю, а не лише цифри в реєстрі (ЛІГА:ЗАКОН, 2026). Про це детальніше — у матеріалі «Прозорість структури власності як конкурентна перевага».

Чим небезпечна «чорна скринька» у фінансовому секторі?

Небезпека «чорної скриньки» — не гіпотетична: коли внутрішні перевірки обходять або ігнорують, бо процедура стає перешкодою для швидкого рішення, результат виявляється роками пізніше і коштує репутації всієй установі. Розслідування ICIJ China Capital на основі 4,8 млн внутрішніх документів показало, як лондонський підрозділ Industrial and Commercial Bank of China оперативно провів операцію на суму понад 1 млрд доларів для Huawei, обійшовши внутрішні механізми контролю буквально за кілька днів після оголошення звинувачень у США (ICIJ, 2026).

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

Хто відповідає, коли рішення ухвалила модель?

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

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

Як перевірити, чи модель компанії пройде питання «чому саме так»?

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

1. Зафіксуйте, які саме дані й параметри впливають на висновок моделі, і хто має доступ до цього переліку.
2. Перевірте, чи існує аудиторський слід для кожного автоматизованого рішення за останні дванадцять місяців.
3. Виберіть кілька випадків навмання і спробуйте пояснити результат моделі людині, яка не брала участі в її розробці.
4. Визначте, хто конкретно має право скасувати або переглянути автоматизоване рішення до того, як воно вплине на клієнта.
5. Задокументуйте, як часто модель переглядається і хто відповідає за оновлення логіки.
6. Порівняйте формальні критерії моделі з реальними випадками, які вона мала б вловити, але не вловила — саме тут зазвичай і ховається розрив.

Цей самий підхід застосовний і до перевірки контрагентів: формальний скоринг за відкритими реєстрами часто пропускає ризики, які видно лише при глибшому аналізі, про що йде мова в матеріалі «Юридичний комплаєнс без сліпих зон».

Модель для галочки чи пояснювана модель — як відрізнити

Ця таблиця не про технології — вона про те, чи витримає компанія момент, коли хтось поставить друге питання після першого «так, модель це визначила».

FAQ

Чи стосується пояснюваність моделі тільки великих компаній з дорогим AI?

Ні, вона стосується будь-якої компанії, яка використовує автоматизовані правила для оцінки ризику — навіть просту таблицю з балами й пороговими значеннями. Складність технології не має значення, значення має здатність пояснити конкретний результат.

Чим пояснюваність відрізняється від прозорості коду?

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

Що робити, якщо модель уже впроваджена, а пояснити її логіку складно?

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

Чи достатньо мати політику про AI, щоб закрити питання регулятора?

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

Чи інвестор або донор теж може поставити це питання?

Так, і дедалі частіше саме так формулює запит про доброчесність процесів — не просто «чи є у вас процедура», а «чи можете ви пояснити конкретне рішення». Більше про це — в матеріалі «Чому інвестор дивиться на процеси, а не на прибуток».

Як пояснюваність пов'язана з оцінкою ризику контрагентів?

Якщо модель оцінки ризику контрагента непояснювана, вона не витримує тиску воєнної економіки, де ланцюги власності й ризики змінюються швидше, ніж оновлюється формула. Детальніше — у статті «Ризики контрагентів у воєнній економіці».

Автоматизація не звільняє від відповідальності — вона лише переносить момент, коли доведеться пояснювати рішення, з моменту ухвалення на момент перевірки. Компанії, яка вже зараз може показати логіку своїх автоматизованих рішень, не потрібно готуватися до цього питання окремо — воно вже має відповідь.