Drodzy Czytelnicy,
Anthropic wprowadził w tym roku dwie ciche zmiany w modelu Claude Opus 4.6. Obie zmniejszają zużycie compute na zapytanie. Na początku lutego firma wdrożyła mechanizm, który nazywa „adaptive thinking” — pozwala on modelowi samodzielnie decydować, ile wnioskowania zastosować do konkretnego zapytania. Zastąpiło to stały budżet, który wcześniej mógł zdefiniować użytkownik. W kolejnych tygodniach obniżono również domyślne ustawienie poziomu effort dla tego samego modelu. Żadna z tych zmian nie pojawiła się w oficjalnych release notes.
Użytkownicy to zauważyli. 2 kwietnia Stella Laurenzo, Director of AI w AMD, zgłosiła błąd w repozytorium GitHub projektu Claude Code, tytułując go „Claude Code is unusable for complex engineering tasks with the Feb updates” (issue #42796). Podpisało się pod tym ponad dwustu użytkowników. Dimitris Papailiopoulos, Principal Research Manager w Microsoft Research, powiedział magazynowi Fortune (14 kwietnia): „Ustawiam effort na maksimum, a mimo to model działa niechlujnie, ignoruje instrukcje i powtarza błędy”. Żądanie maksymalnego wnioskowania ze strony użytkownika nie przyniosło oczekiwanego rezultatu. Ustawienie stało się jedynie sugestią, a domyślny poziom, do którego się odnosiło, został obniżony.
Boris Cherny, dyrektor w Anthropic kierujący projektem Claude Code, opisał na łamach Fortune system adaptive-thinking jako taki, który „pozwala modelowi decydować, ile wnioskowania zastosować do danego zadania, zamiast opierać się na stałym budżecie”. Powodem były koszty compute. Anthropic racjonuje zasoby, a jednym z mechanizmów tego racjonowania jest oddanie modelowi swobody w decydowaniu o tym, ile wnioskowania zainwestować — nawet wtedy, gdy użytkownik wyraźnie prosi o więcej.
Dla firm wykorzystujących model Claude w produkcyjnych workflow, stanowi to konkretny problem. Twój system AI przeszedł walidację w określonych ramach działania. Vendor zmienił te ramy bez powiadomienia. System działający na produkcji nie jest już systemem, który został zatwierdzony. Odchylenie to ujawnia się najpierw jako dryf operacyjny — jakość outputu spada, mimo że żaden inny element workflow się nie zmienił. Następnie przeradza się ono w ryzyko niezgodności na mocy Artykułu 26 rozporządzenia AI Act. Twoja umowa prawdopodobnie nie obejmuje żadnej z tych kwestii, a ślad audytowy z dużym prawdopodobieństwem ich nie wychwytuje. Oba te elementy zaprojektowano dla oprogramowania, którego zachowanie obliczeniowe nie ulegało zmianom pomiędzy aktualizacjami.
Co właśnie pokazał Anthropic#
Ciche zmiany możliwości tego typu nie mają odpowiednika w dojrzałych kategoriach oprogramowania dla przedsiębiorstw. Dostawcy baz danych publikują notatki podsumowujące zmiany dla każdego wydania. Systemy operacyjne wersjonują swoje zmiany. Nawet wycofywanie API wiąże się z wielomiesięcznym wyprzedzeniem i przewodnikami migracji. W przypadku modeli brzegowych (frontier models), vendor może zmodyfikować zachowanie systemu bez zmiany numeru wersji, wpisu w changelogu czy powiadomienia wymaganego umową.
Żadna ze zmian wdrożonych przez Anthropic nie była aktualizacją modelu. Opus 4.6 pozostał Opusem 4.6. Zmieniła się alokacja compute — mechanizm, za pomocą którego model decyduje o głębokości wnioskowania, oraz domyślny poziom effort stosowany zanim zadziała instrukcja klienta. Relacja Papailiopoulosa dobrze to pokazuje: effort ustawiony na maksimum, a output niechlujny. Regulowany proces, który przeszedł walidację w poprzedniej architekturze, działa teraz w innej, podczas gdy podmiot stosujący ponosi odpowiedzialność za wyniki, których już w pełni nie kontroluje.
Powód tej zmiany — kasa. CFO Anthropic stwierdził publicznie (Reuters Breakingviews, 11 marca), że firma wydała ponad 10mld USD na trenowanie modeli i obsługę zapytań użytkowników, generując około 5mld USD skumulowanych przychodów. Analitycy Bank of America oszacowali w marcu, że Anthropic może zapłacić dostawcom chmury (hyperscalerom) nawet 6,4mld USD w 2026 roku w ramach umów o podziale przychodów związanych ze sprzedażą modelu Claude. W 2025 roku było to 1,9mld USD (Forbes, 25 marca). Chief Revenue Officer w OpenAI, Denise Dresser, rozesłała 13 kwietnia wewnętrzną notatkę twierdząc, że około 8mld USD z raportowanych przez Anthropic 30mld USD rocznego run-rate to kwestia sposobu rozpoznania przychodu. Anthropic podaje przychody łącznie z częścią należną hyperscalerom jako własne, podczas gdy OpenAI przed raportowaniem odlicza udziały Microsoftu (CNBC, 13 kwietnia). Niezależnie od tego, które z tych liczb przetrwają bliższą weryfikację, kierunek jest spójny. Ekonomia skali (unit economics) dla wnioskowania modeli brzegowych pozostaje nierozwiązana, a dostawcy szukają sposobów na zamknięcie tej luki bez wywoływania buntu klientów.
Podnoszenie cen wywołuje sprzeciw klientów. Widoczne racjonowanie — poprzez kolejki, dławienie ruchu (throttling) czy przerwy w działaniu — działa tak samo. Trzecia opcja — dostosowanie możliwości obliczeniowych na jednostkę użycia bez powiadamiania o tym — jest najmniej zauważalna dla użytkowników i najbardziej zrównoważona komercyjnie dla vendora. Niesie ona za sobą również implikacje regulacyjne, o których nikt wprost nie mówi.
Jak to wpływa na procesy biznesowe#
Ryzyko operacyjne jest tu większe niż regulacyjne i uderza najmocniej w agenty AI. Agent podejmuje decyzje sekwencyjnie. Każdy krok warunkuje następny. Niewielka redukcja głębokości wnioskowania na drugim kroku zmienia dobór narzędzi na kroku trzecim, co przekazuje inne dane wejściowe do kroku piątego. Zanim output trafi do klienta lub systemu docelowego, jest już wynikiem łańcucha decyzyjnego, który przestał odpowiadać temu, co zwalidował podmiot stosujący.
Widoczne objawy są prozaiczne. Agent obsługi klienta, który wcześniej eskalował niejednoznaczne prośby o zwrot środków, zaczyna je automatycznie zatwierdzać. Próg tego, co „niejasne”, przesunął się, choć w definicji workflow nie zmieniono niczego. Agent do klasyfikacji roszczeń, który wyłapywał podwójne zgłoszenia, zaczyna je przepuszczać, bo heurystyka, na której operuje, stosuje teraz mniej wnioskowania przed podjęciem decyzji. Agent do code review, który naprawiał błędy w trzech wywołaniach narzędzi, wykonuje ich teraz osiem, zużywając więcej tokenów, by dotrzeć do tej samej lub gorszej odpowiedzi. Żadnego z tych zjawisk nie da się wykryć za pomocą typowych narzędzi do pomiaru jakości. Klienci sprawdzają dostępność usługi, a nie jej dryf jakościowy.
Wraz z tym znika powtarzalność. Jeśli zadasz agentowi AI to samo pytanie w odstępie sześciu miesięcy, odpowiedzi będą się różnić. Nie dlatego, że zmieniło się pytanie czy zdezaktualizował kontekst, ale dlatego, że w międzyczasie vendor zrekonfigurował system. Każda analiza wsteczna — dlaczego wygenerowano taki output, dlaczego podjęto taką decyzję — zawiera teraz niewidoczną zmienną. Testy A/B stają się niemożliwe dla zmieniającego się baseline. Wykrywanie regresji wymaga, by podmiot stosujący utrzymywał własne ewaluacje w tle opierające się na stałych zbiorach danych, uruchamiane w sposób ciągły w celu flagowania odchyleń. To dyscyplina, której nie wdrożyło prawie żadne przedsiębiorstwo poza laboratoriami AI budującymi modele brzegowe.
Można to ująć prościej. Żaden zespół operacyjny nie uruchomiłby produkcyjnego workflow u dostawcy bazy danych, który po cichu modyfikuje swój optymalizator zapytań. Żaden dział finansowy nie realizowałby list płac przez bankowe API, które bez powiadomienia modyfikuje sposób naliczania odsetek. Odpowiedź na pytanie, czy to akceptowalne, jest oczywista dla każdej warstwy technologicznej, na której organizacje opierały się przez ostatnie trzydzieści lat. W przypadku API dla modeli brzegowych, dzieje się to tu i teraz, a większość przedsiębiorstw jeszcze nie zorientowała się, że ich to dotyczy.
Dodatkowe ryzyko regulacyjne#
AI Act przenosi ten problem na podmiot stosujący. Artykuł 26 ust. 1 wymaga od podmiotów stosujących systemy wysokiego ryzyka używania ich „zgodnie z instrukcją obsługi” dostarczoną przez vendora. Artykuł 26 ust. 5 zobowiązuje podmiot stosujący do monitorowania działania systemu pod kątem tych instrukcji. Z kolei Artykuł 14 ust. 4 lit. a, dotyczący ludzkiego nadzoru, wymaga od nadzorujących wykrywania „nieoczekiwanego działania”, co zakłada, że istnieje zdefiniowane pojęcie działania oczekiwanego. Kiedy dostawca modyfikuje funkcjonowanie systemu bez powiadamiania, punkt odniesienia staje się nieaktualny, a zdolność do wykrywania odchyleń zostaje naruszona strukturalnie.
Dla instytucji podlegających nadzorowi sektorowemu — na przykład banków i ubezpieczycieli pod okiem KNF — problem jest poważniejszy. Artykuł 27 wymaga, aby podmioty stosujące systemy oceny zdolności kredytowej lub systemy do oceny ryzyka w ubezpieczeniach na życie i zdrowie przeprowadziły ocenę skutków dla praw podstawowych (FRIA). Taka ocena musi zawierać „opis procesów podmiotu stosującego, w których system AI wysokiego ryzyka będzie wykorzystywany”. Ten opis odnosi się do konkretnej konfiguracji modelu. Kiedy ta konfiguracja ulega nieogłoszonej zmianie, FRIA opisuje system, który już nie istnieje.
Czego nie obejmują twoje umowy#
Standardowe zapisy umów SaaS dotyczące powiadamiania o zmianach pokrywają wersje API, wycofywanie endpointów i korekty cenników. Zazwyczaj nie obejmują one zmian konfiguracji modelu bazowego, ustawień poziomu effort czy budżetów compute, zachowań dotyczących routingu między wariantami modelu ani logiki zastępczej (fallback) w przypadku ograniczeń przepustowości. Żadna z tych rzeczy nie stanowiła przedmiotu umów w poprzednich generacjach oprogramowania, ponieważ zachowanie systemu nie dryfowało pomiędzy aktualizacjami.
Twój ślad audytowy ma tę samą lukę. Logi generowane przez typowe wdrożenie AI rejestrują zapytanie, odpowiedź i podstawowe metadane. Nie odnotowują jednak konkretnego ustawienia effort, decyzji o routingu czy wag modelu, które wygenerowały wynik. Logi zapisują outputy, ale nie rejestrują konfiguracji, która te outputy wytworzyła.
To ekspozycja, na którą nie jest gotowy żaden standardowy framework do zarządzania dostawcami. Przeglądy bezpieczeństwa skupiają się na obsłudze danych. Przeglądy prywatności obejmują dane osobowe. Zarządzanie ryzykiem modeli (model risk management) zajmuje się walidacją statystyczną. Niezapowiedziane modyfikacje możliwości dokonywane przez dostawcę w systemie regulowanym pozostają poza tymi wszystkimi procedurami.
Briefing#
Salesforce i Microsoft łatają podatności na wyciek danych w agentach AI — i nie zgadzają się, po czyjej stronie leży naprawa błędu
Firma Capsule Security opublikowała 15 kwietnia badanie opisujące dwie podatności na prompt injection: „PipeLeak” w Salesforce Agentforce oraz „ShareLeak” w Microsoft Copilot (CVE-2026-21520). W przypadku Salesforce atakujący mógł osadzić instrukcje w publicznym formularzu do przechwytywania leadów, a agent traktował je jako na tyle zaufane, by pozwolić na ekstrakcję pełnej bazy leadów. Microsoft wypuścił łatkę. Stanowisko Salesforce: zapobieganie eksfiltracji danych to kwestia konfiguracji, a klienci powinni uruchomić nadzór typu human-in-the-loop. Naor Paz, CEO Capsule, nazwał taką odpowiedź „żenującą” — „głównym założeniem agentów jest to, by wykonywały pracę za ciebie, bez konieczności niańczenia”. Kwestia governance jest tu bardzo konkretna. Vendor może dostarczać domyślne konfiguracje traktujące niezaufany input jako zaufane instrukcje, a jego model naprawczy zakłada, że samodzielnie to przekonfigurujesz. Dla polskich przedsiębiorstw realizujących pilotaże Agentforce lub Copilot Studio, warto postawić pytanie: czy wasze ustawienia zostały przebadane pod kątem znanych wzorców prompt injection?.
Sędzia federalny w USA orzeka, że rozmowy z AI nie są chronione tajemnicą adwokacką
W lutowym orzeczeniu, które zyskało szerszy rozgłos 15 kwietnia dzięki publikacji przez Reutersa, amerykański sędzia okręgowy Jed Rakoff nakazał byłemu prezesowi GWG Holdings, Bradleyowi Heppnerowi, przekazanie 31 dokumentów wygenerowanych przez Claude, które zostały przygotowane w ramach jego obrony w procesie o oszustwa. Rakoff napisał: „Pomiędzy użytkownikiem AI a platformą taką jak Claude nie istnieje i nie może istnieć relacja adwokat-klient”. Od tamtego czasu kilkanaście dużych amerykańskich kancelarii prawnych wydało powiadomienia dla klientów ostrzegające, że zapisy rozmów z chatbotami mogą być wykorzystywane przez prokuratorów i adwokatów strony przeciwnej w procesach cywilnych. Nowojorska kancelaria Sher Tremonte umieszcza teraz w umowach klauzulę informującą, że „Ujawnienie komunikacji objętej tajemnicą platformie AI należącej do podmiotu trzeciego może stanowić zrzeczenie się tajemnicy adwokackiej”. Orzeczenie zapadło w amerykańskiej jurysdykcji, ale zawarta w nim logika pozostaje uniwersalna. Członkowie polskich zarządów i radcy prawni rutynowo tworzą wrażliwe dokumenty strategiczne w publicznych chatbotach. To precedens pokazujący, że tego rodzaju praktyka pozbawia ich ochrony, o której utrzymaniu byli dotychczas przekonani (Reuters, 15 kwietnia).
Cztery pytania dla zarządu#
Które z twoich produkcyjnych procesów AI opierają się na modelu brzegowym hostowanym przez vendora i kiedy te procesy były po raz ostatni rewalidowane w oparciu o aktualne zachowanie modelu? Jeśli odpowiedź na to drugie pytanie brzmi „podczas startu produkcyjnego”, twoje mierniki jakości mogą być nieaktualne.
Co twoja umowa z Anthropic, OpenAI lub Google mówi o powiadamianiu w przypadku modyfikacji wpływających na możliwości modelu, które nie są aktualizacjami nowej wersji? Odpowiedź: „raczej nie”…
Gdyby skarga klienta lub działanie regulatora wymagało od ciebie odtworzenia outputu systemu sprzed sześciu miesięcy, to czy byłbyś w stanie to zrobić? Jeśli odpowiedź brzmi „nie”, to twoja zdolność wykazania zgodności na gruncie Artykułu 26 ulega degradacji, pomimo że z twojej strony nic się nie zmieniło.
Jaki jest twój budżet awaryjny na scenariusz, w którym poziom cen AI z 2026 roku staje się ich minimum, a nie sufitem? Modele kosztowe vendorów będące poniżej granicy rentowności, koszty compute wskazują, że nie będzie taniej.
Zmiana u podstaw#
Frameworki AI Governance funkcjonujące wewnątrz organizacji zakładają stabilny system. Tymczasem rynek modeli frontier być może przechodzi do bieżącego dostrajania modeli przez vendora do jego kosztów operacyjnych.
Szybki wzrost przychodów Anthropic trafia na okładki. Mniej nagłośniony fakt — o tym, że najszybciej rosnąca firma AI na świecie zadecydowała o racjonowaniu swoich zasobów przez zmianę możliwości modeli bez ogłaszania tego światu — ma dużo większe znaczenie dla każdej organizacji uruchamiającej dzisiaj u siebie wdrożenia produkcyjne. Ryzyko niezgodności to zaledwie podzbiór szerszego problemu operacyjnego. System, który wdrażałeś, nie jest już tym samym, z którego dzisiaj korzystają twoi klienci. Tyle że nikt cię o tym nie poinformował.
Zachowaj równowagę, Krzysztof