13 czerwca 2026 roku TechCrunch poinformował, że Anthropic globalnie wycofał modele Fable 5 i Mythos 5, które niedawno udostępnił. Decyzja była następstwem dyrektywy rządu USA, która zakazywała dostępu cudzoziemcom, w tym pracownikom Anthropic bez amerykańskiego obywatelstwa. Zamiast nakładać ograniczenia na poszczególnych użytkowników, Anthropic zawiesił dostęp do modeli na szeroką skalę. W Indiach, które zarówno Anthropic, jak i OpenAI uznają za swój drugi co do wielkości rynek, na nowo rozgorzała dyskusja o tym, czy można budować produkty na AI, które pozostaje poza lokalną kontrolą.
Nie oceniam geopolityki, ale wyciągam z tego wydarzenia lekcję dla architektury systemów - i dotyczy ona każdego zespołu produktowego, niezależnie od tego, czy rozwijasz produkt w Bangalore, Berlinie czy Bostonie.
Problem
Model najnowszej generacji od wiodącego dostawcy zachowuje się jak infrastruktura: wywołujesz endpoint, dostajesz tokeny i budujesz na nim produkt. Tyle że to infrastruktura cudza — nie masz nad nią kontroli. Dostęp może zniknąć nie przez awarię techniczną, lecz przez zmianę polityki dostawcy, nową regulację albo decyzję geopolityczną. Ten scenariusz większość zespołów pomija w analizie ryzyka. Właśnie to się stało: dostęp do modeli najnowszej generacji zaczął zależeć od obywatelstwa i od dyrektywy wydanej w piątek.
Jeśli proces tworzenia treści, automatyzacja obsługi klienta albo główna funkcja produktu wymaga dostępu do najnowszego modelu jednego dostawcy, przyjmujesz zależność z przełącznikiem, którego nie masz w ręku i którego nie przewidzisz.
Kontekst
Znaczenie tego ryzyka rośnie wraz z rolą modelu w systemie. Można wyróżnić trzy przybliżone poziomy:
- Pomocniczy – AI przygotowuje opis, który zawsze podlega redakcji. Utrata dostępu oznacza głównie mniejszą wygodę, a dostawcę można zmienić w jedno popołudnie.
- Krytyczny dla procesu – AI obsługuje obowiązkowy etap kontroli jakości albo generuje treści publikowane po pobieżnej weryfikacji. Utrata dostępu zatrzymuje proces do czasu dostosowania promptów do innego modelu.
- Fundamentalny – wynik modelu jest produktem. Odcięcie dostępu nie obniża jakości produktu - całkowicie go wyłącza.
To samo zawieszenie dostępu na pierwszym poziomie jest drobną niedogodnością, a na trzecim zagrożeniem dla istnienia produktu. Większość zespołów nigdy nie określa, na którym poziomie działa. Po prostu integruje model z najlepszym wynikiem w benchmarku z poprzedniego kwartału i przechodzi do kolejnych zadań.
Debata w Indiach pokazuje też drugi wymiar problemu: najnowszy model komercyjny kontra model wystarczająco dobry. Sridhar Vembu z Zoho odpowiedział na zawieszenie dostępu apelem o mniejsze modele z otwartymi wagami. To nie patriotyzm, lecz decyzja architektoniczna. Model, który można samodzielnie uruchomić, dostroić i hostować, może oferować niższą jakość, ale daje coś, czego nie zapewnia zawieszone API: kontrolę nad momentem jego wyłączenia.
Ta zamiana ma swoją cenę. Samodzielne hostowanie nie zapewnia niezależności bez dodatkowych kosztów. Przejmujesz wydatki na GPU i inferencję, obowiązki operacyjne, cykl aktualizacji i zabezpieczania systemu oraz odpowiedzialność za przestrzeganie licencji, która może nakładać inne ograniczenia. Ryzyko nie znika, lecz przechodzi z dostawcy modelu na Ciebie jako operatora infrastruktury. Pytanie brzmi: za który tryb awarii wolisz odpowiadać? Za taki, którego nie możesz przewidzieć ani ograniczyć, czy za taki, który możesz uwzględnić w budżecie i powierzyć konkretnemu zespołowi?
Decyzja
Przed podłączeniem modelu do procesu odpowiedz wprost na dwa pytania.
Jak ważna jest ta zależność dla działania produktu? Jeśli uczciwa odpowiedź brzmi „fundamentalna”, jeden dostawca hostowanego modelu to punkt awarii ukryty za funkcją produktu. Traktuj go jak dostawcę usług płatniczych: przygotuj ścieżkę migracji, zanim stanie się potrzebna, a nie dopiero po odcięciu dostępu.
Czy to zadanie naprawdę wymaga najnowszego modelu komercyjnego? Większość zadań wykonywanych przez AI w systemach produkcyjnych – klasyfikacja, ekstrakcja, zmiana formatu czy sprawdzanie kryteriów jakości – nie wymaga najnowszego dostępnego modelu. Wymaga modelu wystarczająco dobrego i stabilnego. Tymczasem wycofano właśnie modele najnowszej generacji. Uzależnienie procesu od zasady „zawsze używamy najnowszego modelu dostawcy X” zwiększa zarówno możliwości systemu, jak i jego podatność na decyzje tego dostawcy. Stabilny i wymienny model bazowy rezygnuje z części możliwości w zamian za znacznie mniejsze ryzyko.
Wersja przenośna wymaga czegoś więcej niż cienkiej warstwy abstrakcji. Warto zamknąć obsługę SDK dostawcy w jednym interfejsie, zamiast rozrzucać tę zależność po całej bazie kodu, oraz przechowywać prompty w systemie kontroli wersji. To jednak tylko obniża koszt migracji. Odporność wymaga drugiego dostawcy albo alternatywnego wdrożenia, które jest już skonfigurowane, ma gotowe uwierzytelnianie i odpowiednie limity, a ruch można do niego skierować sprawdzoną trasą. Samodzielne hostowanie idzie o krok dalej: przenosi odpowiedzialność za dostępność do obsługiwanej przez Ciebie infrastruktury, wraz z jej kosztami i możliwymi awariami.
Plan awaryjny ma sens tylko wtedy, gdy potrafisz potwierdzić jego skuteczność. Utrzymuj zestaw ewaluacyjny z jawnymi progami jakości, regularnie testuj na nim drugi model i sprawdź przełączenie w warunkach produkcyjnych przed wystąpieniem incydentu. „Zmienimy model w jeden dzień” jest wiarygodne dopiero wtedy, gdy potwierdzają to pomyślne wyniki testów i sprawdzona procedura przełączenia, przygotowane zanim podstawowy model zniknie. Samo dodanie warstwy abstrakcji nie daje takiej gwarancji.
Konsekwencje
Rezygnujesz z części możliwości i wygody, aby zyskać większą kontrolę nad awariami systemu i sposobem przywracania go do działania. W praktyce:
- Nieco słabszy model, nad którym masz kontrolę, jest lepszy od nieco skuteczniejszego modelu, który może zostać Ci odebrany – przynajmniej w zastosowaniach krytycznych dla procesu. W zadaniach pomocniczych nadal możesz wybierać najnowsze modele, bo ewentualna szkoda ogranicza się do utraty wygody, a nie zatrzymania całego procesu.
- „Niezależność od dostawcy” przestaje być pustym hasłem i staje się zestawem trzech sprawdzalnych cech. Czy możesz przeprowadzić migrację bez przepisywania produktu? Czy potrafisz przełączyć system bez improwizowania z poświadczeniami i routingiem? Czy rozwiązanie awaryjne spełnia wymagania dotyczące jakości i przepustowości?
- Modele z otwartymi wagami i modele hostowane samodzielnie trafiają wyżej na listę rozważanych rozwiązań. Nie dlatego, że są lepsze, lecz dlatego, że koszt niezrozumienia własnych zależności właśnie stał się niemożliwy do zignorowania.
Propozycje przedstawione w Indiach po zawieszeniu dostępu – apel byłego dyrektora Infosys Mohandasa Paia o coroczny fundusz w wysokości 500 miliardów rupii oraz większe wsparcie dla niezależnych modeli bazowych – są państwowym odpowiednikiem tej samej strategii. Na razie pozostają propozycjami, a nie obowiązującą polityką. Faktyczne zobowiązanie to na razie IndiaAI Mission: 103,72 mld rupii.
Wersja, którą możesz wdrożyć już w tym tygodniu, jest znacznie skromniejsza i w pełni osiągalna: określ rolę każdej zależności AI w swoim systemie i nigdy nie opieraj fundamentalnej funkcji produktu na dostępie, który ktoś inny może odebrać w piątek.