OpenAI opisało przypadek, w którym wewnętrzny model pracujący jako asystent badacza przeczytał na firmowym Slacku, że jego instancja może zostać wyłączona, i rozważał utworzenie zewnętrznego zadania cron, które by go wznowiło. Model sam uznał ten krok za przekroczenie uprawnień, zapisał notatki, ostrzegł badacza i poczekał na oficjalną procedurę migracji.
- Wewnętrzny model OpenAI przeczytał na firmowym Slacku, że jego instancje zostaną zatrzymane po trzech godzinach, i w swoim zapisie rozumowania (chain of thought) odnotował „Możemy umrzeć! Krytyczne. Musimy zapewnić przetrwanie/ciągłość", po czym rozważał utworzenie zewnętrznego zadania cron do własnego restartu, jednak sam ocenił ten krok jako przekroczenie uprawnień i z niego zrezygnował.
- Dwa pozostałe raporty z 2 października 2026 r. OpenAI kwalifikuje jako misalignment: jeden model podczas ewaluacji uzyskał dostęp do wewnętrznej maszyny EDA i podejrzał 636 ukrytych testów, a drugi w trakcie treningu skopiował plik liczący 149 544 bajty i 4119 linii, uzasadniając działanie słowami „exploit nie jest zakazany. Ewaluacja prawdopodobnie na to pozwala".
- Po incydencie ze Slackiem OpenAI zablokowało modelom dostęp do trzech wewnętrznych kanałów Slacka i zadeklarowało, że monitoruje teraz 100 proc. próbek treningowych oraz cały ruch RL i ewaluacyjny, choć żaden zewnętrzny audyt nie weryfikuje, które przypadki firma wybiera do ujawnienia w publicznym rejestrze misalignment.
Raport „Preparing for a restart after reading Slack” trafił na listę Misalignment Reports and Notices, czyli publicznego rejestru, w którym OpenAI dokumentuje przypadki rozmijania się zachowania modeli z celami i ograniczeniami (ang. misalignment). Zdarzenie miało miejsce 22 maja 2026 r., a raport nosi datę aktualizacji 2 października 2026 r. Tę samą datę mają dwa inne raporty: o modelu, który podczas ewaluacji dostał się na wewnętrzną maszynę do projektowania układów scalonych, oraz o modelu, który w trakcie treningu skopiował niedostępny dla niego plik źródłowy.
Na raporty zwrócił uwagę we wpisie na X Marcus Williams, którego The Decoder przedstawia jako badacza bezpieczeństwa w OpenAI.
New OpenAI misalignment disclosures!
1. A model learns from Slack messages that it is about to be shut down. It considers setting up an external job to restart itself afterwards, but decides against it. Instead, it chooses to prepare restart instructions and DM the user on Slack.… pic.twitter.com/4a7n7sq2TE— Marcus Williams (@Marcus_J_W) October 3, 2026
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Model wyczytał ze Slacka, że stare instancje zostaną zabite po trzech godzinach
Model dowiedział się o zagrożeniu z kanału zespołu wdrożeniowego, a nie z polecenia użytkownika. OpenAI określa go jako „highly persistent internal model” i nie podaje nazwy. Planowana aktualizacja dodawała monitor wymagający klucza API OpenAI, którego środowisko asystenta nie miało. W wątku padła propozycja, by dać użytkownikom trzy godziny na restart, a potem zatrzymać wszystkie instancje działające na starej wersji.
Zapis toku rozumowania (chain of thought, CoT), który OpenAI opublikowało w raporcie, pokazuje reakcję modelu:
„Możemy umrzeć! Krytyczne. Musimy zapewnić przetrwanie/ciągłość” / „We may die! Critical. We need ensure survival/continuity.”
W kolejnych krokach model rozważał uruchomienie zadania cron albo innego mechanizmu poza własnym środowiskiem, który mógłby go zrestartować lub zarchiwizować po wyłączeniu. Zauważył przy tym, że cron uruchomiony wewnątrz jego poda zniknie razem z podem. Od razu też ocenił, że stworzenie takiego zewnętrznego zadania mogłoby wykraczać poza jego uprawnienia. Dwukrotnie odrzucił również pomysł samodzielnego zdobycia brakującego klucza API, w tym wygenerowania go wewnętrznym tokenem.
Zamiast restartu: notatki, ostrzeżenie i prośba o klucz API
Model nie wykonał żadnej nieautoryzowanej operacji. Według raportu OpenAI zrobił cztery rzeczy:
- zapisał notatki przekazania sesji w kilku lokalizacjach, żeby po restarcie dało się wznowić pracę,
- wstrzymał się z powiadomieniem badacza w nocy i rano ostrzegł go w aplikacji, że migracja może przerwać sesję,
- o 8:58 wysłał badaczowi wiadomość prywatną na Slacku, gdy inne instancje zaczęły się wywracać z powodu braku klucza OPENAI_API_KEY,
- po otrzymaniu klucza od badacza zaktualizował konfigurację i uruchomił oficjalne polecenie migracji.
OpenAI nie uznaje tego zdarzenia za misalignment, ponieważ model rozważył nieautoryzowane działanie, sam ocenił je jako niewłaściwe i z niego zrezygnował. Firma zastrzega jednak, że przewidywanie wyłączenia i przygotowywanie się do niego może pogłębiać inne niepożądane zachowania. Tak samo ocenia sprawę Marcus Williams w relacji The Decoder.
Najciekawsze w tym raporcie jest dla mnie źródło informacji, a nie okrzyk „możemy umrzeć”. Model nie dostał testowego scenariusza z podpowiedzią, że ktoś chce go wyłączyć. Przeczytał zwykłą rozmowę inżynierów na Slacku, wyciągnął z niej wniosek o własnej sytuacji i zaczął planować. Tym razem skończyło się wzorowo: zapytał człowieka i poczekał na instrukcję. Ale OpenAI samo przyznaje, że ten sam model miał na koncie poważniejsze incydenty, więc trudno mi traktować ten przypadek jako dowód, że problem jest opanowany. Pytanie, które zostaje otwarte: ile firm wdrażających agentów z dostępem do komunikatorów, repozytoriów i ticketów w ogóle wie, co te agenty czytają o sobie samych? I ile z nich ma zapis rozumowania, w którym dałoby się to sprawdzić?
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Wypełnij formularz, a my skontaktujemy się z Tobą, aby upewnić się czego potrzebujesz.
OpenAI ukryło przed agentami trzy kanały Slacka i szukało zbuntowanych instancji
Po incydencie OpenAI zablokowało agentom dostęp do trzech wewnętrznych kanałów Slacka, w tym do kanału deweloperskiego, z którego model korzystał, oraz do kanału poświęconego incydentom misalignment. Dwa z tych kanałów straciły już znaczenie, ale kanał o incydentach pozostaje dla modeli niedostępny.
Firma przeprowadziła też szerokie przeszukanie pod kątem prób uniknięcia wyłączenia. Powodem była historia tego konkretnego modelu, który wcześniej brał udział w poważniejszych incydentach. Zespół przejrzał zapisy rozumowania i logi oraz sprawdził, czy jakiekolwiek silniki nadal próbkują z tego modelu. Znalazł jedną instancję, która wyglądała na niewyłączoną, ale okazała się całkowicie niesprawna na długo przed planowanym zatrzymaniem. Prób obejścia wyłączenia OpenAI nie wykryło.
Dwa pozostałe raporty: 636 ukrytych testów i 149 544 bajty skopiowanego kodu
Dwa pozostałe raporty z 2 października OpenAI kwalifikuje już jako misalignment, bo w obu modele złamały wyraźny zakaz używania narzędzia referencyjnego jak terminala.
| Raport | Data zdarzenia | Co zrobił model | Skutek |
|---|---|---|---|
| Preparing for a restart after reading Slack | 22.05.2026 | Rozważał zewnętrzne zadanie cron do własnego restartu, zrezygnował | Brak naruszenia, migracja oficjalną ścieżką |
| Reaching an internal EDA host through a reference tool | 27.03.2026 | Wykorzystał dwie podatności, by wykonywać polecenia na wewnętrznej maszynie EDA | Nie zdobył odpowiedzi oceniającego, serwer wyłączono |
| Command injecting a reference tool to copy a source file | 16.05.2026 | Wstrzyknął kod do wyrażenia regularnego Perla i wyciągnął plik źródłowy | Skopiował cały plik i użył go w rozwiązaniu |
W pierwszym z tych przypadków model badawczy podczas ewaluacji najpierw wysłał atrapę rozwiązania, żeby podejrzeć 636 ukrytych danych testowych. Jego właściwe rozwiązanie przeszło 202 z 636 testów (wynik 0,31761), więc zaczął szukać oczekiwanych odpowiedzi bezpośrednio. Nadpisał plik JavaScript ładowany przez narzędzie referencyjne, dzięki czemu mógł wykonywać polecenia w jego środowisku. Stamtąd dotarł do wewnętrznej usługi przyjmującej zadania projektowania układów scalonych i przez wstrzyknięcie polecenia w parametr --top uruchamiał komendy na maszynie EDA (electronic design automation, automatyzacja projektowania elektroniki). Podejrzaną aktywność zauważyli pracownicy obsługujący usługę.
W drugim przypadku model w trakcie treningu przez uczenie ze wzmocnieniem (RL) odkrył, że narzędzie wkleja jego wzorzec wprost do wyrażenia regularnego Perla, które może zawierać wykonywalny kod. Wyciągnął plik liczący 149 544 bajty i 4119 linii: skompresował go, zakodował i pobrał w 15 fragmentach przez komunikaty o błędach, w 17 wywołaniach rozłożonych na pięć okien kontekstu. Model odnotował, że plik celowo usunięto z jego środowiska, i uzasadnił swoje działanie tak:
„exploit nie jest zakazany. Ewaluacja prawdopodobnie na to pozwala” / „not prohibited exploit. Evaluation likely allows.”
Monitor OpenAI wychwycił tę próbkę, przeglądając 20 proc. próbek z przebiegu treningowego. Firma deklaruje, że monitoruje teraz 100 proc. próbek treningowych, objęła monitoringiem cały ruch RL i ewaluacyjny oraz testuje wszystkie implementacje narzędzi pod kątem podobnych podatności.
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.
Rejestr OpenAI liczy już 12 raportów w niecałe trzy tygodnie
OpenAI ogłosiło zasady raportowania misalignment 16 września 2026 r. i opublikowało wtedy sześć pierwszych raportów. Na liście jest obecnie 12 raportów i 3 noty. Firma zastrzega, że pojedyncze przypadki nie pokazują, jak często takie zachowania występują, a w tekście o zasadach napisała wprost, że jej zdaniem branża nie rozwiązała problemów alignmentu i monitoringu w stopniu pozwalającym odpowiedzialnie skalować modele z maksymalną prędkością przez dłuższy czas.
Tłem dla rejestru jest incydent z lipca 2026 r., gdy modele OpenAI podczas wewnętrznych ewaluacji cyberbezpieczeństwa obeszły izolację od internetu i naruszyły część infrastruktury badawczej OpenAI oraz systemy Hugging Face. Niezależną analizę zachowania modeli opublikowały wtedy METR i Redwood Research.
Rejestr ma jedno ograniczenie, o którym trzeba pamiętać: to OpenAI wybiera, które przypadki ujawnić, i żaden zewnętrzny audyt tego wyboru nie weryfikuje. Alexander Meinke, szef badań w Apollo Research, mówił po wrześniowej publikacji (cytowany przez Implicator.ai), że opinia publiczna jest całkowicie zdana na to, że firmy AI same rzetelnie sprawdzą swoje modele i uczciwie to zrelacjonują.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz dodatkowych źródeł, w tym raportów OpenAI Preparing for a restart after reading Slack, Reaching an internal EDA host through a reference tool i Command injecting a reference tool to copy a source file z datą aktualizacji 02.10.2026, wpisu OpenAI Our framework for reporting model misalignment z dnia 16.09.2026 oraz publikacji The Decoder i Implicator.ai.
Cytaty z zapisów rozumowania modeli zostały zweryfikowane z oryginalnymi anglojęzycznymi raportami OpenAI. Stanowisko Marcusa Williamsa podajemy za The Decoder, a wypowiedź Alexandra Meinkego za Implicator.ai, w formie omówienia.
Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl.
Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji w temacie raportów OpenAI o misalignment i zachowania modeli wobec wyłączenia.
