Jak wdrożyć agenta AI na produkcję, żeby nie padał

Demo agenta AI jest łatwe. Wywołujesz API, model odpowiada, pokazujesz to interesariuszom. Wszyscy są zadowoleni.

Potem wdrażasz go na produkcję. Po tygodniu przychodzi faktura na 3 000 dolarów, bo agent utknął w pętli i wywołał model 8 000 razy. Albo zwraca strukturyzowane polecenie, które nie istnieje, bo użytkownik podstawił mu instrukcję w języku naturalnym. Albo po prostu nie wiesz, co się dzieje — żadnych logów, żadnych metryk, żadnego kontekstu.

To są problemy, na które natrafisz. Nie jeśli, tylko kiedy.

Oto sześć rzeczy, które musisz mieć rozwiązane, zanim wypuścisz agenta AI na produkcję.

1. Cost gate — zatrzymaj runaway loop, zanim pojawi się na fakturze

Każdy agent, który wywołuje LLM w cyklu, to potencjalny runaway loop. Wystarczy błąd w warunku zakończenia, nieoczekiwany wynik modelu lub timeout sieciowy — i agent wywołuje API setki lub tysiące razy.

Rozwiązanie jest mechaniczne: cost gate, który rzuca wyjątek jeszcze przed żądaniem, jeśli dzienny budżet został wyczerpany. Liczysz tokeny dokładnie — cache write są 1,25× droższe niż standardowe wejście, cache read kosztuje 0,10×. Jeśli nie pokazujesz tego w budżecie, nie widzisz rzeczywistej ceny.

Bez tego jeden zapętlony agent przeje miesięczny budżet przez noc. Z nim kończy gracefully z wyjątkiem i alertem.

2. Guardraile — sanityzacja wejścia i server-side walidacja wyjścia

LLM to system open input/output. To oznacza dwa ryzyka:

Na wejściu: użytkownik może wstawić instrukcje w języku naturalnym, które zmienią zachowanie modelu. Prompt injection — nie teoria, ale realny wektor. Wejście sanityzuj, zanim trafi do promptu systemowego.

Na wyjściu: model zwraca strukturyzowany wynik (polecenie JSON, nazwa encji, kod numeryczny). Bez walidacji zwróci wartość, która wygląda poprawnie, ale nie istnieje w systemie. Rozwiązujemy to przez server-side regex guards — nie tylko schema validation, ale rzeczywista kontrola względem dozwolonych wartości. Konkretnie tam, gdzie admin pisze wolny tekst, a model wyciąga z niego strukturyzowane polecenie: bez guardu halucynowane polecenie przeszłoby dalej do systemu po cichu.

Guardraile nie spowolnią agenta. Spowolnią szkody.

3. Obserwowalność — każde wywołanie LLM musi być audytowalne

Systemem produkcyjnym bez widoczności w wywołania LLM sterujesz na ślepo. Nie wiesz, gdzie jest latencja, co kosztuje, która konfiguracja zwraca złe wyniki.

Każde wywołanie logujemy z czterema wymiarami: tokeny (wejście/wyjście/cache), latencja, cena, konfiguracja (model, temperatura, wersja promptu systemowego). Dane agregujemy per dostawca i per model.

Wynik jest konkretny: widzisz, że GPT-4o mini jest w konkretnym use case 8× tańszy niż GPT-4o, a przy tym wystarczająco dokładny. Albo że jeden endpoint odpowiada za 60% całkowitych kosztów. Bez liczb to tylko wrażenia.

4. Fallback i self-healing — agent musi przeżyć własne błędy

Agenci AI popełniają błędy. Model czasem zwróci niepoprawny JSON. Zapytanie zawiedzie przez chwilową niedostępność. Wynik nie pasuje do schematu.

Pomagają dwie rzeczy:

Lokalny inference jako hedge. Proste zadanie — na przykład sentyment — nie musi zawsze iść do chmurowego API. Obliczenie lokalnie = zerowa latencja, zerowa cena, zerowa zależność od zewnętrznego dostawcy. Hedge na dostępność i na koszty.

Self-healing przy awarii. Gdy zapytanie zawiedzie lub zwróci niepoprawny wynik, agent dostaje komunikat błędu i generuje poprawione zapytanie. Jeden retry z kontekstem błędu rozwiązuje większość przejściowych problemów. Zamiast pada dostajesz zdegradowany, ale działający wynik.

Graceful degradation — a nie zbędny pad przy pierwszym błędzie.

5. Human-in-the-loop i audit log — AI nie może być czarną skrzynką

Ekstrakcja danych z faktur, dokumenty prawne, decyzje finansowe — to obszary, gdzie błąd AI ma realne konsekwencje. Tu nie wystarczy śledzić dokładność. Nie wystarczy nawet 90%.

Human-in-the-loop to decyzja architektoniczna, a nie workaround. Model proponuje, człowiek potwierdza. Każda decyzja — propozycja i potwierdzenie — trafia do audit logu z czasem, użytkownikiem i kontekstem.

Dwa efekty: niższe ryzyko przy krytycznych danych i lepszy sygnał treningowy (widzisz, gdzie model się myli i dlaczego człowiek go poprawia).

Dla odniesienia: municypalny RAG chatbot z temperaturą 0.1 osiąga ~90% dokładności na danych na żywo. Pozostałe 10% to argument za review, a nie za ślepym zaufaniem.

6. Eval przed wdrożeniem — skąd wiesz, że zmiana pomogła?

Bez systematycznej ewaluacji zmiany w promptach i konfiguracjach to strzelanie na ślepo. Poprawiłeś dokładność, czy rozbiłeś ją w innym segmencie wejść?

Eval nie musi być skomplikowany — wystarczy zestaw reprezentatywnych wejść i oczekiwanych wyjść, który uruchamia się przy każdej zmianie. Temperaturę wybieramy niską (0.1) dla zadań faktycznych, gdzie deterministyczny wynik jest cenniejszy niż kreatywność.

Honest gap: nie robimy fine-tuningu ani MLOps. Optymalizujemy na poziomie promptów i architektury, a nie na poziomie wag modelu. Dla większości produkcyjnych use case'ów to wystarcza.

Jak to się trzyma razem

Wszystkie powyższe komponenty działają tylko wtedy, gdy agent AI nie jest izolowanym chatbotem. Musi być wpięty w realny system — z danymi, stanem, logiką biznesową. Model ma sens w momencie, gdy wie, z czym pracuje: ma kontekst zlecenia, historię komunikacji, strukturę danych z systemu. Bez tego to tylko generator tekstu.

Cost gate, guardraile, obserwowalność, fallback, human-in-the-loop i eval to infrastruktura wokół modelu. Sam model to tylko jedna warstwa.

---

FAQ

Czy muszę rozwiązać wszystko naraz, czy da się stopniowo?

Da się stopniowo, ale cost gate i obserwowalność należą do pierwszej wersji. Bez nich nie masz danych, żeby zdecydować, co rozwiązać dalej. Guardraile dodaj, gdy tylko agent przetwarza wejście od użytkowników. Human-in-the-loop wdróż tam, gdzie błąd ma realne konsekwencje.

Co jeśli model, którego teraz używam, zniknie albo zdrożeje?

Dlatego oddzielamy wywołanie modelu za warstwą abstrakcji — przełączenie dostawcy lub modelu to wtedy zmiana konfiguracji, a nie refaktor. To jedna z tych rzeczy, gdzie architektura decyduje, zanim problem się pojawi.

Czy AI na produkcji jest wyraźnie droższe niż w demie?

Demo wywołuje model kilkadziesiąt razy. Produkcja wywołuje model tysiące razy dziennie. Koszty są jednak głównie o tym, co liczysz. Cache read kosztuje 0,10× standardowej ceny — poprawne keszowanie obniża fakturę dramatycznie. Obserwowalność powie ci, gdzie idą pieniądze. Bez niej optymalizujesz losowo.

---

Jeśli przygotowujesz agenta AI na produkcję i chcesz przejść architekturę, zanim natrafisz na problemy w działaniu, napisz do nas — przejdziemy to razem.