ШІ для виявлення аномалій у корпоративних даних: як це працює у 2026 році

Виробнича лінія фіксує перегрів датчика о 4:47 ранку. Оператор перевіряє і бачить, що температура зросла на 2 градуси протягом години. Стара порогова система не спрацювала, бо поріг був встановлений на відхилення у 8 градусів. Лише вранці, під час зміни, хтось помічає, що патерн почався дві доби тому, а машина вже працює на межі гарантійних параметрів.

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

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

Різниця конкретна. Транзакція на 47 000 злотих — це нормальний переказ для оптової бази і підозріла аномалія для рахунку, який протягом року оперував лише сумами до 3 000 злотих. Поріг на 50 000 злотих не виявить другий випадок. Контекстна модель виявить обидва.

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

Підхід ML будує класифікатор або ненаглядну модель (isolation forest, autoencoder, One-Class SVM). Наглядний класифікатор потребує позначених інцидентів з минулого. Ненаглядна модель вчиться розподілу нормальності без міток. На практиці використовують обидва шари: статистичний як перша лінія, ML виявляє патерни, які статистика не описує.

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

Хибна тривога (false positive) означає, що система сигналізує про аномалію, якої немає. Витрати: час аналітика, alert fatigue (оператори перестають сприймати сповіщення серйозно), можливе непотрібне зупинення процесу. У середовищах з великою кількістю сповіщень precision є ключовою метрикою.

Пропущений інцидент (false negative) означає, що аномалія існує, але система її не виявила. Витрати: фінансові втрати, пошкодження обладнання, інцидент безпеки, ескалація проблеми. У середовищах, де вартість пропуску висока (фінансове шахрайство, зупинка виробничої лінії, порушення безпеки), recall є ключовою метрикою.

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

Наведена нижче таблиця показує типові діапазони пропорцій для різних середовищ:

Цифри в таблиці — орієнтовні діапазони з впроваджень, не гарантовані результати для кожної організації.

Прапор без пояснення марний. «Система визнала цю транзакцію аномальною» — це не інформація. «Сума на 4,2 стандартних відхилення вища за 90-денну історію для цього контрагента, а час (2:13 ночі) не зустрічався жодного разу за останні 180 днів» — це інформація, на основі якої людина може прийняти рішення.

Explainability у системах аномалій залежить від архітектури. Для статистичних моделей пояснення є нативним: який вимір відхиляється і на скільки стандартних відхилень. Isolation forest вказує ознаки, які скоротили шлях ізоляції. SHAP values для моделей gradient boosting показують внесок кожної ознаки. Autoencodery вказують виміри з найбільшою помилкою реконструкції.

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

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

Мінімальні заходи проти дрейфу: alert rate, що моніториться щотижня (раптове зростання без підтверджених інцидентів — сигнал дрейфу; раптове зниження — сигнал, що модель не виявляє нові патерни), recall на золотому тестовому наборі, що перевіряється щоквартально (зниження більше ніж на 10 п.п. — сигнал для перевчання), інкрементальне вікно навчання для швидкозмінних середовищ. Архітектуру observability для систем ШІ розглядає стаття моніторинг якості агента AI.

Кожне рішення про перевчання вимагає затвердження людиною. Re-training змінює те, що система вважає нормальним, а отже, змінює, що ескалується до аналітика.

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

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

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

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

Цей самий патерн застосовуємо до фінансових рішень у статті ШІ для виявлення шахрайства. Архітектуру даних описує стаття governance даних для ШІ.

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

Structured output з моделі аномалій має містити: ідентифікатор події, результат аномалії (float 0-1), ознаки, що визначили результат з вагами, історичне вікно, використане для калібрування, та поле для коментаря аналітика. Стандартизація цього формату дозволяє інтегрувати результати різних моделей в одному аналітичному інтерфейсі. Підготовку вхідних даних описує стаття ШІ для аналізу даних і BI, а аспекти відповідності RODO розглядає стаття ШІ для контролінгу та фінансів.

Статистична модель і порогові правила працюють з першого дня: збираєте дані 2-4 тижні, будуєте базову статистику розподілу і починаєте фіксувати відхилення. Модель ML потребує історії, а якщо є позначені інциденти (дати простоїв, звернення до сервісу, підтверджені випадки шахрайства), їх можна використати як слабкі мітки для першого тренування. Без міток старт відбувається в ненаглядному режимі: isolation forest або autoencoder на історичних даних, з ручною перевіркою перших сповіщень аналітиком протягом 4-8 тижнів.

Модель має враховувати сезонність як частину розподілу нормальності. Для щоденних даних це означає сезонні корекції для днів тижня та місяців. Prophet і ARIMA мають вбудовані компоненти сезонності. Для моделей ML ознака «день тижня» має бути вхідною для моделі, інакше кожне понеділкове зростання продажів стане аномалією в середовищі, де неділі мають низький трафік. Аналітик має мати можливість позначити подію як «структурна зміна», що оновлює базу нормальності системи.

Залежить від контексту. Система, що моніторить технічні дані (датчики, логи IT), зазвичай є системою низького ризику. Система, що оцінює фінансову поведінку або кредитоспроможність фізичних осіб, згадується в Додатку III AI Act як система високого ризику, що означає обов’язок проведення DPIA, технічної документації, пояснюваності рішень та активного моніторингу після впровадження. В обох випадках лог рішень аналітика (хто затвердив яку дію, коли, з яким обґрунтуванням) є хорошою практикою незалежно від класифікації ризику.

Це питання потрібно поставити перед впровадженням, а не після. Практична межа для аналітика, що працює зі сповіщеннями про аномалії, — 20-50 сповіщень на день при повному розслідуванні кожного. При більшій кількості сповіщень потрібна автоматична пріоритизація: сповіщення з результатом аномалії вище 0,85 та комбінацією кількох сигналів отримують пріоритет P1, решта — P2 або P3 з довшим часовим вікном для відповіді. Якщо система генерує 500 сповіщень на день при потужності 30 сповіщень, проблема не в алгоритмі, а в калібруванні порогу чутливості.

Золотий тестовий набір з підтверджених історичних інцидентів — єдиний надійний метод. Запускаєте модель на подіях, які аналітики підтвердили як реальні інциденти, і перевіряєте recall: скільки з них модель виявила б до фактичного вирішення. Якщо немає історичних міток, перші 60-90 днів — це фаза shadow mode: система логує сповіщення, аналітики їх верифікують і будують набір з нуля. Без цього набору немає надійної відповіді на питання про ефективність. Патерн оцінки описує стаття моніторинг якості агента AI.