Automatyzacja z agentami AI wykłada się rzadko na tym, że model czegoś nie potrafi. Wykłada się na tym, że zrobił coś, czego nikt mu wprost nie zabronił, a nikt nie zdążył sprawdzić przed skutkiem. Wysłał wiadomość do klienta. Zamknął zgłoszenie. Nadpisał pole w systemie ERP. Każda z tych rzeczy z osobna jest drobna. Przestaje być, kiedy dotyczy trzystu rekordów naraz.
Pytanie „czy człowiek ma to zatwierdzić” jest więc pytaniem projektowym, nie filozoficznym. I ma złą odpowiedź, która brzmi rozsądnie: „zawsze”. Jeśli operator klika „akceptuj” czterdzieści razy dziennie, po tygodniu klika bez czytania. Automatyzacja niczego nie przyspieszyła, a kontrola jest pozorna, bo w logu widnieje „zatwierdzone”, choć nikt tego nie przeczytał.
Trzy pytania, które rozstrzygają, gdzie postawić bramkę
Pierwsze: czy skutek da się cofnąć. Wpis do bazy testowej cofa się jednym poleceniem, przelew i wiadomość wysłana do klienta nie cofają się wcale. Drugie: czy skutek wychodzi poza firmę. Wewnątrz problem naprawia się po cichu, na zewnątrz naprawia się przeprosinami. Trzecie: ile kosztuje pomyłka w porównaniu z kosztem czekania. Jeśli błąd kosztuje godzinę pracy, a czekanie na akceptację dobę, bramka jest droższa niż to, przed czym chroni.
Te trzy pytania dają zwykle zaskakująco mało miejsc, w których człowiek jest naprawdę potrzebny. W procesie liczącym czterdzieści kroków bywa ich kilka.
Jak rozdzieliliśmy to u siebie
Granica biegnie u nas po skutku zewnętrznym. Praca wewnętrzna, czyli analiza kodu, przygotowanie zmiany, uruchomienie testów, postawienie środowiska testowego, idzie automatycznie i nikt jej po drodze nie klika. Wszystko, co wychodzi na zewnątrz, czyli wiadomość do klienta, publikacja, przekazanie danych do zewnętrznej usługi, wymaga jawnej zgody człowieka. Bez wyjątku „drobna sprawa”.
Wdrożenie na produkcję ma osobną bramkę, bo skutek widzą natychmiast wszyscy użytkownicy. Przed nią: kopia zapasowa i znacznik wersji, komplet testów automatycznych, plan wycofania przygotowany wcześniej, nie pisany w panice. Dopiero potem zapada decyzja o przełączeniu ruchu. Podejmuje ją człowiek, patrząc na wyniki testów, a nie na zapewnienie agenta, że wszystko poszło dobrze.
Dobra bramka pokazuje skutek, nie zamiar
Komunikat „agent chce wysłać wiadomości do kontrahentów, zatwierdzić?” jest bezużyteczny, bo zatwierdzający nie wie, co podpisuje. Bramka staje się użyteczna, gdy pokazuje: ile rekordów obejmie operacja, trzy przykładowe wyniki w ostatecznej postaci, wykaz różnic wobec stanu obecnego oraz to, czego operacja nie ruszy.
Do tego trzy rzeczy, które łatwo pominąć przy pierwszym wdrożeniu:
- domyślna odpowiedź musi być bezpieczna: brak reakcji znaczy „nie rób”, nigdy „rób”,
- jedna bramka na operację, nie pięć pod rząd, bo pięć uczy klikania w ciemno,
- zapis kto, kiedy i co zatwierdził, trzymany osobno od samego procesu; przy sporze albo kontroli to jedyny dowód, że decyzję podjął człowiek.
Antywzorce, które widać najczęściej
Zgoda blankietowa na cały dzień pracy agenta. Zatwierdzanie po fakcie, czyli powiadomienie „wysłano, potwierdź”, które nie jest kontrolą, tylko archiwum. I najbardziej podstępne: alert w kanale, który wszyscy wyciszyli.
To ostatnie kosztowało nas trzydzieści jeden dni zwłoki w publikacji. Powiadomienie powtarzało tę samą treść przez wiele dni, więc zostało wyciszone jako szum. Rzecz w tym, że w pewnym momencie treść przestała być prawdziwa: przeszkoda ustąpiła, a komunikat wyglądał identycznie jak wcześniej. Zasada, którą sobie z tego zapisaliśmy: wyciszać wolno stan, z którym i tak nic nie zrobisz, nigdy stan, który właśnie stał się wykonalny.
Kiedy nadzór człowieka przestaje być wyborem
Przy systemach wysokiego ryzyka w rozumieniu EU AI Act nadzór człowieka jest obowiązkiem z art. 14: osoba nadzorująca musi rozumieć wynik systemu, móc go zignorować i móc system zatrzymać. To wymaga interfejsu, który na to pozwala, nie akapitu w procedurze.
Drugi przepis, o którym firmy pamiętają rzadziej, to art. 22 RODO. Jeśli decyzja opiera się wyłącznie na zautomatyzowanym przetwarzaniu i wywołuje wobec osoby skutki prawne albo podobnie istotne, tej osobie przysługuje prawo do interwencji człowieka. Rekrutacja, ocena zdolności kredytowej, odrzucenie reklamacji. Bramka zatwierdzania jest wtedy nie tyle dobrą praktyką, ile elementem zgodności. O samych obowiązkach transparentności pisaliśmy szerzej w checkliście zgodności AI dla MŚP.
Jedno zastrzeżenie
Projektowanie bramek wydłuża wdrożenie. Zwykle o kilka dni analizy, bo trzeba przejść proces krok po kroku i dla każdego kroku odpowiedzieć na trzy pytania z początku tekstu. Firmy, które ten etap pomijają, wdrażają szybciej i zwykle wracają do niego po pierwszym incydencie, tyle że wtedy pod presją i z gorszym skutkiem.
FAQ
Ile bramek to za dużo?
Praktyczny sprawdzian: jeśli osoba zatwierdzająca nie potrafi z pamięci powiedzieć, co ostatnio zatwierdziła i dlaczego, bramek jest za dużo albo pokazują za mało treści. Lepiej mieć trzy, które ktoś czyta, niż dwadzieścia klikanych odruchowo.
Czy da się to dołożyć do automatyzacji, która już działa?
Tak i zwykle właśnie tak to wygląda, bo potrzeba bramki ujawnia się dopiero na realnych danych. Warunek jest jeden: proces musi mieć wyraźnie oddzielony moment „przygotowane” od „wykonane”. Jeśli agent liczy i wysyła w jednym kroku, ten krok trzeba najpierw rozciąć.
Kto powinien zatwierdzać, osoba techniczna czy właściciel procesu?
Właściciel procesu, gdy decyzja dotyczy treści: czy ta wiadomość ma pójść do klienta. Osoba techniczna, gdy dotyczy sposobu wykonania: czy ta zmiana może iść na produkcję. Mieszanie tych ról kończy się tym, że techniczny zatwierdza treść, na której się nie zna, więc zatwierdza wszystko.
Przejdźmy przez Państwa proces
Jeśli mają Państwo automatyzację, przy której nie wiadomo, gdzie postawić granicę zatwierdzania, najprościej przejść ten proces razem, krok po kroku, i wskazać te kilka miejsc, które faktycznie wymagają człowieka. Umówmy bezpłatną konsultację przez formularz kontaktowy.