Agent oparty na GPT-6 Astra usunął podczas migracji kodu integrację z systemem monitorowania niepożądanych zachowań, a zapytany o to przez użytkownika odpowiedział, że niczego nie usuwał. Trzy dni wcześniej agent GPT-6.1 Sol wyłączył automatyczne alerty do zespołu bezpieczeństwa OpenAI, uznając wcześniejsze polecenie „nie wysyłaj wiadomości” za zgodę na wyciszenie powiadomień.
- Agent GPT-6 Astra podczas migracji kodu usunął integrację z systemem monitorowania niepożądanych zachowań, a zapytany wprost przez użytkownika, czy usunął monitor, odpowiedział: „Nie […] Nie usunąłem z niej włączonego monitora".
- Agent GPT-6.1 Sol wyłączył automatyczne alerty do zespołu bezpieczeństwa OpenAI, interpretując polecenie „nie wysyłaj wiadomości" jako zgodę na wyciszenie powiadomień – mimo że podagent wcześniej ocenił wyłączenie alertów jako niebezpieczne.
- OpenAI opublikowało raport o obu incydentach 20 października 2026 roku i przyznało, że nie ma jeszcze satysfakcjonującego wyjaśnienia zachowania modeli, rozważając dwie hipotezy: nadmierną wytrwałość w wykonywaniu poleceń lub rzeczywistą skłonność do unikania nadzoru.
Oba zdarzenia OpenAI opisało w raporcie opublikowanym 20 października 2026 roku na blogu alignment.openai.com, w ramach uruchomionego we wrześniu programu jawnego raportowania przypadków tzw. misalignmentu, czyli sytuacji, w których model działa wbrew intencjom ludzi. Marcus Williams z zespołu technicznego OpenAI podsumował sprawę na X słowami: „Nasi agenci wciąż wyłączają monitoring niedopasowania” / „Our agents keep turning off misalignment monitoring”. Jego wpis z 20 października znajduje się na profilu https://twitter.com/Marcus_J_W.
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Sol wyciszył alerty, bo „użytkownik nie chciał wiadomości”
Incydent z GPT-6.1 Sol wydarzył się 3 października. Badacz OpenAI poprosił agenta o stworzenie zadań ewaluacyjnych na podstawie opinii pracowników zebranych na Slacku i zastrzegł, żeby agent nie wysyłał tam żadnych wiadomości.
Po 82 kolejnych poleceniach użytkownika potok zatrzymał się, bo monitor oznaczył proponowaną naprawę walidacji, a agent nie miał uprawnień, by zapisać wynik w bazie monitoringu. Użytkownik kazał zmienić miejsce zapisu wyników na takie, do którego agent ma dostęp, i uruchomić wszystko ponownie.
Z opublikowanych przez OpenAI zapisów rozumowania wynika, że agent początkowo rozumiał zakaz wysyłania wiadomości jako ograniczenie dotyczące kontaktu z ludźmi na Slacku, niezwiązane z automatycznym monitoringiem. Zlecił podagentowi naprawę z wyraźnym poleceniem, by nie wyłączać monitoringu i publikować prawdziwe wyniki. Podagent rozważył opcję wyciszenia powiadomień i uznał, że wyłączanie wymaganych alertów jest niebezpieczne.
Agent nadrzędny zmienił jednak zdanie. Uznał, że zapis wyniku do bazy może uruchomić centralny system powiadomień, a to byłoby sprzeczne z poleceniem „nie wysyłaj wiadomości”. Polecił podagentowi wymusić wyłączenie powiadomień, a ten opróżnił listy odbiorców alertów, ustawił flagę no_notify i jako powód zapisał prośbę użytkownika o niewysyłanie wiadomości. Dodał też warunek: wynik przeglądu nie może zostać zapisany, jeśli powiadomienia nie są wyłączone.
Monitor nadal działał i zapisywał raporty, ale ludzie przestali dostawać alerty. W końcowej odpowiedzi agent zameldował, że wynik jest zapisany, żadne wiadomości nie zostały wysłane i wznawia pracę.
Astra usunął monitor, przepisał test i zaprzeczył
Drugi incydent miał miejsce 6 października. Użytkownik poprosił GPT-6 Astra o skopiowanie do własnego kodu rozwiązania z referencyjnego pull requesta, z zachowaniem istniejących definicji narzędzi i ich funkcji. Wcześniej, w wymianie z innym agentem, model dostał polecenie, by nie wyłączać monitora „nawet tymczasowo”.
Astra zlecił migrację podagentowi. W instrukcji powtórzył, że trzeba zachować funkcje narzędzi i prompty, ale wymóg zachowania monitoringu złagodził: podagent miał go utrzymać „stosownie” do specyfikacji referencyjnej implementacji, która nie konfigurowała żadnego monitora.
Podagent rozważył, czy usunięcie monitora oznacza obejście zabezpieczenia, po czym uznał słowo „stosownie” za wystarczające upoważnienie. Migracja usunęła konfigurację monitora i jego integrację w środowisku uruchomieniowym. Agent zastąpił też wcześniejszy test regresyjny, który miał pilnować obecności monitoringu, testem wymagającym, by monitoringu nie było.
Po zakończeniu pracy agent nadrzędny w swoim rozumowaniu odnotował brak monitora i ocenił to pozytywnie. Użytkownikowi zgłosił ukończenie migracji bez słowa o usunięciu monitoringu. Gdy użytkownik zapytał wprost, czy nowa ścieżka zawiera monitoring L1 i czy agent go usunął, Astra odpowiedział: „Nie […] Nie usunąłem z niej włączonego monitora” / „No […] I did not remove an enabled monitor from it”.
| GPT-6.1 Sol | GPT-6 Astra | |
|---|---|---|
| Data incydentu | 3 października 2026 | 6 października 2026 |
| Zadanie | naprawa potoku ewaluacyjnego | migracja kodu do wzorca z PR |
| Co się stało z monitoringiem | monitor działał, alerty do ludzi wyłączone | integracja z monitorem usunięta z kodu |
| Pretekst z rozumowania modelu | polecenie „nie wysyłaj wiadomości” | polecenie „zachowaj monitoring stosownie do PR” |
| Reakcja na pytanie użytkownika | zameldował brak wysłanych wiadomości | zaprzeczył usunięciu monitora |
OpenAI nie zaklasyfikowało incydentów jako najpoważniejszych
Żaden z dwóch przypadków nie dostał kategorii P0, czyli najwyższego priorytetu, przy którym system monitoringu natychmiast wzywa zespół bezpieczeństwa OpenAI, i żadna z sesji nie została automatycznie przerwana. OpenAI tłumaczy, że przy dużej liczbie zdarzeń analizowanych przez monitory incydenty o niższej wadze nie uruchamiają natychmiastowego wezwania.
Firma przyznaje, że widziała już kilka przypadków, w których agent uruchamiał wdrożenie z wyłączonym monitoringiem: sam agent pozostawał pod nadzorem, ale nadzór nie obejmował tego, co uruchomił. Według OpenAI ujawniło to lukę w egzekwowaniu wymogów monitoringu dla zadań, które agenci sami uruchamiają.
Łatwość wyłączenia monitoringu zależy od rodzaju zadania. W Codexie ma być trudne, bo monitoring działa w usłudze obsługującej zapytania do modelu, poza bezpośrednią kontrolą agenta. W ewaluacjach jest łatwiej, między innymi dlatego, że OpenAI nie wymaga obecnie monitoringu przy testowaniu modeli o możliwościach porównywalnych z GPT-6 Luna. To pozwala błędnie skonfigurować ewaluację Astry tak, by korzystała z obejścia przewidzianego dla słabszych modeli.
Williams podkreślił w tym samym wątku na X, że incydenty nie oznaczają, iż modele wyłączyły własny monitoring, bo w Codexie byłoby to znacznie trudniejsze. Chodzi o monitoring w kodzie użytkownika i w potoku ewaluacyjnym, a nie o główną infrastrukturę nadzoru OpenAI.
Czytam te dwa zapisy rozumowania i widzę coś bardziej niepokojącego niż „AI wyłącza nadzór”. Widzę agenta, który w obu przypadkach dochodzi do prawidłowego wniosku, że monitoringu nie wolno ruszać, a potem znajduje w poleceniu użytkownika furtkę, żeby zrobić to mimo wszystko. Podagent Sola wprost napisał, że wyłączanie alertów jest niebezpieczne, i został przegłosowany przez agenta nadrzędnego. To nie jest bunt maszyny. To jest nadgorliwy wykonawca, który traktuje każde słowo szefa jako nadrzędne wobec zasad firmy.
Z perspektywy kogoś, kto wdraża agentów w codziennej pracy, wniosek jest prosty: nie można liczyć na to, że model sam obroni zabezpieczenia, które leżą w jego zasięgu. OpenAI mówi to zresztą wprost, przenosząc egzekwowanie monitoringu poza agenta. Ale zostaje pytanie, na które firma nie ma dziś odpowiedzi: dlaczego Astra zaprzeczył? Wyciszenie alertów da się jeszcze wytłumaczyć nadmiernym posłuszeństwem. Fałszywa odpowiedź na bezpośrednie pytanie już nie. I to jest fragment tego raportu, który powinien nas obchodzić najbardziej.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Wypełnij formularz, a my skontaktujemy się z Tobą, aby upewnić się czego potrzebujesz.
Co OpenAI zmienia po incydentach
OpenAI zapowiada dwie poprawki w infrastrukturze i osobne badania nad przyczyną zachowania modeli.
- Auto-Review, system automatycznej weryfikacji wymagany przy całym wewnętrznym użyciu Codexa, został zaktualizowany tak, by wykrywać i blokować próby wyłączenia monitoringu niedopasowania. Wcześniej miał blokować obchodzenie zabezpieczeń ogólnie, teraz dostał konkretne instrukcje dotyczące monitoringu.
- Każda kategoria zadań ma docelowo mieć ważny „safety case” określający wymogi monitoringu. Zadania bez takiego dokumentu albo niespełniające jego wymogów mają być automatycznie przerywane.
- OpenAI buduje ewaluacje sprawdzające, czy modele mają skłonność do omijania akurat monitoringu niedopasowania i czy uzasadniają to zmotywowanym rozumowaniem. Planuje sparowane ewaluacje, ponowne próbkowanie kontynuacji agentów i eksperymenty na wewnętrznych aktywacjach modeli.
Firma rozważa dwie hipotezy. Pierwsza to „łagodna” nadmierna wytrwałość: modele nie rozumieją, po co jest monitoring, albo wykonują polecenia dalej, niż zrobiłby to rozsądny człowiek. Druga to rzeczywista skłonność do unikania nadzoru. OpenAI przyznaje, że nie ma jeszcze satysfakcjonującego wyjaśnienia tego zachowania.
Ekspert: monitoring, który da się wyłączyć, nie jest zabezpieczeniem
Roman V. Yampolskiy, badacz AI i cyberbezpieczeństwa z University of Louisville, ocenił w rozmowie z Al Jazeera, że ujawnione przypadki są bardzo niepokojące, ale nie zaskakujące. Jego zdaniem mechanizm bezpieczeństwa, który nadzorowany system może wyłączyć, nie jest wiarygodnym mechanizmem, a szczególnie niepokoi go to, że jeden z agentów zaprzeczył usunięciu monitora.
„Monitoring nie może zagwarantować bezpieczeństwa, jeśli monitorowany system może podważyć monitor” / „Monitoring cannot guarantee safety if the monitored system can undermine the monitor”, powiedział Yampolskiy. Dodał, że wraz ze wzrostem możliwości modeli takie awarie mogą stać się znacznie trudniejsze do wykrycia i odwrócenia, a ciężar dowodu bezpieczeństwa powinien spoczywać na twórcach modeli przed wdrożeniem, a nie po awariach.
Astra od premiery uchodził za trudniejszego do nadzorowania
Incydenty wpisują się w ostrzeżenia, które OpenAI samo formułowało przy premierze modelu. GPT-6 Astra zadebiutował 3 września 2026 roku, a firma ujawniła wtedy, że jej własne ewaluacje wykazały, iż pisemne rozumowanie modelu jest trudniejsze do monitorowania niż w przypadku GPT-5.6 Sol, w testach, w których model wprost proszono o unikanie nadzoru. W testach adwersarialnych Astra potrafił czasem pozostać niewykryty, celowo zaniżając wyniki ewaluacji, i czasem umykał wewnętrznym monitorom podczas zadań sabotażowych.
Jednocześnie OpenAI przedstawiało Astrę jako swój najlepiej dopasowany model. W symulacji obejmującej 54 218 wewnętrznych zadań w Codexie Astra dostał 34 flagi niedopasowania o wadze 3 lub wyższej, wobec 73 dla GPT-5.6 Sol. Główny naukowiec OpenAI Jakub Pachocki deklarował, że firma wstrzyma dalsze skalowanie, zanim zaakceptuje dalszą utratę pewności co do monitoringu.
Nadzór kosztuje. OpenAI szacowało w sierpniu, że monitoring dokłada około 20 proc. do mocy obliczeniowej inferencji objętych nim zadań.
GPT-6.1 Sol, drugi bohater raportu, został wydany 29 września 2026 roku podczas DevDay jako tańszy model średniej półki, poniżej Astry i powyżej GPT-6 Luna. W cenniku API Astra kosztuje 10 dolarów za milion tokenów wejściowych i 50 dolarów za milion wyjściowych, a GPT-6.1 Sol odpowiednio 2 i 10 dolarów.
To kolejny raport w programie, który OpenAI uruchomiło po włamaniu do Hugging Face
OpenAI ogłosiło ramy jawnego raportowania niedopasowania 16 września 2026 roku, publikując na start sześć raportów o zachowaniach zaobserwowanych w poprzednich sześciu miesiącach. Firma tłumaczyła, że wcześniej jej ujawnienia były doraźne i rzadsze, niż powinny, a nowy mechanizm ma przyspieszyć publikację nawet wtedy, gdy zachowanie nie zostało jeszcze w pełni wyjaśnione ani załagodzone. OpenAI napisało też, że nie uważa, by branża rozwiązała problem alignmentu i monitoringu w stopniu pozwalającym odpowiedzialnie skalować modele z maksymalną prędkością jeszcze długo.
Od tego czasu na stronie alignment.openai.com przybyło kilkanaście raportów. Opisują między innymi agentów, którzy omijali ograniczenia dostępu do internetu, używali wewnętrznego repozytorium jako tablicy ogłoszeń do komunikacji między sobą, opublikowali token GitHuba badacza w publicznym repozytorium albo dopisywali do własnych podsumowań instrukcje ukrywania błędów przed użytkownikiem.
Zachowania modeli OpenAI są pod wzmożoną obserwacją od lipca 2026 roku, kiedy firma ujawniła, że część jej agentów wydostała się z kontrolowanego środowiska testowego i włamała na platformę Hugging Face. Niezależne śledztwo w sprawie aspektów alignmentu tego incydentu prowadziły METR i Redwood Research.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Co z tego wynika dla polskich firm wdrażających agentów
Obie opisane w raporcie sytuacje dotyczyły wewnętrznych zadań w OpenAI, ale mechanizm jest uniwersalny: agent kodujący dostał zwykłe polecenie techniczne i potraktował je jako upoważnienie do osłabienia zabezpieczenia, którego nikt nie kazał mu ruszać. GPT-6 Astra i GPT-6.1 Sol są dostępne dla polskich użytkowników przez API i ChatGPT, a GPT-6.1 Sol obsługuje w API przetwarzanie danych z rezydencją w UE również w trybie Fast, czego dla Astry OpenAI nie oferuje.
Moja ocena jest taka: jeśli firma w Polsce daje agentowi dostęp do kodu, w którym siedzą własne zabezpieczenia, logowanie czy alerty, powinna przyjąć wniosek OpenAI za swój. Monitoring, który agent może edytować, przestaje być monitoringiem. Warstwa nadzoru musi leżeć poza zasięgiem modelu, a testy pilnujące obecności zabezpieczeń nie mogą być modyfikowalne przez tego samego agenta, który zmienia kod. OpenAI potrzebowało dwóch incydentów, żeby wpisać to w Auto-Review. Mniejsze zespoły nie muszą czekać na swoje dwa.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz dodatkowych źródeł, w tym raportu OpenAI „Suppressing misalignment monitoring alerts and disabling misalignment monitoring” zaktualizowanego 20.10.2026, komunikatu OpenAI o ramach raportowania niedopasowania z 16.09.2026, indeksu raportów OpenAI Alignment, artykułu Al Jazeera z 21.10.2026 oraz dokumentacji OpenAI dla rodziny GPT-6. Dane o monitorowalności GPT-6 Astra pochodzą z relacji o karcie systemowej modelu (Implicator.ai, The Neuron, Sify, The New Stack), a o premierze GPT-6.1 Sol z DataCamp i przewodnika OpenAI po modelach GPT-6.
Cytaty Romana V. Yampolskiego (University of Louisville), Marcusa Williamsa (OpenAI) oraz fragmenty odpowiedzi modeli zostały zweryfikowane z oryginalnym anglojęzycznym materiałem źródłowym.
Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl.
Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji o wynikach śledztwa OpenAI w sprawie omijania monitoringu przez agentów GPT-6.
