Przejdź do treści
płatności·ai

Bezpieczeństwo i autoryzacja

Human-in-the-loop w płatnościach agenta — gdzie wstawić człowieka

Jak zaprojektować human-in-the-loop dla płatności agenta AI: próg kwotowy, dobry ekran potwierdzenia, związek z SCA i ograniczanie skutków błędu lub ataku.

Autor: Redakcja PłatnościAI · Zespół redakcyjny Publikacja: 28 czerwca 2026 5 min czytania

Gdy agent AI sam realizuje płatności, najważniejsze pytanie projektowe brzmi: w którym momencie zatrzymać automat i poprosić człowieka o decyzję? W skrócie: człowieka wstawiamy tam, gdzie cena pomyłki rośnie — czyli powyżej ustalonego progu kwotowego oraz przy każdej transakcji odbiegającej od normy. Drobne, powtarzalne i przewidywalne zakupy mogą iść w pełni automatycznie w granicach mandatu. Wszystko, co istotne lub nietypowe, przechodzi przez krótkie, jednoznaczne potwierdzenie. Dobrze ustawiony human-in-the-loop (HITL) to nie hamulec dla wygody, tylko bezpiecznik, który ogranicza skutki błędu modelu i udanego ataku.

Po co w ogóle człowiek w pętli płatności?

Agent działa szybko i bez zmęczenia, ale właśnie dlatego pojedynczy błąd potrafi się zwielokrotnić, zanim ktokolwiek go zauważy. Źródła ryzyka są trzy: halucynacja lub błędne zrozumienie zadania, manipulacja z zewnątrz (na przykład wstrzyknięcie złośliwej instrukcji przez treść strony lub maila) oraz zwykła zmiana okoliczności, której agent nie zna. Pętla z człowiekiem nie usuwa tych ryzyk, ale przerywa łańcuch automatyzacji w punkcie o najwyższej stawce — tuż przed nieodwracalnym przesunięciem pieniędzy.

Kluczowe jest słowo „nieodwracalnym”. Wstawienie człowieka ma największy sens tam, gdzie cofnięcie operacji jest trudne, kosztowne albo niemożliwe: przelew do nowego odbiorcy, płatność za granicę, transakcja w stablecoinie, zwiększenie limitu. Tam, gdzie operację łatwo wycofać lub jest ona z natury drobna, dokładanie kliknięcia tylko irytuje i uczy ludzi klikać „akceptuj” bez czytania — co psuje cały mechanizm.

Próg kwotowy: pierwsza i najprostsza linia

Najprostszy, a zarazem najskuteczniejszy parametr to próg kwotowy. Poniżej niego agent płaci samodzielnie w ramach przyznanego mandatu i limitów, powyżej — pyta człowieka. Wartość progu nie jest uniwersalna; ustala się ją osobno do profilu ryzyka: inną dla zakupów biurowych, inną dla rozliczeń z dostawcami.

Sam jeden próg to jednak za mało. W praktyce warto połączyć kilka wymiarów:

  • Próg pojedynczej transakcji — twardy limit na jedną płatność.
  • Limit skumulowany — dzienny lub tygodniowy, żeby seria drobnych płatności nie obeszła progu jednostkowego.
  • Limit częstotliwości — maksymalna liczba transakcji w oknie czasu; nagły wzrost tempa to sygnał ostrzegawczy.
  • Reguły kontekstowe — nowy odbiorca, nietypowa pora, nieznany kraj czy nowa kategoria wydatku powinny obniżać próg lub wymuszać potwierdzenie niezależnie od kwoty.

Dzięki temu agent nie pyta o każdą kawę, ale zatrzyma się, gdy ktoś każe mu wysłać średnią kwotę do odbiorcy, którego nigdy wcześniej nie widział.

Kiedy automat, a kiedy zgoda człowieka

SytuacjaTrybUzasadnienie
Powtarzalny zakup, znany odbiorca, mała kwotaautomatniska stawka, łatwa odwracalność
Kwota powyżej progupotwierdzenierośnie cena pomyłki
Nowy odbiorca lub nowy rachunekpotwierdzenieklasyczny wektor oszustwa
Nietypowa pora, kraj, kategoriapotwierdzenieodstępstwo od wzorca
Zmiana limitu lub uprawnień agentapotwierdzeniedecyzja o charakterze konfiguracyjnym
Wiele prób z rzędu po odrzuceniuwstrzymanie + przeglądmożliwy atak lub pętla błędu

Ważna zasada: odrzucenie powinno być tak samo łatwe jak akceptacja, a brak odpowiedzi nigdy nie może oznaczać zgody. Timeout to „nie”, nie „tak”.

UX potwierdzenia: kilka sekund na świadomą decyzję

Ekran potwierdzenia jest sercem całego mechanizmu — i najczęściej psutym elementem. Jeśli prośba jest niejasna albo zjawia się zbyt często, człowiek przestaje czytać i klika odruchowo. Dobre potwierdzenie spełnia kilka warunków:

  • Trzy fakty od razu i wyraźnie: kwota, odbiorca, cel. Bez przewijania, bez szukania. To, co człowiek zatwierdza, musi być widoczne w jednym rzucie oka.
  • Zaufane urządzenie i kanał. Potwierdzenie powinno trafiać tam, gdzie kontroluje je użytkownik (telefon, aplikacja banku, klucz), a nie być wyłącznie w obrębie sesji samego agenta, którą atakujący może próbować przejąć.
  • Brak domyślnej zgody. Żadnego wstępnie zaznaczonego „akceptuj”, żadnego przycisku akceptacji większego i jaśniejszego od odrzucenia.
  • Jasny powód zapytania. „Kwota powyżej progu” albo „nowy odbiorca” pomaga ocenić, czy sytuacja jest normalna.
  • Pełna lista pozycji. Jeśli agent kupuje koszyk, człowiek widzi, co w nim jest — bez doklejonych po cichu pozycji.

Celem jest decyzja świadoma w kilka sekund, a nie najszybsze możliwe „dalej”. Liczba zapytań ma być na tyle niska, by każde z nich człowiek traktował poważnie. Zbyt częste pytanie to nie więcej bezpieczeństwa — to droga do bezrefleksyjnego klikania.

Związek z SCA: człowiek jako czynnik uwierzytelnienia

Human-in-the-loop dobrze wpina się w wymogi silnego uwierzytelnienia. W modelu PSD2 i SCA wobec agentów potwierdzenie transakcji przez człowieka — gestem na zaufanym urządzeniu, biometrią czy kodem — pełni rolę realnego czynnika uwierzytelnienia i potwierdzenia woli płatnika. Innymi słowy moment „zapytaj człowieka” i moment „wykonaj SCA” mogą być tym samym punktem w przepływie: agent przygotowuje płatność, a właściciel ją autoryzuje swoim uwierzytelnieniem.

Płynie z tego praktyczny wniosek projektowy. Ekran potwierdzenia powinien wiązać autoryzację z konkretną kwotą i odbiorcą (tak zwane dynamic linking), żeby zatwierdzenie nie dało się przenieść na inną transakcję. Człowiek nie potwierdza wtedy abstrakcyjnego „tak”, lecz dokładnie tę płatność, którą widzi.

Ograniczanie skutków: ostatni bezpiecznik, nie jedyny

HITL warto traktować jako jedną z warstw, a nie całość obrony. Limity i mandaty ograniczają, ile agent w ogóle może wydać. Logi i powiadomienia pozwalają wykryć problem po fakcie. Potwierdzenie człowieka stoi w najczulszym miejscu — tuż przed wydaniem pieniędzy — i łapie to, czego nie wyłapały reguły.

Dlatego seria odrzuceń albo nagła fala próśb o potwierdzenie nie jest tylko niedogodnością dla użytkownika; to sygnał. Może oznaczać, że agent padł ofiarą wstrzyknięcia instrukcji i jest „popychany” do płatności. Dobry system w takiej sytuacji nie tylko odrzuca pojedynczą transakcję, ale wstrzymuje agenta i prosi o przegląd. Tak ustawiona pętla z człowiekiem zamienia próbę nadużycia z cichej straty w zauważalny alarm — i właśnie po to wstawiamy człowieka tam, gdzie stawka jest najwyższa.

Podajemy fakty ze źródłami i datami. Nigdy nie stwierdzamy z góry, że dany dostawca jest niebezpieczny — pokazujemy weryfikowalne dane i pytania, które zespół powinien zadać, zanim wdroży płatności agentowe.

Najczęstsze pytania

Kiedy płatność agenta powinna wymagać człowieka? +

Najczęściej powyżej ustalonego progu kwotowego albo gdy transakcja odbiega od normy: nowy odbiorca, nietypowa pora, kraj wysokiego ryzyka. Drobne, powtarzalne zakupy w ramach mandatu idą automatem, a transakcje istotne lub podejrzane wymagają świadomego potwierdzenia człowieka.

Jak zaprojektować dobre potwierdzenie? +

Pokaż jednoznacznie kwotę, odbiorcę i cel płatności, na zaufanym urządzeniu, tak by człowiek mógł świadomie zatwierdzić lub odrzucić w kilka sekund. Unikaj domyślnej zgody, ukrytych pozycji i przycisków, które łatwo kliknąć odruchowo.

Powiązane lektury