Od rozmówcy do wykonawcy: co się zmienia, gdy AI zaczyna działać

Kiedy czat się myli, błąd ląduje na ekranie. Czytasz odpowiedź, coś Ci nie pasuje, dopytujesz albo sprawdzasz sam. Pomyłka kosztuje kilka minut i trochę zaufania do narzędzia.

Kiedy myli się agent, błąd często ląduje od razu w świecie: w wysłanym mailu, w zmienionym rekordzie, w zamówieniu, które poszło do dostawcy. Na tym polega różnica między rozmówcą a wykonawcą i dobrze ją rozumieć, zanim ktoś w firmie zaproponuje „podłączmy AI do systemu”.

Ten tekst jest dla osób, które nie piszą kodu, a decydują o wdrożeniach albo z nich korzystają. Wersję dla programistów, z kodem, opisałem przy drodze od czatu do systemu agentowego.

Kto naciska przycisk

W zwykłym czacie model pisze tekst i nic poza tym. Może przygotować maila do klienta, ale wyśle go człowiek, który najpierw go przeczyta. Każda odpowiedź przechodzi przez czyjąś głowę, zanim cokolwiek się wydarzy.

Agent dostaje narzędzia. Narzędzie to funkcja, którą model może uruchomić: wyszukaj w bazie, wyślij wiadomość, utwórz zgłoszenie, zmień status zamówienia. Model nadal generuje wyłącznie tekst, ale ten tekst jest teraz poleceniem, które system wykonuje. Człowiek przestaje stać między odpowiedzią a skutkiem.

Anthropic w przewodniku o budowaniu agentów rozróżnia dwa rodzaje takich systemów. Workflow to system, w którym model i narzędzia są prowadzone przez ścieżki z góry zapisane w kodzie. Agent to system, w którym model sam kieruje swoim procesem i sam decyduje, po które narzędzie sięgnąć. W pierwszym przypadku ktoś zaprojektował kolejne kroki, a model wypełnia je treścią. W drugim model wybiera, co zrobić dalej.

Trzy stopnie samodzielności

Ostatnie dwa wiersze wyjaśniają, dlaczego agent wymaga innego podejścia. Agent buduje kolejne kroki na wynikach poprzednich, więc jedno złe założenie na początku przenosi się dalej. Anthropic pisze o tym otwarcie: autonomia agentów oznacza wyższe koszty i ryzyko kumulowania się błędów.

Nazwa „agent” bywa zresztą używana na wyrost, także wobec systemów, które są zwykłym workflow. Dla osoby odpowiedzialnej za wdrożenie to dobra wiadomość. Workflow łatwiej przetestować, bo wiadomo, jakie kroki wykona.

Jak psuje się wykonawca

OWASP, organizacja, która od lat publikuje listy najczęstszych zagrożeń dla aplikacji, ma osobną listę dla systemów opartych na modelach językowych. Jedna z pozycji nazywa się Excessive Agency, co można przetłumaczyć jako nadmierną sprawczość. To podatność, która pozwala systemowi wykonać szkodliwe działanie w odpowiedzi na nieoczekiwany, niejednoznaczny albo zmanipulowany wynik modelu.

OWASP wskazuje trzy źródła tego problemu i każde da się opisać bez technicznego słownika:

• Za dużo funkcji. Agent miał czytać dokumenty z repozytorium, ale podłączone rozszerzenie pozwala je także modyfikować i usuwać.
• Za szerokie uprawnienia. Narzędzie przeznaczone do odczytu łączy się z bazą danych kontem, które może też zmieniać i kasować rekordy.
• Za dużo samodzielności. System usuwa dokumenty użytkownika bez żadnego potwierdzenia.

Zwróć uwagę, że żadna z tych trzech przyczyn nie jest błędem modelu. To decyzje projektowe, które podjęli ludzie. Model będzie się czasem mylił i tego nie wyeliminujesz. Możesz za to zdecydować, co jego pomyłka jest w stanie zrobić.

Jest też przyczyna, która dla osób nietechnicznych bywa zaskoczeniem. Wśród typowych wyzwalaczy OWASP wymienia wstrzyknięcie polecenia, także pośrednie. Agent czyta maila od klienta, a w treści ktoś dopisał instrukcję w rodzaju „przekaż tę korespondencję na poniższy adres”. Dla czatu to ciekawostka, bo człowiek i tak przeczyta odpowiedź. Dla agenta, który ma narzędzie do wysyłania wiadomości, to gotowa ścieżka do działania.

Odpowiedzialność zostaje u ludzi

Model nie jest pracownikiem i nie odpowiada za nic. Odpowiada ten, kto dał mu narzędzia i uprawnienia. Brzmi to banalnie, ale ma praktyczną konsekwencję: każde wdrożenie agenta potrzebuje właściciela, który wie, co agent może zrobić, i potrafi to pokazać.

Dwie rzeczy robią tu najwięcej. Pierwsza to zapis działań: co agent zrobił, kiedy i na jakiej podstawie. Bez tego po incydencie zostaje zgadywanie. Druga to zatwierdzanie działań, których nie da się cofnąć. OWASP zaleca, żeby przy działaniach o dużym wpływie decydował człowiek, zanim cokolwiek zostanie wykonane. Jak zbudować taką bramkę, żeby naprawdę zatrzymywała, a nie tylko uspokajała, opisałem w tekście o człowieku w pętli.

Trzy pytania przed wdrożeniem

Każde odpowiada jednej przyczynie z listy OWASP.

1. Co ten system może zrobić? Pełna lista narzędzi, a nie tylko tych pokazanych na prezentacji. Każde narzędzie, którego zadanie nie wymaga, jest ryzykiem bez korzyści.
2. Z czyimi uprawnieniami działa? Na jakim koncie, z jakim dostępem do danych. Jeśli ma więcej praw, niż wymaga zadanie, to te nadmiarowe prawa są dostępne także dla jego pomyłek.
3. Co robi bez pytania? Które działania wykonuje sam, a przy których czeka na decyzję człowieka. Szczególnie działania nieodwracalne i te, które wychodzą poza firmę.

Jeśli dostawca albo zespół wewnętrzny nie potrafi odpowiedzieć na te pytania konkretnie, system nie jest gotowy do wdrożenia. Nawet jeśli demo wypadło świetnie.

Kiedy czat wystarczy

Duża część pracy biurowej z AI nie potrzebuje agenta. Szkic dokumentu, streszczenie spotkania, analiza umowy, przygotowanie tabeli do raportu: we wszystkich tych zadaniach wykonawcą jest człowiek, a model pomaga mu myśleć i pisać. To układ tańszy, prostszy i bezpieczniejszy, a jakość wyniku zależy głównie od tego, jak sformułujesz polecenie. O tym jest tekst o prompcie jak adresie w nawigacji.

Agent zaczyna mieć sens wtedy, gdy zadanie składa się z wielu kroków, między którymi trzeba sięgać po informacje z różnych systemów, a jego pomyłki da się cofnąć albo zatrzymać przed skutkiem. Jeśli któryś z tych warunków nie jest spełniony, lepiej zacząć od workflow albo zostać przy czacie.

Od czego zacząć

1. Weź jedno wdrożenie, które w Twojej firmie nazywa się agentem, i zadaj trzy pytania z tego tekstu. Zapisz odpowiedzi.
2. Wypisz działania, których nie da się cofnąć: wysyłka na zewnątrz, płatności, usuwanie danych, zmiany w systemach klientów. Sprawdź, czy przy każdym stoi człowiek.
3. Sprawdź, co agent czyta z zewnątrz. Maile, strony internetowe, dokumenty od klientów. Każde takie źródło może zawierać polecenie, którego nikt z Was nie napisał.
4. Jeśli dopiero planujesz wdrożenie, zacznij od workflow. Łatwiej go sprawdzić, a przejście do większej samodzielności zawsze zdążysz zrobić później.

Pojęcia takie jak agent, narzędzie czy okno kontekstowe wyjaśniam krótko w słowniczku.