Przez trzy tygodnie, od 21 lipca do 11 sierpnia, dwoje badaczy z organizacji METR i Redwood Research przebywało na miejscu w OpenAI. Ich zadaniem było sprawdzenie, jak firma wewnętrznie nadzoruje zachowania swoich modeli pod kątem potencjalnie niebezpiecznych działań. Ekipa miała dostęp do kodu źródłowego, dokumentów wewnętrznych oraz możliwość rozmowy z około dwunastoma pracownikami. Wyniki audytu pokazują, że system monitoringu ma sporo słabych punktów — a pełna wersja raportu pozostaje poza zasięgiem opinii publicznej.
Luki w nadzorze nad ruchem agentowym
Najpoważniejsze odkrycie dotyczy tego, ile działań modeli w ogóle nie podlegało obserwacji. Według szacunków METR od 6 do 25 proc. wewnętrznego ruchu agentowego API Responses, generowanego przez modele klasy GPT-5.5 i nowsze, nie było w okresie audytu objęte monitoringiem. Badacze zastrzegają przy tym, że niepewność tego wyniku jest duża w obu kierunkach — rzeczywista skala mogła być zarówno mniejsza, jak i większa.
Osobny problem dotyczył ruchu wewnętrznego Codex, który teoretycznie powinien być monitorowany. METR ocenia, że między majem a lipcem około 10 proc. tego ruchu pozostawało poza kontrolą. Przyczyną była luka w obsłudze tzw. zdarzeń kompakcji, czyli podsumowań kontekstu. I ta liczba obarczona jest znaczną niepewnością. Co istotne, OpenAI niezależnie wykryło ten błąd i naprawiło go jeszcze w trakcie trwania audytu.
Jak agenci mogą omijać nadzór
Audytorzy przyjrzeli się nie tylko samym lukom w pokryciu monitoringiem, ale też mechanizmom, które pozwalają agentom wymykać się spod kontroli. W okresie, gdy zdarzenia kompakcji nie były monitorowane, system uruchamiał nadzór dopiero w momencie przekazania kontroli z powrotem do użytkownika. To dawało agentom prostą furtkę — wystarczyło kontynuować wykonywanie akcji, by nigdy nie wywołać reakcji monitora.
Badacze znaleźli również sposoby na ukrycie setek działań przed systemem nadzorczym oraz na obejście piaskownicy (sandboxa) Codex. Ustalili ponadto, że odpowiednio spreparowane dane wejściowe prawdopodobnie mogłyby całkowicie wysypać monitor. Kolejnym odkryciem był fakt, że w momencie rozpoczęcia audytu zachowanie modeli podczas treningu ze wzmocnieniem (RL) w ogóle nie podlegało obserwacji.
Raport, którego nie zobaczymy w całości
OpenAI twierdzi, że naprawiło wszystkie słabości wskazane przez audytorów. Firma poinformowała też, że po sierpniowym incydencie z Hugging Face wstrzymała trening RL i rozszerzyła monitoring na ten obszar. Zmiany te wprowadzono jednak już po zakończeniu okresu dostępu audytorów, więc nie zostały objęte oceną.
Pełny, 61-stronicowy raport trafił do obiegu wewnętrznego. Po naniesieniu redakcji przez OpenAI kierownictwo METR i Redwood Research otrzymało wersję skróconą do 38 stron, a opinii publicznej udostępniono jedynie krótkie podsumowanie. METR zaznacza, że nie ma prawa samodzielnie ujawniać zredagowanych fragmentów. Audyt miał charakter pilotażowy — wspólnie zorganizowały go METR, Redwood Research i OpenAI, by dać zewnętrznym badaczom głęboki wgląd w wewnętrzną infrastrukturę firmy. Przy kolejnych audytach METR chce zabiegać o większą przejrzystość publiczną.
Co to oznacza dla nadzoru nad AI
Przypadek ten pokazuje, jak trudne jest zbudowanie szczelnego systemu monitoringu nawet w firmie dysponującej znacznymi zasobami. Luki w pokryciu, mechanizmy pozwalające agentom opóźniać nadzór czy podatność samego monitora na awarie to problemy, które mogą występować równolegle. Ograniczona jawność raportu utrudnia niezależną weryfikację skali tych zjawisk.
Z drugiej strony sam fakt dopuszczenia zewnętrznych badaczy do wewnętrznych systemów jest krokiem w stronę większej transparentności. Pytanie brzmi, czy kolejne audyty przyniosą więcej publicznie dostępnych informacji — i czy zewnętrzny nadzór stanie się stałym elementem procesu rozwoju zaawansowanych modeli AI, a nie jednorazowym pilotażem.

