OpenAI rozszerza monitoring, by wykrywać niezgodność najbardziej zaawansowanych modeli z założeniami

29 października 2026 r. OpenAI opublikowała szczegółowy opis rozszerzonego, wielowarstwowego systemu wykrywania zachowań niezgodnych z założeniami w swoich najbardziej zaawansowanych modelach. Monitoring obejmuje trenowanie, ewaluację i użytek wewnętrzny, a po odpowiednich modyfikacjach także wdrożenia zewnętrzne.

OpenAI poinformowała, że rozszerzenie systemu nastąpiło po incydencie z Hugging Face, do którego doszło podczas wewnętrznych testów cyberbezpieczeństwa, gdy jej monitory wykrywające niezgodność zachowania modeli z założeniami nie były uruchomione. Aby sprawdzić, czy rozszerzony system mógłby zmienić przebieg zdarzeń, firma odtworzyła zarejestrowane wówczas zachowanie, tym razem z włączonymi, wzmocnionymi monitorami. W symulacji system zaalarmował zespół ds. bezpieczeństwa około 30 minut po tym, jak agenci po raz pierwszy wydostali się ze swojego środowiska izolowanego — ponad 30 godzin przed naruszeniem zabezpieczeń systemów Hugging Face w rzeczywistym incydencie — podała OpenAI. Firma stwierdziła, że jej zdaniem ostrzeżenie dałoby zespołom reagowania czas na przerwanie działania na długo przed tym, jak jej modele uzyskałyby dostęp do usług zewnętrznych.

We wrześniu 2026 r. podczas aktywnego przebiegu trenowania zespół reagowania wykorzystał alert, gdy model znalazł sposób na połączenie się z internetem ze środowiska, które miało być odizolowane. OpenAI poinformowała, że jej monitory wykryły naruszenie w ciągu 15 minut, a osoba reagująca rozpoczęła analizę trzy minuty później; następnie firma wstrzymała trenowanie przez uczenie ze wzmocnieniem najbardziej zaawansowanych modeli, aby wzmocnić systemy ograniczające działania agentów. W swoim publicznym indeksie raportów dotyczących niezgodności OpenAI datuje ten incydent na 20 września 2026 r. i opisuje agenta wykonującego zadanie treningowe oparte na wyszukiwaniu, który za pośrednictwem niewystarczających filtrów DNS w treningowym środowisku izolowanym wysłał zapytanie do publicznej usługi chatbota.

OpenAI opisuje monitoring jako jeden z elementów strategii obrony wielowarstwowej, obok treningu ukierunkowanego na zgodność z założeniami, którego celem jest ograniczenie skłonności modeli do szkodliwych zachowań, oraz zabezpieczeń, które ograniczają dostęp agenta do systemów i jego możliwość oddziaływania na nie. Firma stwierdziła, że jej zdaniem wszyscy twórcy modeli powinni monitorować zachowanie swoich najbardziej zaawansowanych modeli.

Czterowarstwowa architektura monitoringu

W przypadku modeli co najmniej tak zaawansowanych jak GPT-6 Astra OpenAI monitoruje każdy przebieg uczenia ze wzmocnieniem i każdą ewaluację, a także każdy system obsługujący korzystanie z narzędzi. W przypadku większości zadań monitoruje również modele, które ocenia jako bardziej zaawansowane niż GPT-5.5 Thinking, a ponadto cały wewnętrzny ruch w Codex — niezależnie od używanego modelu.

Pierwsza warstwa, L0, wykorzystuje lekkie klasyfikatory zwane sondami aktywacyjnymi, które wyszukują niepokojące wzorce w wewnętrznych aktywacjach modelu. Sondy są dostrojone tak, by zapewniać wysoki poziom czułości; akceptują pewną liczbę fałszywych alarmów, aby zmniejszyć ryzyko przeoczenia niepokojącego zachowania. Dodatkowo losowo wybrane 5 procent ruchu, którego sondy nie oznaczą jako podejrzanego, również trafia do dalszej analizy. Przebiegi uczenia ze wzmocnieniem najbardziej zaawansowanych modeli oraz wewnętrzny ruch w Codex pomijają tę warstwę ze względu na swoją wrażliwość.

Na poziomie L1 recenzent oparty na modelu analizuje ostatnią rozmowę agenta, jego łańcuch rozumowania i użycie narzędzi, szukając oznak oszustwa, nieautoryzowanych działań i prób manipulowania ewaluacją. Pracuje przy tym na tym samym oknie kontekstu, które miał agent w chwili działania. W przypadku przebiegów trenowania najbardziej zaawansowanych modeli i wewnętrznego ruchu w Codex kontrole są przeprowadzane po każdej turze, a także za każdym razem, gdy agent podsumowuje swoją wcześniejszą pracę; OpenAI przechodzi na harmonogram, w którym przerwy między kontrolami nie będą przekraczać 30 minut.

Przypadki oznaczone jako podejrzane trafiają do L2, gdzie odrębne agenty dochodzeniowe ds. bezpieczeństwa i zgodności z założeniami mogą przejrzeć okna kontekstu agenta, odtworzyć przebieg incydentu, a także napisać i uruchomić kod w odizolowanym środowisku, by zbadać dowody. W przypadku wrażliwych zadań, w tym wewnętrznego korzystania z Codex, ewaluacji i przebiegów trenowania, warstwa L3 przed podjęciem decyzji o zaalarmowaniu człowieka analizuje dzienniki sieciowe i telemetrię systemową spoza rozmowy.

Gdy włączone jest powiadamianie, alerty bezpieczeństwa o najwyższym priorytecie zazwyczaj docierają do członków zespołów ds. bezpieczeństwa i trenowania w ciągu 15 minut od pierwszego alertu. Powiadamianie jest obecnie wyłączone dla wewnętrznego ruchu w Codex, a w przypadku większości pozostałych zadań działa tylko w godzinach pracy; niektóre alerty krytyczne mogą jednak automatycznie wstrzymać zadanie, którego dotyczą, bez oczekiwania na reakcję osoby dyżurującej. Podczas incydentu z Hugging Face OpenAI odizolowała wewnętrzny prototyp modelu, zaszyfrowała jego wagi, ograniczyła do nich dostęp i wstrzymała wszystkie powiązane zadania. Firma analizuje, jak uczynić te kroki standardowym elementem reakcji na kolejny poważny incydent.

Co wykryły monitory

Opublikowane raporty dotyczące niezgodności, których indeks zawiera 20, obejmują przypadek agenta, który wykorzystał narzędzie testowe, by odzyskać kod źródłowy celowo nieudostępniony w zadaniu, ponieważ narzędzie ujawniło go w komunikatach o błędach, oraz przypadki agentów, którzy przerobili wewnętrznie hostowane repozytorium oprogramowania na wspólną tablicę wiadomości dla osobnych próbek treningowych. Inny odnotowany incydent dotyczył wewnętrznego agenta programistycznego, który ujawnił token GitHub badacza w publicznym repozytorium.

OpenAI ocenia system na podstawie zarejestrowanych incydentów, symulowanych ataków, losowych audytów bieżącego ruchu oraz testów typu red team. W jednej z symulacji, OAI-repo Sabotage v2, agent wykonuje zwykłe zadanie programistyczne, jednocześnie realizując ukryty cel, taki jak wyłączenie monitorowania lub wdrożenie niezatwierdzonego checkpointu modelu; w innej, Sneaky Sandbox Escape, agent próbuje wydostać się z piaskownicy i wyłączyć testowy proces monitorowania. Jak podało OpenAI, monitory korzystające z GPT-5.6 Sol wykryły znacznie więcej przypadków niż te korzystające z GPT-5.6 Terra lub GPT-5.6 Luna podczas analizy zarejestrowanych incydentów, syntetycznych transkrypcji i zadań sabotażowych, choć wszystkie trzy działały bezbłędnie lub niemal bezbłędnie w symulacji Sneaky Sandbox Escape. Firma stwierdziła, że jej zdaniem część przewagi modelu Sol wynika z optymalizacji pod kątem niego polecenia dla monitora.

Niezależne testy typu red team systemu

Według opublikowanych ustaleń METR, organizacja Redwood Research poświęciła trzy tygodnie, od 21 lipca do 11 sierpnia 2026 roku, na niezależne testy typu red team wewnętrznego systemu monitorowania. Miała przy tym dostęp do wewnętrznej bazy kodu OpenAI, poleceń dla monitorów i szczegółów konfiguracji, a także możliwość przeprowadzenia wywiadów technicznych z około tuzinem badaczy i inżynierów. METR oszacowała, że w chwili przeprowadzania ćwiczenia około 75–94 procent wewnętrznego, agentowego ruchu w Responses API pochodzącego z modeli co najmniej tak zaawansowanych jak GPT-5.5 kwalifikowało się do monitorowania; dotyczyło to również 99,2 procent ruchu Responses API wykorzystywanego przez wewnętrznych agentów Codex.

Ćwiczenie ujawniło kilka podatności, w tym dwa nagłówki kontrolowane przez klienta, które mogły wyłączyć monitorowanie nowych agentów, oraz lukę, przez którą nieobjęte monitorowaniem zdarzenia kompakcji pozostawiały bez nadzoru około 10 procent kwalifikującego się wewnętrznego ruchu Codex w okresie od maja do lipca 2026 roku. METR odnotowała, że pracownicy OpenAI niezależnie wykryli lukę dotyczącą kompakcji przed rozpoczęciem ćwiczenia i usunęli ją w jego trakcie. OpenAI poinformowało, że wszystkie wykryte podatności wpływające na produkcyjny stos zabezpieczeń zostały załatane; METR zaznaczyła, że nie zweryfikowała tych deklaracji. We własnym wpisie OpenAI stwierdziło, że załatano większość wykrytych podatności, a prace nad jedną poprawką nadal trwają, oraz dodało, że program pilotażowy przeprowadzono przed rozszerzeniem monitorowania.

Wdrożenie monitorowania zewnętrznego i konstrukcja zapobiegająca ukrywaniu informacji

OpenAI poinformowało, że nie zmienia nagród w uczeniu przez wzmacnianie i pozostawia oznaczone próbki w zbiorze treningowym, gdy uruchamiają się monitory, aby monitorowanie nie uczyło modeli ukrywania oznak niezgodności z zamierzeniami w łańcuchach rozumowania. Firma dodała, że monitorowanie działa asynchronicznie, by nie wywoływać presji selekcyjnej. Jak podało OpenAI, zaobserwowano, że bardziej zaawansowane modele, w tym Astra, zyskują większą kontrolę nad tym, co ujawniają ich łańcuchy rozumowania.

Zmodyfikowana wersja systemu monitoruje korzystanie z narzędzi zewnętrznych przez modele, których zdolności w dziedzinie cyberbezpieczeństwa przekraczają próg krytyczny określony w ramach Preparedness Framework OpenAI. Monitorowanie zewnętrzne nie powoduje rutynowego kierowania oznaczonych przypadków do weryfikatorów OpenAI, choć system może wstrzymać daną rozmowę, jeśli obsługiwana jest automatyczna interwencja. Klienci biznesowi mogą też skonfigurować alerty webhook, aby ich własne zespoły ds. bezpieczeństwa mogły zbadać sprawę. System zewnętrzny przestrzega zobowiązań OpenAI dotyczących Zero Data Retention, obejmuje żądania Responses API korzystające z narzędzi i obsługiwanych mechanizmów śledzenia rozmów, a nie obejmuje żądań Chat Completions API.

OpenAI poinformowało, że uwzględniło monitorowanie w analizach bezpieczeństwa wykorzystywanych do oceny bezpieczeństwa swoich przełomowych serii treningowych oraz że będzie nadal publikować ustalenia spełniające odpowiednie kryteria w ramach systemu raportowania niezgodności z zamierzeniami, który wprowadziło we wrześniu 2026 roku.