Pięć agentów, które badają sygnały oszustwa, zamiast jedynie oceniać je.

Model wykrywania oszustw jest dobry w jednej rzeczy: informowaniu o tym, że transakcja wygląda podejrzanie. O wiele gorzej radzi sobie z odpowiadaniem na pytania, które analityk musi zadać, aby zamknąć sprawę. Co się tutaj stało? Dlaczego wygląda to podejrzanie? Co powinien teraz zrobić?

FraudLens AI, projekt z hackathonu organizowanego podczas Google Cloud Hackathon w 2026 roku, jest opracowany wokół tych drugich pytań. Nie próbuje dostarczyć lepszej oceny ryzyka oszustwa. Zamiast tego otacza istniejącą ocenę pięcioma współpracującymi agentami, które przeprowadzają dochodzenie: zbierają dowody behawioralne, porządkują zdarzenia autoryzacyjne, piszą streszczenie sprawy i umożliwiają analitykom wyszukiwanie danych w prostym języku angielskim.

Ocena to nie wyjaśnienie

Wiele systemów antyoszustwa zatrzymuje się przy wartości takiej jak 0.87. Model stojący za nimi może doskonale wykrywać nieprawidłowe zachowania, ale śledczy patrzący na tę wartość nadal nie ma pojęcia, co się wydarzyło ani dlaczego model to zaobserwował.

Dziś tę lukę wypełnia człowiek. Otwiera konto, przegląda historię transakcji, sprawdza, czy urządzenie pojawiło się już wcześniej, czyta logi autoryzacji, porównuje najnowsze działania z wcześniejszymi wzorcami i w końcu pisze notatkę opisującą decyzję.

Wszystko to jest powolne i powtarzalne, a przy gwałtownym wzroście liczby alertów przestaje być skuteczne. Ideą FraudLens jest zachowanie modelu antyoszustwa w niezmienionej formie oraz zautomatyzowanie dochodzenia, które rozpoczyna się po wygenerowaniu przez model alertu.

Pięć agentów, pięć zadań

Platforma dzieli ocenę ryzyka i dochodzenie pomiędzy pięciu agentów. Każdy z nich ma wąski zakres obowiązków, podobnie jak specjaliści, którzy dzielą pracę w zespole zajmującym się oszustwami.

Agent wykrywania

Ocena jest przeprowadzana za pomocą klasyfikatora XGBoost. Został on zweryfikowany na publicznym zbiorze danych Kaggle Credit Card Fraud Detection, który zawiera 284 807 transakcji oraz 492 potwierdzone przypadki oszustwa. Wyniki weryfikacji:

Ten zestaw danych z rzeczywistego świata jest używany wyłącznie do weryfikacji modelu wykrywania, co zostanie ponownie omówione poniżej.

Agent badawczy

Gdy transakcja przekracza progi badawcze, ten agent tworzy jej kontekst. Bierze pod uwagę:

• behawior konta i historię transakcji
• kwoty, które nie pasują do profilu konta
• behawior kraju i kontekst IP
• które urządzenia są powiązane z którymi kontami
• odchylenia od historycznych wzorców

Zamiast podać Wskaźnik ryzyka: 0,92, system generuje wnioski, na których można działać, na przykład „ta kwota jest znacznie wyższa od historycznej średniej konta” lub „to urządzenie było używane przez kilka różnych kont”. Te wnioski są umieszczane w ustrukturyzowanym pliku sprawy, który są wykorzystywane przez kolejne agenty.

Agent analizujący logi

Aktywność logowania jest często najważniejszym dowodem, jaki masz, szczególnie gdy istnieje możliwość przejęcia konta. Projekt wykorzystuje syntetyczny rejestr autoryzacji zawierający takie zdarzenia jak LOGIN_FAILED, LOGIN_SUCCESS, OTP_FAILED, NEW_DEVICE_REGISTERED oraz PASSWORD_RESET, a ten agent porównuje te zdarzenia z podejrzanymi transakcjami.

LOGIN_FAILED (Multiple) ──> OTP_FAILED ──> NEW_DEVICE_REGISTERED ──> SUSPICIOUS_TRANSACTION

Taka sekwencja mówi o wiele więcej niż sama transakcja. Ujawnia sygnały przejęcia kontroli, których model analizujący wyłącznie płatności nigdy by nie dostrzegł.

Gdzie pasuje Gemini, a gdzie nie

Agent wyjaśniający

Google Gemini wchodzi w grę dopiero na tym etapie. Agenty do wykrywania i badania najpierw tworzą ustrukturyzowane dowody, a agent wyjaśniający przekazuje te dowody Gemini, aby przekształcić je w czytelną narrację, na przykład: ta transakcja została oznaczona jako KRYTYCZNA, ponieważ znacznie odbiega od normalnego zachowania konta i koreluje z nietypową aktywnością urządzenia i logowania, więc wymaga natychmiastowej oceny.

Ważną decyzją projektową jest to, że Gemini nigdy nie ustala oceny oszustwa. Tłumaczy to dowody, które już zostały wygenerowane przez kod deterministyczny. Dzięki temu kluczowa decyzja pozostaje wiarygodna, a halucynacje nie mogą wpłynąć na to, czy płatność zostanie zaznaczona jako podejrzana.

Agent zapytań

Analizyści mogą wpisywać pytania takie jak „pokaż mi krytyczne transakcje z Nigerii”. Model nie ma prawa uruchamiać dowolnego kodu ani surowego SQL. Zamiast tego funkcje wywoływane przez Gemini wyodrębniają intencję i przekształcają ją w zweryfikowane parametry, które następnie jest wykorzystywany przez zwykły kod do pobierania danych.

Natural Language Request
       │
       ▼
Gemini Function Calling (Intent Extraction)
       │
       ▼
Structured Filters (risk_tier = CRITICAL, country = Nigeria)
       │
       ▼
Application Parameter Validation
       │
       ▼
Controlled Pandas Filtering Layer
       │
       ▼
Filtered Transaction Results

Proces pobierania pozostaje bezpieczny, przewidywalny i łatwy do audytu.

Architektura i dane

Całość jest dostarczana jako aplikacja Flask w formacie Docker, hostowana na Render dla demonstracji online, przy czym jej struktura kontenerowa działa również na Google Cloud Run.

Jedną z świadomych decyzji było oddzielenie twierdzeń dotyczących wyników testów od możliwości demonstracyjnych. Dane z Kaggle są używane wyłącznie do weryfikacji skuteczności wykrywania, stąd też wynik 0,985 w metryce ROC-AUC. Procesy badawcze w trybie online odbywają się na syntetycznych danych firmowych, ponieważ anonimizowane dane testowe nie zawierają poli relacyjnych takich jak historia urządzeń, logi logowania czy powiązania między kontami.

┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│           REAL KAGGLE DATA            │      │        SYNTHETIC ENTERPRISE           │
│         284,807 Transactions          │      │     50,000 Transactions + Logs        │
└───────────────────┬───────────────────┘      └───────────────────┬───────────────────┘
                    │                                              │
                    ▼                                              ▼
┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│          XGBoost Validation           │      │          Live Investigation           │
│ ROC-AUC 0.985 | Precision/Recall 82%  │      │  Accounts + Devices + Auth Logs       │
└───────────────────────────────────────┘      └───────────────────┬───────────────────┘
                                                                   │
                                                                   ▼
                                               ┌───────────────────────────────────────┐
                                               │         Interactive Dashboard         │
                                               │      Evidence + Gemini Narrative      │
                                               └───────────────────────────────────────┘

Przepływ od początku do końca

Gdy analityk rozpoczyna dochodzenie, proces przebiega w określonej kolejności: agent wykrywania ocenia transakcję, agent dochodzeniowy zbiera dowody behawioralne, agent analizy logów dodaje informacje o autoryzacji, agent wyjaśniający tworzy opis sytuacji, a wynik trafia na panel sterowania sprawą, gdzie agent wyszukiwania może kontynuować badania.

Zaprojektowane tak, by awarie były łagodne

API sztucznej inteligencji napotykają ograniczenia liczby żądań oraz błędy sieciowe. Aby uniknąć wyłączenia aplikacji, usługa opisów Gemini jest całkowicie oddzielona od deterministycznego procesu przetwarzania.

Jeśli połączenie z Gemini nie udaje się bez takiej separacji, strona zawiesza się z błędem 500. Przy takim podejściu aplikacja nadal zwraca wszystkie kluczowe wskaźniki ryzyka, flagi urządzenia, odchylenia behawioralne oraz szczegóły z dziennika, a także komunikat nieblokujący informujący, że narracja wyjaśniająca jest tymczasowo niedostępna. W najgorszym przypadku otrzymujemy zwykłą tablicę kontrolną dochodzenia, która nadal pełni swoją funkcję.

Lekcje z procesu tworzenia

• Bądź szczery co do danych. Oddzielenie weryfikacji benchmarków od syntetycznej demonstracji buduje zaufanie u recenzentów technicznych, którzy w przeciwnym razie kwestionowaliby każdą liczbę.
• Zbieraj dowody w kodzie, rozumuj z modelem LLM. Zasady i agregacja powinny znajdować się w kodzie deterministycznym. Zadaniem modelu jest przekształcenie tych wyników w naturalne wyjaśnienie.
• Przetestuj części, które nie wymagają żywego API. Pakiet zawiera 53 testy skierowane na deterministyczny proces przetwarzania, który zapewnia wysoką niezawodność bez konieczności wydawania tokenów API przy każdym uruchomieniu.

Co następuje dalej

• przetwarzanie strumieniowe za pomocą Google Cloud Pub/Sub i Dataflow zamiast przetwarzania partiami
• natywna persistencja w Google Cloud przy użyciu BigQuery i Firestore
• sieci neuronowe grafowe do wykrywania siatek oszustw rozprzestrzenionych między wieloma kontami
• dowody multimodalne – włączanie plików PDF z sporów, dokumentów tożsamości oraz transkryptów rozmów do kontekstu Gemini

Zasada, na której to opiera się

Praca z oszustwami nie kończy się w momencie, gdy model wyświetla wynik. Kluczowe jest ustalenie, jakie dowody tłumaczą alarm oraz co analityk powinien zrobić dalej. FraudLens dokładnie to rozdziela: model wykrywa oszustwo, kod deterministyczny zbiera dowody, specjalistyczni agenci prowadzą dochodzenie, a model językowy jedynie tłumaczy wyniki.

Literatura pokrewna

• Stateful Remote Sandboxes With Antigravity Managed Agents and the GenAI SDK — Uruchamianie wieloetapowych agentów z skryptu: utrzymywanie aktywnego zdalnego środowiska Ubuntu, ponowne podłączenie za pomocą identyfikatora środowiska oraz pobieranie zrzutu stanu przestrzeni roboczej, wraz z dwoma przykładami zastosowania.
• Dlaczego agenty, które imponują w demonstracjach, zawodzą w produkcji, i co zamiast tego warto stworzyć — punkty awarii, kompromis między jednym a wieloma agentami, praktyki projektowe takie jak ponawianie prób i mechanizmy awaryjne, oraz pełny obraz kosztów działania agenta AI poza opłatami za tokeny.