Dostawca podmienił model pod spodem. Skąd wiecie, że wyniki się nie pogorszyły?

Identyfikator modelu w waszej integracji nie zmienił się od marca. Dostawca nie przysłał żadnego pisma, faktura wygląda tak samo, a zespół obsługi zgłasza, że od kilku tygodni odpowiedzi wymagają więcej poprawek niż wcześniej. Nikt nie potrafi powiedzieć, czy to prawda, bo nikt nie ma z czym porównać.

Ta sytuacja nie jest awarią ani niedopatrzeniem dostawcy. Jest normalnym trybem pracy rynku, na którym stabilna nazwa modelu nie oznacza stabilnego zachowania – i w którym nikt nie obiecał, że będzie inaczej.

Co dostawcy obiecują, a czego nie obiecuje żaden

Publikowane zobowiązania dotyczą wycofania modelu, czyli momentu, w którym przestanie odpowiadać. Zestawienie okresów wypowiedzenia podaje minimum sześciu miesięcy dla modeli ogólnie dostępnych u OpenAI, trzech miesięcy dla wariantów specjalistycznych i dwóch tygodni dla wersji zapoznawczych, przy 60 dniach jako dolnej granicy u Anthropic i braku stałego okresu po stronie Google. Przy dostępie przez platformy partnerskie, takie jak chmury publiczne, obowiązują harmonogramy tych platform, nie dostawcy modelu.

Te liczby odpowiadają na pytanie „kiedy model przestanie działać”. Nie odpowiadają na pytanie, które kosztuje was pieniądze: czy model działający pod tą samą nazwą zachowuje się tak samo jak miesiąc temu. To samo zestawienie zwraca uwagę, że okresy wypowiedzenia są standardem dla wycofania, a nie dla zmiany zachowania.

Dostawcy mówią to wprost we własnej dokumentacji. Microsoft pisze o modelach napędzających Copilota, że są regularnie aktualizowane i ulepszane, a aktualizacje nie zmieniają ustawień bezpieczeństwa, prywatności ani zgodności (przegląd dokumentu: 8 października 2026). Gwarancja dotyczy więc ustawień. O wynikach nie ma w tym zdaniu nic – i nie jest to przeoczenie redakcyjne, bo takiej gwarancji nikt na tym rynku nie daje.

Ile z tych zmian jest w ogóle udokumentowane

Badanie zgłoszone na konferencję AIES-26 zmierzyło to na próbie dziewięciu dostawców własnych API i siedmiu zewnętrznych platform udostępniających modele. Wyniki w liczbach:

Dwie liczby z tej tabeli wystarczą do decyzji. Pierwsza: zmiany zachowania na poziomie wersji dokumentuje trzech dostawców z dziewięciu, więc w większości przypadków dziennik zmian odnotuje nowy produkt i nową cenę, a nie to, że istniejące wdrożenie zaczęło odpowiadać inaczej. Druga: żaden dostawca w tej próbie nie publikował informacji pozwalających stronie trzeciej zweryfikować, że obsługiwany model jest tym opisanym w dokumentacji. Autorzy nazywają ten stan przejrzystością bez możliwości weryfikacji.

Dla zarządu oznacza to jedno: nie ma zewnętrznego źródła, które potwierdzi stabilność waszego dostawcy. Jedynym dostępnym dowodem jest pomiar po waszej stronie.

Dlaczego to decyzja zarządu, a nie sprawa działu IT

Dopóki model obsługuje wewnętrzne podsumowania, pogorszenie jakości jest kosztem wygody. Zmienia się to w trzech sytuacjach, i wszystkie trzy są przedmiotem decyzji na poziomie zarządu.

• Proces dotyka klienta. Odpowiedzi, wyceny, pisma, kwalifikacja zgłoszeń. Pogorszenie o kilka procent nie rzuca się w oczy w żadnym raporcie, ale schodzi na reklamacje i na czas obsługi.
• Na wyniku modelu oparto decyzję liczbową. Klasyfikacja, ocena ryzyka, priorytetyzacja. Zmiana rozkładu odpowiedzi przesuwa próg, którego nikt nie przestawiał.
• Wdrożenie zostało rozliczone jako oszczędność. Jeśli efekt policzono raz, przy starcie, to deklarowana oszczędność opiera się na zachowaniu modelu z tamtego miesiąca. Po cichej zmianie nie macie ani oszczędności, ani wiedzy o jej braku.

Mechanizm jest ten sam co przy każdym dostawcy krytycznego komponentu: ryzyko nie polega na tym, że jakość spadnie, a na tym, że spadnie bez sygnału. Pierwszym sygnałem w takim układzie zawsze jest klient.

Zestaw kontrolny: trzydzieści przypadków, które mierzą to za was

Rozwiązanie jest nudne i tanie: zbiór przypadków testowych z zapisanymi poprawnymi odpowiedziami, uruchamiany automatycznie raz na tydzień. Konstrukcja, która wystarcza:

• Trzydzieści przypadków z realnej pracy z ostatnich dwóch kwartałów, nie wymyślonych. Dobierane tak, by obejmowały typową sprawę, dwie trudne i jedną, na której wdrożenie już raz się pomyliło.
• Oczekiwany wynik opisany kryterium, nie dosłownym tekstem. Dla klasyfikacji – właściwa kategoria. Dla pisma – obecność trzech wymaganych elementów i brak zdania o czymś, czego nie ma w danych wejściowych.
• Ten sam zestaw, te same parametry, ta sama godzina. Zmiana czegokolwiek po waszej stronie unieważnia porównanie, a dokładnie porównanie jest tu produktem.
• Wynik zapisywany do rejestru z datą i wersją, którą dostawca podaje w odpowiedzi, jeśli ją podaje.

Koszt: zbudowanie zestawu to zwykle dwa do czterech dni pracy osoby, która zna proces, plus kilka godzin na automatyzację uruchomienia. Utrzymanie to kilkadziesiąt minut miesięcznie i koszt zapytań, który przy trzydziestu przypadkach raz na tydzień jest pomijalny wobec rachunku za samo wdrożenie.

Co z tym robić, gdy wskaźnik spadnie: nie dzwonić do dostawcy od razu. Najpierw powtórzyć pomiar następnego dnia, bo pojedynczy odczyt bywa przypadkowy. Przy dwóch odczytach z rzędu poniżej progu macie coś, czego nie dało się mieć wcześniej – datowany dowód zmiany, z którym idzie się na rozmowę o umowie, a nie przypuszczenie.

Co zapisać w umowie przed najbliższym odnowieniem

Ostatni wiersz pokazuje, dlaczego kolejność jest taka, a nie odwrotna: bez własnego pomiaru nie da się napisać zapisu umownego, bo nie ma czym zdefiniować progu. Negocjowanie gwarancji jakości przed zbudowaniem zestawu kontrolnego kończy się klauzulą, której nie da się wykorzystać.

Kto to robi i komu to podlega

Zestaw kontrolny nie ma właściciela naturalnego. Dział IT widzi integrację, ale nie wie, co jest poprawną odpowiedzią. Dział biznesowy wie, co jest poprawne, ale nie uruchomi pomiaru. Dostawca nie ma interesu w mierzeniu własnej regresji.

Praktyczny podział, który się nie rozsypuje: kryteria poprawności definiuje osoba odpowiedzialna za proces, uruchomienie i rejestr prowadzi dział techniczny, a przegląd wyników raz na miesiąc należy do osoby, która odpowiada w firmie za wdrożenia agentów i rozmowy z dostawcami. Jeśli takiej osoby nie ma, pomiar będzie robiony przez kwartał, a potem zniknie – nie z powodu kosztu, a z braku kogoś, kto pyta o wynik.

Na zarząd z tego idzie jedna liczba miesięcznie: odsetek przypadków kontrolnych zaliczonych, z datą ostatniego pomiaru. To pozycja, która ma sens w zestawieniu zarządczym mieszczącym się na jednej kartce, i nie potrzebuje slajdu.

Gdy dostawca wycofuje waszą wersję: migracja jako projekt, nie jako poprawka

Oznaczona wersja modelu rozwiązuje problem stabilności i wprowadza drugi: wersje oznaczone mają krótszy okres życia niż alias. Prędzej czy później przychodzi komunikat o wycofaniu, a wtedy zmiana nie jest podmianą jednej linii w konfiguracji.

Co trzeba policzyć w takim przejściu, w kolejności od największej pozycji:

• Przejście zestawem kontrolnym na nowej wersji – jeśli zestaw istnieje, to kilka godzin i macie twardą odpowiedź, czy nowa wersja jest lepsza, równa czy gorsza. Jeśli nie istnieje, migracja odbywa się na wyczucie i to jest realny koszt jego braku.
• Korekta instrukcji i promptów – zachowanie zmienia się nierównomiernie, więc poprawki zwykle dotyczą kilku przypadków skrajnych, nie wszystkiego. Bez zestawu kontrolnego nie wiadomo których.
• Okres pracy równoległej – stara i nowa wersja obsługują ten sam proces przez tydzień lub dwa, z porównaniem wyników. Podwójny koszt zapytań w tym okresie jest tańszy niż jedna reklamacja od klienta.
• Zmiana kosztu jednostkowego – nowa wersja ma inny cennik i inną długość odpowiedzi, co przy tej samej liczbie spraw zmienia rachunek w obie strony.

Wniosek dla planowania: data wycofania obecnej wersji jest pozycją w kalendarzu zarządu, nie w zgłoszeniu technicznym. Sprawdźcie ją raz na kwartał, bo wyprzedzenie, które daje dostawca, bywa krótsze niż czas potrzebny na przejście w procesie dotykającym klientów.

Czego ten pomiar nie załatwia

Trzy ograniczenia, które trzeba przyjąć razem z metodą.

Nie wykryje zmian poza zestawem. Trzydzieści przypadków pokrywa to, co ktoś pomyślał, że warto pokryć. Przypadek, który pojawi się po zmianie modelu, nie będzie w zestawie z definicji. Dlatego zestaw rozszerza się o każdy realny błąd, który przeszedł przez proces – to jedyny sposób, żeby rósł w stronę rzeczywistości.

Nie powie, dlaczego wynik się zmienił. Pokaże, że się zmienił i kiedy. Przyczyna może leżeć w modelu, w waszej zmianie promptu, w innej wersji biblioteki albo w danych wejściowych, które też się zmieniły. Rejestr z datami pozwala wykluczyć wasze zmiany – i tylko tyle, ale to zwykle wystarcza do rozmowy.

Nie zastąpi decyzji o progu. Jeśli nikt nie ustalił, przy jakim spadku wdrożenie przestaje się opłacać, pomiar wyprodukuje wykres bez konsekwencji. Próg jest decyzją zarządu, nie wynikiem pomiaru.

Pytania na najbliższe spotkanie

• Które z naszych procesów opartych na modelu dotykają klienta albo podejmują decyzję liczbową? Lista z nazwami, nie z liczbą.
• Czy w umowie z dostawcą mamy oznaczoną wersję modelu, czy alias? Kto to potwierdzi do końca tygodnia?
• Kiedy ostatnio ktokolwiek sprawdził jakość wyników na tych samych przypadkach co przy starcie? Jeśli nigdy – jaki jest nasz punkt odniesienia?
• Kto jest właścicielem kryteriów poprawności dla każdego z tych procesów?
• Przy jakim spadku jakości wstrzymujemy proces, a przy jakim wracamy do rozmowy z dostawcą? Dwie konkretne liczby.
• Kiedy wygasa obecna umowa i czy mamy przed tą datą własny pomiar, na którym da się oprzeć negocjacje?

Pierwsze i trzecie pytanie wystarczą, żeby wyjść ze spotkania z decyzją: albo macie punkt odniesienia, albo zlecacie jego zbudowanie z datą. Trzeci wariant – uznanie, że dostawca poinformuje was o zmianie – nie ma pokrycia w tym, co dostawcy obiecują.