Sytuacja wyjściowa

Instytucja pieniądza elektronicznego w Anglii, ok. 110 osób, obsługuje rosnący wolumen płatności klientów detalicznych i biznesowych. Poniedziałek zespołu compliance zaczyna się od kolejki alertów z systemu monitorowania transakcji (AML/KYC): kilkaset flag do przejrzenia, z których większość okazuje się fałszywym alarmem po pierwszym spojrzeniu (L1 review), a część trafia do drugiej linii (L2) na dokładniejszą analizę. Model AI, który generuje te flagi, wdrożono osiemnaście miesięcy temu od zewnętrznego dostawcy, żeby nadążyć za wolumenem, którego zespół compliance nie jest w stanie przeglądać ręcznie.

Część kolejki starzeje się ponad wewnętrzny SLA na przegląd, a notatki zamykające alert na poziomie L1 bywają wklejane z gotowego szablonu, bez odrębnego uzasadnienia dla konkretnej transakcji. Klient czasem dzwoni do obsługi, bo jego płatność zamarła w miejscu po tym, jak system zażądał dodatkowej weryfikacji, a konsultant obsługi klienta nie wie, dlaczego, bo nie ma wglądu w to, co wywołało żądanie.

Nikt jednak nie ustalił, kto formalnie odpowiada za próg, od którego transakcja staje się alertem: analityk L1 zgłasza, że próg wydaje się zbyt czuły (za dużo fałszywych alarmów), ale nie ma mandatu do jego zmiany, a osoba, która wdrażała model, już nie pracuje w firmie. Gdy alert eskaluje do decyzji o zgłoszeniu SAR (Suspicious Activity Report), analityk L2 pisze uzasadnienie od zera, bo model nie zostawia wyjaśnienia, które dane doprowadziły do flagi, tylko wynik.

Co ustalił audyt

Adresat obowiązku monitorowania i SAR

Audyt zaczyna od pytania o adresata obowiązku: to sama firma płatnicza, jako „relevant person" w rozumieniu Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017, musi prowadzić ongoing monitoring relacji z klientem: „scrutiny of transactions… to ensure that the transactions are consistent with the relevant person's knowledge of the customer, the customer's business and risk profile" (reg. 28(11)). Obowiązek nie przechodzi na dostawcę modelu, niezależnie od tego, kto go zbudował.

Drugie ustalenie audytu: obowiązek zgłoszenia SAR z s. 330 Proceeds of Crime Act 2002 ciąży na osobie, która wie lub ma uzasadnione podstawy do podejrzenia prania pieniędzy, i musi ona zgłosić to „as soon as is practicable" do nominated officer (w praktyce Money Laundering Reporting Officer, MLRO) albo do NCA. Model AI może pomóc dojść do tego podejrzenia, ale nie może go zastąpić: obowiązek jest osobisty, nie systemowy.

Brak horyzontalnego aktu AI w Wielkiej Brytanii

Trzecie ustalenie: w Wielkiej Brytanii nie ma jednego, horyzontalnego aktu AI do sprawdzenia, FCA sama odsyła firmy do sprawdzenia, jak jej istniejące reguły (m.in. Consumer Duty) stosują się do AI, nie do odrębnego „AI rulebooka".

Ujawnienie materiału i zautomatyzowane decyzje

Audyt sprawdza też osobno, kto widzi materiał po eskalacji: s. 333A Proceeds of Crime Act 2002 czyni przestępstwem ujawnienie przez osobę z sektora regulowanego informacji mogącej zaszkodzić postępowaniu, w tym faktu złożenia zgłoszenia, więc dane alertu i uzasadnienia nie mogą wracać do dostawcy modelu jako materiał do strojenia bez odrębnej analizy tego przepisu.

Audyt sprawdza osobno, czy jakikolwiek wynik modelu prowadzi do w pełni zautomatyzowanej decyzji o kliencie (np. zamknięcie rachunku, odmowa onboardingu), bo to aktywuje art. 22A do 22D UK GDPR (wprowadzone przez Data (Use and Access) Act 2025), stosowane od 5 lutego 2026 r., z prawem klienta do żądania interwencji człowieka. Typowo żadna decyzja o zamknięciu rachunku w firmie na tym etapie wdrożenia nie jest jeszcze w pełni automatyczna, audyt to odnotowuje jako stan obecny, nie jako gwarancję na przyszłość.

Decyzje governance

Zarząd wyznacza właściciela modelu z realnym mandatem: to ta osoba, nie dostawca technologii, decyduje o zmianie progu alarmowego, i to na niej, nie na analityku L1, spoczywa odpowiedzialność za skalibrowanie liczby fałszywych alarmów wobec ryzyka przeoczenia realnego sygnału.

Po drugie, zarząd wprowadza wymóg dokumentacji wyjaśnialności: każdy alert, który trafia do L2, musi nieść ze sobą dane wejściowe, które go wygenerowały, nie tylko wynik, bo to jest materiał, na którym MLRO opiera decyzję o SAR, a nie substytut tej decyzji. Po trzecie, zarząd ustala, że jeśli w przyszłości model zacznie samodzielnie decydować o zamknięciu rachunku bez przeglądu człowieka, taka zmiana wymaga odrębnej oceny wobec art. 22A do 22D UK GDPR, zanim zostanie wdrożona, nie po fakcie.

Po czwarte, jeśli dostawca modelu odmówi ujawnienia, jakie dane wejściowe faktycznie trafiają do progu alarmowego, zarząd traktuje to jako przesłankę do wstrzymania rozszerzania modelu na nowe segmenty klientów, dopóki dostawca nie zgodzi się na przegląd tych danych wejściowych przez właściciela modelu.

Co zautomatyzowano i dlaczego dopiero teraz

Dopiero po wyznaczeniu właściciela modelu firma automatyzuje odświeżanie CDD (customer due diligence refresh) dla klientów niskiego ryzyka: system przypomina zespołowi, które profile klientów wymagają aktualizacji dokumentów zgodnie z reg. 28, i porządkuje kolejkę według terminu, a nie według tego, kto zgłosił się pierwszy. Ta automatyzacja nie ocenia, czy klient jest podejrzany, tylko przypomina o terminie odświeżenia dokumentacji, i z tego powodu nie musiała czekać na zamknięcie pracy nad progiem alarmowym. Sposób rozdzielania „przypomnienie o terminie" od „ocena ryzyka klienta" opisujemy szerzej w AI governance i w automatyzacjach AI.

Rezultat

Alert transakcyjny, który wcześniej trafiał do kolejki bez adresata mogącego zmienić próg, ma teraz nazwanego właściciela modelu i ślad danych wejściowych, na podstawie których MLRO ocenia, czy zgłosić SAR. Odświeżanie CDD dla klientów niskiego ryzyka przestaje czekać na to, kto pierwszy zauważy przeterminowany profil, i staje się kolejką sortowaną według terminu.

Czego ten scenariusz nie mówi

Nie zakłada, że firma jest podmiotem regulowanym w UE: jeśli obsługuje też klientów z Unii, może dodatkowo podlegać unijnemu AI Act przez zasięg eksterytorialny (art. 2 ust. 1 lit. c), to wymaga odrębnej analizy, którą ten scenariusz nie zastępuje.

Przy firmie działającej wyłącznie na rynku brytyjskim unijny AI Act nie ma zastosowania, a wartość audytu i automatyzacji jest operacyjna i wynika z prawa krajowego, nie z rozporządzenia unijnego. Nie ocenia, czy konkretny próg alarmowy jest właściwie skalibrowany, to decyzja biznesowa i regulacyjna właściciela modelu, poparta doświadczeniem compliance, którą musi potwierdzić prawnik lub doradca klienta w Wielkiej Brytanii: Novus Point nie jest kancelarią.

Następny krok

Dla zarządu, który podejrzewa, że model monitorowania transakcji działa bez ustalonego właściciela i bez dokumentacji wyjaśnialności wyniku, punktem wejścia jest rozmowa 30-minutowa przez formularz kontaktowy, prowadzona przez Google Meet, bez gwarancji wyniku regulacyjnego z góry. Kto chce najpierw sam zmapować, gdzie AI wpływa na decyzje o kliencie, może zacząć od bezpłatnego audytu wstępnego pod adresem novus-point.pl/audyt.