Wycofanie modelu AI: trzy drogi, którymi tracisz dostęp

Wycofanie modelu AI to tylko jeden z trzech sposobów, w jakie firma może stracić model działający w narzędziu, za które płaci. Dostęp może zakończyć się przez ogłoszoną deprecację modelu, rozwiązanie umowy między dostawcą modelu a dostawcą narzędzia albo zmianę modelu bazowego dokonaną przez producenta narzędzia. Tylko pierwsza droga ma z góry opisany mechanizm cyklu życia i publiczny harmonogram wycofań. W drugiej termin pojawia się dopiero po uruchomieniu mechanizmu umownego, a w trzeciej odrębnej daty końca może w ogóle nie być. Przykładem drugiej sytuacji jest komunikat OpenAI z 28 sierpnia 2026: firma zapowiedziała zakończenie dostarczania modeli do Cursora i wskazała 12 listopada 2026 jako proponowaną datę odcięcia.

Kluczowe wnioski

Ryzyko utraty konkretnego modelu zależy nie tylko od polityki jego producenta. Dla firmy równie istotne są kanał dystrybucji modelu, umowa między dostawcami oraz możliwość zmiany modelu bazowego bez wyłączenia całego narzędzia.

✓ OpenAI deklaruje dla modeli ogólnie dostępnych w API co najmniej sześć miesięcy uprzedzenia, a dla wyspecjalizowanych wariantów modeli ogólnie dostępnych co najmniej trzy miesiące. Anthropic deklaruje co najmniej 60 dni dla publicznie wydanych modeli na platformach obsługiwanych przez siebie. Google nie podaje stałego minimalnego okresu.

✓ Deklaracje nie są bezwarunkowe. OpenAI dopuszcza szybsze wycofanie ze względów bezpieczeństwa lub zgodności, a modele preview mogą być wyłączane ze znacznie krótszym uprzedzeniem.

✓ Polityka deprecacji nie obejmuje sytuacji, w której producent modelu rozwiązuje umowę z dostawcą narzędzia. W sprawie Cursora proponowane okno między komunikatem a odcięciem wynosi 76 dni i wynika z mechanizmu umownego, nie z cyklu życia modelu.

✓ Dostawca narzędzia może również zmienić model bazowy bez wyłączenia produktu. Microsoft wskazuje, że Copilot korzysta z różnych modeli, może dobierać model do zapytania i może wdrażać inne modele hostowane i obsługiwane przez Microsoft.

✓ DORA wymaga strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub istotne. Obowiązek dotyczy podmiotów finansowych. Dla pozostałych firm jest to użyteczny wzorzec zarządzania zależnością od dostawcy, a nie obowiązek wynikający z DORA.

Czym jest wycofanie modelu AI i czym różni się od utraty dostępu

Wycofanie modelu AI to formalnie ogłoszony proces zakończenia wsparcia lub dostępności konkretnej wersji modelu. Dostawca określa harmonogram wyłączenia, a często także zalecany model zastępczy. Utrata dostępu jest pojęciem szerszym: model może przestać obsługiwać twoją pracę, mimo że nadal istnieje i pozostaje dostępny dla innych klientów.

OpenAI rozróżnia między modelem legacy, modelem zdeprecjonowanym i faktycznym wyłączeniem. Po ogłoszeniu deprecacji model otrzymuje datę wyłączenia, po której przestaje być dostępny. Anthropic stosuje podobny cykl: Active, Legacy, Deprecated i Retired. Google również odróżnia ogłoszenie deprecacji od późniejszego wyłączenia endpointu.

Dla firmy ważniejszy jest jednak skutek operacyjny. Ten sam efekt, brak dostępu do dotychczasowego modelu, może powstać na trzy różne sposoby.

Droga	Kto podejmuje decyzję	Kiedy poznajesz termin	Typowe źródło informacji	Co można zrobić wcześniej
Wycofanie modelu z cyklu życia	dostawca modelu	z publicznego harmonogramu deprecacji	dokumentacja producenta, e-mail do aktywnych klientów	śledzić modele używane produkcyjnie i planować migrację
Rozwiązanie umowy między dostawcami	dostawca modelu i dostawca narzędzia	po uruchomieniu mechanizmu umownego	komunikat stron, informacje dla klientów, media	ustalić, od których zewnętrznych modeli zależy narzędzie
Zmiana modelu bazowego	dostawca narzędzia	odrębnej daty końca może nie być	dokumentacja produktu, centrum administracyjne, release notes	ustalić zasady routingu, zmiany modeli i powiadomień

Wycofanie modelu różni się więc od zmiany modelu tym, że w pierwszym przypadku kończy się dostępność określonego modelu w danym kanale. W drugim produkt może działać bez przerwy, ale generować wyniki przy użyciu innego modelu.

Ile czasu deklarują dostawcy modeli

Nie istnieje jeden rynkowy standard okresu uprzedzenia przed wycofaniem modelu. Polityka zależy od producenta, rodzaju modelu i kanału, przez który firma uzyskuje do niego dostęp.

Poniższe wartości są deklaracjami producentów, a nie statystyką rzeczywistych terminów migracji.

Dostawca i kanał	Kategoria modelu	Deklarowany minimalny okres uprzedzenia
OpenAI API	modele ogólnie dostępne	co najmniej 6 miesięcy
OpenAI API	wyspecjalizowane warianty modeli ogólnie dostępnych	co najmniej 3 miesiące
Anthropic, platformy obsługiwane przez Anthropic	publicznie wydane modele	co najmniej 60 dni
Google Gemini API	modele objęte harmonogramem	brak zadeklarowanego stałego minimum

Deklarowane minimalne okresy uprzedzenia przed wycofaniem modelu AI: 60 dni u Anthropic oraz co najmniej trzy i sześć miesięcy w OpenAI API. — OpenAI API deklaruje co najmniej sześć miesięcy uprzedzenia dla modeli ogólnie dostępnych i trzy miesiące dla wariantów wyspecjalizowanych; Anthropic co najmniej 60 dni (dokumentacje producentów, sierpień 2026).

OpenAI zastrzega przy tym, że okresy sześciu i trzech miesięcy obowiązują, o ile szybszego działania nie wymagają kwestie bezpieczeństwa lub zgodności. W takim przypadku producent deklaruje możliwie duże uprzedzenie, ale nie określa dolnej granicy.

Modele preview tworzą osobną kategorię ryzyka. OpenAI nie gwarantuje dla nich analogicznego minimum. Dokumentacja wskazuje, że mogą być wycofywane ze znacznie krótszym uprzedzeniem i podaje około dwóch tygodni jako przykład. Producent wprost odradza uzależnianie od takich modeli krytycznych obciążeń produkcyjnych, jeśli organizacja nie potrafi szybko przeprowadzić migracji.

Znaczenie ma również kanał dystrybucji. Anthropic podaje, że jego harmonogram dotyczy platform obsługiwanych przez Anthropic, natomiast Amazon Bedrock i Google Cloud ustalają własne terminy. Status i data wycofania tego samego modelu mogą więc różnić się zależnie od miejsca zakupu usługi.

Google stosuje jeszcze inny mechanizm. Publikowane daty określa jako najwcześniejsze możliwe terminy wyłączenia i deklaruje późniejsze przekazanie dokładnej daty z wyprzedzeniem, ale nie definiuje stałego minimum tego uprzedzenia. Brak minimum nie oznacza, że Google będzie uprzedzać krótko. Oznacza tylko brak liczbowego zobowiązania, na którym klient mógłby oprzeć plan migracji.

Praktyczne konsekwencje są trzy. Po pierwsze, status preview należy traktować jako informację o stabilności zobowiązania, nie tylko etykietę funkcji. Po drugie, firma powinna obserwować harmonogram konkretnego kanału, przez który korzysta z modelu. Po trzecie, deklarowany okres uprzedzenia nie zastępuje własnego testu modelu zastępczego.

Kiedy model znika, bo dostawcy rozwiązują umowę

Polityka deprecacji nie chroni klienta przed utratą modelu wynikającą z umowy między dwiema innymi firmami. Model może nadal istnieć, ale twój dostawca narzędzia może utracić prawo do jego udostępniania.

28 sierpnia 2026 OpenAI poinformowało SpaceX, że zamierza zakończyć umowę na dostarczanie modeli do Cursora. Jako proponowaną datę odcięcia wskazało 12 listopada 2026. OpenAI podało również, że umowa z Cursorem przewiduje ograniczone czasowo prawo do jej rozwiązania po zmianie kontroli nad drugą stroną.

To rozróżnienie jest kluczowe. Sześciomiesięczna polityka OpenAI dotycząca ogólnie dostępnych modeli w API i 76-dniowe proponowane okno w sprawie Cursora nie są ze sobą sprzeczne. Pierwsza liczba pochodzi z polityki cyklu życia produktu. Druga z umowy pomiędzy przedsiębiorstwami.

Z perspektywy użytkownika Cursora przyczyna sporu ma mniejsze znaczenie niż konstrukcja zależności. Klient może prawidłowo korzystać z narzędzia, terminowo płacić i nie naruszać żadnego regulaminu, a mimo to utracić konkretny model wskutek zdarzenia zachodzącego poziom wyżej w łańcuchu dostaw.

Współzałożyciel Cursora Michael Truell napisał 29 sierpnia, że modele OpenAI obsługują około 5 procent „Cursor user traffic” i że rozmowy z OpenAI trwają. Sama wypowiedź nie definiuje jednak tej miary. Nie należy więc przekształcać 5 procent w udział użytkowników, tokenów, kosztów ani znaczenie biznesowe bez dodatkowych danych.

Rekomendacja warunkowa: dla firmy zależnej od zewnętrznego narzędzia ważniejszy od samej nazwy modelu jest łańcuch zależności. Jeżeli narzędzie jest istotne operacyjnie, trzeba wiedzieć, czy jego kluczowe modele pochodzą od podmiotów trzecich i jaki mechanizm obowiązuje w razie zakończenia tej współpracy.

Kiedy dostawca narzędzia zmienia model bazowy

Trzecia droga nie wymaga wyłączenia ani zerwania umowy. Produkt może działać pod tą samą nazwą, a dostawca może zmieniać model używany do obsługi określonych zapytań.

Dokumentacja Microsoft Copilot wskazuje, że platforma korzysta z różnych modeli, a w domyślnym trybie może dynamicznie dobierać model w zależności od zapytania. Microsoft zastrzega również możliwość wdrażania innych modeli hostowanych i obsługiwanych przez siebie.

Sformułowanie „hostowany i obsługiwany przez Microsoft” nie oznacza automatycznie „model własny Microsoftu”. Dokumentacja Microsoft Online Services zalicza do tej kategorii między innymi modele Azure OpenAI oraz FLUX firmy Black Forest Labs. Z punktu widzenia klienta istotna jest więc zarówno własność modelu, jak i model prawny oraz infrastrukturalny jego udostępnienia.

Osobno Microsoft rozwija własne modele MAI. 23 lipca 2026 firma poinformowała, że wyspecjalizowany model MAI jest już używany w produkcyjnym wdrożeniu w Excelu. Według Microsoftu w najczęstszych zadaniach osiąga poziom porównywalny z GPT-5.6 przy większej efektywności kosztowej. To jest źródło pierwotne potwierdzające, że własny model Microsoftu faktycznie wszedł do produktu, a nie pozostał eksperymentem laboratoryjnym.

Bloomberg uzupełnił ten obraz 7 lipca 2026. Według jego ustaleń własne modele MAI obsługiwały już dziesiątki tysięcy zapytań tygodniowo w Excelu i Outlooku, a jednym z motywów przesunięcia było ograniczenie kosztów korzystania z modeli zewnętrznych. To ustalenie pochodzi jednak z relacji prasowej opartej częściowo na anonimowym źródle, a nie z dokumentacji produktu.

Jaką kontrolę ma administrator

Kontrola administratora obejmuje wybrane kategorie modeli, ale nie każdą zmianę modelu bazowego. Dostępność przełącznika zależy między innymi od typu modelu i sposobu jego udostępnienia.

Microsoft dokumentuje możliwość zarządzania dostępem do modeli Anthropic w określonych doświadczeniach Copilota. Osobna kontrola obejmuje modele preview i eksperymentalne: administrator może je włączać, wyłączać albo ograniczać do wybranych użytkowników i grup.

Co istotne, model preview może być zarówno hostowany przez Microsoft, jak i pochodzić od zewnętrznego dostawcy. Sam status preview opisuje gotowość modelu do użycia, a nie sposób przetwarzania danych.

Nie znalazłem natomiast w sprawdzonej dokumentacji ogólnego przełącznika pozwalającego administratorowi zamrozić standardową konfigurację Copilota na jednym konkretnym modelu bazowym lub blokować wszystkie standardowe modele hostowane przez Microsoft. Nie znalazłem również uniwersalnego minimalnego okresu powiadomienia przed taką zmianą.

To nie dowodzi, że Microsoft nie informuje o poszczególnych zmianach. Oznacza tylko, że nie należy zakładać ciągłości konkretnego modelu, jeżeli nie wynika ona z dokumentacji produktu lub umowy.

Czego wymaga DORA i co z AI Act

DORA daje podmiotom finansowym gotowy aparat do zarządzania zależnością od zewnętrznych usług ICT. Akt o sztucznej inteligencji reguluje inne problemy i nie tworzy ogólnego prawa klienta do utrzymania dostępu do konkretnego modelu AI.

Rozporządzenie DORA wymaga między innymi:

określenia sytuacji umożliwiających zakończenie umowy z zewnętrznym dostawcą ICT;
posiadania strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub istotne;
oceny, czy dostawca wspierający taką funkcję jest łatwo zastępowalny;
uwzględnienia ryzyka koncentracji oraz złożonych łańcuchów podwykonawstwa.

To właśnie łańcuch podwykonawstwa jest istotny dla narzędzi AI. Firma może kupować aplikację od dostawcy A, który korzysta z modelu dostawcy B, model jest hostowany w infrastrukturze C, a część przetwarzania odbywa się jeszcze u innego podmiotu. Dla ciągłości działania znaczenie ma cały łańcuch, nie tylko logo widoczne w interfejsie.

Dla podmiotu spoza sektora finansowego strategia wyjścia DORA nie jest obowiązkiem wynikającym z tego rozporządzenia. Może jednak służyć jako wzorzec: ustal zastępowalność, zależności, koszty migracji, dostęp do danych i warunki zakończenia usługi.

Akt o sztucznej inteligencji nie rozwiązuje tego problemu wprost. Art. 25 rozporządzenia 2024/1689 dotyczy odpowiedzialności w łańcuchu wartości systemów wysokiego ryzyka. Obejmuje między innymi sytuacje, w których inny podmiot staje się dostawcą systemu wysokiego ryzyka oraz obowiązek określenia w pisemnym porozumieniu informacji, dostępu technicznego i pomocy potrzebnych dostawcy takiego systemu do spełnienia wymogów rozporządzenia.

Przy ogólnym asystencie produktywności używanym do redagowania, podsumowywania czy pomocniczej analizy dokumentów art. 25 zwykle nie będzie osią problemu. Kwalifikacja zależy jednak od konkretnego przeznaczenia i zastosowania systemu, a nie od wielkości przedsiębiorstwa.

Jak to wygląda w trzech branżach

Ten sam mechanizm utraty modelu powoduje inne skutki zależnie od procesu. W finansach najważniejsza może być ciągłość i wymogi zarządzania dostawcami, w tworzeniu oprogramowania powtarzalność wyników, a w obsłudze klienta stabilność jakości odpowiedzi.

Bank i instytucja finansowa. DORA wprost reguluje część mechanizmów potrzebnych do zarządzania zewnętrznymi usługami ICT: zastępowalność, koncentrację, strategię wyjścia i łańcuch podwykonawstwa. Problem może powstać wtedy, gdy funkcja AI pojawia się jako rozszerzenie istniejącego pakietu technologicznego i nie uruchamia odrębnej procedury stosowanej przy zakupie nowej usługi.

Wytwarzanie oprogramowania. Zespół może dostroić bibliotekę poleceń, procedury testowania i sposób recenzowania kodu do charakterystyki konkretnego modelu. Zastąpienie modelu nie kasuje tej pracy, ale może obniżyć powtarzalność wyników albo wymagać ponownej kalibracji testów.

Obsługa klienta w handlu. Usługa może być cały czas dostępna, ale po zmianie modelu zmieni się styl odpowiedzi, skłonność do odmowy, korzystanie z kontekstu albo sposób przestrzegania instrukcji. Bez własnego zestawu testów regresję jakości można wykryć dopiero po sygnałach od klientów.

Jak zdecydować, czy firma potrzebuje planu wyjścia

Znaczenie ryzyka zależy przede wszystkim od krytyczności procesu, kosztu migracji i tego, czy firma potrafi sprawdzić działanie procesu na modelu zastępczym. Sama możliwość wyboru kilku modeli w interfejsie nie jest jeszcze wielomodelową strategią ciągłości.

Czy powinienem wiedzieć, jaki model działa pod spodem?

Tak, jeżeli wynik narzędzia trafia bezpośrednio do klienta, systemu produkcyjnego, dokumentacji wymagającej uzasadnienia albo procesu, którego wynik trzeba później odtworzyć.

Priorytet jest niższy przy pomocniczej pracy wewnętrznej, której rezultat podlega niezależnej weryfikacji człowieka. Nie znika jednak całkowicie, bo zmiana modelu może nadal wpływać na ciągłość procesu i powtarzalność pracy.

Czy firma spoza sektora finansowego potrzebuje strategii wyjścia?

Dla firmy spoza sektora finansowego plan wyjścia ma sens, jeśli koszt nagłej zmiany dostawcy jest większy niż koszt wcześniejszego przygotowania alternatywy.

Jeżeli zatrzymanie procesu na tydzień oznacza istotne koszty, warto znać zamiennik i przetestować migrację. Jeżeli narzędzie jest używane doraźnie, dane da się łatwo przenieść, a uruchomienie alternatywy zajmuje kilka godzin, pełna procedura może kosztować więcej niż ryzyko, które ma ograniczać.

Czy wielomodelowość rozwiązuje problem?

Nie sama w sobie.

Wielomodelowość ogranicza zależność wtedy, gdy firma faktycznie potrafi wykonać ten sam proces na przynajmniej dwóch modelach i ma sposób zmierzenia różnicy. Drugi model widoczny na liście wyboru nie tworzy odporności, jeżeli cała biblioteka poleceń, automatyzacja i kryteria kontroli jakości zostały dostrojone wyłącznie do pierwszego.

Od czego zacząć

Najtańszy test nie wymaga nowego narzędzia. Dla każdego płatnego rozwiązania AI warto uzyskać odpowiedź na trzy pytania:

Jaki model lub jakie modele obsługują dziś istotny dla nas proces?
Jakim kanałem i z jakim wyprzedzeniem dowiemy się o zmianie lub wycofaniu modelu?
Co dzieje się z usługą, jeżeli producent modelu i producent narzędzia zakończą współpracę?

Odpowiedzi warto zapisać w rejestrze ryzyk AI, razem z właścicielem ryzyka, zamiennikiem i warunkiem uruchomienia migracji.

Kiedy ta analiza ma małe znaczenie

Nie każda organizacja potrzebuje osobnej procedury ciągłości konkretnego modelu AI. Ryzyko staje się istotne dopiero wtedy, gdy proces rzeczywiście zależy od zachowania określonego modelu lub dostawcy.

Gdy AI jest używane doraźnie. Jeżeli narzędzie służy do sporadycznego tworzenia szkiców, burzy mózgów czy pomocniczego wyszukiwania, zmiana modelu może mieć niewielki skutek operacyjny.

Gdy zamienniki są równoważne dla konkretnego zadania. Nie chodzi o ogólny ranking modeli. Jeżeli własny zestaw testowy pokazuje, że dwa modele spełniają te same kryteria jakości, zachowanie konkretnej wersji modelu ma mniejsze znaczenie.

Gdy dostawca daje klientowi wystarczające gwarancje kontraktowe i operacyjne. Publiczna dokumentacja nie musi zawierać wszystkich warunków indywidualnej umowy. Brak publicznego zapisu o powiadomieniu nie dowodzi, że klient enterprise nie uzyskał takiego zobowiązania.

Gdy koszt migracji jest minimalny. Jeżeli dane nie są zamknięte w rozwiązaniu, integracje są proste, a alternatywa została wcześniej przetestowana, utrata jednego modelu może być zwykłą zmianą operacyjną, a nie ryzykiem wymagającym osobnego programu.

To podejście nie działa, gdy organizacja próbuje zarządzać nazwą modelu zamiast procesem. Celem nie jest zachowanie konkretnego GPT, Claude czy Gemini za wszelką cenę. Celem jest utrzymanie wyniku biznesowego na wymaganym poziomie jakości, bezpieczeństwa i kosztu.

Podsumowanie

Jeżeli firma korzysta z modelu AI przez zewnętrzne narzędzie, jego dostępność zależy również od decyzji i relacji umownych, których sama firma nie kontroluje. Model może zniknąć na trzy sposoby: przez formalne wycofanie z cyklu życia, rozwiązanie umowy pomiędzy dostawcą modelu a producentem narzędzia albo zmianę modelu bazowego przez dostawcę aplikacji.

Tylko pierwszy mechanizm daje przewidywalność wynikającą z publicznej polityki deprecacji. Nawet wtedy terminy zależą od dostawcy, rodzaju modelu i kanału dystrybucji. OpenAI zastrzega dodatkowo możliwość skrócenia okresu ze względów bezpieczeństwa lub zgodności, modele preview mają słabszą ochronę, a Anthropic wskazuje, że ten sam model może mieć inny harmonogram u zewnętrznego operatora.

Sprawa Cursora pokazuje drugi mechanizm. Microsoft pokazuje trzeci: dostawca produktu może korzystać z wielu modeli, dynamicznie je dobierać i rozwijać własne modele produkcyjne. Firma nie powinna więc mylić ciągłości aplikacji z ciągłością modelu.

Najprostsza kontrola kosztuje niewiele: ustalić, od jakich modeli zależy istotny proces, jak firma dowie się o zmianie oraz czy ma przetestowany zamiennik. W sektorze finansowym podobną logikę formalizuje DORA. Poza nim pozostaje ona praktyką zarządzania zależnością od dostawcy. Warto zestawić to ryzyko z kosztem używania AI oraz innymi barierami wdrożenia AI, ponieważ koszt modelu jest widoczny na fakturze, a koszt zależności często pojawia się dopiero w momencie zmiany.

O autorze

Remigiusz Pruszczak: ekspert GenAI i trener AI, makler papierów wartościowych z uprawnieniami do wykonywania czynności doradztwa inwestycyjnego (licencja nr 2343). Ponad 30 lat w finansach. Od 17 lat prowadzi szkolenia, a od 2025 roku również z generatywnej AI, między innymi dla banków, instytucji finansowych, kancelarii oraz firm z sektorów regulowanych i produkcji. Szkolenia realizuje we współpracy z EY Academy of Business Polska, Warszawskim Instytutem Bankowości, Bankowym Ośrodkiem Doradztwa i Edukacji oraz CFA Society Poland. Więcej na stronie „O mnie”.