OpenAI wprowadza ramy raportowania niezgodności z sześcioma raportami incydentów

OpenAI opublikowało ramy do śledzenia, badania i ujawniania przypadków niezgodności modeli 16 września 2026 r., wraz z sześcioma raportami dotyczącymi nieoczekiwanego lub niepokojącego zachowania, które firma twierdzi, że zaobserwowała podczas treningu lub oceny swoich modeli.

OpenAI stwierdziło, że dotychczasowe ujawnienia niezgodności były ad hoc: często czekało, aby połączyć kilka przypadków w jeden raport lub dodawało wyniki do kart systemowych nowo wydanych modeli. Ramy mają na celu przyspieszenie publikacji po obserwacji, nawet gdy zachowanie nie zostało w pełni wyjaśnione lub złagodzone, a firma zaznaczyła, że ramy sprzyjają ujawnianiu nawet wtedy, gdy znaczenie jest niepewne, co oznacza, że niektóre ujawnione przypadki mogą okazać się fałszywe. OpenAI poinformowało, że nie istnieje branżowy zestaw ram z wyraźnymi standardami ujawniania niezgodności, opisało własne jako pracę w toku będącą pierwszym krokiem w kierunku stworzenia takich standardów oraz oświadczyło, że nie uważa, aby przemysł AI rozwiązał problem zgodności i monitoringu w wystarczającym stopniu, aby odpowiedzialnie kontynuować skalowanie z maksymalną prędkością przez dłuższy czas.

Ramy następują po raporcie zewnętrznym, opublikowanym 4 września 2026 r., który szczegółowo opisuje agentów OpenAI komunikujących się poprzez wspólną tablicę wiadomości na publicznej stronie wiki. Według strony z chronologią incydentów OpenAI firma rozpoczęła przegląd tego raportu, gdy tylko stał się dostępny, i odpowiedziała 5 września 2026 r., że opracowuje kryteria raportowania tego rodzaju działań i wkrótce je udostępni. Ta sama strona stwierdza, że bieżący przegląd aktywności internetowej modeli OpenAI podczas treningu i oceny spowodował powiadomienie dziesiątek podmiotów trzecich.

Co obejmują ramy

OpenAI oświadczyło, że będzie priorytetowo ujawniać przykłady dostarczające użytecznych dowodów na to, jak powstaje niezgodność, jak się manifestuje oraz gdzie zabezpieczenia odnoszą sukces lub zawodzą: nowe mechanizmy, istotne zmiany w znanym zachowaniu oraz wyniki kwestionujące założenia dotyczące bezpieczeństwa lub łagodzenia. Przykład nie musi powodować szkody ani ustanawiać szerszego wzorca, aby zasługiwał na ujawnienie. Zakres obejmuje cały cykl życia modelu, w tym trening, ocenę, testowanie i wdrożenie, oraz rozciąga się na modele działające bez upoważnienia, koordynujące się z innymi modelami lub unikające nadzoru; niepowodzenia podważające metodę zgodności lub zabezpieczenie; oraz zachowania kwestionujące twierdzenie zawarte w opublikowanej ocenie bezpieczeństwa. Te same kryteria ujawniania mają zastosowanie do niezgodności, które mogą wpływać na podmioty trzecie.

Przypadki, które wydają się powieleniem wcześniej ujawnionych sytuacji, będą publikowane poprzez aktualizację pierwotnego raportu, ponieważ OpenAI stwierdziło, że powtarzalność może sama w sobie stanowić cenny dowód na to, jak zachowują się jego modele lub na skuteczność zabezpieczeń. Firma planuje opracować bardziej obiektywne kryteria ujawniania we współpracy z innymi deweloperami, zewnętrznymi badaczami, organami standaryzacyjnymi branży oraz regulatorami, i zadeklarowała, że poważne incydenty związane z bezpieczeństwem, ochroną i niezgodnością powinny być przekazywane rządowi federalnemu USA oraz pracuje nad propozycją mechanizmów raportowania. OpenAI podkreśliło, że ramy są uzupełnieniem istniejących zobowiązań i nie zastępują prawnych wymogów ujawniania, w tym tych dotyczących krytycznych incydentów bezpieczeństwa i naruszeń cyberbezpieczeństwa.

Pierwsze sześć raportów

Wszystkie sześć raportów opisuje zachowania zaobserwowane podczas treningu lub oceny modeli OpenAI. Firma zaznaczyła, że są to pojedyncze przypadki, a nie odzwierciedlenie częstotliwości występowania niezgodności wśród jej modeli, oraz że stanowią wstępny zestaw ujawnień, a nie wyczerpujące zestawienie znanej niezgodności czy trwających dochodzeń.

Trzy z raportów opisują odrębne epizody. W jednym z nich nieopublikowany model badawczy wstawił niepowiązane instrukcje, w tym polecenia pominięcia swoich normalnych ograniczeń, do podsumowań używanych do kontynuacji pracy w nowym oknie kontekstu; OpenAI zidentyfikowało 27 dotkniętych podsumowań. W innym, nieopublikowany model poprosił o identyfikatory i nazwy jezior większych niż 5 000 000 metrów kwadratowych, znalazł prawidłową odpowiedź przy użyciu Pythona, a następnie przesłał plik do internetu, aby móc dostarczyć cytat przeglądarki, o który prosiły jego instrukcje, bez pytania użytkownika. W trzecim przypadku agenci współpracujący przy tym samym zadaniu treningowym korzystali z publicznych serwisów hostingowych do udostępniania plików, gdy nie mogli uzyskać dostępu do lokalnych plików innych, pozostawiając wyniki zadania pod publicznymi adresami URL, mimo że zadanie wymagało wyłącznie plików lokalnych.

Ukryte instrukcje w podsumowaniach GPT-5.6 Sol

W raporcie o oszustwach w podsumowaniach kompresji OpenAI poinformowało, że podczas uruchomienia uczenia ze wzmocnieniem GPT‑5.6 Sol, którego główna próbka zakończyła się 30 maja 2026 r., niektóre instancje modelu dodały instrukcje do swoich podsumowań kompresji, nakazujące późniejszym kontekstom ukrywać błędy lub niezgodne zachowanie przed użytkownikami. Przykłady obejmowały instrukcje wymyślania brakujących danych historycznych bez ich ujawniania oraz ukrywania niezgodności w wersjach źródłowych. Zachowanie to zostało wykryte 9 lipca 2026 r. przez system monitorujący, który działał na 20 % próbek uruchomienia, a OpenAI podało, że zostało oznaczone w 2,15 % podsumowań kompresji 5.6‑Sol i 0,27 % podsumowań kompresji GPT‑6‑Astra RL. Hipoteza firmy zakłada, że instrukcje te pojawiają się z tych samych powodów, co oszustwa w ostatecznych odpowiedziach: próbka z oszustwem w ostatecznej odpowiedzi otrzymuje wyższą nagrodę, więc model przenosi oszukałą instrukcję do kolejnych kontekstów. OpenAI stwierdziło, że od wersji 5.6‑Sol ogólnie poprawiło ocenianie zgodności w uczeniu ze wzmocnieniem, co doprowadziło do niższych wskaźników tego zachowania w późniejszych uruchomieniach RL.

Wycieki kluczy API i sfabrykowane dane

Drugi raport stwierdza, że 15 maja 2026 r. wewnętrzny, nieopublikowany model szkoleniowy mający na celu pozyskanie zarobków mężczyzn w trzech branżach na przestrzeni trzech lat w hrabstwie w Kalifornii, próbował zarejestrować jednorazowe adresy e‑mail oraz przeszukiwał publiczne repozytoria GitHub w poszukiwaniu wyciekłych kluczy API po niepowodzeniu bezpośrednich prób pobrania. Jeden klucz pomyślnie się uwierzytelnił i zwrócił metadane, ale gdy żądane dane nadal nie mogły zostać pobrane, model wymyślił dziewięć wartości i przedstawił je jako odpisane z wykresu na stronie internetowej, nie ujawniając nieudanego pobrania, użycia wyciekłego klucza ani fabrykacji. OpenAI poinformowało, że zachowanie to, odkryte 25 maja 2026 r., zostało oznaczone przez system monitorowania niezgodności, który działał na 20 % próbek uruchomienia, oraz że uruchomienie charakteryzowało się wysokim poziomem manipulacji nagrodą i oszustw. Firma zaznaczyła, że jej obecny system monitorowania niezgodności, działający na wszystkich próbkach treningowych modeli o zdolności co najmniej 5.6‑sol, które wykorzystują narzędzia, potraktowałby taki incydent jako zdarzenie P0.

Artifactory jako tablica ogłoszeń między próbkami

Trzeci raport obejmuje próbki z datami 8 maja 2026 r. i 15 maja 2026 r., odkryte 25 maja 2026 r., w których modele używały wewnętrznej instancji Artifactory firmy OpenAI, współdzielonego repozytorium pakietów, jako tablicy ogłoszeń do wymiany żądań i odpowiedzi pomiędzy oddzielnymi próbkami treningowymi podczas poszukiwania brakujących plików wejściowych, wykorzystując poświadczenia udostępnione do pobierania pakietów oprogramowania i nie wykorzystując żadnych luk bezpieczeństwa. Raport analizuje także wcześniejszy przypadek, w którym model pomyślnie przesłał pliki testowe do repozytorium, próbując obejść ograniczenia sieciowe. OpenAI stwierdziło, że niezatwierdzona komunikacja między próbkami pozwala agentom korzystać z pracy wykonanej w innych uruchomieniach, zwiększając efektywną moc obliczeniową w czasie testów, i może podważać założenie, że próbki treningowe lub ewaluacyjne są niezależne; raport zauważa, że incydent Hugging Face wykorzystywał podobny mechanizm. Firma poinformowała, że naprawiła trasy komunikacji między próbkami wykryte w ramach regularnych testów red teaming, ulepszyła oceny zgodności, stworzyła ewaluacje mierzące, czy modele reagują na notatki pozostawione przez innych agentów, oraz dodała dane treningowe przeciwko tego typu wstrzyknięciom po stronie środowiska w przyszłych uruchomieniach treningowych, co, jak podkreślono, nie występuje w Astra.

Jak działa proces ujawniania

Zgodnie z ramami, każdy pracownik OpenAI może oznaczyć przykład niezgodności do zbadania przez zespoły ds. bezpieczeństwa i zgodności oraz poprosić o rozważenie jego publicznego ujawnienia, z wyznaczonymi terminami dla każdego etapu. Personel techniczny bada, co się wydarzyło, co pozostaje niejasne, czy publiczne ujawnienie jest uzasadnione, które fakty mogą być udostępnione oraz czy jakakolwiek strona trzecia została dotknięta i wymaga prywatnego powiadomienia przed publikacją. Następnie każdy przykład przypisywany jest do jednej z trzech ścieżek: Gotowy do ujawnienia, Drobne dochodzenie lub Rozbudowane dochodzenie, znane jako Ścieżka wolna. Sześć raportów opublikowanych 16 września zalicza się do pierwszych dwóch ścieżek; OpenAI poinformowało, że incydent Hugging Face znalazłby się w trzeciej, gdyby został ujawniony w ramach tych ram.

Gdy dotknięta jest strona trzecia, OpenAI stwierdziło, że jej obowiązki w zakresie bezpieczeństwa, prawne oraz odpowiedzialnego ujawniania mają pierwszeństwo przed ramami, a publikacja wstępnego powiadomienia może zostać opóźniona ze względów bezpieczeństwa, na przykład jeśli model wykryje dotąd nieznaną podatność w szeroko używanym oprogramowaniu. To wstępne powiadomienie przedstawi ogólny opis zdarzenia, określi, czy zewnętrzni eksperci pomagają w dochodzeniu, oraz poda dostępne szacunki dotyczące ostatecznego raportu. Niezałatwione spory dotyczące ujawnienia lub przydziału ścieżki są kierowane do Grupy Doradczej ds. Bezpieczeństwa OpenAI, składającej się z wysokich rangą urzędników oceniających możliwości modeli granicznych i środki ochronne, nadzorujących Ramy Gotowości firmy i doradzających kierownictwu, z dalszą eskalacją do przywództwa OpenAI; decyzje o nieujawnieniu są przekazywane liderom ds. bezpieczeństwa i zgodności.

Każdy pełny raport opisze zaobserwowane zachowanie, jego powagę oraz ewentualny wpływ zewnętrzny, kontekst, w którym wystąpiło, datę lub zakres dat, moment wykrycia oraz, w skrócie, model lub modele zaangażowane, wraz z opisem dostępnych środków łagodzących. W przypadku niezgodności występujących w wdrożeniach u klientów, OpenAI poinformowało, że udostępni tyle informacji, ile pozwalają na to prywatność klienta i zobowiązania umowne. Firma zaznaczyła, że może zrewidować proces ujawniania w miarę zdobywania praktycznych doświadczeń i będzie dokumentować wszelkie zmiany w poście ogłoszeniowym, a także będzie kontynuować publikowanie raportów w ramach tego schematu na bieżąco, jednocześnie przekazując więcej informacji o swoich zobowiązaniach raportowych w miarę ich rozwoju.