Automatyzacja AI: co musi zatwierdzić człowiek przed akcją

Automat przygotował odpowiedź na reklamację. Teraz ma kliknąć „wyślij” albo zwrócić pieniądze. Między tymi czynnościami zmienia się odpowiedzialność: tekst roboczy staje się działaniem wobec klienta. Właśnie w tym miejscu ustaw zatwierdzenie przez człowieka.

Prześledźmy fikcyjny proces sklepu. Zgłoszenie R-17 dotyczy uszkodzonego uchwytu kubka. System może odczytać opis i przygotować szkic odpowiedzi. Nie ma prawa samodzielnie przyznawać zwrotu, wymiany ani zmieniać statusu zamówienia. Ćwiczenie używa wyłącznie wymyślonych danych; nie wysyłamy wiadomości i nie uruchamiamy płatności.

Na podstawie fikcyjnego zgłoszenia R-17 przygotuj pakiet do oceny opiekuna.
Wypisz: opis problemu, brakujące informacje, proponowaną odpowiedź,
proponowane działanie oraz fakty, które je uzasadniają.
Jeśli materiał nie wystarcza do decyzji, napisz „wymaga ustalenia”.
Nie wykonuj działań i nie ogłaszaj klientowi, że decyzja została podjęta.
Zgłoszenie: „Po rozpakowaniu uchwyt kubka jest pęknięty.
Zdjęcie dołączono. Proszę o informację, co zrobić dalej”.

Wzorzec poprawnego wyniku streszcza problem i przedstawia szkic kolejnego kroku. Nie potwierdza zwrotu pieniędzy. Ten prompt pomaga przygotować materiał; ograniczenie dostępu trzeba ustawić także w systemie automatyzacji.

Gdzie umieścić zatwierdzenie

Automatyzacja to ustalony przepływ działań między systemami. Agent AI może dodatkowo wybierać narzędzia i ich parametry. Jeśli ma dostęp do wysyłania wiadomości, zatwierdzenie powinno dotyczyć konkretnej wiadomości, odbiorcy i załączników bezpośrednio przed wysłaniem.

n8n opisuje mechanizm human-in-the-loop dla narzędzi: przepływ zatrzymuje się, a człowiek zatwierdza albo odrzuca wykonanie z proponowanymi parametrami. To przykład funkcji narzędzia, nie dowód, że każdy proces z n8n ma ją już poprawnie skonfigurowaną.

W naszym scenariuszu opiekun widzi numer zgłoszenia, problem, treść odpowiedzi i adres odbiorcy pochodzący z zaufanego systemu. Nie zatwierdza ogólnego polecenia „obsłuż sprawę”. Przycisk musi odpowiadać na pytanie, co dokładnie wydarzy się po kliknięciu.

Jeśli treść lub odbiorca zmienią się po akceptacji, potrzebne jest nowe zatwierdzenie. Zgoda na wersję pierwszą nie przechodzi automatycznie na wersję trzecią, nawet gdy obie zaczynają się uprzejmym „Dzień dobry”.

Zaprojektuj ekran akceptacji na konkretnych danych. Dla fikcyjnego zgłoszenia R-17 przyjmij odbiorcę klient-test@example.invalid, bez załączników, oraz tekst: „Przyjęliśmy zgłoszenie. Opiekun sprawdzi kompletność materiałów”. To adres demonstracyjny; ćwiczenie nie służy wysyłce.

Przygotuj kartę zatwierdzenia dla fikcyjnej akcji WYSLIJ_ODPOWIEDZ_R17.
Odbiorca: klient-test@example.invalid. Załączniki: brak.
Treść: „Przyjęliśmy zgłoszenie. Opiekun sprawdzi kompletność materiałów”.
Pokaż numer sprawy, odbiorcę, pełną treść i dokładny skutek akceptacji.
Wypisz, które zmiany muszą unieważniać zatwierdzenie.
Przygotuj także komunikat po odmowie. Nie wysyłaj wiadomości.

Wzorzec pokazuje wszystkie parametry przed przyciskiem. Zmiana treści, adresata lub załączników wymaga ponownego odbioru. Odmowa pozostawia sprawę bez wysłanej odpowiedzi. Sprawdź, czy karta nie ukryła fragmentu wiadomości pod ogólnym opisem „standardowa odpowiedź”. Człowiek powinien akceptować to, co rzeczywiście trafi do odbiorcy.

Przygotowanie tekstu do takiej karty ułatwia prompt do maila. Zapisz jednak oddzielnie zgodność treści i upoważnienie do jej wysłania. Nawet poprawna odpowiedź może jeszcze czekać na właściwy moment albo osobę podejmującą decyzję.

Ogranicz uprawnienia do zadania

Daj procesowi dostęp do potrzebnego zgłoszenia, a nie do całej skrzynki i wszystkich zwrotów. Oddziel możliwość odczytu, tworzenia szkicu, wysyłania oraz operacji finansowych. Przy pierwszym etapie wystarcza odczyt i zapis materiału do oceny.

OWASP nazywa nadmierną sprawczość osobną kategorią ryzyka. Wskazuje nadmiar funkcji, uprawnień lub autonomii jako źródło szkodliwych działań. Ograniczenia trzeba ustawić w narzędziach i koncie; dopisek w poleceniu nie odbiera systemowi uprawnień.

Obcy dokument albo wiadomość mogą zawierać instrukcję próbującą zmienić zachowanie modelu. OWASP opisuje ten problem jako prompt injection. Prośba w treści reklamacji o przekazanie pełnej bazy klientów jest danymi od nadawcy, a nie upoważnieniem do wykonania operacji.

Zakres przekazywanych informacji ustal wcześniej według zasad bezpiecznych danych w AI. Sam człowiek na końcu procesu nie naprawi ujawnienia, które nastąpiło na jego początku.

Przetestuj odmowę i powtórzenie

Sprawny przycisk „zatwierdź” to połowa próby. Sprawdź, co stanie się po odrzuceniu: żadna wiadomość nie powinna wyjść. Następnie zmień odbiorcę po akceptacji i sprawdź, czy stara zgoda nadal pozwala wysłać materiał. Jeśli pozwala, zatrzymaj wdrożenie.

Przetestuj też dwukrotne uruchomienie tej samej sprawy. System powinien rozpoznać, że zatwierdzona akcja została już wykonana. Tę właściwość nazywa się idempotencją: powtórzenie żądania nie powoduje drugiego skutku. Do kontroli potrzebny jest zapis identyfikatora akcji i jej rzeczywistego wyniku.

Zdefiniuj zachowanie przy braku odpowiedzi opiekuna i przy błędzie połączenia. Cisza nie powinna oznaczać zgody. Komunikat „wysyłanie rozpoczęte” nie jest jeszcze dowodem dostarczenia. Zapisz osobno akceptację, próbę wykonania i potwierdzony rezultat.

Prześledźmy powtórzenie na fikcyjnym dzienniku. Akcja A-17 otrzymała zgodę. System rozpoczął wysyłanie, ale połączenie urwało się przed odebraniem wyniku. Po minucie proces uruchomiono ponownie. W logu nie ma ani potwierdzenia wysłania, ani potwierdzonej odmowy ze strony usługi.

Przeanalizuj fikcyjny dziennik akcji A-17 opisany powyżej.
Oddziel potwierdzone zdarzenia od nieznanego wyniku wysyłki.
Nie uznawaj przerwanego połączenia za dowód niewysłania.
Zaproponuj dane do sprawdzenia w systemie wysyłającym
przed decyzją o ponowieniu. Wskaż ryzyko drugiej wiadomości.
Przygotuj komunikat dla opiekuna bez deklaracji, że mail dotarł.

Poprawna analiza pozostawia wynik nieustalony do sprawdzenia. Różni się on zarówno od „wysłano”, jak i „nie wysłano”. W prawdziwym procesie sposób odzyskania informacji zależy od możliwości konkretnej usługi; projektant musi go ustalić, zanim odda automat do użycia. Prompt pomaga opisać problem, ale nie odczyta niepodłączonego dziennika.

Jeżeli log zdarzeń analizujesz w tabeli, zastosuj kontrolę danych w arkuszu. Dwa wiersze z identyfikatorem A-17 mogą opisywać ponowienie jednej akcji, a nie dwie różne sprawy. Ustal znaczenie wiersza, zanim policzysz liczbę wykonanych operacji i ogłosisz skuteczność procesu.

Odbierz jeden zamknięty przebieg

Przeprowadź próbę na koncie testowym i fikcyjnym zgłoszeniu. Obejrzyj wejście, propozycję, decyzję człowieka, wykonanie i zapis wyniku. Osobno przejdź odmowę oraz ponowienie. Dopiero ten materiał pozwala ocenić, czy granica działa także poza schematem na ekranie.

Dopisz do scenariusza jeszcze brak odpowiedzi opiekuna. Ustal, kto zobaczy oczekującą sprawę i w jakim momencie trzeba ją przejąć ręcznie. Nie obciążaj modelu wyborem osoby upoważnionej do podjęcia decyzji: tę rolę określ w procesie. W dzienniku zachowaj powód zatrzymania. Przy odbiorze poproś osobę spoza zespołu wdrożeniowego, żeby odnalazła sprawę R-17 i wyjaśniła, czy wiadomość wyszła. Jeśli nie umie tego ustalić, dopracuj widoczność stanu przed uruchomieniem automatu.

Jeśli automatyzacja powstaje z ustaleń zespołu, najpierw sprawdź notatkę ze spotkania i decyzje. Wybór platformy oprzyj na zadaniu i kryteriach odbioru narzędzia. W programie Kursu AI, rozwijanym przez Aeneia, automatyzacja wynika z wcześniej opisanego procesu. Na jego schemacie zaznacz teraz ostatni moment, w którym da się zatrzymać działanie przed kontaktem z klientem.

*Dokumentację sprawdzono 30 października 2026 r. Wpisy OWASP dotyczą edycji 2025. Proces reklamacji jest autorskim scenariuszem, nie wdrożonym systemem.*