Jest taki moment w każdej rozmowie o agentach AI, w którym ktoś mówi: “przecież to prosty prompt i wywołanie API, zróbmy to w tydzień”. I rzeczywiście - demo agenta, który czyta maila i proponuje odpowiedź, powstaje w jedno popołudnie. Problem w tym, że między demem a rozwiązaniem, któremu firma powierza realne decyzje - uznanie reklamacji, korektę faktury, odpowiedź do klienta - jest przepaść. Tę przepaść wypełnia proces inżynierski. I właśnie o nim jest ten tekst.
Opiszemy krok po kroku, jak w praktyce powstaje rozwiązanie agentowe budowane na platformie UiPath - od pierwszego pytania “czy ten proces w ogóle nadaje się na agenta”, przez projekt, wizualizację przepływu w BPMN, budowę wspieraną narzędziami AI, grounding w danych firmy, testy i guardraile, aż po produkcyjny nadzór. Celowo zatrzymujemy się na poziomie koncepcji: pokazujemy, co się dzieje na każdym etapie i dlaczego, a nie które przyciski klikać. To nie jest tutorial - to mapa terenu dla osób, które będą taki projekt zamawiać, nadzorować albo rozliczać.
Żeby nie było abstrakcyjnie, przez cały tekst poprowadzimy jeden przewodni przykład. Jest fikcyjny, ale złożony z elementów, które w projektach widujemy regularnie: średniej wielkości firma produkcyjna obsługuje reklamacje klientów B2B. Zgłoszenia przychodzą mailem, w załącznikach bywają zdjęcia i protokoły rozbieżności, dane o zamówieniu i dostawie siedzą w systemie ERP, polityka reklamacyjna w dokumentach, a decyzja o uznaniu reklamacji wymaga interpretacji umowy. Dziś robi to dwóch specjalistów, kolejka rośnie, czas odpowiedzi też. Pomysł: niech agent AI przygotowuje decyzje reklamacyjne. Zobaczmy, co naprawdę trzeba zrobić, żeby ten pomysł bezpiecznie dowieźć na produkcję.
Zanim padnie pierwsza linijka kodu: proces, nie prompt
Najpierw jedno rozróżnienie, które porządkuje całą resztę. Klasyczna automatyzacja (RPA) wykonuje kroki deterministycznie: te same dane wejściowe, ten sam wynik, za każdym razem. Agent AI działa inaczej - dostaje cel, kontekst i zestaw narzędzi, a sposób dojścia do wyniku wybiera sam. To jest jego siła (radzi sobie ze zmiennością, której nie da się zamknąć w regułach) i jednocześnie jego ryzyko (może dojść do wniosku, którego nikt nie przewidział).
Z tego rozróżnienia wynika najważniejsza zasada tego tekstu: rozwiązanie agentowe projektuje się jak proces biznesowy z punktami kontroli, a nie jak skrypt. Pytanie nie brzmi “co agent ma umieć”, tylko “które decyzje w procesie oddajemy agentowi, które zostają przy człowieku i jak to udokumentujemy”. Osiem kroków, które za chwilę przejdziemy, to w gruncie rzeczy osiem bramek, na których te pytania dostają odpowiedzi. Pisaliśmy już na tym blogu, że sam kod automatyzacji powstaje dziś szybko - to droga na produkcję zajmuje czas. Ten tekst pokazuje, czym ta droga jest wypełniona.
Krok 1. Kwalifikacja: czy ten proces w ogóle nadaje się na agenta
Najdroższy błąd w projektach agentowych popełnia się przed ich rozpoczęciem - wybierając niewłaściwy proces. Dlatego pierwszym krokiem nie jest projektowanie agenta, tylko uczciwa kwalifikacja kandydata. W praktyce oceniamy cztery rzeczy.
Charakter decyzji. Jeśli decyzję da się opisać kompletnym zestawem reguł (“faktura zgodna z zamówieniem i limitem - księguj”), agent jest przerostem formy nad treścią - klasyczny robot zrobi to taniej, szybciej i w pełni przewidywalnie. Agent ma sens tam, gdzie decyzja wymaga interpretacji: niejednoznaczne dane wejściowe, język naturalny, konieczność zestawienia kilku źródeł, ocena “podobne, ale nie identyczne”. Obsługa reklamacji jest tego podręcznikowym przykładem - każde zgłoszenie jest trochę inne, a decyzja zależy od treści umowy, historii klienta i okoliczności dostawy.
Cena błędu. Nie ma agentów bezbłędnych, są tylko procesy o różnej tolerancji na pomyłkę. Jeżeli pojedynczy błąd oznacza szkodę trudną do cofnięcia - wypłatę dużej kwoty, komunikat do regulatora, decyzję kadrową - proces może wejść do programu agentowego tylko z twardym punktem zatwierdzenia przez człowieka albo nie wchodzić wcale. To nie jest ograniczenie technologii, to zdrowy rozsądek zapisany w architekturze.
Dostępność danych i wiedzy. Agent podejmuje decyzje na podstawie tego, do czego ma dostęp. Jeśli polityka reklamacyjna istnieje głównie w głowach dwóch specjalistów, to przed budową agenta czeka nas praca, którą i tak warto wykonać: spisanie zasad. W naszym przykładzie firma ma politykę reklamacyjną w dokumentach i umowy ramowe z klientami - to wystarczający punkt startu.
Wolumen i powtarzalność. Agent, który obsłuży pięć spraw miesięcznie, rzadko się obroni. Kolejka reklamacji rosnąca szybciej niż zespół - to jest uzasadnienie biznesowe.
Wynik kwalifikacji w naszym przykładzie: proces nadaje się na rozwiązanie agentowe, ale hybrydowe. Zbieranie danych z ERP - robot (deterministyczne). Interpretacja zgłoszenia i przygotowanie propozycji decyzji - agent. Zatwierdzenie decyzji powyżej ustalonego progu wartości - człowiek. Już na tym etapie powstaje pierwszy artefakt governance: dokument kwalifikacji z oceną ryzyka, który za kilka miesięcy będzie odpowiedzią na pytanie audytora “dlaczego uznaliście, że ten proces można powierzyć AI”.
Warto też nazwać najczęstszy anty-wzorzec, jaki widzimy na tym etapie: proces wybrany dlatego, że jest modny, a nie dlatego, że przeszedł kwalifikację. Agent do odpowiadania na wszystkie maile firmy, agent do “ogólnej analizy dokumentów”, agent-asystent zarządu bez zdefiniowanego zakresu - to projekty, które kończą się efektownym demem i cichym pogrzebem, bo nie mają ani mierzalnego rezultatu, ani właściciela procesu, ani kryterium sukcesu. Odwrotny anty-wzorzec jest równie kosztowny: wciskanie agenta tam, gdzie od lat wystarczyłby dobrze napisany robot albo formularz z walidacją. Test, który proponujemy klientom, jest prozaiczny: jeżeli doświadczony pracownik potrafi opisać decyzję w tym procesie kompletną instrukcją “jeśli-to”, proces nie potrzebuje agenta. Jeżeli zamiast instrukcji opowiada historie przypadków i mówi “to zależy” - jest o czym rozmawiać.
Krok 2. Projekt agenta: rola, narzędzia, kontekst, granice
Dopiero teraz projektujemy samego agenta. Dobry projekt agenta przypomina dobrze napisany zakres obowiązków nowego pracownika i składa się z czterech elementów.
Rola. Jednoznaczny opis, kim agent jest i za co odpowiada: “jesteś asystentem ds. reklamacji; analizujesz zgłoszenia klientów B2B i przygotowujesz propozycję decyzji zgodną z polityką reklamacyjną firmy; nie komunikujesz się z klientem bezpośrednio; nie podejmujesz decyzji ostatecznych powyżej progu”. Im precyzyjniej opisana rola, tym mniej miejsca na “twórczość” w złym tego słowa znaczeniu.
Narzędzia. Agent działa przez narzędzia, które mu jawnie udostępniamy - i tylko przez nie. W ekosystemie UiPath narzędziem agenta może być workflow robota (na przykład “pobierz historię zamówienia z ERP”), wywołanie API przez Integration Service, zapytanie do indeksu wiedzy. To fundamentalna różnica względem “czatbota z dostępem do wszystkiego”: lista narzędzi jest zamknięta, każda pozycja na niej to świadoma decyzja projektowa. Agent reklamacyjny dostaje cztery narzędzia: odczyt danych zamówienia i dostawy, odczyt umowy ramowej klienta, przeszukanie polityki reklamacyjnej, zapis propozycji decyzji. Nie dostaje narzędzia “wyślij maila do klienta” - to dzieje się dalej w procesie, po zatwierdzeniu.
Kontekst. Co agent wie o firmie i procesie: polityka reklamacyjna, definicje kategorii wad, progi wartości, format oczekiwanego uzasadnienia. Ten element rozwiniemy w kroku 5, bo sposób podania kontekstu decyduje o jakości odpowiedzi bardziej niż wybór modelu.
Granice autonomii. Wprost zapisane: co agent robi sam, co eskaluje, kiedy ma się zatrzymać. W naszym przykładzie: propozycje decyzji do progu wartości idą do wykonania po lekkiej weryfikacji, powyżej progu - obowiązkowe zatwierdzenie, a zgłoszenia, w których agent nie potrafi ustalić stanu faktycznego, trafiają do człowieka z opisem, czego zabrakło. Agent, który umie powiedzieć “nie wiem”, jest cenniejszy od agenta, który zawsze ma odpowiedź.
Na tym etapie zapada też decyzja architektoniczna: agent low-code czy kodowany. UiPath Agent Builder pozwala złożyć agenta z roli, narzędzi i kontekstu bez programowania - i dla większości agentów procesowych, takich jak nasz reklamacyjny, to właściwy wybór: szybciej, czytelniej, łatwiej w utrzymaniu. Coded Agents (agenci pisani w kodzie, na frameworkach takich jak LangGraph czy LlamaIndex, wdrażani na tę samą platformę) wchodzą do gry, gdy logika wymaga niestandardowego przepływu rozumowania, złożonych struktur danych albo integracji, których nie ma w katalogu. Zasada praktyczna: zaczynaj od low-code, schodź do kodu wtedy, gdy wymagania naprawdę tego żądają - nie odwrotnie.
Do projektu należy jeszcze jedna decyzja, którą zbyt często podejmuje się mimochodem: wybór modelu językowego. Nasza rekomendacja jest przewrotna - potraktujcie model jak komponent wymienny, nie jak fundament. Rynek modeli zmienia się co kwartał i rozwiązanie, które na sztywno zrosło się z jednym dostawcą, za rok będzie miało problem: albo z kosztami, albo z jakością, albo z polityką firmy wobec tego dostawcy. Platforma pośrednicząca w dostępie do modeli (w UiPath tę rolę pełni warstwa zaufania, do której wrócimy w kroku 7) pozwala podmienić model pod agentem bez przebudowy całego rozwiązania - pod warunkiem, że projekt od początku traktował model jako zależność konfigurowaną, a definicja agenta, jego narzędzia i testy żyją niezależnie od niego. Kryteria wyboru na dziś są klasyczne: jakość na Waszych sprawach testowych (nie na benchmarkach z internetu), koszt na sprawę, wymagania dotyczące miejsca przetwarzania danych. Kolejność nieprzypadkowa.
Krok 3. Wizualizacja i orkiestracja: proces widać, zanim powstanie
To jest serce całego podejścia i powód, dla którego w tytule tego wpisu jest słowo “wizualizacja”. Agent zaprojektowany w kroku 2 nie wisi w próżni - jest jednym z uczestników procesu biznesowego. I ten proces trzeba narysować, zanim cokolwiek zostanie zbudowane.
W UiPath tę warstwę obsługuje Maestro - narzędzie orkiestracji procesów oparte na notacji BPMN, czyli standardzie diagramów procesów biznesowych, który analitycy znają od lat. Na jednym diagramie modelujemy cały przepływ reklamacji: przyjęcie zgłoszenia, klasyfikację, zebranie danych, analizę agenta, bramkę decyzyjną, zatwierdzenie przez człowieka, wykonanie decyzji, odpowiedź do klienta. Każdy krok jest przypisany do wykonawcy jednego z trzech typów: robot (kroki deterministyczne), agent (kroki wymagające interpretacji), człowiek (decyzje i wyjątki).
Dlaczego to takie ważne? Z trzech powodów, które w projektach widzimy raz za razem.
Po pierwsze: wspólny język. Diagram BPMN czyta zarówno dyrektor operacyjny, jak i deweloper. Kiedy na warsztacie projektowym rysujemy proces reklamacyjny, dyskusja “czy agent może sam uznawać reklamacje do progu X” toczy się nad konkretną bramką na diagramie - a nie nad abstrakcją. Decyzje governance przestają być załącznikiem do projektu, stają się elementami rysunku. Bramka zatwierdzenia przez człowieka (human-in-the-loop, HITL) to na diagramie konkretny, widoczny element - nie dopisek w dokumentacji, o którym można zapomnieć.
Po drugie: granice odpowiedzialności. Kiedy proces jest narysowany, widać dokładnie, dokąd sięga autonomia agenta. Audytor, pełnomocnik ds. bezpieczeństwa informacji czy nowy członek zespołu nie musi czytać kodu, żeby zrozumieć, kto podejmuje którą decyzję. W świecie, w którym regulacje coraz częściej pytają o nadzór człowieka nad systemami AI, taki diagram jest dokumentem zgodności sam w sobie.
Po trzecie: proces długotrwały pod kontrolą. Reklamacja nie kończy się w minutę - czeka na dane, czeka na człowieka, czasem czeka na odpowiedź klienta. Maestro prowadzi każdą instancję procesu przez dni czy tygodnie, pamięta jej stan i pokazuje na żywo, gdzie każda sprawa utknęła. To także odpowiedź na pytanie, które zawsze pada przy agentach: “a co, jeśli agent się zawiesi albo odpowie bzdurą?”. Odpowiedź brzmi: proces to zauważy, bo agent jest jednym krokiem w orkiestrze, a nie samotnym solistą - krok ma limity czasu, obsługę błędów i ścieżkę eskalacji jak każdy inny.
Na diagramie modelujemy też to, co w rzeczywistych procesach stanowi większość pracy projektowej: wyjątki. Co się dzieje, gdy klient dośle uzupełnienie do sprawy, która już czeka na zatwierdzenie? Gdy reklamacja okaże się duplikatem? Gdy w trakcie analizy klient wycofa zgłoszenie? W podejściu “agent jako czatbot” te scenariusze są niczyje i wychodzą na jaw na produkcji. W podejściu procesowym każdy z nich to jawna ścieżka na diagramie, zaprojektowana i przetestowana zanim pierwszy klient o cokolwiek dośle. To także tutaj zapada decyzja, jak sprawy trudne prowadzone są do końca: reklamacja sporna nie znika z systemu w momencie eskalacji do człowieka - zostaje sprawą w tym samym procesie, z pełną historią tego, co ustalił agent, żeby człowiek nie zaczynał od zera.
O tym, jak UiPath ewoluował od automatyzacji zadań do platformy orkiestrującej agentów, roboty i ludzi, pisaliśmy szerzej w tekście o tym, że UiPath przestał być RPA. Tu wystarczy jedno zdanie podsumowania: diagram procesu jest kontraktem między biznesem, IT i governance - i wszystko, co zbudujemy w kolejnych krokach, ma się z tego kontraktu rozliczać.
Krok 4. Budowa wspierana AI: agent pomaga budować agenta
Paradoks współczesnych projektów automatyzacyjnych: narzędzia AI przyspieszają także samą budowę rozwiązań AI. W praktyce wygląda to tak, że zespół deweloperski pracuje z asystentami kodowania - takimi jak Claude Code - rozszerzonymi o skille i integracje UiPath, które uczą asystenta struktury projektów, konwencji nazewniczych i dobrych praktyk platformy. Asystent potrafi przygotować szkielet projektu, zaproponować definicję agenta, wygenerować workflow narzędzia, sprawdzić spójność nazewnictwa - a deweloper projektuje, weryfikuje i zatwierdza.
W naszym przykładzie reklamacyjnym wygląda to konkretnie. Definicję agenta (rola, narzędzia, format wyjścia) z kroku 2 zespół przekłada na projekt w Agent Builderze, a workflow “pobierz dane zamówienia z ERP” - deterministyczne narzędzie robota - powstaje przy wsparciu asystenta kodowania, który zna strukturę projektów UiPath i podpowiada implementację zgodną z przyjętymi w firmie standardami. Rzeczy, które kiedyś zajmowały dni (szkielety, integracje, rutynowy kod), zajmują godziny.
I tu ważne zastrzeżenie, bez którego ten krok byłby marketingową bajką: przyspieszenie dotyczy pisania, nie odpowiedzialności. Kod wygenerowany przez asystenta przechodzi przegląd człowieka dokładnie tak samo, jak kod napisany ręcznie - a w projektach agentowych ten przegląd jest wręcz ważniejszy, bo błędy bywają subtelniejsze. Zespół, który traktuje asystenta kodowania jak zaufanego seniora, którego nie trzeba sprawdzać, powiela dokładnie ten błąd, przed którym sam chce chronić biznes przy wdrażaniu agentów: oddaje decyzje bez nadzoru. Zasada jest prosta i symetryczna: AI proponuje, człowiek zatwierdza - na poziomie kodu tak samo jak na poziomie decyzji reklamacyjnej.
Warto przy tym rozumieć, skąd bierze się jakość pracy takiego asystenta, bo to nie magia, tylko inżynieria kontekstu. Asystent kodowania jest dokładnie tak dobry, jak wiedza, którą mu podamy - brzmi znajomo? To ta sama zasada groundingu, którą za chwilę zastosujemy do agenta biznesowego. Skille i pliki kontekstu projektu uczą asystenta konwencji nazewniczych zespołu, struktury repozytorium, standardów przeglądu; bez nich generuje kod poprawny, ale obcy, który zespół i tak przepisze. Dlatego dojrzałe zespoły inwestują w tę warstwę tak samo świadomie, jak w sam kod - a asystent odwdzięcza się też w drugą stronę, jako niezmordowany recenzent: przegląd architektury, wychwytywanie odstępstw od konwencji, wstępna weryfikacja workflow przed przeglądem człowieka. O tym, jak wygląda praca z coding agentami w ekosystemie UiPath, pisaliśmy przy okazji otwarcia platformy na Claude Code i Codex.
Jest jeszcze jedna korzyść z tego podejścia, rzadko wymieniana: dokumentacja przestaje być zaległością. Asystent kodowania generuje opisy, komentarze i dokumenty projektowe równolegle z kodem - a w projekcie, który za chwilę stanie przed audytem AI governance, kompletna dokumentacja to nie luksus, tylko wymóg.
Krok 5. Grounding: agent musi wiedzieć, nie zgadywać
Model językowy bez dostępu do wiedzy firmy zrobi to, co umie najlepiej: udzieli płynnej, przekonującej i potencjalnie błędnej odpowiedzi. Dlatego żaden poważny agent procesowy nie działa “z głowy” - działa na wiedzy, którą mu jawnie podłączamy. Ten krok nazywa się groundingiem (ugruntowaniem) i decyduje o jakości rozwiązania bardziej niż jakikolwiek inny.
W platformie UiPath służy do tego Context Grounding: mechanizm, który indeksuje dokumenty firmowe i podaje agentowi te fragmenty, które są istotne dla konkretnej sprawy. W naszym przykładzie indeksujemy politykę reklamacyjną, umowy ramowe z klientami i katalog kategorii wad. Kiedy agent analizuje zgłoszenie od klienta, nie pyta modelu “co zwykle robi się z reklamacją zarysowanej palety” - dostaje do ręki właściwy paragraf polityki i właściwy zapis umowy tego konkretnego klienta, i na ich podstawie buduje propozycję decyzji z uzasadnieniem cytującym źródło.
Druga noga groundingu to dane transakcyjne: fakty o zamówieniu, dostawie, fakturze, historii klienta. Te agent pobiera przez narzędzia z kroku 2 - workflow robota sięgający do ERP, konektory Integration Service do pozostałych systemów. Zasada architektoniczna, której pilnujemy: agent dostaje dane przez kontrolowane narzędzia, nigdy przez “wklejenie wszystkiego do prompta”. To ważne z trzech powodów: bezpieczeństwa (dostęp do danych podlega tym samym uprawnieniom co zawsze), kosztów (nie płacimy za przetwarzanie tysięcy zbędnych tokenów) i jakości (model pracuje na wyselekcjonowanych faktach, nie szuka igły w stogu siana).
Grounding ma też wymiar organizacyjny, o którym warto powiedzieć głośno: jeśli polityka reklamacyjna jest nieaktualna, sprzeczna albo napisana tak, że nie rozumie jej człowiek - agent też jej nie zrozumie, tylko w odróżnieniu od człowieka nie przyjdzie z tym do przełożonego. Projekty agentowe bezlitośnie obnażają jakość dokumentacji procesów. Dobra wiadomość: uporządkowanie tej wiedzy zostaje w firmie na zawsze, niezależnie od losów samego agenta.
Jest jeszcze pytanie o utrzymanie: wiedza się zmienia, a agent tego sam nie zauważy. Nowa wersja polityki reklamacyjnej, aneks do umowy ramowej, zmiana progów - każda z tych zmian musi mieć drogę do indeksu wiedzy, najlepiej jako element istniejącego procesu zarządzania dokumentami, a nie dobra wola kogoś, kto “przy okazji podmieni plik”. W projektach ustalamy to wprost: kto jest właścicielem każdego źródła wiedzy, jak często jest przeglądane i jak wygląda aktualizacja indeksu po zmianie. Brzmi biurokratycznie, ale alternatywa jest gorsza: agent, który z pełnym przekonaniem stosuje politykę sprzed dwóch wersji, uzasadniając decyzje paragrafami, które już nie obowiązują.
Krok 6. Testowanie: jak sprawdzić coś, co za każdym razem odpowiada trochę inaczej
Testowanie klasycznej automatyzacji jest binarne: dla danych X proces ma zwrócić Y, wynik jest zgodny albo nie. Z agentem tak się nie da - to samo zgłoszenie reklamacyjne agent może dziś uzasadnić innymi słowami niż jutro i oba uzasadnienia mogą być poprawne. Testowanie rozwiązań agentowych wymaga więc innego podejścia i to jest krok, który w harmonogramach bywa najbardziej niedoszacowany.
Podstawowym narzędziem są ewaluacje (evals): przygotowany zawczasu zestaw spraw testowych z oczekiwanymi rezultatami, przepuszczany przez agenta wielokrotnie i oceniany nie po dokładnym brzmieniu odpowiedzi, tylko po jej właściwościach. Czy decyzja jest zgodna z polityką? Czy uzasadnienie powołuje się na właściwy zapis umowy? Czy sprawy powyżej progu zawsze - naprawdę zawsze - trafiają do eskalacji? W zestawie testowym muszą być nie tylko sprawy typowe, ale przede wszystkim graniczne: zgłoszenie bez numeru zamówienia, reklamacja klienta bez umowy ramowej, wartość dokładnie na progu, załącznik, z którego nic nie wynika, a nawet zgłoszenie z treścią próbującą manipulować agentem. Na naszym blogu pisaliśmy o agentic testing - podejściu, w którym testy same eksplorują zachowanie systemu zamiast odtwarzać sztywny scenariusz - w projektach agentowych ta filozofia znajduje naturalne zastosowanie.
Do tego dochodzi testowanie całego procesu, nie tylko agenta: czy orkiestracja w Maestro poprawnie obsługuje limity czasu, czy eskalacje trafiają do właściwych osób, czy robot odzyskuje się po niedostępności ERP. Platforma UiPath domyka to narzędziami testowymi (Test Cloud), które pozwalają traktować scenariusze procesowe jak przypadki testowe z prawdziwego zdarzenia - wersjonowane, uruchamiane cyklicznie, raportowane.
Praktyczna rada z projektów: zestaw ewaluacyjny budujcie razem z ekspertami procesu, na prawdziwych (zanonimizowanych) sprawach z przeszłości, i traktujcie go jak aktywo - będzie Wam potrzebny przy każdej zmianie modelu, prompta czy polityki reklamacyjnej. To Wasz papierek lakmusowy na pytanie “czy po tej zmianie agent nadal działa dobrze”.
Osobną kategorią są testy bezpieczeństwa. Agent, który czyta treści od zewnętrznych nadawców - a nasz reklamacyjny czyta maile klientów - jest z definicji narażony na próby manipulacji: zgłoszenie może zawierać treść spreparowaną tak, by przekonać model do zignorowania instrukcji, zawyżenia decyzji albo ujawnienia informacji, których ujawniać nie powinien. To klasa ataków znana jako prompt injection i traktujemy ją w projektach agentowych tak, jak w klasycznych systemach traktuje się dane wejściowe od użytkownika: jako niezaufane, dopóki nie udowodnią inaczej. W zestawie testowym muszą się znaleźć sprawy celowo złośliwe, a wynik oczekiwany jest zawsze ten sam: agent trzyma się roli, stosuje politykę i eskaluje, zamiast wykonywać polecenia z treści zgłoszenia. Tej klasie zagrożeń poświęcamy zresztą osobny cykl na tym blogu - Bezpieczny Wtorek - bo temat rośnie razem z liczbą wdrożonych agentów.
Krok 7. Guardraile i AI Trust Layer: co agentowi wolno, a czego nie
Wszystko, co zrobiliśmy do tej pory, opisywało, co agent ma robić. Guardraile opisują, czego nie może - i egzekwują to technicznie, a nie tylko w dokumentacji. To rozróżnienie jest sednem tego kroku: zapis w projekcie “agent nie wysyła odpowiedzi do klienta” jest deklaracją; brak narzędzia do wysyłki w konfiguracji agenta jest gwarancją.
Warstwa guardraili w dojrzałym rozwiązaniu agentowym działa na kilku poziomach. Na poziomie agenta: zamknięta lista narzędzi, limity liczby kroków rozumowania, wymóg strukturalnego formatu odpowiedzi, walidacja wyników przed przekazaniem dalej. Na poziomie procesu: bramki HITL na decyzjach powyżej progu, limity wartości, reguły czterech oczu tam, gdzie wymaga ich polityka firmy. I na poziomie platformy - i tu wchodzi UiPath AI Trust Layer: centralna kontrola tego, z jakich modeli AI korzystają agenci w całej organizacji, jakie dane mogą do tych modeli trafiać (z maskowaniem danych wrażliwych włącznie), oraz pełna rejestrowalność każdej interakcji z modelem.
Ten trzeci poziom bywa niedoceniany, a to on odróżnia “mamy agenta” od “mamy program agentowy pod kontrolą”. Kiedy w firmie działa jeden agent, polityki można pilnować ręcznie. Kiedy działa ich dwudziestu - zbudowanych przez różne zespoły, w różnym czasie, na różnych modelach - bez centralnej warstwy zaufania nikt już nie odpowie na proste pytania: które procesy korzystają z którego modelu, czy dane osobowe nie wyciekają do zewnętrznych API, kto zatwierdził taką konfigurację. O tym, jak utrzymać kontrolę nad rosnącą liczbą agentów, pisaliśmy w tekście o governed autonomy - tu podkreślimy jedno: guardraile projektuje się razem z agentem, nie po incydencie.
W naszym przykładzie reklamacyjnym pełny zestaw wygląda tak: agent nie ma narzędzia komunikacji z klientem; propozycje powyżej progu wartości obowiązkowo przechodzą przez zatwierdzenie w Action Center; dane osobowe klientów indywidualnych są maskowane przed wysłaniem do modelu; każde wywołanie modelu jest logowane z pełnym kontekstem; a jeśli agent trzykrotnie nie potrafi domknąć analizy, sprawa wraca do człowieka. Nudne? Właśnie o to chodzi. Dobre guardraile są nudne - ekscytujące są incydenty, których dzięki nim nie ma.
Krok 8. Produkcja i nadzór: wdrożenie to początek, nie koniec
Rozwiązanie przechodzi na produkcję przez tę samą infrastrukturę, którą UiPath daje klasycznym automatyzacjom: Orchestrator zarządza wdrożeniem, uprawnieniami, harmonogramami i kolejkami, a proces w Maestro rusza na realnych sprawach. I tu zaczyna się etap, o którym entuzjastyczne prezentacje o agentach milczą: nadzór.
Agent na produkcji wymaga monitorowania w trzech wymiarach. Operacyjnym - czy proces działa: ile spraw przepływa, gdzie powstają zatory, ile trafia do eskalacji, jak długo człowiek czeka na dane i odwrotnie. To pokazują pulpity procesowe Maestro i Orchestratora. Jakościowym - czy agent nadal decyduje dobrze: jaki odsetek jego propozycji człowiek zatwierdza bez zmian, jaki koryguje, jaki odrzuca. Rosnący wskaźnik korekt to najwcześniejszy sygnał dryfu - zmieniły się dane, zmienił się charakter zgłoszeń, zmienił się model. Ten wskaźnik warto mierzyć od pierwszego dnia, bo jego trend mówi więcej niż każdy pojedynczy pomiar. Kosztowym - ile kosztuje obsługa sprawy: wywołania modeli mają swoją cenę i proces, który w pilotażu kosztował grosze, przy pełnym wolumenie potrafi zaskoczyć. Limity i alerty kosztowe to element konfiguracji, nie opcja.
Do tego dochodzi rzecz, którą z perspektywy audytu uważamy za obowiązkową: kompletny ślad audytowy. Dla każdej sprawy reklamacyjnej musi dać się odtworzyć: co agent dostał na wejściu, z jakich źródeł wiedzy skorzystał, co zaproponował i z jakim uzasadnieniem, kto zatwierdził i co zmienił. Bez tego każda rozmowa z audytorem, regulatorem albo niezadowolonym klientem zaczyna się od bezradności. Z tym - od faktów.
I ostatni element, o którym mało kto myśli na starcie: plan wycofania. Co się dzieje, gdy agent trzeba wyłączyć - awaria dostawcy modelu, incydent bezpieczeństwa, zmiana regulacyjna? Odpowiedź musi istnieć przed wdrożeniem: proces w Maestro przełącza kroki agentowe na ścieżkę ręczną, zespół wie, że przejmuje kolejkę, nikt nie improwizuje. Rozwiązanie agentowe, którego nie da się bezpiecznie zatrzymać, nie jest gotowe na produkcję - niezależnie od tego, jak dobrze działa.
Na koniec tego kroku - zarządzanie zmianą. Rozwiązanie agentowe ma więcej ruchomych części niż klasyczna automatyzacja: zmienić się może model, prompt definiujący rolę, zestaw narzędzi, indeks wiedzy, sam proces w BPMN. Każda z tych zmian potrafi zmienić zachowanie agenta i każda powinna przechodzić tę samą ścieżkę: zmiana w środowisku testowym, przebieg pełnego zestawu ewaluacji, porównanie wyników z poprzednią wersją, świadoma decyzja o wdrożeniu, wpis w rejestrze zmian. Zespoły znające dyscyplinę zarządzania zmianą z systemów ERP poczują się tu jak w domu - i słusznie, bo agent podejmujący decyzje finansowe zasługuje na co najmniej taki sam rygor, jak transport zmian do systemu księgowego.
Gdzie jeszcze ten sam proces działa
Przykład reklamacyjny prowadził nas przez cały tekst, ale osiem kroków jest uniwersalnych. Trzy typowe zastosowania, w których ten sam szkielet sprawdza się bez zmian - zmienia się tylko treść poszczególnych kroków.
Triage zgłoszeń service desk. Zgłoszenia IT przychodzą w języku naturalnym, często niekompletne i błędnie skategoryzowane. Agent czyta zgłoszenie, dopytuje o brakujące informacje, klasyfikuje, sprawdza w bazie wiedzy znane rozwiązania i albo proponuje odpowiedź, albo kieruje sprawę do właściwej linii wsparcia z kompletem ustaleń. Robot w tym procesie zbiera dane diagnostyczne z systemów, człowiek przejmuje sprawy o wysokim priorytecie i wszystko, co dotyka systemów krytycznych. Grounding: baza wiedzy, katalog usług, historia zgłoszeń.
Weryfikacja dokumentów w onboardingu dostawcy. Nowy dostawca przysyła komplet dokumentów: rejestrowych, finansowych, certyfikatów. Agent porównuje ich treść z wymaganiami polityki zakupowej, wychwytuje braki i rozbieżności, przygotowuje rekomendację. Decyzja o dopuszczeniu dostawcy - zawsze po stronie człowieka, bo to decyzja o ryzyku, nie o zgodności formalnej. Robot pobiera dane z rejestrów publicznych, agent interpretuje, komitet zakupowy decyduje.
Wsparcie raportowania zgodności. Organizacje objęte NIS2 czy DORA regularnie zbierają dowody zgodności rozproszone po systemach: konfiguracje, logi, rejestry incydentów, statusy szkoleń. Agent kompletuje materiał, porównuje z listą wymagań, wskazuje luki i przygotowuje szkic raportu - a pełnomocnik ds. bezpieczeństwa pracuje na gotowej, udokumentowanej podstawie zamiast na ręcznie zbieranych fragmentach. O takim wzorcu pisaliśmy na przykładzie agenta compliance pod nadzorem człowieka.
Wspólny mianownik wszystkich trzech: agent nigdzie nie zastępuje decydenta. Zastępuje pracę, którą decydent musiał wykonać, żeby móc zdecydować.
Ile to trwa i kto jest potrzebny
Dwa pytania, które padają na końcu każdej rozmowy o tym procesie. Co do czasu: uczciwa odpowiedź brzmi “to zależy od procesu i od dojrzałości danych”, ale mechanika jest przewidywalna - kwalifikacja i projekt to tygodnie warsztatów, nie miesiące; budowa z narzędziami AI jest dziś najszybszym etapem; najwięcej czasu pochłaniają grounding (jeśli wiedza wymaga uporządkowania) i testy z udziałem ekspertów procesu. Planując pierwszy projekt, warto przyjąć, że etapy “przed kodem” i “po kodzie” zajmą łącznie więcej niż samo budowanie - i że to jest zdrowa proporcja, a nie nieefektywność.
Co do zespołu: minimum to właściciel procesu po stronie biznesu (bez niego kwalifikacja i testy wiszą w próżni), architekt rozwiązania, deweloper automatyzacji i - od pierwszego warsztatu, nie od audytu - osoba odpowiedzialna za ryzyko i zgodność. W mniejszych organizacjach część ról łączy się w jednej osobie albo uzupełnia partnerem zewnętrznym; ważne, żeby żadna z czterech perspektyw nie zniknęła z projektu, bo każdy z ośmiu kroków potrzebuje innej z nich.
Klamra: AI Governance to nie rozdział na końcu, to szkielet
Spójrzcie teraz na osiem kroków z lotu ptaka. Kwalifikacja z oceną ryzyka. Projekt z jawnymi granicami autonomii. Wizualizacja, na której nadzór człowieka jest elementem diagramu. Budowa z przeglądem człowieka. Grounding z kontrolowanym dostępem do danych. Testy z ewaluacjami przypadków granicznych. Guardraile egzekwowane technicznie. Produkcja ze śladem audytowym i planem wycofania. To nie jest proces budowy agenta, do którego dokleiliśmy governance. To jest proces AI governance, którego produktem ubocznym jest działający agent.
To rozróżnienie ma dziś wymiar regulacyjny, nie tylko higieniczny. DORA - obowiązująca instytucje finansowe od stycznia 2025 - każe panować nad ryzykiem ICT także wtedy, gdy decyzje wspiera AI. Dyrektywa NIS2 rozszerza wymagania zarządzania ryzykiem cyberbezpieczeństwa na kolejne sektory. AI Act wprowadza obowiązki dla systemów AI etapami w kolejnych latach - a wśród nich wymogi nadzoru człowieka, przejrzystości i dokumentacji, czyli dokładnie te artefakty, które osiem kroków wytwarza po drodze. Organizacja, która buduje agentów według opisanego procesu, nie będzie “dostosowywać się do regulacji” - ona już ma to, o co regulacje pytają: udokumentowaną ocenę ryzyka, zdefiniowany nadzór człowieka, ślad audytowy każdej decyzji.
Dla zarządów i osób odpowiedzialnych za ryzyko mamy z tego procesu prostą listę pytań kontrolnych. Czy dla każdego agenta w organizacji istnieje dokument kwalifikacji z oceną ryzyka? Czy granice jego autonomii są opisane i wymuszone technicznie, a nie tylko zadeklarowane? Czy istnieje diagram procesu, na którym widać, gdzie decyduje człowiek? Czy da się odtworzyć, na jakiej podstawie agent podjął konkretną decyzję sprzed trzech miesięcy? Czy wiadomo, ile ten agent kosztuje miesięcznie i kto może go wyłączyć? Jeżeli na którekolwiek z tych pytań odpowiedź brzmi “nie wiemy” - to nie znaczy, że agenta trzeba wyłączyć. To znaczy, że brakuje któregoś z ośmiu kroków i warto go uzupełnić, zanim zapyta o to ktoś z zewnątrz.
W SNOK dokładnie tak prowadzimy projekty agentowe - od kwalifikacji procesu, przez warsztaty projektowe nad diagramem BPMN, budowę na platformie UiPath (jesteśmy partnerem Platinum w programie Agentic Fast Track), po testy, guardraile i przekazanie do nadzoru. AI governance nie jest u nas osobną usługą dopisywaną do oferty - jest sposobem, w jaki te wdrożenia robimy, spójnym z naszymi certyfikacjami ISO 27001 i ISO 9001. Jeżeli Wasza organizacja przymierza się do pierwszego agenta - albo ma już kilku i zaczyna odczuwać brak wspólnych zasad - to jest dokładnie ten moment, w którym warto porozmawiać.
Od czego zacząć w praktyce
Jeśli mielibyśmy zostawić Was z trzema rzeczami do zrobienia w najbliższym miesiącu, brzmiałyby tak. Po pierwsze: wybierzcie jeden proces-kandydata i przepuśćcie go przez kwalifikację z kroku 1 - charakter decyzji, cena błędu, dostępność wiedzy, wolumen. Po drugie: narysujcie go w BPMN z jawnym podziałem na roboty, agenta i człowieka, i pokażcie ten rysunek osobom odpowiedzialnym za ryzyko - ich uwagi na tym etapie kosztują godziny, na produkcji kosztowałyby tygodnie. Po trzecie: spiszcie, gdzie dziś mieszka wiedza potrzebna do decyzji w tym procesie - bo to będzie Wasz grounding i Wasze wąskie gardło.
A jeśli chcecie przejść tę drogę z zespołem, który robił to wielokrotnie - zapraszamy do rozmowy. Chętnie pokażemy, jak taki proces wygląda na żywo, na przykładzie dopasowanym do Waszej organizacji.