AI для виявлення шахрайства та аномалій у компанії

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

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

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

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

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

Модельний шар — це класифікатор, навчений на історії транзакцій, позначених як легітимні або шахрайські. Вхід: вектор ознак транзакції (сума, час, категорія, дані контрагента, історія рахунку). Вихід: ймовірність шахрайства (0-1) та категорія ризику. Моделі градієнтного бустінгу (XGBoost, LightGBM) та табличні нейронні мережі дають тут найкраще співвідношення ефективності до інтерпретованості.

Шар послідовної поведінки аналізує послідовність подій, а не окрему подію. Користувач, який протягом 20 хвилин увійшов з нового пристрою, змінив контактні дані, додав новий рахунок та ініціював переказ, створює шаблон високого ризику, навіть якщо кожен з цих кроків окремо є нижче порогу оповіщення. Моделі LSTM або Transformer для послідовностей подій є відповідним інструментом.

Агент, що координує, збирає сигнали з усіх шарів, запускає додаткові перевірки (запит до реєстру, пошук історії постачальника) та генерує уніфіковане оповіщення з контекстом, який аналітик бачить на дашборді.

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

Автоматична дія (без human-gate): позначення транзакції в системі як підозрілої, зниження денного ліміту, вимога додаткової авторизації при наступному вході. Зворотна протягом кількох секунд аналітиком або самим користувачем.

Дія, що вимагає human-gate: блокування рахунку, відхилення переказу, повідомлення регулятору, передача справи до відділу комплаєнсу. Незворотна або дорога для скасування. Тут завжди має бути людина, яка затверджує рішення.

Шаблон реалізації human-gate на практиці: оповіщення з оцінкою ризику вище 0,75 потрапляє до черги аналітика з повним контекстом (чому система оцінила ризик так високо, які ознаки вирішили, історія рахунку за останні 30 днів, подібні попередні справи). Аналітик затверджує або відхиляє в інтерфейсі з обов'язковим коментарем обґрунтування. Цей коментар потрапляє до аудит-логу.

Нижче наведена таблиця порівнює шари та їхні властивості:

Єдина чесна відправна точка: модель ML для виявлення шахрайств потребує історичних даних з позначками. Якщо організація раніше не мала системи відстеження, звідки взяти позитивні дані (підтверджені випадки шахрайств)?

Чотири підходи, які ми застосовуємо на практиці:

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

Зовнішні набори даних. Для фінансового сектору існують публічні набори даних про транзакції з позначеними шахрайствами (наприклад, IEEE-CIS Fraud Detection, PaySim). Хороша відправна точка для першої моделі, що вимагає подальшого налаштування на власних даних.

Синтетичні дані. Генератор синтетичних даних (CTGAN або спеціалізований симулятор бізнес-процесів) створює приклади шахрайської поведінки на основі експертних знань про шаблони шахрайств. Докладно цю тему розкриває стаття синтетичні дані для AI.

Active learning з аналітиками. Перші тижні роботи системи — це режим shadow: система генерує оповіщення, але не блокує. Аналітики переглядають оповіщення та позначають їх. Протягом 4-6 тижнів збираєш кількасот міток, які дозволяють навчити першу реальну модель.

Точність (accuracy) — це хибна метрика для виявлення шахрайств. При 0,5% шахрайств у наборі модель, яка завжди відповідає «не шахрайство», має точність 99,5% і є марною.

Правильні метрики:

Precision (точність): скільки з транзакцій, позначених системою як шахрайські, є справжніми шахрайствами. Низька точність = багато хибних тривог = аналітики витрачають час на перевірку чистих транзакцій, а система втрачає довіру.

Recall (повнота): скільки реальних шахрайств система виявила. Низька повнота = шахрайство проходить через систему непоміченим. Для виявлення шахрайств повнота зазвичай важливіша за точність, але обидві метрики повинні мати встановлені мінімуми.

F1-score та ROC-AUC як узагальнені показники. ROC-AUC вище 0,95 на тестовому наборі — це хороша відправна точка для продакшену.

Вартість помилки є остаточною бізнес-метрикою. Хибно позитивний результат (блокування легітимної транзакції) коштує: втрачена транзакція, обробка скарг, пошкодження відносин з клієнтом. Хибно негативний результат (невиявлене шахрайство) коштує: фінансові втрати, вартість розслідування, репутаційні ризики. Визнач цю вартість числово та налаштуй поріг класифікатора на мінімізацію загальної вартості, а не на максимізацію F1.

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

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

Ключові вимоги на практиці:

Правова підстава обробки. Для обробки даних з метою виявлення шахрайств підставою є законний інтерес адміністратора (ст. 6 п. 1 літ. f RODO) або юридичний обов'язок, що випливає з регуляцій AML (закон про протидію відмиванню грошей). Підстава має бути задокументована в реєстрі обробки даних.

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

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

DPIA. Для систем автоматизованого профілювання транзакцій з метою оцінки ризику DPIA є обов'язковою згідно зі ст. 35 RODO. DPIA має включати опис профілів ризику, оцінку наслідків для осіб, чиї дані обробляються, та заходи мінімізації ризику.

Self-hosting vs хмара. Моделі ML та тренувальні дані для виявлення шахрайств містять повну історію транзакцій організації. У багатьох секторах (банківська справа, страхування) регулятори вимагають, щоб дані не залишали контрольованого середовища. Self-hosting моделі та інфраструктури забезпечує повний контроль над data residency.

Системи AI для виявлення шахрайств у фінансовому та кредитному секторах прямо згадані в Додатку III AI Act як системи високого ризику (п. 5b: системи AI, що застосовуються для оцінки кредитоспроможності та кредитного рейтингу фізичних осіб). Це стосується як готових рішень, так і систем, створених для власних потреб, якщо організація виступає в ролі деплоєра або провайдера.

Обов'язки, що випливають з класифікації як системи високого ризику:

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

Прозорість рішень. Система повинна дозволяти пояснити, чому транзакція була позначена як ризикована. SHAP values або LIME для моделей градієнтного бустінгу, увага (attention) для послідовних моделей. Аналітик має розуміти, які ознаки вирішили. Питання пояснюваності розглядає стаття проблема чорної скриньки.

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

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

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

Alert rate (відсоток транзакцій, що генерують оповіщення) — моніториться щоденно. Раптовий стрибок — сигнал атаки або помилки системи. Раптове падіння — сигнал, що модель перестала виявляти новий шаблон.

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

Час від транзакції до оповіщення (latency). Зростання latency може означати перевантаження інфраструктури або збільшення обчислювальної складності при зростанні кількості ознак.

Показник ескалації до human-gate. Якщо зростає, аналітики перевантажені або пороги автоматичних дій занадто консервативні. Якщо знижується при стабільному alert rate, можлива проблема з калібруванням порогів.

Повну архітектуру моніторингу агентів описує стаття моніторинг якості агента AI.

Впровадження системи виявлення шахрайств не починається з моделі ML. Воно починається з інвентаризації даних та процесів.

Тиждень 1-2: інвентаризація. Які системи-джерела містять транзакційні дані? Як вони структуровані? Чи є історичні позначки шахрайств (хоча б скарги клієнтів, рішення відділу комплаєнсу)? Де знаходиться human-gate в поточному процесі?

Тиждень 3-4: shadow mode з правилами. Запусти спрощену систему правил у режимі shadow (логує оповіщення, не блокує). Збираєш дані про розподіл транзакцій, калібруєш пороги, перевіряєш, чи оповіщення взагалі потрапляють до потрібних людей.

Місяць 2: перша статистична модель. Навчи на зібраних історичних даних. Запускай у shadow mode поряд з правилами. Порівнюй оповіщення правил з оповіщеннями моделі. Аналітики позначають розбіжності.

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

Місяць 4+: цикл вдосконалення. Перенавчай модель на зібраних мітках. Додавай шари послідовностей, коли збереш достатньо історії. Розширюй автоматизацію лише для зворотних дій.

Повний план впровадження описує стаття план впровадження AI крок за кроком. Інструмент blueprint агента допомагає спроєктувати архітектуру потоку оповіщень.

Опиши свій сценарій виявлення шахрайств або аномалій, а модель підкаже, яку архітектуру застосувати, які метрики моніторити та що вимагається за RODO та AI Act у твоєму випадку (playground: PII маскуються, нульове зберігання):

Система правил та статистична система працюють з першого дня без тренувальних даних. Модель ML потребує історії транзакцій з щонайменше кількома сотнями підтверджених випадків шахрайств або хибних тривог. Якщо таких даних немає, перші 4-6 тижнів — це режим shadow: система логує оповіщення, аналітики позначають їх, лише після цього навчається модель. Синтетичні дані можуть прискорити цей старт, але вимагають валідації на реальних даних перед запуском у продакшен. Докладний опис підходів до стартових даних містить стаття як підготувати корпоративні дані для AI.

Системи AI, що застосовуються для профілювання або оцінки фінансового ризику фізичних осіб, згадані в Додатку III AI Act як високоризикові. Наслідок: потрібна технічна документація, обов'язок DPIA (оцінка впливу на захист даних), забезпечення пояснюваності рішень та активний моніторинг після впровадження. Організація, що впроваджує таку систему, також має забезпечити можливість оскарження рішення людиною. Це не теорія: інспекції відповідності AI Act у фінансовому секторі почалися в Польщі у 2026 році. Обов'язки за AI Act та RODO для компаній розглядає стаття AI Act та RODO 2026.

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

Виявлення шахрайств передбачає, що відома цільова категорія (шахрайство як мітка в тренувальних даних) і використовує контрольовані класифікатори. Виявлення аномалій не потребує міток: навчається розподілу нормальності та сигналізує про все, що від нього відхиляється. На практиці застосовують обидва підходи разом. Контрольований класифікатор виявляє відомі шаблони шахрайств. Некероване виявлення аномалій (autoencoders, isolation forest, DBSCAN на ембедінгах) виявляє невідомі шаблони, включаючи абсолютно нові типи атак. Шар агента, що координує, об'єднує сигнали з обох джерел. Архітектуру багатоетапних агентів описує стаття багатоетапний агент AI.

Вартість залежить від обсягу: чи інтегруємо з існуючою транзакційною системою (ERP, платіжна платформа), скільки джерел даних охоплюємо, чи потрібен self-hosting через регуляторні вимоги, і яка очікувана затримка оповіщення. Пілотний обсяг (shadow mode, один потік транзакцій, система правил та статистики) коштує інакше, ніж повна багатошарова архітектура з послідовною моделлю та дашбордом аналітика. Обсяг, який має сенс для твоєї організації, розрахуй через калькулятор ROI або зв'яжися з нами через контактну форму.