Agent AI w firmie: co może zrobić sam, a co zatwierdza człowiek?

Krótka odpowiedź

Agent AI w firmie może sam wykonywać powtarzalne, odwracalne działania w ściśle określonym zakresie: zebrać dane, je uporządkować, przygotować projekt odpowiedzi albo utworzyć zadanie w systemie. Człowiek powinien zatwierdzać działania, których błąd może zmienić zobowiązanie firmy, dane źródłowe, uprawnienia, pieniądze, komunikację zewnętrzną lub sytuację klienta.

To nie jest podział na „AI samodzielne” i „AI niesamodzielne”. Poziom autonomii ustala się osobno dla konkretnej czynności, danych i konsekwencji błędu. Dobrze zaprojektowany agent nie dostaje ogólnego polecenia „obsłuż proces”, lecz wąski cel, dozwolone narzędzia, limity oraz wyraźny punkt przekazania sprawy człowiekowi.

Asystent, agent i automatyzacja regułowa: trzy różne role

Te pojęcia bywają używane zamiennie, choć odpowiadają za inny rodzaj pracy. Rozdzielenie ich przed wyborem technologii pozwala uniknąć dwóch błędów: budowania agenta tam, gdzie wystarczy reguła, oraz nadawania modelowi dostępu, którego nie potrzebuje.

Przykład: reguła może przekazać formularz z tematem „reklamacja” do właściwej kolejki. Asystent może zaproponować odpowiedź na podstawie zaakceptowanej bazy wiedzy. Agent może odczytać zgłoszenie, znaleźć powiązane zamówienie, przygotować odpowiedź i utworzyć sprawę w CRM. Nie wynika z tego, że powinien sam przyznać rabat, zmienić warunki umowy czy wysłać wiadomość w imieniu firmy.

Agent nie jest więc „mądrzejszą automatyzacją” z definicji. Jego przewagą jest radzenie sobie z treścią i ścieżkami, których nie da się sensownie rozpisać w każdym wariancie. Ceną jest większa niepewność odpowiedzi modelu oraz ryzyko wywołania niewłaściwego działania przez narzędzie.

Jaki poziom autonomii dobrać do kosztu błędu?

Najpierw nazwij koszt błędu w języku procesu, a nie technologii. Czy błędny krok da się łatwo cofnąć? Czy dotyka jednej wewnętrznej notatki, czy klienta, rozliczenia albo danych produkcyjnych? Czy istnieje niezależna reguła, która może sprawdzić wynik? Dopiero potem wybierz poziom autonomii.

Poniższa macierz jest narzędziem do rozmowy z operacjami, IT i właścicielem procesu. Nie zastępuje analizy ryzyka ani decyzji prawnej.

Koszt błędu nie jest jedynym kryterium. Znaczenie ma też częstotliwość działania: nawet drobny błąd powielony setki razy może stać się problemem. Dlatego limit liczby operacji i limit czasu działania są częścią decyzji o autonomii, a nie technicznym dodatkiem na końcu projektu.

Przykładowy przebieg: od zgłoszenia do przygotowanej odpowiedzi

Załóżmy hipotetyczny proces obsługi zapytania, które trafia do wspólnej skrzynki. To przykład projektowy, a nie opis wdrożenia ani wyniku klienta Aether.

1. Nowe zgłoszenie uruchamia obieg. System zapisuje identyfikator sprawy i przekazuje agentowi tylko treść oraz dane niezbędne do klasyfikacji.
2. Agent wybiera jedną z dozwolonych kategorii, odczytuje rekord sprawy i przeszukuje zatwierdzoną bazę wiedzy w trybie tylko do odczytu.
3. Agent buduje szkic odpowiedzi, wskazuje źródła wewnętrzne użyte do jej przygotowania i proponuje status sprawy. Jeśli brakuje danych, nie zgaduje: oznacza sprawę jako wymagającą uzupełnienia.
4. Reguły poza modelem sprawdzają format, odbiorcę, dozwoloną kategorię oraz próg ryzyka. Zgłoszenia dotyczące reklamacji, warunków handlowych lub danych wrażliwych kierują się automatycznie do człowieka.
5. Pracownik widzi projekt, źródła i proponowane działanie. Może go poprawić, zatwierdzić, odrzucić albo przekazać do kolejki specjalistycznej.
6. Dopiero po akceptacji system wysyła wiadomość i zapisuje wynik. W rejestrze zostaje ślad: jaka sprawa, jaki model i wersja obiegu, jakie narzędzia wywołano, kto zatwierdził oraz jaki był rezultat.

W tym układzie agent przyspiesza przygotowanie sprawy, ale nie dostaje prawa do tworzenia zobowiązania firmy. Sam sposób, w jaki sięga po rekord sprawy i zapisuje wynik, jest osobną decyzją projektową: opisuje ją tekst o połączeniu AI z CRM i ERP. Jeśli proces kiedyś ma przejść na poziom 2, najpierw warto wybrać jedną odwracalną czynność, na przykład dodanie tagu lub utworzenie roboczego zadania, oraz zmierzyć jakość na reprezentatywnej próbie.

Granice, które powinny istnieć przed pierwszym uruchomieniem

NIST AI RMF opisuje zarządzanie ryzykiem jako pracę ciągłą, obejmującą między innymi funkcje govern, map, measure i manage. W praktyce dla agenta oznacza to, że firma powinna najpierw nazwać właściciela procesu i akceptowany poziom ryzyka, opisać kontekst użycia, testować zachowanie, a potem monitorować działanie i reagować na incydenty. To ramy zarządzania, nie certyfikat pełnego bezpieczeństwa.

OWASP określa ryzyko Excessive Agency jako możliwość wykonania szkodliwych działań wskutek nieoczekiwanego, niejednoznacznego lub zmanipulowanego wyniku modelu. Źródłem bywa nadmiar funkcji, uprawnień albo autonomii. Dlatego kontrola powinna być zaprojektowana na kilku warstwach:

• Uprawnienia minimalne. Osobna tożsamość techniczna powinna otrzymać tylko potrzebne zakresy, np. odczyt wybranej bazy zamiast konta administratora. System docelowy ma sam egzekwować autoryzację; model nie może być jedynym arbitrem tego, czy operacja jest dozwolona.
• Wąskie narzędzia. Zamiast funkcji „wykonaj dowolne polecenie” udostępnij konkretne akcje, takie jak „pobierz status sprawy” lub „utwórz szkic”. Każda powinna walidować dane wejściowe i zakres operacji poza modelem.
• Rejestr działań możliwy do prześledzenia. Rejestruj żądanie, decyzję polityki, wywołania narzędzi, identyfikator obiegu i rezultat. Treść logów oraz czas przechowywania trzeba dopasować do polityki danych, aby samo logowanie nie tworzyło nowego problemu z dostępem do informacji.
• Limity i zatrzymanie. Ustaw maksymalną liczbę działań na sprawę, limit czasu, limit wartości operacji oraz wyłącznik dla pojedynczego narzędzia i całego obiegu. Alarm bez osoby odpowiedzialnej za reakcję nie jest kontrolą.
• Cofnięcie zmian i obsługa skutków. Dla każdego działania opisz, co można odwrócić, kto to robi i jak obsłużyć przypadki nieodwracalne. Cofnięcie zapisu w systemie nie cofnie wysłanego e-maila ani ujawnionej informacji; tam potrzebny jest punkt akceptacji przed wykonaniem oraz procedura incydentowa.
• Zatwierdzanie przez człowieka (human in the loop). Zatwierdzenie ma być konkretną decyzją człowieka z widokiem na dane i konsekwencje, a nie automatycznym kliknięciem. Reguły eskalacji powinny obejmować również niską pewność, konflikt danych i prośbę wykraczającą poza cel obiegu.

Kiedy agent AI nie ma sensu?

Agent nie jest obowiązkowym etapem cyfryzacji. Jeżeli ścieżka procesu jest stabilna, wejścia są ustrukturyzowane, a decyzję można zapisać jako kilka jednoznacznych warunków, prostsza automatyzacja regułowa będzie łatwiejsza do testowania i utrzymania. Jeżeli potrzebny jest wyłącznie szkic, wyszukanie lub podsumowanie na prośbę pracownika, wystarczy asystent bez prawa uruchamiania narzędzi.

Nie warto zaczynać od agenta także wtedy, gdy firma nie ma właściciela procesu, aktualnego źródła prawdy, kryterium poprawnej decyzji albo zdolności do obsługi wyjątków. Brak tych elementów nie znika po dodaniu modelu: najczęściej staje się mniej widoczny, a przez to trudniejszy do wykrycia.

Sygnałem ostrzegawczym jest również potrzeba przyznania szerokich uprawnień, aby demo „działało”. Jeśli nie można wskazać minimalnego zestawu funkcji i danych potrzebnych do celu, warto zmniejszyć zakres albo wrócić do analizy procesu. Tak samo, gdy szkoda po błędzie jest wysoka, a człowiek nie może sprawdzić działania przed jego skutkiem: wtedy autonomiczne wykonanie nie jest dobrym punktem startu.

Co zrobić dalej

Wybierz jeden proces, w którym zespół już dziś podejmuje powtarzalną decyzję. Na jednej stronie opisz: zdarzenie uruchamiające, dane wejściowe, oczekiwany wynik, koszt błędu, czynności odwracalne, działania wymagające akceptacji oraz właściciela reakcji na incydent. Z tej karty powstanie decyzja, czy potrzebna jest reguła, asystent czy ograniczony agent, a także od jakiego poziomu autonomii zacząć. Zanim agent wyjdzie poza demonstrację, ta sama karta powinna przejść przez warunki przejścia z prototypu na produkcję. Jeśli potrzebujesz takiej analizy procesu, zobacz zakres usług Aether lub skontaktuj się z zespołem.

Źródła i metodologia

• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 26 stycznia 2023, https://www.nist.gov/itl/ai-risk-management-framework. Wykorzystano jako podstawę opisu ciągłego zarządzania ryzykiem oraz funkcji govern, map, measure i manage.
• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), 26 lipca 2024, https://doi.org/10.6028/NIST.AI.600-1. Wykorzystano jako kontekst ryzyk charakterystycznych dla generatywnej AI.
• OWASP Foundation, LLM06:2025 Excessive Agency, 2025, https://genai.owasp.org/llmrisk/llm062025-excessive-agency/. Wykorzystano dla zasad minimalizacji funkcji, uprawnień i autonomii oraz dla zatwierdzania działań o dużym wpływie.

Macierz i przykładowy przebieg są autorskim, neutralnym przykładem metody projektowej. Nie przedstawiają danych, wdrożeń ani wyników Aether Solutions.