Dlaczego to dostęp do sztucznej inteligencji, a nie jej zdolności, stanowi prawdziwe ryzyko zależności.
Ten artykuł analizuje najnowsze incydenty związane z kontrolem eksportu modeli Claude i GPT-5.6, aby pokazać, że dostęp do modeli sztucznej inteligencji jest zmienną niestabilną, niezależną od samej zdolności technicznej.
Czym właściwie różni się wynajmowanie inteligencji od jej posiadania?
Toczyły się intensywne debaty na temat standardów oceny, zdolności rozumowania, częstotliwości halucynacji oraz wielkości okna kontekstowego — wszystkich czynników stanowiących proxy dla stopnia inteligencji tych systemów.
Jednak pytanie, które jest dziś ważniejsze, brzmi inaczej: kto posiada przycisk, który może wyłączyć tę inteligencję?
12 czerwca 2026 roku rząd Stanów Zjednoczonych nałożył ograniczenia eksportowe na dwa najnowsze modele firmy Anthropic, Claude Fable 5 i Claude Mythos 5.
Rozporządzenie to wymagało od Anthropic przerwania dostępu dla obywateli zagranicznych, niezależnie od tego, czy znajdowali się fizycznie w Stanach Zjednoczonych, czy poza nimi.
Anthropic stwierdził, że nie ma niezawodnej metody na natychmiastowe potwierdzenie narodowości.
Rozważmy, co ta sekwencja faktycznie ujawnia.
Nic nie zostało skonfiskowane, usunięte ani uszkodzone z powodu błędnego kodu.
A jednak przez pewien czas niektóre z najskuteczniejszych komercyjnych systemów sztucznej inteligencji były technicznie sprawne, ale niedostępne dla tych właśnie użytkowników, którzy ich potrzebowali.
Cały ten incydent dodaje kolejny wymiar do trwającej dyskusji na temat tempa rozwoju sztucznej inteligencji — nie chodzi już tylko o to, jak szybko powinniśmy rozwijać jej możliwości, ale także o to, jak starannie należy planować wprowadzanie i dostęp do tych technologii.
Prawdziwa lekcja polega nie na tym, że dostęp znika. Chodzi o to, że dostęp funkcjonuje jako zmienna niezależna, oddzielona od samej możliwości technologicznej, kierowana własną logiką, działająca według własnego harmonogramu i zdolna do zmiany kierunku szybciej, niż jakakolwiek organizacja jest w stanie zareagować.
To o wiele bardziej niepokojąca rzeczywistość niż powoli zamykane okno, ponieważ w przypadku zmniejszającego się okna można coś zaplanować. Nie można natomiast planować w sytuacji, gdy przełącznik jest zmieniany administracyjnie, w nieprzewidywalnych kierunkach, w skali kilku dni.
Oto pytanie, nad którym warto się zastanowić: gdyby model, od którego polegasz, zniknął nagle, czy twoja praca przetrwałaby?
Własność to nie plik do pobrania
Gdy ludzie wyczuwają zależność, ich pierwszą reakcją jest poszukiwanie czegoś, co mogłoby to zastąpić.
Zabierasz otwarte wagi, przechowujesz je na dysku twardym i sądzisz, że możesz spać spokojnie. Jednak posiadanie zestawu parametrów obejmuje zaledwie niewielką część tego, co wymaga prawdziwej niezależności, a mylenie tych dwóch koncepcji rodzi specyficzny rodzaj fałszywego poczucia bezpieczeństwa – to odpowiednik w świecie sztucznej inteligencji kupna generatora awaryjnego, bez żadnej kontroli, czy w ogóle się uruchamia.
Funkcjonalny agent, który wykonywać może znaczącą pracę, to w rzeczywistości zbiór co najmniej pięciu komponentów: samych wag modelu, silnika inferencji, który je uruchamia, zgromadzonego kontekstu projektu, narzędzi, których może używać, oraz zestawu narzędzi oceniających, które pokazują, czy dany zamiennik rzeczywiście spełnia swoje zadanie.
Pobrany plik modelu to zaledwie jeden element tego zestawu.
Prawdziwa niezależność wymaga prawnego uprawnienia do działania modelu, środowiska uruchomieniowego inferencji, które można odbudować wyłącznie na podstawie dokumentacji, stanu projektu, który można swobodnie eksportować, uprawnień do narzędzi kontrolowanych przez aplikację, a nie dostawcę, oraz dowodu na to, że system zastępczy może rzeczywiście dokończyć pracę.
Sama kwestia prawna jest bardziej skomplikowana, niż się na pierwszy rzut oka wydaje.
"Open weights" i "open source" to nie terminy wymienne — definicja Inicjatywy Open Source wymaga znacznie więcej niż tylko możliwości pobrania parametrów, a licencja permissive w czasie wykonywania nie obejmuje automatycznie każdego modelu, który przez nią jest uruchamiany.
Należy faktycznie przeczytać konkretną licencję obowiązującą każdy artefakt i przechowywać jej kopię wraz z tym artefaktem.
Prawo własności danych znajduje się na zupełnie innej osi. Zgodnie z warunkami handlowymi Anthropic, klienci zachowują prawa do wszystkiego, co przesyłają, posiadają własność wyników uzyskanych przez obie strony, a Anthropic nie może używać tych treści do szkolenia modeli w ramach tych usług. Samo przesłanie treści dostawcy nie oznacza przeniesienia własności na niego. To, czy te treści zostaną później zachowane, to zupełnie inna kwestia, a odpowiedź zależy od konkretnego produktu, umowy i ustawień – a nie od tego, co ktoś kiedyś gdzieś przeczytał.
To wszystko nie stanowi argumentu przeciwko używaniu modeli hostowanych.
To po prostu przypomnienie, że fraza „my posiadamy naszą sztuczną inteligencję” obejmuje pięć lub sześć odrębnych warunków, z których każdy musi być spełniony, a większość zespołów w ogóle nie sprawdza żadnego z nich.
Arytmetyka samowystarczalności
Obliczenie ilości pamięci potrzebnej do uruchomienia modelu to prosta część zadania: bierze się liczbę parametrów, mnoży ją przez liczbę bitów używanych na każdy parametr i dzieli przez osiem.
Model z ośmioma miliardami parametrów przy dokładności szesnastu bitów wymaga około szesnastu gigabajtów; przy dokładności czterech bitów ta wartość spada do około czterech gigabajtów. Model z siedemdziesięcioma miliardami parametrów potrzebuje około stu czterdziestu gigabajtów przy dokładności szesnastu bitów, a około trzydziestu pięciu gigabajtów przy dokładności czterech bitów.
Zazwyczaj w tym momencie ludzie przestają myśleć o wymaganiach sprzętowych, a to też jest obliczenie, które najczęściej udaje im się poprawnie wykonać.
Prawdziwe błędy pojawiają się później w procesie.
Kasza KV – struktura, która przechowuje stan uwagi w trakcie rozmowy – powiększa się w miarę wydłużania się okien kontekstowych, a także skaluje w zależności od liczby jednoczesnych żądań, którymi się zajmujemy.
Architektury typu Mixture-of-experts wprowadzają dodatkową złożoność: ponieważ każdy token aktywuje tylko podzbiór sieci, rzeczywisty koszt obliczeniowy na token pozostaje niski, ale każdy ekspert, niezależnie od tego, czy jest aktywny, czy nie, musi nadal znajdować się gdzieś w pamięci.
Wiedza o liczbie aktywowanych parametrów informuje nas o koszcie przetwarzania na token. Nie mówi nam jednak nic o ilości pamięci zajmowanej przez model.
Przenoszenie części modelu w inne miejsce nie eliminuje problemu przechowywania, jedynie go przesuwa – a teraz musimy ponosić koszt transferu danych, który wcześniej nie istniał.
Model, który z powodzeniem załaduje się do pamięci, nie dowodzi jeszcze, że faktycznie może obsługiwać ruch użytkowników.
Szybkość przetwarzania promptu, szybkość generowania oraz całkowity czas ukończenia zadania to trzy odrębne wskaźniki, a szybkie przyjmowanie promptu nic nie mówi o tym, jak szybko zostanie wygenerowana długa odpowiedź.
Rzeczywiście istotny jest ten obciążenie, które wymaga dużo zasobów – duże dokumenty, wielu jednoczesnych użytkowników, wywołania narzędzi, które powtarzają się w kółko.
Testowanie z jednym krótkim promptem ukrywa właśnie te opóźnienia w kolejce i konflikty pamięci, które sprawiają problemy przy lokalnej inferencji, gdy korzysta z niej kilka osób.
To, co łączy te błędy, to pewien wzorzec: każdy z nich bierze liczbę łatwą do podania i myli ją z rzeczywistym czynnikiem ograniczającym.
Przeprowadź własne testy na sprzęcie, który już posiadasz, albo wynajmij czas na dokładnej konfiguracji, którą oceniasz, zanim podejmiesz decyzję.
Kupowanie mocy obliczeniowej, zanim określisz, gdzie znajduje się prawdziwy wąskie gardło, to dobry sposób na zapewnienie, że to wąskie gardło będzie nadal istnieć.
Zapytanie nie jest zezwoleniem
Najważniejsze nieporozumienie w projektowaniu agentów prawie w ogóle nie ma związku z tym, jaki model jest używany.
Gdy model generuje żądanie wywołania narzędzia, jest to jedynie prośba, nic więcej.
Jakiś oddzielny mechanizm musi zdecydować, czy to żądanie zostanie faktycznie wykonane.
Zaskakująco łatwo ostatecznie stworzyć system, w którym ten oddzielny mechanizm funkcjonalnie jest po prostu modelem, który ufa samemu sobie — wzmocnionym uprzejmą instrukcją zawartą gdzieś w zapytaniu, proszącą go o zachowanie się w określonych granicach.
To jest preferencja, a nie rzeczywista granica, a właśnie preferencje są wykorzystywane w atakach typu injection promptów.
Cokolwiek agent pobiera z zewnętrznych źródeł, uważa się za niezaufany dane wejściowe.
Plik README może zawierać instrukcje skierowane do twojego agenta. To samo dotyczy komentarza ukrytego w kodzie źródłowym, treści wpisu w narzędziu do śledzenia problemów lub zwykłej strony internetowej.
Rozwiązaniem nie jest lepsza instrukcja, lecz bardziej rygorystyczny model uprawnień: ograniczenie dostępu do zatwierdzonej listy ścieżek zamiast do całego systemu plików, ustalenie maksymalnej wielkości plików, kontrola tego, co można zapisać, wykonywanie testów w tymczasowym środowisku, zabezpieczenie haseł używanych do deploju przed dostępem procesu roboczego oraz wymaganie przeglądu każdej poprawki przez człowieka przed jej wdrożeniem w produkcji.
Uruchamianie własnych lokalnych procesów analizy oraz ograniczanie uprawnień narzędzi to dwa różne problemy, i łatwo jest założyć, że rozwiązanie jednego automatycznie rozwiązuje drugi.
Samodzielne przechowywanie wag określa, gdzie fizycznie znajdują się twoje dane oraz czy twój system zależy od dostępności innej firmy. Nie ma to żadnego wpływu na to, jakie działania agent może faktycznie wykonać.
Zespoły, które łączą te dwa aspekty, ostatecznie mają model w pełni samodzielnie hostowany, który nadal może powodować nieograniczone szkody w ich własnym kodzie.
W skali całego zespołu ta sama logika wskazuje na konieczność umieszczenia uwierzytelnionego bramy przed punktem końcowym wykonywania zadań, ustanowienia budżetów zużycia na użytkownika oraz określenia wyraźnej polityki dla każdego procesu — uruchomienie go lokalnie, zezwolenie na używanie określonego modelu hostowanego lub przekierowanie go do człowieka w celu sprawdzenia.
Zapisuj punkty kontrolne przed ponowną próbą wykonania nieudanych kroków, a każdy narzędzie wywołujące efekty uboczne powinno być projektowane tak, by było idempotentne, dzięki czemu próba przywrócenia nie będzie mogła w tajemnicy powtórzyć już wykonanej czynności.
Dlaczego niezawodność działa na twoją niekorzyść
Załóżmy, że każdy krok w procesie pracy agenta ma niezależne 95 procent szans na powodzenie. Połączmy dziesięć takich kroków, a ogólny wskaźnik sukcesu wyniesie około sześćdziesięciu procent — 0,95 w dziesiątej potęgi daje mniej więcej 0,599.
Gdy kroków będzie dwadzieścia, wskaźnik spada do około trzydziestu sześciu procent.
Kroki w rzeczywistym świecie nie są naprawdę niezależne, więc traktujmy to raczej jako ilustrację niż dokładny wskaźnik. Mimo to pokazuje ono coś, czego żadna jakość modelu nie może odwrócić: niezawodność poszczególnych kroków się nie sumuje, lecz mnoży, przy czym rośnie wykładniczo wraz z długością łańcucha.
Gdy niezawodność poszczególnych kroków wzrośnie z 95% na 98%, sekwencja dziesięciu kroków przeskoczy z 60% sukcesów na 82%. Ale dodanie dziesięciu kolejnych kroków do procesu działającego z 95% niezawodności sprawi, że cały ten wzrost zostanie zniweczony.
To zmienia to, czego powinieneś faktycznie oczekiwać od małego modelu lokalnego. Jego prawdziwym zadaniem nie jest bycie genialnym — lecz byciem niezawodnym w procesie pracy, który jest krótki, ma ograniczony zakres, łatwy do sprawdzenia oraz w którym można szybko odzyskać funkcjonalność, jeśli coś się zepsuje.
A co najważniejsze, liczba kroków w tym procesie nie jest określana przez wagi modelu. To wybór projektowy, który dokonujesz podczas budowania aplikacji.
Skrócenie łańcucha operacji, sprawdzanie pośrednich wyników oraz włączenie punktów kontrolnych, które umożliwią kontynuację pracy zamiast rozpoczynania jej od nowa w przypadku awarii, zazwyczaj zapewnia większą niezawodność niż użycie modelu większego.
Dlatego też ocena nie może pozostać niejasna lub oparta wyłącznie na anegdotach.
Weź pięćdziesiąt zadań ze swojego rzeczywistego backlogu, przy czym każde z nich powinno mieć zapisany oczekiwany wynik w miejscu, do którego agent nie ma dostępu ani możliwości modyfikacji.
Nadzoruj poprawność – czy wywołania narzędzi były ważne, jaka była opóźniona reakcja, ile razy konieczne były próby ponowne oraz ile czasu poświęcił człowiek na naprawę problemów – wszystko to mierzone przy realistycznych rozmiarach danych i poziomach równoczesności, oceniane według ustalonych przez Ciebie progów, zanim dowiesz się, który model okazuje się lepszy.
Jedna kategoria wymaga osobnego pola w Twoich danych telemetrycznych: model niedostępny oraz model dający błędną odpowiedź to zasadniczo różne rodzaje awarii.
Pierwszy to problem z routowaniem i odzyskiwaniem, drugi zaś dotyczy jakości.
Gdy połączysz je w jeden wskaźnik szybkości działania, stracisz dokładnie te informacje, które wskazują, czy rzeczywistym rozwiązaniem jest większa przepustowość, lepszy model czy mniejsze, bardziej ograniczone zadanie.
To, co faktycznie kupujesz
Jedynym porównaniem, które warto przeprowadzić, jest koszt za zrealizowane zadanie.
Porównywanie cen tokenów polega na porównywaniu rzeczy, które nie są do siebie podobne; natomiast porównywanie zatwierdzonych zadań dotyczy rzeczy, które są do siebie podobne. W przypadku rozwiązania lokalnego twoimi kosztami są amortyzacja sprzętu, energia, konserwacja, czas bezczynności oraz wysiłek potrzebny do przeglądania. W przypadku rozwiązania hostowanego kosztami są tokeny, próby ponowne oraz wysiłek potrzebny do przeglądania.
Zrób to samo zestawienie zadań przy tym samym progu akceptacji po obu stronach – mniej niż to sprawi, że porównanie stanie się jedynie pozorem.
Rachunki wychodzą tak, jak można by się spodziewać.
Powiedzmy, że lokalna infrastruktura generuje dla ciebie sześćset dolarów miesięcznie w postaci kosztów stałych, przy czym każde zatwierdzone zadanie kosztuje lokalnie dwa centy, podczas gdy przez hostowaną API – dwadzieścia centów. Punkt równowagi przypada mniej więcej na 3 333 zatwierdzone zadania miesięcznie.
Te dane mają charakter ilustracyjny, a nie wynikają z pomiarów, ale podstawowy wzorzec pozostaje niezmienny: wykonywanie inferencji lokalnie to inwestycja o stałych kosztach, która przynosi zysk dopiero po osiągnięciu określonego progu ilościowego, a przy niższych obrotach powoduje straty.
Większość zespołów pozostaje poniżej tego progu.
Tutaj szczera ocena korzyści z lokalnej sztucznej inteligencji ostro odbiega od argumentów marketingowych.
Poniżej punktu równowagi lokalna inferencja nie jest tańszą opcją, a twierdzenie przeciwnego sprawia, że wybór staje się nieuzasadniony już przy pierwszej weryfikacji danych.
W rzeczywistości kupujesz raczej możliwość wyboru – gwarancję, że możesz kontynuować działalność nawet w przypadku zmian warunków dostępu, przy warunkach kontrolowanych przez ciebie.
Ceny opcji ustala się na podstawie zmienności, a nie oczekiwanych średnich wyników.
Jeśli ostatnie zakłócenia cokolwiek pokazały, to fakt, że ta zmienność jest rzeczywista, wynika z decyzji administracyjnych, a nie technicznych, i pojawia się bez uprzedzenia.
To uzasadniony powód, by wydać te pieniądze.
Jest to jednak inny powód niż ten, który zwykle się podaje, i zasługuje na obronę ze względu na same swoje zalety, a nie jako środek oszczędnościowy.
Test, który naprawdę coś mówi
Nic z tego nie zależy od przekonania, że prawa skalowania będą nadal obowiązywać, że jakaś okno dostępu rzeczywiście się zamyka, lub że AGI w końcu zmieści się w danej ilości pamięci VRAM, czy też nie.
To są prognozy, a ryzyko zależności nie wymaga, by okazały się prawdziwe.
Wystarczy uświadomić sobie, że system, od którego zależymy, może przestać funkcjonować z powodów, które nie mają nic wspólnego z jego wydajnością ani z naszym zachowaniem. Tak było w przypadku sieci energetycznych, kabli podmorskich i sieci płatniczych, a teraz jest to oczywiście prawdą również w odniesieniu do nowoczesnych modeli sztucznej inteligencji.
Praktyczne rozwiązanie nie jest ekscytujące. Polega głównie na nabywaniu umiejętności, które obecnie uważamy za oczywiste lub zakładamy, że ktoś inny już się nimi zajął.
Spróbuj tego: odbuduj cały swój stack całkowicie na podstawie notatek i kopii zapasowych, które przechowujesz, a następnie przekaż te same notatki innemu inżynierowi i obserwuj, jak on samodzielnie próbuje dokonać tej samej odbudowy. Ten jeden ćwiczenie nauczy cię więcej o tym, jak naprawdę jesteś samodzielny, niż wiele płynnych rozmów z modelem, który akurat jest dostępny dzisiaj. Dostępność modelu w tym momencie nic nie dowodzi co do jutra, a jedynym prawdziwym dowodem odporności jest to, czy twoja konfiguracja funkcjonuje bez niego.
Literatura pokrewna
- ReAct Explained: Jak agenci AI łączą rozumowanie z działaniami w rzeczywistym świecie — Dowiedz się, jak framework ReAct łączy rozumowanie i używanie narzędzi w celu napędzania agentów AI oraz w jaki sposób różni się od modeli typu Chain-of-Thought, RL i modeli opartych na rozumowaniu.