Wdrażanie agentów AI w firmie — 5 zasad skutecznej pracy

Wyobraź sobie, że w poniedziałek do firmy dołącza sto nowych osób. Każda może od razu tworzyć dokumenty, zmieniać kod i obsługiwać zgłoszenia. Nie znają jednak ustaleń zespołu, nie mają jasnych kryteriów jakości, a nikt nie określił, które decyzje mogą podejmować samodzielnie.

Takie wdrożenie pracowników trudno uznać za przygotowane. Przy agentach AI łatwo jednak skupić się na dostępie do narzędzia i oczekiwać, że reszta ułoży się podczas pracy.

Agent potrzebuje celu, właściwych informacji, granic działania i sposobu sprawdzania wyniku. Samo przyspieszenie tworzenia kodu, raportów czy odpowiedzi nie mówi jeszcze, czy firma lepiej rozwiązuje problemy klientów.

Poniżej znajdziesz pięć zasad, które pomagają uporządkować wdrażanie agentów AI w zespołach programistycznych i biznesowych, wraz z przykładami zastosowań i propozycją małego pilotażu.

1. Najpierw kontekst, potem samodzielność

Polecenie „przygotuj odpowiedź klientowi” brzmi konkretnie, dopóki nie trzeba ustalić, co klient kupił, jakie warunki obowiązują i czego firma już mu obiecała.

W programowaniu podobną rolę pełnią wymagania, dokumentacja, historia decyzji i zależności między systemami. Jeżeli wiedza istnieje wyłącznie w głowach kilku osób, agent nie ma do niej dostępu. Może wtedy uzupełniać luki założeniami, których zespół nie zauważy od razu.

Przed przekazaniem zadania przygotuj krótki pakiet kontekstu:

Cel: jaki problem ma zostać rozwiązany i dla kogo?
Źródła: które dokumenty lub dane są aktualne i obowiązujące?
Ograniczenia: czego agent nie może zmienić ani obiecać?
Kryteria odbioru: po czym poznamy, że zadanie zostało wykonane?
Braki: kiedy ma przerwać pracę i poprosić o decyzję?

Przykładowo przed wycofaniem starszej aplikacji warto uporządkować wiedzę o jej funkcjach, zależnościach i powodach wcześniejszych decyzji. Na tej podstawie można planować pracę zespołów. Na początek wystarczy aktualny opis procesu i wskazanie źródeł, które rozstrzygają wątpliwości.

Praktyczna zasada: zwiększaj samodzielność dopiero po sprawdzeniu, czy agent poprawnie korzysta z potrzebnych informacji. Więcej dokumentów nie gwarantuje lepszego kontekstu; ważne są ich trafność, aktualność i spójność.

2. Zasady powinny mieć mechanizm sprawdzania

Instrukcja „zawsze sprawdzaj poprawność danych” nie określa jeszcze, co system ma sprawdzić ani co stanie się po wykryciu błędu.

W repozytorium można uruchamiać testy, sprawdzać formatowanie i blokować połączenie zmian, które nie przechodzą wymaganych kontroli. W procesie biznesowym podobną funkcję pełni walidacja pól, sprawdzenie sum, kontrola dozwolonych odbiorców albo wymagane zatwierdzenie przed wysyłką.

Zasada	Przykładowy mechanizm kontroli
Raport musi zawierać wszystkie wymagane pola	Program sprawdza obecność i typ każdego pola
Kwoty w podsumowaniu muszą odpowiadać pozycjom	Kod oblicza sumę i porównuje ją z podsumowaniem
Agent nie może sam wysyłać odpowiedzi	Narzędzie umożliwia przygotowanie szkicu; wysyłka wymaga osobnego uprawnienia
Zmiana kodu musi spełniać ustalone wymagania	Wymagane testy w procesie CI, czyli automatycznej kontroli zmian

Anthropic opisuje możliwość dodawania programowych kontroli między kolejnymi krokami pracy z modelem. Zwraca też uwagę na potrzebę informacji zwrotnej z narzędzi oraz warunków zatrzymania agenta. Źródło: Anthropic, Building effective agents.

Dziesięć kroków po 95% nie daje 95% skuteczności

Pomaga tu analogia do dostępności systemów, czyli availability. Jeżeli system wymaga działania wszystkich niezależnych komponentów połączonych szeregowo, jego dostępność obliczamy, mnożąc ich dostępności. Takie podejście opisuje AWS w dokumentacji dotyczącej zależności systemu.

Podobny rachunek można zastosować do workflow, w którym każdy krok musi zakończyć się poprawnie. Załóżmy, że mamy dziesięć kroków, każdy ma 95% szans powodzenia, a błędy są niezależne. Przy jednej próbie wykonania, bez ponowień i napraw, prawdopodobieństwo sukcesu całego procesu wynosi:

0,95 × 0,95 × 0,95 × 0,95 × 0,95 × 0,95 × 0,95 × 0,95 × 0,95 × 0,95 = 0,95¹⁰ ≈ 0,5987, czyli 59,9%.

To oznacza około 40,1% szans, że przynajmniej jeden krok zawiedzie. Wysoka skuteczność pojedynczej operacji może więc dawać znacznie niższą skuteczność całego łańcucha.

To analogia matematyczna: tutaj liczymy poprawne wykonanie procesu, podczas gdy dostępność opisuje możliwość korzystania z systemu. W rzeczywistym workflow błędy mogą być zależne — na przykład błędne dane z pierwszego kroku wpływają na kolejne — więc nie należy bez sprawdzenia mnożyć osobno zmierzonych skuteczności.

Dlatego potrzebujemy kontroli między etapami: wykrycia błędu, zatrzymania przekazywania niepoprawnego wyniku i określonego sposobu naprawy lub przekazania sprawy człowiekowi. Sama walidacja nie zwiększa automatycznie szans sukcesu, ale pozwala wykryć problem i uruchomić reakcję. Obliczenia i jednoznaczne reguły warto wykonywać kodem, a niepotrzebne kroki usuwać. Skuteczność trzeba też mierzyć dla całego workflow.

To nie oznacza, że wszystko da się ocenić automatycznie. Sens rekomendacji, ton odpowiedzi i zgodność ze strategią mogą wymagać ludzkiego osądu. Warto jednak oddzielić je od rzeczy, które da się policzyć lub jednoznacznie zweryfikować.

Jeżeli podczas przeglądu wraca ten sam błąd, sprawdź, czy można dodać kontrolę, poprawić źródło albo doprecyzować wzorzec zadania. Każda taka poprawka powinna rozwiązywać zaobserwowany problem. Dokładanie kolejnych ogólnych instrukcji może utrudnić odnalezienie tych naprawdę potrzebnych.

3. Zespoły eksperymentują, liderzy wyznaczają granice

Osoby wykonujące pracę zwykle najlepiej widzą jej powtarzalne trudności: ręczne przepisywanie danych, szukanie ustaleń czy poprawianie tych samych braków w zgłoszeniach. To dobre miejsca do szukania pierwszych zastosowań AI.

Gdy każdy eksperymentuje osobno, łatwo jednak stworzyć kilka rozwiązań tego samego problemu. Różne zespoły mogą też używać innych definicji klienta, zamówienia czy zakończonej sprawy.

Proponuję prosty podział odpowiedzialności. Liderzy ustalają dozwolone narzędzia, zasady dostępu do danych, właściciela procesu i sposób oceny efektów. Zespół wybiera konkretny problem oraz sprawdza rozwiązanie w tych granicach.

DORA wskazuje, że jasne i komunikowane stanowisko organizacji wobec AI sprzyja eksperymentowaniu. Zaleca także utrzymywanie dostępnych zasad i zbieranie pytań oraz sugestii od zespołów. Źródło: DORA, Clear and communicated AI stance.

Praktycznym uzupełnieniem może być wspólny rejestr prób: problem, właściciel, użyte dane, wynik i decyzja o dalszych krokach. Nie musi to być rozbudowany system. Ważne, żeby kolejny zespół mógł skorzystać z wcześniejszej nauki.

4. Mierz rozwiązany problem, a nie liczbę wytworzonych materiałów

Agent przygotował dwadzieścia raportów zamiast dziesięciu. Czy to dobry wynik? Zależy, czy raporty były potrzebne, poprawne i czy ktoś wykorzystał je do podjęcia decyzji.

Przed pilotażem wybierz miarę związaną z problemem odbiorcy i miarę jakości, która pokaże ewentualne koszty uboczne.

Zastosowanie	Co warto mierzyć
Obsługa zgłoszeń	Czas do rozwiązania sprawy oraz odsetek ponownych kontaktów w tej samej sprawie
Przygotowanie raportu	Czas do zaakceptowanego zestawienia oraz liczba błędów wymagających korekty
Rozwój oprogramowania	Osiągnięcie celu funkcji, czas dostarczenia i problemy po wdrożeniu
Baza wiedzy	Skuteczność znalezienia odpowiedzi i liczba spraw wymagających dalszego wyjaśniania

Zapisz też stan początkowy. Bez niego trudno ocenić, czy proces się poprawił, czy tylko zmienił wygląd.

Zespół powinien wiedzieć, kiedy zakończyć pracę. Jeżeli problem został rozwiązany, kolejna funkcja lub następny agent potrzebują osobnego uzasadnienia. Sam fakt, że można coś szybko zbudować, nie przesądza o potrzebie budowania.

5. Usuwaj przyczyny poprawek i ponownych kontaktów

Część pracy powstaje dlatego, że wcześniejszy etap procesu nie rozwiązał problemu odbiorcy. Zamiast wyłącznie przyspieszać obsługę kolejnych poprawek i pytań, warto znaleźć ich przyczynę.

Klient pyta o status zamówienia, bo potwierdzenie nie podało terminu. Konsultant odpowiada z pomocą AI, lecz klient pisze ponownie, ponieważ odpowiedź nie uwzględnia brakującego dokumentu. Agent może przyspieszyć obie wiadomości, ale przyczyna kontaktów nadal pozostaje.

Przejrzyj próbkę powracających spraw. Sprawdź, czy wywołały je niejasne instrukcje, brak danych, błędna odpowiedź czy niespójność między systemami. Dopiero potem zdecyduj, co automatyzować.

Czasami najlepszą zmianą będzie poprawienie formularza albo potwierdzenia zamówienia. W innym przypadku warto dodać kontrolę kompletności przed rozpoczęciem obsługi. Miarą powodzenia może być wtedy mniej zgłoszeń wymagających obsługi, nawet jeśli agent wygeneruje mniej odpowiedzi.

W ocenie kosztu uwzględniaj czas sprawdzania, poprawiania i ponownego wykonywania pracy. Oszczędność podczas generowania szkicu może zniknąć na dalszych etapach procesu.

Jak sprawdzić te zasady w małym pilotażu?

Nie trzeba zaczynać od automatyzacji całego działu. Proponowany punkt startu to jeden powtarzalny proces, dostępne źródła i osoba odpowiedzialna za odbiór wyniku.

Opisz problem i stan początkowy. Zmierz czas pracy, liczbę poprawek oraz efekt dla odbiorcy.
Przygotuj kontekst. Wskaż obowiązujące materiały, wymagany wynik i postępowanie przy brakach danych.
Ogranicz zakres działania. Na początku agent może przygotowywać propozycje, a człowiek zatwierdzać wykonanie.
Dodaj kontrole. Ustal, co sprawdza program, a co ocenia osoba odbierająca pracę.
Porównaj cały proces. Uwzględnij przygotowanie danych, oczekiwanie, przegląd, poprawki i ponowne kontakty. Sprawdź także przypadki nietypowe.
Podejmij decyzję. Rozszerz zakres, zmień podejście albo zakończ próbę, jeżeli korzyść nie uzasadnia kosztu.

Nie każde zadanie wymaga agenta samodzielnie wybierającego kolejne kroki. Anthropic zaleca rozpoczynanie od najprostszego rozwiązania i zwiększanie złożoności dopiero wtedy, gdy poprawia to wyniki. Dla dobrze opisanego procesu może wystarczyć stała sekwencja działań, czyli workflow. Źródło: Anthropic.

Dobrym pierwszym zadaniem może być przygotowanie projektu raportu z jednego ustalonego źródła. Pozwala sprawdzić jakość danych, instrukcji i kontroli, zanim agent otrzyma możliwość działania w kolejnych systemach.

Przećwicz projektowanie automatyzacji w ChatGPT

Podczas dwudniowego szkolenia z budowania automatyzacji w ChatGPT uczestnicy projektują workflow z określonymi wejściami, krokami, wynikami i obsługą wyjątków. Program obejmuje sprawdzanie powtarzalności, wykorzystanie kodu do obliczeń i walidacji oraz prototyp agenta korzystającego z Sites.

Wcześniejsza umiejętność programowania nie jest wymagana; potrzebna jest podstawowa znajomość ChatGPT. Dostęp do funkcji wykorzystywanych podczas ćwiczeń ustalamy przed zajęciami. Wynik warsztatu jest punktem wyjścia do dalszych testów w organizacji.

Zobacz program szkolenia lub zapytaj o warsztat dla swojego zespołu.

Źródła i zakres opracowania

Anthropic: Building effective agents — rozróżnienie workflow i agentów, kontrole między krokami oraz dobór złożoności rozwiązania.
DORA: Clear and communicated AI stance — jasne zasady korzystania z AI i informacja zwrotna od zespołów.

Pakiet kontekstu, tabele, przykłady biznesowe i schemat pilotażu są praktycznymi propozycjami autora. Nie są gwarancją określonego wzrostu produktywności.