Wdrożyliście AI pół roku temu. Skąd wiecie, że nadal działa?

Dlaczego AI nie psuje się tak, jak psuje się zwykły system

W klasycznej aplikacji granica między „działa” i „nie działa” jest ostra. Zapytanie przechodzi albo nie przechodzi, suma się zgadza albo nie, test przechodzi albo pada. Dlatego monitoring IT od dwudziestu lat mierzy dostępność, czas odpowiedzi i liczbę błędów — i to wystarcza.

W systemie opartym na modelu językowym te trzy wskaźniki mogą być idealne w dniu, w którym jakość odpowiedzi spadła o połowę. Odpowiedź przychodzi w sekundę, kod HTTP to 200, dashboard jest zielony. Tylko treść jest nie ta. Branżowe opracowania nazywają to cichą degradacją i zgadzają się w jednym: standardowy monitoring aplikacyjny jej nie widzi, bo mierzy ruch, a nie zachowanie.

Praktyczna konsekwencja dla firmy jest brutalna: o spadku jakości dowiadujecie się od klienta, od handlowca albo z reklamacji — czyli najdroższą możliwą drogą i z opóźnieniem liczonym w tygodniach. W małej firmie, gdzie nikt nie przegląda losowej próbki rozmów, to opóźnienie bywa kwartalne.

Dlatego utrzymanie wdrożenia AI nie jest „opieką powdrożeniową” w sensie, w jakim rozumie ją większość umów IT. To nie jest gotowość do naprawy awarii. To ciągłe mierzenie czegoś, co nie zgłasza się samo.

Pięć powodów, dla których działające wdrożenie przestaje działać

Degradacja prawie nigdy nie ma jednej przyczyny i prawie nigdy nie wynika z tego, że „model się zepsuł”. Oto układ, który widzimy najczęściej — od przyczyn, o których nikt nie myśli, do tych, które są oczywiste dopiero po fakcie.

• Zmienił się model pod spodem. Dostawcy wycofują starsze wersje modeli i podmieniają punkty końcowe, a nowa wersja zachowuje się inaczej przy tym samym prompcie. To nie jest awaria — to zaplanowana zmiana w cudzym kalendarzu, która w Waszym systemie wygląda jak nagła zmiana stylu lub trafności odpowiedzi.
• Zmieniły się dane, z których system korzysta. Nowy cennik, nowy regulamin, zmieniona struktura folderów, dokument przeniesiony do innego systemu. Asystent nadal odpowiada, tylko z nieaktualnego źródła — a to gorsze niż brak odpowiedzi, bo klient dostaje konkretną, wiarygodnie brzmiącą nieprawdę.
• Zmieniły się pytania. Po trzech miesiącach użytkownicy pytają o rzeczy, których nie było w zestawie testowym: nową usługę, nową promocję, nowy problem. Zakres pytań dryfuje szybciej niż baza wiedzy.
• Ktoś coś poprawił. Jedna zmiana w prompcie, zrobiona w dobrej wierze, żeby naprawić jeden przypadek. Badania nad iteracją promptów pokazują powtarzalny efekt: ogólne „ulepszenia” poprawiają przykład, na którym były testowane, i psują trzy inne, których nikt nie sprawdził.
• Zmienił się zespół. Osoba, która rozumiała, jak to jest zbudowane, zmieniła stanowisko albo firmę. System nadal działa, ale nikt nie wie, dlaczego działa — i nikt nie odważy się nic zmienić. To nie degradacja techniczna, tylko organizacyjna, i jest najtrudniejsza do odwrócenia.

Data wycofania modelu jest datą w Waszym projekcie

To najbardziej konkretna zmiana ostatniego roku i wciąż najrzadziej uwzględniana w umowach. Modele dostępne przez API nie są wieczne. Dostawcy publikują harmonogramy wycofania i trzymają się ich: po terminie zapytania do starej wersji zaczynają zwracać błąd, a nie ostrzeżenie.

Skala jest już niebanalna. Publiczne zestawienia na 2026 rok wyliczają kilkadziesiąt identyfikatorów modeli z przypisaną datą wyłączenia u największych dostawców, a terminy bywają zgrupowane — październik 2026 to miesiąc, w którym jeden dostawca usuwa z API całą grupę starszych modeli naraz. Okresy wypowiedzenia są przyzwoite, zwykle od dwóch do sześciu miesięcy, ale liczą się od ogłoszenia na stronie dla programistów, a nie od momentu, w którym ktoś w Waszej firmie to ogłoszenie przeczytał.

Dla firmy, która kupiła wdrożenie i rozliczyła projekt, wygląda to tak: w środę wszystko działa, w czwartek integracja zwraca błąd albo — w wariancie gorszym, gdy dostawca sam przełączył Was na następnik — zaczyna odpowiadać inaczej. Pierwszy wariant jest tani, bo widoczny natychmiast. Drugi kosztuje tygodnie.

Minimum, które da się zrobić w jeden dzień: wypiszcie, które konkretne wersje modeli obsługują Wasze procesy, kto w firmie dostaje powiadomienia dostawcy o ich wycofaniu i gdzie te daty są zapisane poza głową jednej osoby. Jeśli na którekolwiek z tych pytań nie ma odpowiedzi, macie termin, o którym nie wiecie. Czego jeszcze szukać w umowie z dostawcą, opisaliśmy w tekście o umowie z dostawcą AI.

Zestaw testowy jest aktywem, nie etapem projektu

Większość firm buduje zestaw pytań kontrolnych raz — przy odbiorze wdrożenia — i nigdy do niego nie wraca. To marnowanie najcenniejszej rzeczy, jaka powstała w projekcie. Zestaw testowy to jedyne narzędzie, które pozwala odpowiedzieć na pytanie „czy po tej zmianie jest lepiej, czy gorzej” liczbą, a nie wrażeniem.

Zasada jest prosta: ten sam zestaw uruchamiany jest po każdej zmianie, która może cokolwiek ruszyć — po podmianie wersji modelu, po edycji promptu, po aktualizacji bazy wiedzy, po zmianie integracji. I raz w miesiącu bez żadnego powodu, właśnie po to, żeby wyłapać zmiany, o których nikt Was nie poinformował.

Zestaw musi też rosnąć. Każde zgłoszenie „bot odpowiedział bzdurę” powinno kończyć się nowym przypadkiem w zestawie, a nie tylko poprawką. Inaczej ten sam błąd wróci po trzeciej kolejnej zmianie promptu. Po pół roku dojrzałe wdrożenie ma zestaw dwa–trzy razy większy niż w dniu startu, a jego przyrost to najlepszy wskaźnik, że ktoś naprawdę pilnuje systemu.

Jak taki zestaw zbudować od zera i jak oceniać odpowiedzi, których nie da się porównać znak w znak, opisaliśmy szczegółowo w tekście o testowaniu wdrożeń AI. Tutaj liczy się jedna różnica: tam był to warunek odbioru, tu jest to cykl.

Cztery liczby, które wystarczą małej firmie

Rynek narzędzi do obserwowalności modeli jest w 2026 zatłoczony i w większości zbudowany pod zespoły, które mają dedykowanego inżyniera do pilnowania modeli. Firma na dwadzieścia osób nie potrzebuje platformy. Potrzebuje czterech liczb raportowanych raz w miesiącu na jednej stronie.

• Trafność na zestawie kontrolnym. Procent odpowiedzi ocenionych jako poprawne na tym samym, niezmiennym zestawie pytań. To jedyna liczba, która porównuje stan dziś ze stanem z dnia odbioru. Spadek o kilka punktów to sygnał, nie szum.
• Odsetek przekazań do człowieka i ich powody. Rosnący odsetek eskalacji nie zawsze jest zły — ale zmiana rozkładu powodów to najwcześniejszy sygnał, że coś się przesunęło. Mechanikę samej eskalacji opisaliśmy w tekście o eskalacji do człowieka w obsłudze AI.
• Odsetek pytań bez dobrego dopasowania w bazie wiedzy. Rośnie, kiedy użytkownicy pytają o rzeczy, których w bazie nie ma. To gotowa lista zadań redakcyjnych, nie powód do zmiany modelu.
• Koszt na jedną obsłużoną sprawę, a nie koszt miesięczny. Rachunek rosnący wraz z użyciem jest w porządku. Rachunek rosnący przy tym samym wolumenie oznacza, że ktoś wydłużył prompt, dołożył kontekst albo przełączył się na droższy model — i warto wiedzieć o tym w tym miesiącu, a nie w rozmowie o budżecie na przyszły rok.

Rachunek, który rośnie sam

Koszt działania AI jest jedyną pozycją w budżecie IT, która potrafi wzrosnąć bez żadnej decyzji po Waszej stronie. Cena jednostkowa spada — w ciągu ostatniego roku o kilkadziesiąt procent — ale zużycie rośnie szybciej, bo systemy agentowe wykonują wiele wywołań na jedną sprawę, a każda poprawka jakości zwykle oznacza więcej kontekstu, czyli więcej tokenów.

Dane branżowe są tu zgodne i mało optymistyczne: zdecydowana większość firm przekroczyła pierwotne założenia kosztowe dla AI, a projekty agentowe przekraczają budżet średnio ponad dwukrotnie. Nie dlatego, że ktoś się pomylił w arkuszu — dlatego, że arkusz zakładał stałą liczbę wywołań, a produkcja jej nie ma.

Trzy zabezpieczenia, które warto wprowadzić, zanim rachunek zdąży zaskoczyć: twardy limit wydatków na poziomie konta u dostawcy, rozbicie kosztu po procesach (żeby wiedzieć, który proces zjada połowę), oraz alert na zmianę kosztu na jedną sprawę, nie na sumę. Bez trzeciego elementu nie odróżnicie wzrostu użycia od wzrostu marnotrawstwa.

Realny rząd wielkości dla miesięcznego utrzymania sensownego wdrożenia w małej lub średniej firmie to kilka procent kosztu wdrożenia miesięcznie — i w tej kwocie tokeny są zwykle mniejszą częścią niż praca ludzi, którzy przeglądają próbki, poprawiają bazę wiedzy i aktualizują integracje. Anatomię całego budżetu rozłożyliśmy w tekście ile kosztuje wdrożenie AI.

Od 28 października nadzór przestaje być teorią

Do utrzymania doszedł w tym roku wątek, którego w 2024 jeszcze nie było: obowiązki po stronie firmy, która system stosuje — niezależnie od tego, kto go zbudował. Polska ustawa o systemach sztucznej inteligencji weszła w zasadniczej części w sierpniu 2026, a uprawnienia kontrolne i karne krajowego organu nadzoru zaczynają obowiązywać 28 października 2026. Od tej daty kontrola i postępowanie przestają być scenariuszem hipotetycznym.

Dla większości firm nie oznacza to nowych systemów ani nowych narzędzi. Oznacza, że trzy rzeczy, które i tak są dobrą praktyką utrzymaniową, stają się czymś, co trzeba umieć pokazać: że ktoś konkretny nadzoruje działanie systemu i ma kompetencje oraz uprawnienia, żeby interweniować; że działanie systemu jest monitorowane zgodnie z instrukcją dostawcy; i że zostają zapisy tego, co system zrobił. W przypadku zastosowań wysokiego ryzyka przepisy mówią o przechowywaniu logów przez co najmniej sześć miesięcy.

Warto przy tym zachować proporcje. Większość wdrożeń w małej firmie — asystent na dokumentach, bot obsługowy, notatki ze spotkań — nie jest systemem wysokiego ryzyka i nie wchodzi w najcięższy reżim. Wyjątki są jednak dokładnie tam, gdzie wdrożenia bywają najbardziej kuszące: rekrutacja i ocena pracowników, scoring kredytowy, decyzje o dostępie do usług. Granice opisaliśmy w tekstach o AI Act w małej firmie i AI w rekrutacji po AI Act.

Praktyczny wniosek dla utrzymania jest nudny i dlatego skuteczny: logi i miesięczny raport jakości przestają być luksusem inżynierskim, a stają się dokumentacją. To ta sama praca, tylko zapisywana.

Kto to robi — bo „wszyscy” znaczy nikt

Najczęstsza przyczyna, dla której wdrożenie gaśnie, nie jest techniczna. Po odbiorze projektu dostawca przechodzi do następnego klienta, osoba, która forsowała temat w firmie, wraca do swoich obowiązków, a system zostaje bez właściciela. Zestawienia przyczyn, dla których firmowe projekty AI nie wychodzą poza pilota, konsekwentnie wymieniają brak jasnej odpowiedzialności organizacyjnej w pierwszej piątce — obok braku narzędzi do monitoringu.

Właściciel systemu AI nie musi być inżynierem i w małej firmie zwykle nim nie jest. To osoba z działu, który z systemu korzysta: kierownik obsługi klienta, osoba odpowiedzialna za ofertowanie, biuro zarządu. Potrzebuje trzech rzeczy: godziny w miesiącu wpisanej w kalendarz, dostępu do raportu z czterema liczbami i prawa do zgłoszenia zmiany bez zbierania zgód.

Druga rola jest dostawcy albo partnera technicznego i powinna być zapisana w umowie w sposób mierzalny: kto podmienia wersję modelu, gdy dostawca ogłosi wycofanie, w jakim czasie, na czyj koszt i z jakim testem regresji. „Wsparcie powdrożeniowe” bez tych czterech elementów nie jest zobowiązaniem, tylko dobrą intencją.

Trzecia rola jest najtańsza i najczęściej pomijana: ktokolwiek, kto korzysta z systemu, musi mieć sposób zgłoszenia złej odpowiedzi w jednym kliknięciu, z zapisanym kontekstem. Zgłoszenia pracowników są najszybszym systemem wykrywania degradacji, jaki firma ma — o ile nie wymagają napisania maila. Dlaczego zespół milczy, gdy narzędzie jest kiepskie, opisaliśmy w tekście kupiłeś zespołowi AI i nikt z niego nie korzysta.

Rytm, który się utrzymuje

Utrzymanie działa wtedy, gdy jest nudne i powtarzalne. Poniższy rytm sprawdza się w firmach, które nie mają zespołu danych i nie zamierzają go mieć.

1. Co tydzień, piętnaście minut: przeczytajcie dziesięć losowych interakcji systemu. Nie najgorszych, nie zgłoszonych — losowych. To jedyny sposób, żeby zobaczyć stan przeciętny, a nie skrajny.
2. Co miesiąc, godzina: uruchomcie zestaw kontrolny, zapiszcie cztery liczby obok liczb z poprzedniego miesiąca, przejrzyjcie zgłoszenia z formularza. Jedna strona, jeden właściciel, archiwum w jednym miejscu.
3. Co kwartał, pół dnia: przegląd bazy wiedzy pod kątem nieaktualnych dokumentów, przegląd uprawnień systemu (czy nadal widzi dokładnie to, co powinien) i sprawdzenie harmonogramów wycofania modeli u dostawców. Kwestię dostępów i porządku w danych rozwinęliśmy w tekście o danych gotowych na AI.
4. Po każdej zmianie, zawsze: zestaw regresyjny przed wypuszczeniem zmiany na produkcję. Zmiana promptu to zmiana w systemie produkcyjnym, nawet jeśli wygląda jak edycja zdania.
5. Raz w roku, jeden dzień: pytanie, czy ten proces nadal wymaga AI. Część wdrożeń po roku okazuje się droższa niż zwykła automatyzacja, która robiłaby to samo taniej i przewidywalnie. Kryteria wyboru opisaliśmy w tekście agent AI czy zwykła automatyzacja.

Trzy sygnały, że wdrożenie jest już bez opieki

• Nikt nie potrafi powiedzieć z pamięci, która wersja modelu obsługuje dany proces. Jeśli odpowiedź wymaga wejścia w kod albo maila do dostawcy, nie ma właściciela.
• Nie istnieje liczba, którą można porównać z liczbą z dnia odbioru. Zdanie „chyba działa dobrze” po pół roku oznacza, że nikt nie mierzy, a nie że jest dobrze.
• Ostatnia zmiana w bazie wiedzy jest starsza niż ostatnia zmiana w cenniku, regulaminie albo ofercie. System odpowiada na pytania o firmę, której już nie ma.

Od czego zacząć

Pierwszy krok zajmuje godzinę i nie wymaga żadnego narzędzia: wypiszcie na jednej stronie każdy proces, w którym firma dziś używa AI, a obok — kto jest jego właścicielem, która wersja modelu go obsługuje, kiedy ostatnio ktoś sprawdził jakość i jaki był wynik. Puste pola na tej stronie są dokładną listą ryzyk, które macie w tej chwili.

Prowadzimy utrzymanie wdrożeń AI jako osobną usługę właśnie dlatego, że to w niej decyduje się, czy projekt zwróci koszt — monitoring jakości, aktualizacje przy wycofaniu modeli, przeglądy bazy wiedzy i miesięczny raport dla właściciela systemu. Jeśli macie wdrożenie, którego nikt nie pilnuje, albo planujecie start i chcecie od razu ustawić to porządnie, umówcie bezpłatną konsultację albo zobaczcie, jak wygląda nasz konsulting i wdrożenia AI.