AI do wykrywania oszustw i anomalii w firmie

Firma wykrywa nieprawidłowość w zestawieniu finansowym dwa miesiące po tym, jak się wydarzyła. Przez osiem tygodni transakcje wyglądały normalnie w cotygodniowych raportach, bo raport porównuje miesiąc do miesiąca i nie śledzi wzorców behawioralnych w czasie rzeczywistym. To scenariusz, który powtarza się w działach finansowych, operacjach zakupowych i systemach płatności: anomalia istnieje w danych, ale żaden reguła progowa jej nie łapie.

AI do wykrywania oszustw działa inaczej niż lista reguł. Uczy się wzorca normalności i zgłasza odchylenie, zanim przekroczy próg, który człowiek zdążyłby ustawić. Poniżej opisuję architekturę takiego systemu, jakie metryki mierzyć, gdzie leżą granice automatyzacji i co narzuca prawo.

Dojrzały system wykrywania oszustw działa w kilku warstwach, z których każda wyłapuje inny typ odchylenia.

Warstwa regułowa to nadal pierwsza linia. Reguły typowe: kwota przekraczająca limit autoryzacji, transakcja z kraju poza białą listą, numer rachunku z listy bloków. Reguły są deterministyczne, szybkie i audytowalne. Problem: atakujący, którzy znają reguły, dostosowują działania dokładnie poniżej progów.

Warstwa statystyczna liczy odchylenie od średniej wartości transakcji dla danego konta, częstotliwość działań w oknie czasowym, odchylenie od typowego godzinowego rozkładu aktywności. Wykrywa rozsypanie wielu małych transakcji celowo zaprojektowanych, żeby nie trafić w regułę progową.

Warstwa modelowa to klasyfikator wytrenowany na historii transakcji oznaczonych jako prawidłowe lub fraudowe. Wejście: wektor cech transakcji (kwota, czas, kategoria, dane kontrahenta, historia konta). Wyjście: prawdopodobieństwo oszustwa (0-1) i kategoria ryzyka. Modele gradient boosting (XGBoost, LightGBM) i sieci neuronowe tabularyczne dają tutaj najlepszy stosunek skuteczności do interpretowalności.

Warstwa zachowań sekwencyjnych analizuje ciąg zdarzeń, a nie pojedyncze zdarzenie. Użytkownik, który w ciągu 20 minut zalogował się z nowego urządzenia, zmienił dane kontaktowe, dodał nowy rachunek i zainicjował przelew, tworzy wzorzec wysokiego ryzyka, nawet jeśli każdy z tych kroków osobno jest poniżej progu alertu. Modele LSTM lub Transformer na sekwencjach zdarzeń są właściwym narzędziem.

Agent koordynujący zbiera sygnały ze wszystkich warstw, uruchamia dodatkowe sprawdzenia (zapytanie do rejestru, lookup historii dostawcy) i produkuje ujednolicony alert z kontekstem, który analityk widzi na dashboardzie.

Kluczowy wzorzec projektowy dla systemu fraud detection to rozdzielenie akcji odwracalnych od nieodwracalnych.

Akcja automatyczna (bez human-gate): flag transakcji w systemie jako podejrzanej, obniżenie limitu dziennego, wymuszenie dodatkowej autoryzacji przy kolejnym logowaniu. Odwracalne w kilka sekund przez analityka lub samego użytkownika.

Akcja wymagająca human-gate: zablokowanie konta, odrzucenie przelewu, zgłoszenie do regulatora, przekazanie sprawy do działu compliance. Nieodwracalna lub kosztowna do cofnięcia. Tu zawsze musi być człowiek zatwierdzający decyzję.

Wzorzec implementacji human-gate w praktyce: alert z oceną ryzyka powyżej 0,75 trafia do kolejki analityka z pełnym kontekstem (dlaczego system ocenił ryzyko tak wysoko, które cechy zadecydowały, historia konta za ostatnie 30 dni, podobne poprzednie sprawy). Analityk zatwierdza lub odrzuca w interfejsie z wymuszonym komentarzem uzasadnienia. To komentarz trafia do logu audytowego.

Poniższa tabela zestawia warstwy i ich właściwości:

Jedyny uczciwy punkt: model ML do wykrywania fraudów potrzebuje danych historycznych z oznaczeniami. Jeśli organizacja nie miała wcześniej systemu śledzącego, skąd wziąć dane pozytywne (zweryfikowane przypadki oszustw)?

Cztery podejścia, które stosujemy w praktyce:

Reguły jako generator etykiet. Uruchamiasz stary system regułowy na danych historycznych i traktujesz jego wyniki jako słabe etykiety. Model uczy się wzorców, które reguły już łapały, plus anomalie w sąsiedztwie tych wzorców.

Zewnętrzne zbiory danych. Dla sektora finansowego istnieją zbiornicze zbiory danych o transakcjach z oznaczonymi fraudami (np. IEEE-CIS Fraud Detection, PaySim). Dobry punkt startowy dla pierwszego modelu, wymagający późniejszego dostrojenia na własnych danych.

Dane syntetyczne. Generator danych syntetycznych (CTGAN lub dedykowany symulator procesów biznesowych) produkuje przykłady zachowań fraudowych na podstawie eksperckiej wiedzy o wzorcach oszustw. Szczegółowo ten temat opisuje artykuł dane syntetyczne do AI.

Active learning z analitykami. Pierwsze tygodnie działania systemu to tryb shadow: system generuje alerty, ale nie blokuje. Analitycy przeglądają alerty i etykietują. W ciągu 4-6 tygodni zbierasz kilkaset oznaczeń, które pozwalają wytrenować pierwszy rzeczywisty model.

Dokładność (accuracy) to błędna metryka dla fraud detection. Przy 0,5% fraudów w zbiorze model, który zawsze odpowiada „nie fraud", ma dokładność 99,5% i jest bezużyteczny.

Właściwe metryki:

Precision (precyzja): ile z transakcji oznaczonych przez system jako fraud to rzeczywiście fraud. Niska precyzja = dużo fałszywych alarmów = analitycy tracą czas na sprawdzanie czystych transakcji, a system traci wiarygodność.

Recall (czułość): ile rzeczywistych fraudów system wykrył. Niska czułość = fraud przechodzi przez system niezauważony. Dla fraud detection recall jest zazwyczaj ważniejszy od precyzji, ale obydwie metryki muszą mieć ustalone minima.

F1-score i ROC-AUC jako zbiorcze wskaźniki. ROC-AUC powyżej 0,95 na zbiorze testowym to dobry punkt wyjścia dla produkcji.

Koszt błędu jest ostateczną metryką biznesową. Fałszywie pozytywny wynik (zablokowanie legalnej transakcji) kosztuje: utracona transakcja, obsługa reklamacji, uszkodzenie relacji z klientem. Fałszywie negatywny wynik (niewychwycony fraud) kosztuje: strata finansowa, koszt postępowania, ryzyko reputacyjne. Zdefiniuj ten koszt numerycznie i dostosuj próg klasyfikatora pod minimalizację łącznego kosztu, a nie pod maksymalizację F1.

Czas reakcji na alert to metryka operacyjna: ile czasu upływa od generowania alertu do decyzji analityka. Kolejka alarmów, która rośnie wolniej niż jest przetwarzana, jest sygnałem problemów z obsadą lub priorytetyzacją.

Systemy fraud detection przetwarzają dane, które niemal zawsze są danymi osobowymi: numery kont, historia transakcji, lokalizacja, identyfikatory urządzeń. Każda z tych kategorii podlega RODO.

Kluczowe wymagania w praktyce:

Podstawa prawna przetwarzania. Dla przetwarzania danych w celu wykrywania fraudów podstawą jest uzasadniony interes administratora (art. 6 ust. 1 lit. f RODO) lub obowiązek prawny wynikający z regulacji AML (ustawa o przeciwdziałaniu praniu pieniędzy). Podstawa musi być udokumentowana w rejestrze czynności przetwarzania.

Minimalizacja danych. Model nie potrzebuje imienia i nazwiska klienta do oceny ryzyka transakcji. Pracuj na pseudonimizowanych identyfikatorach wewnętrznych wszędzie tam, gdzie pełna identyfikacja nie jest wymagana na danym etapie. Dane identyfikacyjne są dołączane dopiero przy potwierdzonym alercie wymagającym działania.

Retencja. Dane treningowe, logi alertów i decyzje analityków mają różne czasy retencji. Dane treningowe bez PII mogą być przechowywane długo. Logi z pełnymi danymi transakcji podlegają TTL zgodnie z polityką RODO i regulacjami sektorowymi.

DPIA. Dla systemów zautomatyzowanego profilowania transakcji w celach oceny ryzyka DPIA jest wymagana przez art. 35 RODO. DPIA musi obejmować opis profili ryzyka, ocenę skutków dla osób, których dane dotyczą, i środki minimalizacji ryzyka.

Self-hosting a chmura. Modele ML i dane treningowe dla fraud detection zawierają pełną historię transakcji organizacji. W wielu sektorach (bankowość, ubezpieczenia) regulatorzy wymagają, żeby dane nie opuszczały kontrolowanego środowiska. Self-hosting modelu i infrastruktury daje pełną kontrolę nad data residency.

Systemy AI do wykrywania fraudów w sektorze finansowym i kredytowym są wprost wymienione w Załączniku III AI Act jako systemy wysokiego ryzyka (pkt 5b: systemy AI stosowane do oceny wiarygodności kredytowej i zdolności kredytowej osób fizycznych). Dotyczy to zarówno gotowych rozwiązań, jak i systemów budowanych na własne potrzeby, jeśli organizacja pełni rolę deployera lub providera.

Obowiązki wynikające z klasyfikacji jako system wysokiego ryzyka:

Dokumentacja techniczna obejmuje opis modelu, dane treningowe (źródła, zakres, procedury anonimizacji), metryki jakości na zbiorze testowym, ograniczenia i znane błędy. Musi być aktualizowana przy każdej istotnej zmianie modelu.

Przejrzystość decyzji. System musi umożliwiać wyjaśnienie, dlaczego transakcja została oznaczona jako ryzykowna. SHAP values lub LIME dla modeli gradient boosting, uwaga (attention) dla modeli sekwencyjnych. Analityk musi rozumieć, które cechy zadecydowały. Wyjaśnialność omawia artykuł problem czarnej skrzynki.

Human-oversight jako wymóg, nie opcja. Dla decyzji o negatywnych skutkach dla osoby fizycznej (blokada konta, odmowa transakcji, eskalacja do organów ścigania) prawo wymaga możliwości zakwestionowania decyzji przez człowieka i jej przeglądu. System musi to umożliwiać technicznie, nie tylko proceduralnie.

Monitorowanie po wdrożeniu. AI Act wymaga aktywnego monitorowania skuteczności systemu na danych produkcyjnych. Oznacza to regularne uruchamianie testów jakości, dokumentowanie degradacji i posiadanie procedury odpowiedzi na wykrytą degradację.

System fraud detection bez monitoringu degraduje się cicho. Wzorzec zachowania frauderów ewoluuje: model trenowany na danych sprzed roku może nie rozpoznawać nowych wzorców. Minimalne metryki produkcyjne:

Alert rate (procent transakcji generujących alert) monitorowany dziennie. Nagły skok to sygnał ataku lub błędu systemu. Nagły spadek to sygnał, że model przestał wykrywać nowy wzorzec.

Precision na potwierdzonych alertach (analitycy oznaczają alerty jako prawdziwy fraud lub fałszywy alarm). Spadek precyzji przez dwa kolejne tygodnie to sygnał dryfu modelu wymagający retrainingu.

Czas od transakcji do alertu (latency). Wzrost latency może oznaczać przeciążenie infrastruktury lub wzrost złożoności obliczeniowej przy rosnącej liczbie cech.

Wskaźnik eskalacji do human-gate. Jeśli rośnie, analitycy są przeciążeni lub progi automatycznych akcji są zbyt konserwatywne. Jeśli maleje przy stabilnym alert rate, możliwy problem z kalibracją progów.

Kompletną architekturę monitorowania agentów opisuje artykuł monitoring jakości agenta AI.

Wdrożenie systemu fraud detection nie zaczyna się od modelu ML. Zaczyna się od inwentaryzacji danych i procesów.

Tydzień 1-2: inwentaryzacja. Jakie systemy źródłowe mają dane transakcyjne? Jak są ustrukturyzowane? Czy są historyczne oznaczenia fraudów (choćby reklamacje klientów, decyzje działu compliance)? Gdzie leży human-gate w obecnym procesie?

Tydzień 3-4: shadow mode z regułami. Uruchom uproszczony system regułowy w trybie shadow (loguje alerty, nie blokuje). Zbierasz dane o rozkładzie transakcji, kalibrujesz progi, weryfikujesz, czy alerty w ogóle trafiają do właściwych ludzi.

Miesiąc 2: pierwszy model statystyczny. Trenuj na zebranych danych historycznych. Uruchamiaj w shadow mode obok reguł. Porównuj alerty reguł z alertami modelu. Analitycy etykietują rozbieżności.

Miesiąc 3: uruchomienie z human-gate. Model generuje alerty, reguły mogą blokować automatycznie, wszystko powyżej ustalonego progu ryzyka trafia do kolejki analityka. Mierzysz metryki tygodniowo.

Miesiąc 4+: cykl doskonalenia. Retrenuj model na zebranych etykietach. Dodawaj warstwy sekwencyjne, gdy zbierzesz wystarczającą historię. Rozszerzaj automatyzację tylko dla akcji odwracalnych.

Pełny plan wdrożeniowy opisuje artykuł plan wdrożenia AI krok po kroku. Narzędzie blueprint agenta pomaga zaprojektować architekturę przepływu alertów.

Opisz swój scenariusz fraud detection lub anomalii, a model wskaże, jaką architekturę zastosować, jakie metryki monitorować i co jest wymagane przez RODO i AI Act w Twoim przypadku (playground: PII maskowane, zero retencji):

System regułowy i statystyczny działa od pierwszego dnia bez danych treningowych. Model ML potrzebuje historii transakcji z co najmniej kilkoma setkami potwierdzonych przypadków fraudów lub fałszywych alarmów. Jeśli takich danych nie ma, pierwsze 4-6 tygodni to tryb shadow: system loguje alerty, analitycy etykietują, dopiero potem trenuje się model. Dane syntetyczne mogą przyspieszyć ten start, ale wymagają walidacji na rzeczywistych danych przed uruchomieniem produkcyjnym. Szczegółowy opis podejść do danych startowych zawiera artykuł jak przygotować dane firmowe pod AI.

Systemy AI stosowane do profilowania lub oceny ryzyka finansowego osób fizycznych wymienione są w Załączniku III AI Act jako wysokie ryzyko. Konsekwencja: wymagana dokumentacja techniczna, obowiązek DPIA (ocena skutków dla ochrony danych), zapewnienie wyjaśnialności decyzji i aktywne monitorowanie po wdrożeniu. Organizacja wdrażająca taki system musi też zapewnić możliwość zakwestionowania decyzji przez człowieka. To nie teoria: inspekcje zgodności AI Act w sektorze finansowym zaczęły się w Polsce w 2026 roku. Obowiązki wynikające z AI Act i RODO dla firm omawia artykuł AI Act i RODO 2026.

Model trenowany na historycznych decyzjach może utrwalać wzorce dyskryminacyjne, jeśli historyczne decyzje były stronnicze (np. wyższy odsetek kontroli dla konkretnych grup demograficznych). Minimalne zabezpieczenia: audyt bias na zbiorze testowym (czy wskaźnik false positive różni się istotnie między grupami), usunięcie z cech modelu atrybutów prawnie chronionych (płeć, wiek, narodowość), regularne testy równości skuteczności. AI Act dla systemów wysokiego ryzyka wymaga udokumentowania środków mitygacji bias jako części dokumentacji technicznej. Więcej o stronniczości algorytmicznej opisuje artykuł stronniczość algorytmiczna w badaniach.

Wykrywanie fraudów zakłada, że jest znana klasa docelowa (fraud jako etykieta w danych treningowych) i używa klasyfikatorów nadzorowanych. Wykrywanie anomalii nie wymaga etykiet: uczy się rozkładu normalności i sygnalizuje wszystko, co od niej odbiega. W praktyce stosuje się oba podejścia razem. Klasyfikator nadzoroany wyłapuje znane wzorce fraudów. Wykrywanie anomalii nienadzorowane (autoencoders, isolation forest, DBSCAN na embeddingach) wyłapuje wzorce nieznane, w tym całkowicie nowe typy ataków. Warstwa agenta koordynującego łączy sygnały z obu źródeł. Architekturę agentów wielokrokowych opisuje artykuł agent AI wielokrokowy.

Koszt zależy od zakresu: czy integrujemy z istniejącym systemem transakcyjnym (ERP, platforma płatności), ile źródeł danych obejmujemy, czy wymagany jest self-hosting ze względu na regulacje, i jaka jest oczekiwana latencja alertu. Pilotowy zakres (shadow mode, jeden strumień transakcji, system regułowo-statystyczny) to inny koszt niż pełna architektura wielowarstwowa z modelem sekwencyjnym i dashboardem analityka. Zakres, który ma sens dla Twojej organizacji, wylicz przez kalkulator ROI lub porozmawiaj z nami przez formularz kontaktowy.