Agent AI do monitoringu zgodności w finansach: kontrolowany proces z decyzją człowieka

Agent AI w monitoringu zgodności może przygotować materiał do analizy: zebrać dozwolone źródła, wskazać braki i napisać szkic notatki z odnośnikami. W opisanym tu zakresie zamknięcie alertu AML, blokada środków i wysłanie zawiadomienia do GIIF pozostają poza uprawnieniami aplikacji. Instytucja określa procedurę, a uprawniona osoba ocenia sprawę. To propozycja technicznego obiegu, bez deklaracji wykrywalności nadużyć lub wdrożenia Syntalith w banku.

Dla zespołów compliance, AML, przeciwdziałania oszustwom, ryzyka i bezpieczeństwa oraz dla zarządu pierwsze pytanie brzmi: który fragment pracy analityka można usprawnić bez utraty kontroli nad sprawą? Najczęściej warto zacząć od kompletowania materiału, wyszukiwania procedur, przygotowania notatki i pilnowania listy kontrolnej. Wstępna klasyfikacja lub priorytetyzacja alertów wymaga osobnego zakresu i walidacji.

Pierwszym zakupem może być Audyt procesu AI od 2 495 zł netto: opis procesu, architektura, plan wdrożenia i wycena uzgodnionego zakresu. Audyt techniczny nie stanowi poświadczenia zgodności AML ani odbioru przez nadzór. Przed budową instytucja musi wskazać osoby odpowiedzialne za ocenę prawną, bezpieczeństwo i jakość pracy analitycznej.

Problem monitoringu i rola całego procesu

Klasyczny monitoring AML i fraud łączy reguły, scoring, listy sankcyjne, dane KYC, historię klienta, analizę ręczną i eskalacje. Alert może wynikać z:

• nietypowej kwoty względem historii klienta,
• nowego kontrahenta lub jurysdykcji podwyższonego ryzyka,
• sekwencji transakcji przypominającej dzielenie płatności,
• dopasowania do listy sankcyjnej albo alertu PEP,
• niezgodności profilu działalności z opisem transakcji.

Przekroczenie progu wymaga sprawdzenia kontekstu. Instytucja obowiązana stosuje podejście oparte na ryzyku i środki bezpieczeństwa finansowego. Punktem odniesienia są ustawa AML z 1 marca 2018 r., materiały Ministerstwa Finansów o roli GIIF oraz wytyczne EBA dotyczące czynników ryzyka ML/TF. Procedury i ocena ryzyka wymagają aktualizacji wraz ze zmianą danych oraz warunków działania.

Duża część pracy odbywa się już po utworzeniu alertu. Analityk zbiera historię klienta i informacje o beneficjencie rzeczywistym, sprawdza relacje kontrahentów, odtwarza poprzednie alerty i decyzje, porównuje transakcje z profilem działalności, sięga do aktualnych list i procedur. Na końcu dokumentuje podstawę zamknięcia lub eskalacji.

Agent może pomóc uporządkować tę pracę, jeżeli każde pobranie danych i każdy fragment notatki dają się sprawdzić.

Którą część obsługi alertu warto usprawnić

Najpierw ustal, co zajmuje czas: wyszukanie dokumentów, porównanie identyfikatorów, lektura historii czy uzasadnienie decyzji. Dla pobrania danych z kilku tabel może wystarczyć zwykła integracja. Model warto rozważyć, gdy analityk musi czytać opisy i odnajdywać fragmenty istotne dla ustalonego zadania.

W proponowanym obiegu system AML nadal tworzy alert. Dodatkowa aplikacja otrzymuje identyfikator sprawy i pobiera tylko źródła dostępne dla danej roli. Przygotowuje zestawienie dokumentów, dat i braków. Model może streszczać wskazane fragmenty, ale recenzent musi móc sprawdzić je bez opuszczania kontekstu sprawy.

Nie zakładamy, że stare zamknięcie alertu jest poprawną etykietą do uczenia modelu. Decyzję mogły poprzedzać informacje, których nie ma w początkowym opisie. Próbę trzeba oprzeć na materiale i kryteriach ocenionych przez właściwych specjalistów instytucji.

Co agent AI może robić w monitoringu zgodności

Agent może koordynować pobieranie danych i przygotowanie materiału nad istniejącymi systemami oraz procedurami. LangGraph, LangChain, n8n, OpenClaw lub własne środowisko wykonawcze mogą być elementami rozwiązania. O wyborze decydują dostępne narzędzia, kontrola uprawnień, możliwość zatrzymania działania, sposób zatwierdzania i jakość historii wykonania.

1. Kompletowanie dossier alertu

Pakiet dla analityka może obejmować:

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

Zakres musi odpowiadać zadaniu i uprawnieniom. Przy każdym elemencie powinny być widoczne źródło, wersja, identyfikator sprawy i potwierdzone przypisanie do klienta. Brak danych pozostaje widoczny w pakiecie.

2. Materiał do ustalenia priorytetu przez człowieka

Poniższa tabela pokazuje przykładowe obszary analizy. Opisuje materiał pomocniczy dla analityka; ocenę ryzyka i priorytet pozostawiamy w dotychczasowej procedurze instytucji.

Jeżeli późniejszy etap projektu ma obejmować sugestię priorytetu, trzeba osobno określić kryteria, składniki uzasadnienia i sposób walidacji. Zamknięcie alertu, zmiana profilu ryzyka, zawiadomienie lub blokada środków wymagają właściwej podstawy i procedury instytucji. Niezweryfikowana odpowiedź modelu nie wystarcza do wykonania takich działań.

3. RAG po procedurach i materiałach referencyjnych

Wyszukiwanie w dokumentach, często określane jako RAG, może udostępniać właściwe fragmenty:

• wewnętrznych procedur AML/CFT,
• polityki sankcyjnej i instrukcji obsługi alertów,
• typologii oraz scenariuszy ryzyka zaakceptowanych przez instytucję,
• instrukcji dotyczących retencji, eskalacji i roli drugiej linii,
• wzorów notatek i list kontrolnych dla konkretnych typów spraw.

Każda odpowiedź zależna od tych materiałów powinna wskazywać dokument, wersję, fragment i datę obowiązywania. Osoba odpowiedzialna za materiały musi ustalić wersje obowiązujące oraz dostęp.

RAG nie rozstrzyga, czy procedura jest właściwa dla sprawy. Samo odnalezienie podobnego akapitu nie daje modelowi prawa do zastosowania go do dowolnego klienta. Przy sprzecznych wersjach aplikacja powinna wskazać konflikt i zatrzymać przygotowanie wniosku, który od niego zależy.

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

Szkic notatki może porządkować:

• przyczynę uruchomienia alertu,
• sprawdzone dane i dokumenty,
• informacje wspierające lub osłabiające podejrzenie, z podstawą w źródłach,
• braki wymagające wyjaśnienia przed decyzją,
• materiał do oceny potrzeby eskalacji do starszego analityka, osoby odpowiedzialnej za AML lub innej właściwej funkcji,
• pytania do klienta lub jednostki biznesowej wymagające zatwierdzenia w procedurze.

Proponowany szkic rozdziela dane pobrane, fragmenty przytoczone ze źródeł, braki i uwagi autora. Każde twierdzenie zależne od dokumentu powinno prowadzić do jego konkretnej wersji. Jeżeli źródło nie uzasadnia zdania, zdanie wymaga poprawki lub usunięcia.

W pierwszym zakresie proponujemy pozostawić ocenę ryzyka i decyzję w dotychczasowej procedurze. Aplikacja przygotowuje materiał, a analityk zapisuje swoją ocenę. Wyniku korekty nie należy automatycznie używać do dalszego uczenia bez ustalenia celu, praw do danych i sposobu weryfikacji przykładów.

Przykład: komplet dokumentów nie oznacza podstawy decyzji

W fikcyjnej sprawie aplikacja znajduje aktualny profil klienta, historię transakcji i notatkę z poprzedniego przeglądu. Jeden załącznik pochodzi jednak z innej sprawy o podobnej nazwie. Płynne streszczenie wszystkich czterech dokumentów ukryłoby błąd przypisania.

Dlatego przy każdym elemencie pakietu powinny być widoczne identyfikator klienta, identyfikator sprawy, źródło i wersja. Dokument bez potwierdzonego związku ze sprawą pozostaje do wyjaśnienia. Pracownik widzi brak i jego przyczynę.

Ta tabela opisuje warunki przyszłego odbioru technicznego. Nie określa stopnia ryzyka klienta ani podstawy do zawiadomienia.

Czego agent nie powinien robić samodzielnie

Zakres działania trzeba zapisać przed integracją z systemami. W proponowanym pierwszym etapie wykluczamy samodzielne:

• zamykanie alertów, w tym alertów wysokiego ryzyka,
• wysyłanie zawiadomień do GIIF,
• zmienianie profilu ryzyka klienta,
• blokowanie środków lub usług,
• pobieranie pełnych danych klienta, gdy wystarczy węższy zakres,
• wykonywanie zapytań do systemów produkcyjnych poza listą dozwolonych narzędzi,
• trenowanie lub dostrajanie modelu na danych klientów bez ustalenia podstawy, celu i kontroli.

Jeżeli instytucja chce w przyszłości automatycznie zamykać część spraw niskiego ryzyka, potrzebuje osobnej oceny dopuszczalności, polityki, walidacji, limitów i kontroli jakości. Zakres powinien obejmować próby na ocenionych danych historycznych, możliwość ponownego przeglądu i odpowiednie procedury odwoławcze tam, gdzie mają zastosowanie. Wymagane są też okresowe przeglądy. Ten artykuł nie zakłada takiej funkcji w pierwszym wdrożeniu.

Projekt kontrolowanego procesu

Proponowany obieg wygląda tak:

1. System AML lub fraud tworzy alert.
2. Aplikacja otrzymuje identyfikator sprawy i zakres uprawnień dla danego zadania.
3. Pobiera dane przez zdefiniowane narzędzia, z kontrolą dostępu w usługach źródłowych.
4. Buduje dossier, sprawdza przypisanie materiałów i oznacza braki.
5. Przygotowuje szkic notatki z odnośnikami do konkretnych wersji źródeł.
6. Analityk sprawdza materiał, poprawia szkic i zapisuje ocenę według procedury instytucji.
7. Zatwierdzona wersja, komentarz człowieka i uzgodniony ślad działań trafiają do systemu spraw.
8. Informacje o błędach służą ewaluacji jakości. Dalsze uczenie wymaga osobnych ustaleń i weryfikacji przykładów.

LangGraph opisuje przerwanie i wznowienie procesu po decyzji człowieka, a LangChain mechanizm zatwierdzania wywołań narzędzi. n8n może obsługiwać przepływ pracy, lecz trzeba ocenić dostęp do danych wykonania, poświadczeń i ról; jego dokumentacja opisuje redakcję danych wykonania. Przy OpenClaw należy ocenić narzędzia, izolację, kanały i polityki uprawnień. Wybór frameworka wymaga sprawdzenia zachowania całego obiegu.

Jak sprawdzić uprawnienia i zapis decyzji

Uprawnienia należy egzekwować w aplikacji i usługach źródłowych. Samo polecenie dla modelu dotyczące ochrony danych nie zastępuje kontroli dostępu. Model nie powinien sam wybierać dowolnego klienta ani wykonywać nieograniczonych zapytań do produkcyjnej bazy.

Zakres dostępu agenta powinien odpowiadać konkretnemu zadaniu. W projekcie warto przewidzieć:

• osobne konta techniczne do odczytu danych,
• brak domyślnego dostępu do eksportu pełnych baz,
• listę dozwolonych narzędzi dla danego typu alertu,
• rozdzielenie odczytu, zapisu notatki, komentarza i eskalacji,
• zatwierdzenie przed działaniami zmieniającymi stan sprawy,
• limity liczby zapytań i zakresu pobieranych dat,
• kontrolę prób obejścia procedury przez treść dokumentów lub polecenia,
• historię wersji instrukcji, modelu, użytych narzędzi oraz osoby zatwierdzającej.

Zapis notatki wiąże się z użytkownikiem i wersją materiału. Historia powinna pozwalać ustalić, co zostało zatwierdzone i na jakiej podstawie, przy uzgodnionej retencji i zakresie logów. Kopiowanie pełnych danych klientów do każdego logu nie jest domyślnym celem. Zakres zapisu wejść, odpowiedzi i wyników narzędzi trzeba uzgodnić z wymaganiami audytowymi oraz minimalizacją danych.

Próby odbiorowe powinny obejmować zmianę uprawnień po rozpoczęciu pracy, dokument z innej sprawy, nieaktualną akceptację oraz przerwę połączenia podczas zapisu. Trzeba również sprawdzić treść dokumentu zawierającą polecenie dla modelu, np. żądanie pominięcia procedury. Nie podajemy uniwersalnego progu jakości dla tych prób; wymagania ustala instytucja przed oceną.

AML, AI Act, RODO i DORA: odrębne pytania

AML: kontekst klienta i procedura instytucji

Komunikat GIIF nr 22 opisuje m.in. analizę transakcji w kontekście wiedzy o kliencie oraz aktualizację dokumentów. To punkt odniesienia dla rozmowy o materiałach potrzebnych analitykowi. Nie wyprowadzamy z niego automatycznych reguł zamykania alertów ani terminów działania konkretnej instytucji.

Instytucja musi wskazać właściwe procedury, odpowiedzialność za ocenę sprawy i sposób formalnego zatwierdzania dalszych działań. Materiał przygotowany przez aplikację podlega tym samym wymaganiom dotyczącym podstawy analizy i jakości dokumentacji.

AI Act: najpierw klasyfikacja zastosowania

Klasyfikacja według AI Act zależy od zastosowania. Załącznik III, punkt 5(b) wymienia ocenę zdolności kredytowej osób fizycznych i scoring, z wyjątkiem systemów używanych do wykrywania oszustw finansowych. Ten wyjątek nie oznacza zwolnienia całego obiegu compliance ze wszystkich obowiązków. Zespół prawny powinien ocenić konkretny cel i rolę systemu.

W ocenie trzeba ustalić:

• czy aplikacja tylko porządkuje materiał dla człowieka,
• jak jej wynik wpływa na decyzję wobec osoby fizycznej,
• czy wspiera lub podejmuje decyzje o skutkach prawnych albo podobnie istotnych,
• czy zastosowanie należy do kategorii wysokiego ryzyka,
• jakie obowiązki dotyczą dostawcy i instytucji jako podmiotu stosującego.

Jeśli system podlega wymaganiom dla systemów wysokiego ryzyka, projekt powinien uwzględnić odpowiednie zarządzanie ryzykiem, dokumentację, rejestrowanie zdarzeń, przejrzystość, nadzór człowieka, dokładność, odporność i cyberbezpieczeństwo. Zakres należy ustalić na podstawie rozporządzenia AI Act i właściwego harmonogramu stosowania. Sama nazwa „agent compliance” nie rozstrzyga klasyfikacji.

RODO: minimalizacja, ocena skutków i retencja

Dane używane w monitoringu mogą ujawniać sytuację ekonomiczną, zachowania i relacje klienta. Trzeba ustalić cel, podstawę przetwarzania, zakres danych, zabezpieczenia i okresy przechowywania.

UODO wskazuje, że ocena skutków dla ochrony danych należy do administratora, z konsultacją inspektora ochrony danych. Jest wymagana przy przetwarzaniu mogącym z dużym prawdopodobieństwem powodować wysokie ryzyko dla praw lub wolności osób fizycznych. Sam nadzór człowieka nie rozstrzyga tych kwestii.

Przed pilotażem trzeba rozpoznać:

• administratora, podmioty przetwarzające i dalszych podwykonawców,
• cel i podstawę przetwarzania dla każdego źródła,
• odbiorców danych, w tym dostawcę modelu, telemetryki i narzędzi do obserwacji działania,
• dane osobowe w promptach, odpowiedziach oraz wynikach narzędzi,
• potrzebny zakres logów i dane nadmiarowe,
• retencję notatek, załączników, promptów i historii działań,
• sposób anonimizacji lub pseudonimizacji materiału do ewaluacji,
• obsługę praw osób, których dane dotyczą, z uwzględnieniem właściwych obowiązków i ograniczeń.

Deklaracja przechowywania danych w UE wymaga sprawdzenia całego przepływu. Mapa powinna obejmować logi, kopie zapasowe, kolejki, pamięć podręczną, rejestrowanie przebiegu wywołań, błędy aplikacji i eksportowane pliki.

DORA: odporność i powrót do dotychczasowej pracy

KNF opisuje DORA jako przepisy dotyczące odporności cyfrowej sektora finansowego i usług ICT. Przy projekcie instytucja ocenia m.in. dostawców, ciągłość i obsługę incydentów. Nie zakładamy, że każdy system wymaga prywatnego serwera, ani że wybór konkretnej chmury sam potwierdza zgodność.

W zakresie właściwym dla instytucji i procesu trzeba ustalić:

• krytyczność procesu oraz rolę aplikacji w obsłudze alertów,
• wymagania wobec dostawców ICT i umów,
• testy odporności oraz plan ciągłości,
• monitoring i obsługę incydentów,
• kontrolę zmian modeli, instrukcji, narzędzi i integracji,
• możliwość wyłączenia aplikacji i powrotu do pracy ręcznej,
• dostępność kolejki alertów podczas awarii.

Punktem odniesienia pozostaje rozporządzenie DORA. Przed uruchomieniem analitycy muszą wiedzieć, jak kontynuować pracę, gdy model lub integracja nie odpowiada.

Źródła sprawdzono 11 października 2026. Powyższe rozróżnienie pomaga ustalić zakres rozmowy; nie jest opinią o dopuszczalności określonego wdrożenia.

Co zmierzyć w trybie obserwacyjnym

Przed włączeniem aplikacji do obsługi decyzji można porównać przygotowany przez nią materiał z pakietem ocenionym przez analityków. Próba działa bez zmiany decyzji wobec klienta. Jej zbiór i kryteria należy ustalić przed konfiguracją, z osobną częścią do oceny.

Wynik powinien pokazać pominięte dokumenty, błędne przypisania do sprawy, zdania bez podstawy i czas poprawek. Osobno raportuje się naruszenia dostępu oraz błędnie zachowaną akceptację. Wysoka liczba poprawnych rutynowych notatek nie usuwa znaczenia pojedynczego ujawnienia danych innego klienta.

Warto mierzyć również:

• kompletność dossier dla poszczególnych typów alertów,
• liczbę szkiców i sugestii zaakceptowanych, zmienionych oraz odrzuconych przez analityków,
• rodzaje błędów i ich rozkład między typami spraw,
• próby użycia narzędzi poza uprawnieniami,
• liczbę twierdzeń bez podstawy w źródłach,
• sprawy wracające po kontroli jakości,
• czas obsługi wraz z pełnym przeglądem i poprawkami.

Porównaj czas przygotowania i pełnego przeglądu z dotychczasowym procesem. Szybszy szkic może wymagać dłuższej kontroli. Ocena językowa i ocena procesu powinny być prowadzone osobno: poprawny styl notatki nie potwierdza poprawności analizy.

Dopiero obserwacja na uprawnionym materiale instytucji pozwoli ocenić przydatność. Nie obiecujemy procentu redukcji fałszywych alarmów ani uniwersalnej wykrywalności nadużyć.

Pilotaż z jasno zapisanym celem

W ogólnej ofercie Syntalith pilotaż na uzgodnionych danych firmy trwa zwykle od 3 do 6 tygodni. To orientacyjny przedział dla ograniczonego zakresu. Termin projektu compliance zależy również od dostępów, przygotowania danych i oceny przez instytucję.

Pilotaż powinien mieć jeden zapisany cel i ograniczony zakres odpowiedzialności. Najpierw wybiera się wąski typ alertu oraz materiał oceniony przez specjalistów. Podłączenie do produkcyjnego obiegu decyzji wymaga wcześniejszego sprawdzenia wyników.

Faza 1. Zakres i ryzyka

• Wybór jednego lub dwóch dobrze opisanych typów alertów.
• Opis obecnej procedury, punktów decyzyjnych i odpowiedzialnych osób.
• Mapa danych, systemów, właścicieli i ograniczeń dostępu.
• Określenie czynności tylko do odczytu oraz działań wymagających zatwierdzenia.
• Ocena wymagań AML, RODO, AI Act, DORA i polityk wewnętrznych przez właściwe osoby.
• Zapis celu, materiału do prób i kryteriów odbioru przed konfiguracją.

Faza 2. Tryb obserwacyjny

• Aplikacja przygotowuje dossier i szkic bez wpływu na decyzję wobec klienta.
• Analitycy oceniają kompletność, przypisanie dokumentów i przydatność materiału.
• Wyniki porównuje się z pakietem ocenionym przez specjalistów, z uwzględnieniem kontekstu dostępnego w chwili analizy.
• Błędy są kategoryzowane; wspólna średnia nie może ukrywać naruszeń dostępu.
• Sprawdza się logi, retencję, aktualność zatwierdzeń i możliwość odtworzenia podstawy notatki.

Faza 3. Ograniczona produkcja

• Aplikacja działa wyłącznie w odebranym zakresie.
• Akcje zmieniające stan sprawy wymagają zatwierdzenia przez człowieka.
• Zakres automatyzacji jest formalnie uzgodniony, a ocena ryzyka pozostaje w procedurze instytucji.
• Istnieje plan wycofania zmiany i powrotu do wcześniejszej pracy.
• Compliance, bezpieczeństwo, inspektor ochrony danych i właściciel biznesowy otrzymują raport jakości.

Zmiana modelu, instrukcji lub procedury wymaga ponownego sprawdzenia zależnych zachowań. Wcześniejszy wynik próby nie potwierdza automatycznie działania po zmianie.

Ile to kosztuje

Zakres budowy zależy od źródeł, ról i wymagań odbioru. Ogólna cena agentów AI w Syntalith zaczyna się od 12 500 zł netto, ale nie stanowi oferty cenowej na system AML w banku. Koszt infrastruktury, użycia modeli, integracji i utrzymania wymaga osobnego uzgodnienia.

Ceny Syntalith: automatyzacja od 7 500 zł netto, aplikacja lub agent od 12 500 zł netto, szkolenie od 2 450 zł netto za dzień (cennik). Jeśli po Audycie zlecisz nam budowę systemu, jego koszt zaliczymy na poczet wdrożenia. Wycena powinna wskazywać, które integracje i testy obejmuje oraz jakie wydatki bieżące trzeba przewidzieć.

Najważniejsze składniki budżetu rozwiązania compliance to:

• integracja z systemem AML lub fraud, KYC, systemem prowadzącym sprawy i źródłami sankcyjnymi,
• przygotowanie wyszukiwania w procedurach i wersjonowania dokumentów,
• kontrola uprawnień narzędzi oraz zatwierdzeń,
• obserwacja działania, logi, retencja i eksport audytowy,
• próby na ocenionych danych historycznych oraz testy błędów i dostępu,
• przegląd bezpieczeństwa i ochrony danych,
• szkolenie analityków i właścicieli procesu,
• infrastruktura, użycie modeli i utrzymanie.

Wycena modelu i promptu nie obejmuje automatycznie kosztu całego obiegu compliance. Przed zakupem poproś o zakres odbioru, wymagania wobec źródeł i sposób rozliczania kosztów działania. Architektura może wykorzystywać infrastrukturę prywatną lub odpowiednio ocenione usługi zewnętrzne; wybór zależy od wymagań instytucji.

Przed pilotażem zapisujemy w umowie cel i sposób sprawdzenia wyniku. Jeśli system nie osiąga celu, wprowadzamy uzgodnione poprawki w ramach stałej ceny pilotażu. Warunki obejmują dostępność danych przewidzianych w projekcie, wystarczającą liczbę spraw do oceny i zachowanie ustalonego zakresu. Zobowiązanie dotyczy uzgodnionego wyniku technicznego; nie stanowi poświadczenia zgodności AML.

FAQ

Czy KNF akceptuje AI w compliance?

Nie ma ogólnego potwierdzenia dla każdej architektury. Instytucja powinna ocenić konkretne zastosowanie, ryzyka, nadzór człowieka, dostawców, bezpieczeństwo, ciągłość i zgodność z własnymi procedurami. Zakres oceny zależy także od tego, czy aplikacja przygotowuje materiał, czy wpływa na decyzje wobec klienta. Audyt techniczny Syntalith nie stanowi akceptacji nadzorczej.

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

Może pomóc przygotować materiał i szkic pakietu do sprawdzenia. Decyzja, formalne zatwierdzenie oraz przekazanie zawiadomienia muszą być obsłużone według procedury instytucji przez uprawnione osoby. W opisanym zakresie aplikacja nie wysyła zawiadomień samodzielnie.

Czy agent może zamykać false positives, czyli fałszywe alarmy?

W pierwszym zakresie przygotowuje materiał do oceny i pozostawia zamknięcie alertu w dotychczasowej procedurze. Automatyczne zamykanie części spraw niskiego ryzyka wymaga osobnej oceny dopuszczalności, polityki, walidacji, limitów, kontroli jakości i śladu audytowego. Dla spraw wymagających pogłębionej analizy podstawą dalszego działania pozostaje decyzja właściwej osoby.

Czy dane mogą trafiać do zewnętrznego modelu językowego?

Zależy to od rodzaju danych, podstawy przetwarzania, umów, odbiorców, konfiguracji i architektury. Możliwe warianty obejmują model w kontrolowanej infrastrukturze lub usługę zewnętrzną z odpowiednio ograniczonym kontekstem. Pseudonimizacja nie usuwa automatycznie obowiązków ochrony danych. Trzeba ocenić także logi, telemetrykę, kopie zapasowe i retencję u dostawców.

Czy LangGraph, n8n albo OpenClaw wystarczą do compliance?

Są elementami technicznymi, które trzeba ocenić w konkretnym projekcie. Wymagania obejmują proces, uprawnienia, źródła, retencję, historię zatwierdzeń, nadzór, próby odbiorowe i odpowiedzialność instytucji. Sam wybór frameworka nie potwierdza zgodności.

Ile kosztuje agent AI do monitoringu zgodności?

Ogólna cena usługi agentów AI w Syntalith zaczyna się od 12 500 zł netto. System obsługujący materiał do alertów AML wymaga wyceny źródeł, integracji, kontroli dostępu i odbioru. Audyt procesu AI zaczyna się od 2 495 zł netto, a skan procesów kosztuje 0 zł. Infrastruktura, modele i utrzymanie wymagają osobnego uzgodnienia.

Ile trwa pilotaż i co trzeba przygotować?

W ogólnej ofercie pilotaż trwa zwykle od 3 do 6 tygodni. Termin konkretnego projektu ustalamy po ocenie dostępów, danych i wymagań instytucji. Potrzebne są opis wybranego etapu, właściwe procedury, mapa źródeł, osoby odpowiedzialne za ocenę i materiał do prób z ustalonymi kryteriami. Pierwsza rozmowa może odbyć się bez przekazywania danych klientów.

Zakres pilotażu zgodności i następny krok

Jeżeli rozważasz agenta AI do monitoringu zgodności, przygotuj jeden ograniczony proces:

1. Wybierz typ alertu: częsty, dobrze opisany i z jasną procedurą.
2. Zmapuj dane: źródła, właścicieli, podstawy przetwarzania, retencję i ograniczenia dostępu.
3. Ustal zakres aplikacji: odczyt, zatwierdzenia, eskalacje i zakazane działania.
4. Zaprojektuj historię sprawy: wersje materiału, osobę zatwierdzającą i zakres logów pozwalający odtworzyć podstawę oceny.
5. Uruchom tryb obserwacyjny: bez wpływu na decyzje wobec klienta, z przeglądem jakości przez analityków.

Syntalith może przygotować techniczny zakres takiego rozwiązania i plan jego weryfikacji. W tym artykule nie przedstawiamy referencji bankowej, certyfikacji AML ani gotowego połączenia z systemem instytucji.

Umów bezpłatny skan procesów: 30 minut z inżynierem, 0 zł, pisemne podsumowanie w ciągu 2 dni roboczych. Wystarczy opis etapu, źródeł i dzisiejszego sposobu zatwierdzania. Przekazanie danych klientów wymaga wcześniejszego uzgodnienia kanału oraz zakresu. Porozmawiamy o kontrolowanym pilotażu w wąskim procesie z jasno określonym wynikiem.

Sprawdź też: Agent AI do raportowania finansowego | Agent AI: ile kosztuje? | Przewodnik tworzenia agentów 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
• GIIF: komunikat nr 22 o środkach bezpieczeństwa finansowego i zawiadomieniach
• UODO: ocena skutków dla ochrony danych
• Rozporządzenie (UE) 2024/1689, AI Act: EUR-Lex
• AI Act: załącznik III
• Komisja Europejska: harmonogram stosowania AI Act
• Rozporządzenie DORA (UE) 2022/2554: EUR-Lex
• KNF: DORA
• EBA: Guidelines on ML/TF risk factors
• FATF: Digital Transformation of AML/CFT
• LangGraph: przerwania procesu i zatwierdzenie
• LangChain: zatwierdzenie działań przez człowieka
• n8n: execution data redaction
• OpenClaw: tools