Відділ KYC у фінтех-компанії обробляє п’ять тисяч онбордингів на місяць. Кожен клієнт надсилає посвідчення особи, підтвердження адреси та виписку з банку в різних форматах, з різною якістю скану, іноді фото з телефону під незручним кутом. Хтось все це відкриває, перевіряє, переписує дані в систему CRM і вирішує, чи достатньо чіткий документ, щоб продовжити. При п’яти тисячах справ на місяць це десятки робочих годин самого переписування. І саме тут ШІ має вимірюваний сенс. Проблема починається, коли хтось обіцяє «повністю автоматичний KYC без людини» або «AML, який сам блокує рахунки». Це інша розмова, що торкається прав споживача, RODO та AI Act. Нижче розділяємо одне від іншого, без обіцянок, яких у регульованому секторі неможливо дотриматися.
KYC та онбординг: екстракція документів без ручної роботи
#Перша сфера, яка дає реальний результат, — це перетворення документів, що посвідчують особу, довідок про адресу та виписок з банку на структуровані записи. OCR зчитує текст із зображення, а мовна модель витягує конкретні поля: ім’я та прізвище, номер документа, дату народження, адресу, номер IBAN.
На чистих, стандартних документах (посвідчення особи з сучасним макетом, банківська виписка) добре налаштований пайплайн екстракції даних досягає точності понад 90% на рівні полів. На фото з телефону, старих документах з неоднорідним макетом чи закордонних документах точність знижується і буває важко передбачуваною без тестування на репрезентативній вибірці реальних документів. Тому не припускається, що зчитана дата народження завжди правильна: для полів, що впливають на подальший процес, людина підтверджує, а система показує фрагмент документа, з якого взято значення.
| Тип документа | Що витягує ШІ | Очікувана точність полів | Роль людини |
|---|---|---|---|
| Посвідчення особи / паспорт PL | Ім’я, прізвище, PESEL, термін дії | Висока (зазвичай понад 90%) | Підтверджує дані для онбордингу |
| Довідка про адресу / рахунок | Адреса, дата документа | Висока на типових бланках | Перевіряє адресу щодо заявленої |
| Виписка з банку | IBAN, баланс, історія оборотів | Середня, залежить від банку та формату | Підтверджує відповідність заявці |
| Закордонний / рукописний документ | Спроба зчитування ключових полів | Низька та мінлива | Перевіряє вручну спірні поля |
Як забезпечити якість і структуру вихідних даних, щоб пайплайн мав із чого працювати, описано в governance даних для ШІ. Екстракцію даних з документів в інших контекстах розглядає ШІ для аналізу документів.
AML: моніторинг транзакцій та позначення аномалій
#Протидія відмиванню грошей — це сфера, в якій ШІ робить реальну різницю порівняно з суто регламентними системами. Регламентна модель вимагає, щоб хтось заздалегідь знав, якого порогу шукати. Модель аномалій навчається розподілу норми та сигналізує відхилення, перш ніж хтось встигне встановити правило.
Архітектура, яку ми застосовуємо, працює шарами. Регламентний шар виявляє прості перевищення (сума вище ліміту, країна поза білим списком). Статистичний шар виявляє розсіювання багатьох дрібних транзакцій, спеціально спроєктованих нижче порогу. Модельний шар, заснований на класифікаторі, навченому на історії транзакцій, оцінює ймовірність підозрілої активності та генерує сигнал ризику з поясненням, які ознаки зіграли роль. Детальну багатошарову архітектуру, разом із питанням холодного старту, описує ШІ для виявлення шахрайства та аномалій.
Тут потрібно чітко сказати те, про що в багатьох презентаціях мовчать: показник хибних спрацьовувань (false positive rate) в AML — це реальні операційні витрати. Аналітики compliance витрачають час на перевірку сповіщень, які виявляються чистими транзакціями. Типові системи AML ML досягають precision на рівні 20-40%, що означає, що 60-80% сповіщень — це хибні спрацьовування, які потребують ручного відхилення. Це все одно краща ситуація, ніж суто регламентні системи, які генерують ще більше хибних спрацьовувань, але не слід замовчувати це при проєктуванні штату аналітиків.
Нерушима межа: повідомлення фінансовому органу (звіт STR/SAR), закриття рахунку та відмова в транзакції — це незворотні дії, які потребують рішення людини з повним обґрунтуванням у лозі аудиту.
Credit risk: скоринг як підтримка, а не вирок
#Оцінка кредитоспроможності — це, мабуть, найбільш регульована сфера застосування ШІ у фінансах. ШІ може тут розрахувати скоринг, зіставити сигнали ризику та підготувати обґрунтування для аналітика. Але не може самостійно відмовити у кредиті фізичній особі без можливості втручання людини.
Причина як правова, так і практична. Правова: автоматичні рішення, що тягнуть за собою правові наслідки для фізичної особи, вимагають права на втручання людини згідно зі ст. 22 RODO. Практична: модель, навчена на історичних даних, може закріплювати дискримінаційні патерни, якщо історичні рішення були упередженими (наприклад, вищий відсоток відмов для певних демографічних груп чи регіонів).
Пояснюваність рішень — це вимога, а не опція зручності. Аналітик, який схвалює або відхиляє заявку, повинен розуміти, які сигнали вплинули на скоринг угору чи вниз: SHAP values для моделей gradient boosting дозволяють показати внесок кожної ознаки в оцінку. Це також вимога AI Act для систем високого ризику, а системи оцінки кредитоспроможності фізичних осіб прямо згадані в Додатку III.
DPIA (оцінка впливу на захист даних) є обов’язковою при впровадженні автоматизованого профілювання з метою кредитування, перш ніж щось потрапить у продакшн. Шаблон governance даних, який ми застосовуємо для таких систем, детально описує governance даних для ШІ.
Обслуговування клієнтів та банківський асистент
Четверта сфера — це обробка запитів клієнтів: статус заявки, необхідні документи, умови продукту, процедури скарг. Асистент, заснований на знаннях з регламентів, тарифів оплат та FAQ, звільняє консультантів від повторюваних запитів.
Принципи, яких ми не обходимо в цьому контексті: асистент має бути ґрунтованим на реальних документах установи, бо модель без цієї прив’язки може вигадати умову договору, якої немає. У момент, коли запитання стосується індивідуального фінансового рішення, скарги з елементом юридичної відповідальності чи блокування рахунку, асистент передає справу людині. Нагляд людини тут — це і регуляторна вимога, і питання довіри клієнта до установи.
Архітектура цього асистента базується на тих самих принципах, що й системи, описані в ШІ для страхування: екстракція знань з документів, guardrails, що блокують імпровізацію, human-handoff у чутливих питаннях.
AI Act, RODO та де проходять межі
#Банківництво та фінтех — це сектори, в яких регуляції чітко вказують, які застосування ШІ є високоризиковими. Системи оцінки кредитоспроможності та кредитного рейтингу фізичних осіб прямо згадані в Додатку III AI Act (п. 5b). Системи AML, якщо впливають на доступ до фінансових послуг, можуть підпадати під ту саму класифікацію. Класифікацію варто підтвердити для конкретного застосування з юристом, перш ніж щось потрапить у продакшн.
Практичні наслідки класифікації як високий ризик:
- Технічна документація включає опис моделі, джерела даних для навчання, метрики якості, відомі обмеження та процедури перенавчання. Має оновлюватися при кожній суттєвій зміні моделі.
- Пояснюваність рішень. Кожне рішення з негативними наслідками для клієнта має бути пояснюваним: які сигнали зіграли роль, як клієнт може оскаржити.
- Human-gate як технічна вимога, а не лише процедурна. Система має забезпечувати можливість втручання людини, а не лише декларувати її в документах.
- Моніторинг після впровадження. AI Act вимагає активного відстеження якості системи на продуктивних даних та документованих процедур при виявленій деградації.
RODO та захист персональних даних (PII) — це окремий шар вимог: транзакційні дані та документи, що посвідчують особу, є персональними даними, які потребують правової основи обробки, мінімізації, терміну зберігання (TTL) та договору доручення при зовнішніх моделях. Обов’язки, що випливають з AI Act та RODO для компаній, які впроваджують системи ШІ, описує стаття AI Act та RODO 2026.
Як розпочати розумно
Точка входу, яку ми бачимо як найкраще збалансовану для регульованого фінансового сектору: одна вузька проблема з вимірюваними витратами та низьким регуляторним ризиком. Зазвичай це екстракція даних з одного типу документів KYC або маршрутизація запитів клієнтів до відповідної черги обслуговування. Не починаємо з credit risk чи AML як першого проєкту.
Потім пілот поруч із поточним процесом у режимі shadow: ШІ готує та типізує, людина все одно вирішує, а ми вимірюємо реальну точність на вибірці реальних документів, перш ніж щось почне працювати самостійно. Лише коли цифри відомі та прийняті, поступове розширення з збереженням human-gate скрізь, де йдеться про рішення щодо грошей або доступу до послуги клієнта.
FAQ
#Чи може ШІ самостійно приймати кредитні рішення без участі людини?
Не рекомендуємо цього, і в багатьох випадках закон це забороняє. Ст. 22 RODO надає фізичній особі право на те, щоб рішення, яке тягне за собою правові наслідки щодо неї, не приймалося виключно автоматично. Системи оцінки кредитоспроможності є системами високого ризику згідно з AI Act, з обов’язком нагляду людини та пояснюваності. ШІ розраховує скоринг і готує обґрунтування, аналітик приймає остаточне рішення.
Наскільки точний ШІ для екстракції даних з документів KYC?
#Це залежить від якості та стандартизації документів. На чистих, польських документах, що посвідчують особу, добре налаштований пайплайн екстракції даних зазвичай досягає точності понад 90% на рівні полів. На фото з телефону, закордонних документах чи старих макетах точність знижується, тому поля, що впливають на подальший процес, завжди підтверджує людина, а система показує вихідний фрагмент документа.
Який рівень хибних спрацьовувань у системах AML?
#Системи AML на основі ML зазвичай досягають precision у діапазоні 20-40%, що означає, що 60-80% сповіщень — це хибні спрацьовування, які потребують ручної перевірки аналітиком. Це все одно краща ситуація, ніж суто регламентні системи, але вимагає відповідного штату аналітиків та пріоритизації сповіщень. Пороги класифікатора підбираються для мінімізації сукупних операційних витрат, а не для максимізації чутливості.
Чи підпадають системи AML або credit risk під дію AI Act?
#Системи оцінки кредитоспроможності фізичних осіб прямо згадані в Додатку III AI Act як системи високого ризику. Системи AML, що впливають на доступ до фінансових послуг, можуть підпадати під ту саму класифікацію. Обов’язки включають технічну документацію, DPIA, пояснюваність рішень, активний моніторинг та можливість оскарження рішення людиною.
Чи можуть банківські дані та KYC залишатися в інфраструктурі компанії і не потрапляти до зовнішньої моделі?
#Так, це проєктне рішення, а не технічна необхідність. Дані, що посвідчують особу, та транзакційні дані можуть оброблятися моделями, запущеними локально (self-hosting), або у постачальника з гарантією обробки в ЄС та договором доручення згідно зі ст. 28 RODO. У регульованому фінансовому секторі варто прийняти це рішення свідомо на самому початку проєкту, бо воно визначає всю архітектуру та обсяг DPIA.