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

Я пам’ятаю засідання правління, де команда з кількох десятків людей пів року впроваджувала «розумну» систему, а на першому ж кейсі СЕО попросив пояснити просте: «Хто саме вирішив відхилити клієнта — людина чи машина?» Тиша тривала хвилину.

Що означає «система, яку ніхто не розуміє», у реальному бізнесі?

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

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

Чому це стало критично важливо саме зараз?

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

Наприклад, Національна комісія з цінних паперів та фондового ринку заявила про перегляд процедур випуску цінних паперів для спрощення доступу бізнесу до ринку капіталу НКЦПФР, 2026. Це не зменшує вимоги до доброчесності емітента — навпаки, піднімає планку до якості його внутрішніх процесів.

Паралельно держава переводить дозволи в електронну форму, як у випадку з лісогосподарськими документами з QR-кодами ЛІГА:ЗАКОН, 2026. Це означає: будь-яка аномалія у ваших даних буде помітна миттєво. Система, яку ніхто не розуміє всередині, у такому середовищі стає просто небезпечною.

Як автоматизація перетворюється на «чорну скриньку»?

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

У таких системах:

1. Ніхто не може пояснити, які саме правила зашиті в алгоритм.
2. Дані підтягнуті хаотично: щось із внутрішніх систем, щось з OSINT, частина — з пам’яті співробітника.
3. Не розділено технічне спрацювання і бізнес-рішення.

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

Якщо вам близька ця тема, окремо варто подивитися, що саме реально має сенс віддавати машині у фінмоніторингу: /blog/avtomatyzaciya-finansovogo-monitoryngu-shcho-spravdi-mozhna-viddaty-mashyni.

Які сигнали, що ви вже будуєте систему, яку ніхто не розуміє?

Є кілька типових ознак, які легко побачити навіть без глибокого аудиту:

1. Команда не може узгодити одну відповідь. На просте питання «чому ми відмовили цьому клієнту?» юрист, ризик-менеджер і керівник напрямку дають різні версії.
2. Люди бояться змінювати налаштування. Будь-яке втручання в систему сприймається як ризик «щось зламати», тож усі живуть із неідеальними правилами.
3. Документи існують окремо від практики. Те, що написано в політиці, не збігається з тим, що реально відбувається в системі і в рішеннях.
4. Немає короткої схеми ухвалення рішень. Щоб пояснити процес, вам потрібен довгий опис, а не одна-дві візуальні діаграми.

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

Швидкий чекліст: ви керуєте системою чи вона вами?

Використайте цей простий чекліст:

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

Якщо на щонайменше три питання відповідь «ні» або «не впевнена/ий» — це сигнал діяти.

Як AI і дані змінюють очікування регулятора та інвестора?

AI та аналітика зв’язків не скасовують відповідальності людини, але змінюють тип питань, які вам ставлять. Раніше запитували: «Чи була у вас політика?» Тепер запит стає тоншим: «Поясніть, як ваша система прийшла до цього рішення і хто це затвердив».

Навіть там, де закон прямо не згадує AI, дух регулювання рухається до прозорості процесів. Окремий закон про сек’юритизацію та облігації з покриттям ЛІГА:ЗАКОН, 2026 показує: увага зміщується від «чи є документ» до «як ви управляєте пулом активів і контролюєте операції».

Для інвестора це теж критично. Коли він дивиться на компанію, його цікавить не стільки декларативний рівень комплаєнсу, скільки те, як реально працюють процеси. Якщо вам це близько, логічне продовження — розмова про те, чому інвестор взагалі дивиться на процеси, а не на прибуток: /blog/chomu-investor-dyvyt-sya-na-procesy-a-ne-na-prybutok.

Як відокремити технічне спрацювання від бізнес-рішення?

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

Практично це означає:

1. Для кожного типу спрацювання чітко визначте, хто приймає фінальне рішення — роль, а не ПІБ.
2. Зафіксуйте мінімальний пакет даних, який людина має переглянути перед тим, як погодити або відхилити.
3. Розділіть у логах системи: коли спрацювало правило і коли хтось клікнув «approve/decline».

У протилежному випадку ви опиняєтесь у сірій зоні, де «система відмовила, але ніхто не відповідає». Це рівно той сценарій, який не витримує ні перевірки банку-кореспондента, ні уваги донора, ні ретельного due diligence.

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

Менше, але точніше. Проблема більшості «розумних» систем не в тому, що даних мало, а в тому, що ніхто не розуміє, які з них критичні для рішення.

Базовий підхід:

1. Ядро даних. Чітко визначте 5–10 полів, без яких рішення взагалі не приймається.
2. Надбудова. Додаткові джерела, що можуть змінити або підсилити базове рішення (OSINT, медіа, санкційні списки тощо).
3. Контекст. Короткий опис логіки: чому саме ці дані впливають на ризик.

Для роботизованих перевірок контрагентів, суден чи вантажів це особливо помітно. Технічно можна підтягнути десятки реєстрів, але на практиці краще мати чіткий фільтр і розуміти, як ви читаєте ланцюги власності й маршрути. Детальніше про це — у матеріалі про перевірку судна, вантажу й маршруту: /blog/yak-pereviryty-sudno-vantazh-i-marshrut-2.

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

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

Мінімальний пакет доказів для одного рішення

1. Вхідні дані. Що саме система і людина бачили на момент рішення (скрін, витяг, лог).
2. Правила/політика. Яке внутрішнє правило застосовувалося (посилання на документ, версію).
3. Лог дій. Хто і коли переглядав кейс, які коментарі залишав.
4. Фінальне формулювання. Коротка текстова причина: чому погодили/відмовили.

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

Чим відрізняється «розумна» система від просто складної?

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

Ось проста порівняльна таблиця.

Які ролі критично мати, щоб система не стала «чорною скринькою»?

Питання не лише в організаційній структурі, а в тому, хто реально виконує три ключові функції:

1. Архітектор процесу. Людина, яка розуміє і бізнес, і регуляторні вимоги, і може сформулювати логіку у вигляді правил.
2. Власник даних. Той, хто відповідає за якість даних, які потрапляють у систему, і за маршрути їхнього руху.
3. Оператор рішень. Люди, що щоденно працюють із системою, приймають фінальні рішення й залишають пояснення.

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

Як почати приводити вже існуючу систему до зрозумілого стану?

Найтиповіша ситуація: система вже є, гроші витрачені, «відкотити» неможливо. Тоді завдання — не зламати, а зробити зрозумілою. Логічний підхід — короткий рев’ю-проєкт з фокусом на пояснюваності.

Покроковий план мінімальної інвентаризації

1. Намалюйте карту рішень. Не систему, а саме рішення: які є типи кейсів і через які кроки вони проходять.
2. Зберіть приклади. По 3–5 реальних кейсів на кожен тип рішення: що було на вході, що зробила система, що зробила людина.
3. Порівняйте з політиками. Подивіться, де практика розходиться з документами — і чому.
4. Виділіть «чорні зони». Ті ділянки процесу, де ніхто не може чітко пояснити логіку.
5. Пріоритезуйте. Спочатку — зони з найбільшим регуляторним або фінансовим впливом.
6. Оновіть опис процесу. Перепишіть схеми й короткі гайдлайни під фактичну практику (або навпаки — практику під політику, якщо вона краща).

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

Як пов’язані AI, санкції, сек’юритизація і перевірки контрагентів?

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

Як тільки ви починаєте автоматизувати такі речі, ризик «чорної скриньки» зростає. Наприклад, системи аналітики зв’язків можуть будувати ланцюги власності в десятки компаній, але питання до вас буде дуже просте: «На підставі чого ви вирішили, що цей контрагент прийнятний/неприйнятний?» І відповідь «так показала система» тут не працюватиме.

Для більш глибокого погляду на те, чому прозорість структури власності стає окремою конкурентною перевагою, можна окремо прочитати: /blog/prozoriznist-struktury-vlasnosti-yak-konkurentna-perevaha.

FAQ

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

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

Наскільки детально потрібно документувати логіку системи?

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

Що робити, якщо система вже впроваджена, а логіки ніхто не пам’ятає?

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

Чи обов’язково мати окремого «власника даних» у структурі?

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

Як пояснити правлінню, що проблема не в «поганій системі», а в непрозорих процесах?

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

---

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