Agent AI do monitoringu zgodności w finansach: kontrolowany proces, nie autopilot

Zespół compliance nie potrzebuje kolejnego demo, w którym AI "wykrywa pranie pieniędzy" na trzech przykładowych przelewach. Potrzebuje systemu, który działa w granicach procedur instytucji, nie gubi źródeł, nie miesza danych klientów z promptami marketingowymi i nie zamyka spraw, których nie powinien zamykać.

W 2026 roku rozmowa o agencie AI w finansach powinna zaczynać się od pytania operacyjnego: który fragment pracy analityka ma zostać odciążony bez utraty kontroli?

Najczęściej nie jest to "automatyczna decyzja". Jest to triage alertów, kompletowanie dossier, sprawdzanie danych w wielu systemach, przygotowanie uzasadnienia, wyszukiwanie procedur, pilnowanie checklisty i przekazanie sprawy człowiekowi z właściwym poziomem uprawnień.

Problem: monitoring jest procesem, nie jednym modelem

Klasyczny monitoring AML/fraud zwykle łączy reguły, scoring, listy sankcyjne, dane KYC, historię klienta, ręczną analizę i eskalacje. Reguły bywają proste:

• nietypowa kwota względem historii klienta,
• nowy kontrahent lub jurysdykcja podwyższonego ryzyka,
• sekwencja transakcji, która wygląda jak dzielenie płatności,
• zbieżność z listą sankcyjną albo alert PEP,
• niezgodność profilu działalności z opisem transakcji.

To nie znaczy, że każde przekroczenie progu jest podejrzeniem. Instytucja obowiązana ma stosować podejście oparte na ryzyku, środki bezpieczeństwa finansowego i analizę kontekstu. Polski system AML/CFT opiera się na ustawie z 1 marca 2018 r., a Ministerstwo Finansów opisuje rolę GIIF jako centralnego elementu krajowego systemu przeciwdziałania praniu pieniędzy i finansowaniu terroryzmu. W perspektywie unijnej warto też czytać wytyczne EBA dotyczące czynników ryzyka ML/TF, bo przypominają, że monitoring i ocena ryzyka muszą być aktualizowane, a nie ustawione raz na zawsze.

W praktyce największy koszt nie zawsze leży w samym "wykryciu". Często leży w pracy dookoła alertu:

• zebranie historii klienta i beneficjenta rzeczywistego,
• sprawdzenie relacji kontrahentów,
• odtworzenie poprzednich alertów i decyzji,
• porównanie transakcji z profilem działalności,
• sprawdzenie aktualnych list i wewnętrznych procedur,
• przygotowanie notatki analitycznej,
• udokumentowanie, dlaczego sprawa została zamknięta albo eskalowana.

Agent AI ma sens wtedy, gdy skraca właśnie tę pracę pomocniczą i robi to w sposób możliwy do przejrzenia.

Co agent AI może robić bez obiecywania cudów

W dobrym wdrożeniu agent nie jest "modelem decyzyjnym". Jest warstwą orkiestracji nad istniejącymi systemami, procedurami i narzędziami. Może działać na LangGraph/LangChain, n8n, OpenClaw albo własnym runtime, ale nazwa frameworka jest drugorzędna. Najważniejsze są granice: jakie narzędzia wolno wywołać, jakie dane wolno pobrać, kiedy wymagane jest zatwierdzenie i co trafia do logu.

1. Kompletowanie dossier alertu

Zamiast prosić analityka o ręczne przeklikiwanie systemów, agent może przygotować uporządkowany pakiet:

• dane alertu z systemu AML/fraud,
• profil klienta, segment, kraj, branża i deklarowany cel relacji,
• historię podobnych transakcji oraz poprzednich alertów,
• informacje KYC/KYB i status aktualizacji dokumentów,
• wynik screeningu list sankcyjnych, PEP i wewnętrznych watchlist,
• powiązania klienta z kontrahentami albo innymi rachunkami,
• dokumenty źródłowe wskazane przez procedurę.

To jest praca techniczna, ale istotna. Dobre dossier pozwala człowiekowi szybciej zobaczyć, czy alert jest powtarzalnym szumem, czy wymaga pogłębienia.

2. Priorytetyzacja kolejki, nie automatyczny wyrok

Agent może proponować priorytet alertu, ale powinien pokazać składniki oceny. Przykładowy opis jest bardziej wartościowy niż sama liczba:

Wrażliwe decyzje, zamknięcie alertu, eskalacja do organu lub blokada środków nie powinny zależeć wyłącznie od niezweryfikowanej odpowiedzi modelu językowego. Agent może rekomendować i uzasadniać. Instytucja nadal odpowiada za proces.

3. RAG po procedurach i materiałach referencyjnych

RAG w compliance nie służy do tego, żeby model "znał prawo". Służy do kontrolowanego pobierania aktualnych dokumentów, na których analityk może się oprzeć:

• wewnętrzne procedury AML/CFT,
• polityka sankcyjna i instrukcje obsługi alertów,
• typologie i scenariusze ryzyka zaakceptowane przez instytucję,
• instrukcje dotyczące retencji, eskalacji i roli drugiej linii,
• wzory notatek i checklisty dla konkretnych typów spraw.

Każda odpowiedź agenta powinna wskazywać użyte źródła: dokument, wersję, fragment i datę obowiązywania. Bez tego RAG łatwo zmienia się w eleganckie streszczenie bez wartości audytowej.

4. Przygotowanie notatki, którą człowiek zatwierdza

Agent może wygenerować szkic notatki analitycznej:

• co uruchomiło alert,
• jakie dane zostały sprawdzone,
• jakie źródła potwierdzają lub osłabiają podejrzenie,
• czego brakuje do decyzji,
• czy sprawa powinna trafić do senior analyst, MLRO/compliance officera albo innej funkcji,
• jakie pytania trzeba zadać klientowi lub jednostce biznesowej.

Taki szkic oszczędza czas, ale nie jest gotową decyzją. Powinien przejść review osoby z właściwymi kompetencjami i uprawnieniami.

Czego agent nie powinien robić samodzielnie

Największe ryzyko w projektach agentowych polega na tym, że "automatyzacja" niepostrzeżenie zaczyna oznaczać "system wykonał czynność, bo model tak zasugerował".

W finansach warto jasno zablokować:

• samodzielne zamykanie alertów wysokiego ryzyka,
• samodzielne wysyłanie zawiadomień do GIIF bez zatwierdzenia,
• zmianę profilu ryzyka klienta bez procedury i logu,
• blokowanie środków albo usług na podstawie samej odpowiedzi LLM,
• pobieranie pełnych danych klienta, gdy do zadania wystarczy zakres minimalny,
• wykonywanie zapytań do produkcyjnych systemów poza allowlistą narzędzi,
• trenowanie lub fine-tuning na danych klientów bez osobnej podstawy, celu i kontroli.

Jeżeli organizacja chce automatycznie zamykać część spraw niskiego ryzyka, najpierw potrzebuje walidacji, definicji zakresu, kontroli jakości, limitów, testów na danych historycznych, procedury odwoławczej i okresowych przeglądów. Sama etykieta "AI" niczego tu nie upraszcza.

Projekt kontrolowanego procesu

Bezpieczniejszy wzorzec wygląda tak:

1. System AML/fraud tworzy alert.
2. Agent dostaje tylko identyfikator sprawy i zakres uprawnień dla danego typu alertu.
3. Agent pobiera dane przez jawnie zdefiniowane narzędzia, nie przez dowolne zapytania.
4. Agent buduje dossier i oznacza braki.
5. Agent proponuje priorytet, ale pokazuje uzasadnienie i źródła.
6. Analityk akceptuje, koryguje albo odrzuca rekomendację.
7. Decyzja, komentarz człowieka i ślad działania trafiają do systemu spraw.
8. Feedback zasila ewaluację jakości, nie bezpośrednie samouczenie produkcyjnego agenta.

LangGraph ma mechanizmy przerwania wykonania i wznowienia po decyzji człowieka, a LangChain opisuje human-in-the-loop jako przerwanie przed wywołaniem narzędzia lub akcją. n8n może być użyteczne jako warstwa workflow, ale trzeba uważać na dane wykonania, dane uwierzytelniające i role; jego dokumentacja opisuje m.in. redakcję danych wykonania. OpenClaw i podobne runtime'y agentowe warto oceniać przez pryzmat narzędzi, sandboxa, kanałów i polityk uprawnień, a nie przez obietnicę "autonomii".

Uprawnienia narzędzi: najważniejsza część architektury

Agent compliance powinien mieć mniej uprawnień niż człowiek, nie więcej. Minimalny model kontroli:

• osobne service accounty dla odczytu danych,
• brak domyślnego dostępu do eksportu pełnych baz,
• allowlista narzędzi per typ alertu,
• osobne uprawnienia dla odczytu, zapisu, komentarza i eskalacji,
• zatwierdzenie przed narzędziami zmieniającymi stan sprawy,
• limity liczby zapytań i zakresu dat,
• blokada promptów, które próbują obchodzić procedury,
• pełny log wejścia, wyjścia, narzędzia, wersji promptu, wersji modelu i osoby zatwierdzającej.

To nie jest biurokracja. To różnica między asystentem analityka a niekontrolowanym procesem decyzyjnym.

RODO: minimalizacja, DPIA i retencja

W monitoringu finansowym agent będzie pracował na danych osobowych, a często na danych pozwalających wnioskować o sytuacji ekonomicznej, zachowaniu i relacjach klienta. RODO wymaga m.in. ograniczenia celu, minimalizacji, bezpieczeństwa i ograniczenia przechowywania. UODO przypomina, że ocena skutków dla ochrony danych jest wymagana, gdy planowane przetwarzanie, zwłaszcza z użyciem nowych technologii, może z dużym prawdopodobieństwem powodować wysokie ryzyko dla praw lub wolności osób fizycznych.

W praktyce przed pilotem warto ustalić:

• administratora, procesora i podprocesorów,
• podstawę i cel przetwarzania dla każdego źródła danych,
• czy dane klienta trafiają do dostawcy modelu, telemetryki lub narzędzia observability,
• czy prompt, odpowiedź i wynik narzędzia są danymi osobowymi,
• które logi są potrzebne audytowo, a które są nadmiarowe,
• okres retencji promptów, trace'ów, notatek i załączników,
• anonimizację lub pseudonimizację danych używanych do ewaluacji,
• procedurę obsługi praw osób, których dane dotyczą, tam gdzie ma zastosowanie.

Nie wystarczy napisać, że "dane zostają w EU". Trzeba wiedzieć, gdzie są logi, backupy, kolejki, cache, tracing, błędy aplikacyjne i pliki eksportowe.

AI Act: najpierw klasyfikacja użycia

Nie każdy agent wspierający compliance automatycznie jest systemem AI wysokiego ryzyka w rozumieniu AI Act. Klasyfikacja zależy od konkretnego celu i użycia. AI Act wyraźnie obejmuje wybrane zastosowania finansowe, np. ocenę zdolności kredytowej osób fizycznych lub ustalanie scoringu kredytowego, a dla systemów wysokiego ryzyka wprowadza wymagania dotyczące m.in. zarządzania ryzykiem, przejrzystości, logów, nadzoru człowieka, dokładności, odporności i cyberbezpieczeństwa.

Dlatego w projekcie compliance trzeba zrobić klasyfikację:

• czy agent tylko porządkuje materiał dla człowieka,
• czy jego wynik wpływa na decyzję wobec osoby fizycznej,
• czy system podejmuje albo wspiera decyzje o skutkach prawnych lub podobnie istotnych,
• czy użycie podpada pod kategorie wysokiego ryzyka,
• jakie obowiązki ma dostawca, a jakie instytucja jako podmiot stosujący.

Jeżeli system zostanie sklasyfikowany jako wysokiego ryzyka, trzeba projektować go od początku z rejestrowaniem zdarzeń, instrukcją użycia, nadzorem człowieka i dokumentacją. Doklejanie logów po pilocie zwykle kończy się źle.

DORA i operacyjna odporność

DORA jest ważna nie dlatego, że "reguluje AI", tylko dlatego, że agent compliance jest elementem ICT w instytucji finansowej. Jeżeli bierze udział w procesie monitoringu, trzeba traktować go jak część krajobrazu ryzyka operacyjnego:

• klasyfikacja krytyczności procesu,
• zarządzanie dostawcami ICT i umowami,
• testy odporności i plan ciągłości,
• monitoring incydentów,
• kontrola zmian modeli, promptów, narzędzi i integracji,
• możliwość wyłączenia agenta bez zatrzymania procesu compliance,
• procedura fallback do pracy ręcznej.

Agent nie może być pojedynczym punktem awarii. Jeżeli przestaje działać, analitycy muszą wiedzieć, gdzie jest kolejka alertów i jak wrócić do standardowej procedury.

Nadzór nad systemem: co trzeba mierzyć

W projektach compliance nie wystarcza ogólny dashboard "accuracy". Potrzebne są metryki procesu:

• ile spraw agent skompletował bez braków danych,
• ile rekomendacji analitycy zaakceptowali, zmienili lub odrzucili,
• które typy alertów generują najwięcej błędnych sugestii,
• ile razy agent próbował użyć narzędzia bez uprawnienia,
• ile odpowiedzi nie miało źródła w dokumentach,
• ile spraw wróciło po kontroli jakości,
• czy czas obsługi spada bez pogorszenia jakości decyzji.

Warto oddzielić ewaluację językową od ewaluacji procesowej. Ładnie napisana notatka nie znaczy, że agent poprawnie zinterpretował ryzyko.

Pilotaż: jak przeprowadzić go uczciwie

Pilotaż na realnych danych trwa około 6–8 tygodni, ma jeden zapisany cel i ograniczony zakres odpowiedzialności. Zaczyna się od wyboru wąskiego typu alertu i danych historycznych, nie od integracji z produkcją.

Faza 1: zakres i ryzyka

• wybór 1-2 typów alertów,
• opis obecnej procedury i punktów decyzyjnych,
• mapa danych, systemów i właścicieli,
• decyzja, które akcje są tylko do odczytu, a które wymagają zatwierdzenia,
• wstępna ocena RODO, AI Act, DORA i polityk wewnętrznych.

Faza 2: tryb obserwacyjny

• agent przygotowuje dossier bez wpływu na decyzję,
• analitycy oceniają kompletność i przydatność,
• porównuje się rekomendacje z decyzjami człowieka,
• błędy są kategoryzowane, nie zamiatane do jednej metryki,
• testuje się logi, retencję i odtwarzalność sprawy.

Faza 3: ograniczona produkcja

• agent działa tylko w wybranym zakresie,
• wszystkie akcje zmieniające stan sprawy wymagają zatwierdzenia przez człowieka,
• próg automatyzacji jest niski i formalnie zatwierdzony,
• istnieje procedura rollbacku,
• compliance, bezpieczeństwo, DPO i właściciel biznesowy widzą raport jakości.

Wyniki pilota powinny być mierzone na danych instytucji. Nie ma uczciwej uniwersalnej obietnicy typu "redukcja false positives o X%".

Ile to kosztuje

Budżet zależy od integracji i wymogów kontroli. Pilotaż na realnych, zanonimizowanych danych ma ograniczony zakres odpowiedzialności; produkcyjny agent w banku musi dodatkowo logować każde wywołanie narzędzia, działać w prywatnej infrastrukturze i przejść przegląd bezpieczeństwa. Jeśli zapisany cel pilotażu nie zostanie osiągnięty przy uzgodnionych warunkach, umowa określa ograniczone działanie naprawcze.

Najważniejsze składniki kosztu:

• integracja z systemem AML/fraud, KYC, case management i źródłami sankcyjnymi,
• przygotowanie RAG po procedurach i wersjonowanie dokumentów,
• warstwa uprawnień narzędzi i zatwierdzeń,
• observability, logi, retencja i eksport audytowy,
• testy na danych historycznych,
• przegląd bezpieczeństwa i privacy,
• szkolenie analityków oraz właścicieli procesu.

Jeżeli vendor wycenia tylko "model + prompt", to nie jest wycena systemu compliance. To wycena prototypu.

FAQ

Czy KNF akceptuje AI w compliance?

Nie ma prostej odpowiedzi "tak" albo "nie" dla każdej architektury. Instytucja finansowa powinna ocenić konkretne użycie, ryzyka, nadzór, outsourcing, bezpieczeństwo, ciągłość działania i zgodność z własnymi procedurami. Agent wspierający pracę analityka jest innym przypadkiem niż system automatycznie podejmujący decyzje wobec klienta.

Czy agent może wysłać zawiadomienie do GIIF?

Technicznie można zautomatyzować przygotowanie pakietu danych, ale decyzja o zawiadomieniu i jego formalne zatwierdzenie powinny pozostać w procedurze instytucji. W artykule nie zakładamy automatycznej wysyłki bez człowieka.

Czy agent może zamykać false positives?

Może wspierać identyfikację spraw niskiego ryzyka, ale automatyczne zamykanie wymaga osobnej polityki, walidacji, limitów, jakościowego review i śladu audytowego. Dla alertów średniego i wysokiego ryzyka bezpieczniejszym standardem jest rekomendacja plus decyzja człowieka.

Czy dane mogą trafiać do zewnętrznego LLM?

To zależy od klasyfikacji danych, umów, konfiguracji i architektury. W finansach często sensowniejszy jest model hostowany w kontrolowanej infrastrukturze albo warstwa, która wysyła do modelu tylko zminimalizowany, pseudonimizowany kontekst. Trzeba też sprawdzić logi i telemetrykę dostawcy.

Czy LangGraph, n8n albo OpenClaw wystarczą do compliance?

Nie. To mogą być elementy architektury. Compliance wynika z projektu procesu, uprawnień, logów, retencji, nadzoru, testów i odpowiedzialności. Framework pomaga, ale nie zastępuje governance.

Co dalej?

Jeżeli rozważasz agenta AI do compliance monitoringu, zacznij od małego zakresu:

1. Wybierz typ alertu - taki, który jest częsty, dobrze opisany i ma jasną procedurę.
2. Zmapuj dane - źródła, właścicieli, podstawy przetwarzania, retencję i ograniczenia dostępu.
3. Ustal granice agenta - tylko odczyt, zatwierdzenia, eskalacje, zakazane akcje.
4. Zaprojektuj logi - tak, żeby sprawę dało się odtworzyć po miesiącu i po kontroli.
5. Uruchom tryb obserwacyjny - bez wpływu na decyzje, z oceną jakości przez analityków.

Umów bezpłatny skan procesów: 30 minut z inżynierem i pisemne podsumowanie w 2 dni robocze. Porozmawiamy o kontrolowanym pilotażu agenta compliance na wąskim, mierzalnym procesie.

Sprawdź też: Agent AI do raportowania finansowego | Agent AI - ile kosztuje? | Dedykowany Agent AI

Źródła i punkty odniesienia

• Ustawa z dnia 1 marca 2018 r. o przeciwdziałaniu praniu pieniędzy oraz finansowaniu terroryzmu
• Generalny Inspektor Informacji Finansowej - Ministerstwo Finansów
• Przeciwdziałanie praniu pieniędzy i finansowaniu terroryzmu - Ministerstwo Finansów
• UODO: ocena skutków dla ochrony danych
• Rozporządzenie (UE) 2024/1689, AI Act - EUR-Lex
• Komisja Europejska: harmonogram stosowania AI Act
• Rozporządzenie DORA (UE) 2022/2554 - EUR-Lex
• EBA: Guidelines on ML/TF risk factors
• FATF: Digital Transformation of AML/CFT
• LangGraph: interrupts i human-in-the-loop
• LangChain: human-in-the-loop middleware
• n8n: execution data redaction
• OpenClaw: tools