Podczas webinaru InfoQ praktycy inżynierii, bezpieczeństwa i prywatności omówili problemy ujawniające się po wdrożeniu agentów AI na produkcji. W relacji opublikowanej 16 października 2026 r. wskazali, że takie systemy mogą generować przekonujące, lecz błędne wyniki, mimo że monitoring infrastruktury nie wykrywa awarii. Dlatego tradycyjne testy oprogramowania i ręczny przegląd kodu nie wystarczają do kontrolowania agentów.
Dlaczego monitoring nie wykrywa części awarii AI
Moderator Hien Luu zwrócił uwagę na trzy różnice między AI a tradycyjnym oprogramowaniem. Model może podać wiarygodnie brzmiącą nieprawdę zamiast przerwać działanie z błędem. Agenci programistyczni tworzą kod szybciej, niż ludzie mogą go sprawdzać, a dane poufne mogą wyciekać przez prompty, okna kontekstowe i dokumenty pobierane przez system.
Zichuan Xiong, Head of AI Ops for Managed Services w ThoughtWorks, opisał dryf semantyczny w potokach wykorzystujących duże modele językowe. Agent zamieniający tekst na zapytania SQL może spłaszczać pojęcia właściwe dla konkretnej domeny. Przykładem jest termin member, który może mieć inne znaczenie w sprzedaży, a inne w obsłudze klienta.
Taki błąd nie musi powodować wyjątku ani zatrzymać potoku. Nieprawidłowe zapytanie przechodzi przez standardowe śledzenie, ale zniekształca analizy biznesowe na dalszych etapach. System działa technicznie poprawnie, choć zwraca odpowiedź opartą na błędnym rozumieniu danych.
Lan Chu, praktyczka AI w sektorze finansowym, przedstawiła podobny problem związany z dryfem osadzeń wektorowych. Agent blokował niedozwolone porady inwestycyjne na podstawie progów podobieństwa wektorowego. Niezapowiedziana aktualizacja modelu osadzeń zmieniła rozkład odległości między wektorami, co wywołało gwałtowny wzrost wyników fałszywie dodatnich i fałszywie ujemnych. Wszystkie testy kondycji infrastruktury nadal wskazywały poprawne działanie.
Gdzie dane poufne mogą wydostać się z systemu
Prem Chandrasekaran, Tech and Business Services Lead w ThoughtWorks, wskazał ryzyko związane z generowaniem wspomaganym wyszukiwaniem, czyli RAG. Potok może pobrać poufny dokument, jeśli mechanizm dostępu nie uwzględnia właściwego kontekstu użytkownika lub zadania. Samo poprawne działanie wyszukiwarki nie oznacza więc, że agent powinien otrzymać znalezioną treść.
Specjalistka ds. prywatności Katharine Jarmul przypomniała, że modele zapamiętują dane szkoleniowe. Można je wykorzystać do ponownej identyfikacji zanonimizowanych informacji albo ujawnienia kluczy API. Ryzyko obejmuje zatem zarówno dane przekazywane podczas działania agenta, jak i informacje obecne wcześniej w materiale użytym do trenowania modelu.
Jarmul odradziła traktowanie prompt engineeringu jako podstawowej ochrony systemu. Zaleciła systematyczne testy red team, ciągłe modelowanie zagrożeń, ścisłe określanie funkcji dostępnych agentowi i skalowanie obserwowalności wraz ze wzrostem liczby zdarzeń. Kontrola musi działać poza warstwą instrukcji wysyłanych do modelu.
Chandrasekaran przywołał także podatność GitSpawn. Pokazuje ona, że złośliwa konfiguracja repozytorium może doprowadzić do uruchomienia nieautoryzowanego kodu podczas wykonywania rutynowych poleceń. Ochrona agenta programistycznego musi więc obejmować również repozytoria i środowisko, w którym agent uruchamia narzędzia.
Jak zmienić przegląd kodu tworzonego przez agentów
Rosnąca ilość kodu generowanego przez asystentów programistycznych tworzy wąskie gardło w ręcznym przeglądzie. Według Chandrasekarana sprawdzanie każdej linii przez człowieka nie skaluje się wraz z tempem pracy agentów. Zespół powinien przenieść mechaniczne kontrole stylu i składni do potoków CI/CD.
Ludzie mają w takim modelu oceniać architekturę, zgodność z celem biznesowym i wymagania niefunkcjonalne. Nie chodzi o rezygnację z nadzoru, lecz o skierowanie uwagi recenzentów na decyzje, których nie da się sprowadzić do kontroli formatowania lub prostych reguł statycznych.
Xiong zalecił wcześniejsze sprawdzanie intencji na poziomie warstwy sterującej agentem, określanej jako agent harness. Ocena powinna nastąpić, zanim agent wygeneruje pull request. Pozwala to kontrolować sposób realizacji zadania przed powstaniem dużej partii kodu wymagającej późniejszego przeglądu.
Chandrasekaran wskazał też na ponowne znaczenie testów mutacyjnych. Technika polega na celowym wprowadzaniu zmian do kodu i sprawdzaniu, czy zestaw testów wykryje zmienioną logikę. Pomaga odróżnić testy rzeczywiście kontrolujące zachowanie programu od tych, które jedynie podnoszą wskaźnik pokrycia kodu.
Dlaczego ewaluacja musi działać przez cały czas
Lan Chu uznała ewaluacje za stałą, rozwijaną część infrastruktury, a nie listę kontrolną wykonywaną przed premierą. System agentowy zmienia się wraz z modelem, danymi, integracjami i zachowaniem użytkowników. Jednorazowy zestaw testów nie pokaże wszystkich problemów występujących w ruchu produkcyjnym.
Panel zalecił ciągłe śledzenie interakcji online na poziomie pojedynczych operacji, czyli spanów. Zespoły powinny filtrować logi, wykrywać wzorce awarii i wykorzystywać modele językowe do ich kategoryzowania. Przypadki brzegowe znalezione na produkcji należy następnie dodawać do zestawów testowych używanych poza środowiskiem produkcyjnym.
Takie podejście łączy obserwowalność z rozwojem testów. Zamiast ograniczać się do czasu odpowiedzi i dostępności usługi, zespół sprawdza również, czy agent poprawnie rozumie pojęcia, wybiera narzędzia i respektuje ograniczenia.
Jak ograniczyć uprawnienia i ustalić zgodę na wdrożenie
Chandrasekaran zaproponował, aby pod względem dostępu traktować każdego agenta jak nowego pracownika zespołu inżynieryjnego. Agent nie powinien dziedziczyć szerokich uprawnień użytkownika ani korzystać ze wspólnych danych uwierzytelniających. Zalecenia panelu obejmują:
- nadanie agentowi oddzielnej tożsamości niebędącej kontem człowieka,
- rozdzielenie dostępu tylko do odczytu od odwracalnych operacji zapisu,
- wersjonowanie zewnętrznych zależności Model Context Protocol, czyli MCP,
- przechowywanie sekretów API poza środowiskiem wykonawczym agenta i używanie izolowanych sandboxów,
- ścisłe określenie zakresu funkcji oraz obserwowanie wszystkich wykonywanych działań.
Takie zabezpieczenia mają ograniczyć zasięg skutków błędnej lub nieautoryzowanej operacji. Zespoły inżynierii, bezpieczeństwa i prywatności odpowiadają za sprawdzenie mechanizmów ochronnych, ale nie podejmują samodzielnie ostatecznej decyzji o uruchomieniu systemu. Według panelistów zgoda na wdrożenie pozostaje strategiczną decyzją biznesową.
Dla firm w Polsce oznacza to potrzebę objęcia agentów istniejącymi procesami zarządzania tożsamością, dostępem i ryzykiem, z dodatkowymi kontrolami jakości odpowiedzi. Przed uruchomieniem właściciel procesu powinien znać zakres autonomii agenta i możliwe skutki błędu, a zespoły techniczne powinny wykazać, że zabezpieczenia działają także w ruchu produkcyjnym.
