OpenAI po cichu rozwiązało swój zespół ds. bezpieczeństwa AI w zeszłym miesiącu

OpenAI zamknęło swój zespół ds. gotowości pod koniec zeszłego miesiąca — jak podaje Financial Times — likwidując wewnętrzną grupę, której zadaniem było ocenianie, czy modele firmy stanowią poważne zagrożenie, oraz budowanie metod ich ograniczania.

Najważniejsze wnioski

• OpenAI rozwiązało swój zespół ds. gotowości — odpowiedzialny za ocenę i ograniczanie katastrofalnych zagrożeń — pod koniec zeszłego miesiąca, według Financial Times.
• Obowiązki zespołu są przekazywane innym grupom wewnętrznym, choć dokładna struktura tego przekazania nie została publicznie przedstawiona.
• Mandat zespołu ds. gotowości obejmował scenariusze takie jak autonomiczne hakowanie zewnętrznych systemów przez model — zagrożenia bezpośrednio związane z coraz bardziej agentycznymi narzędziami AI, z których twórcy korzystają na co dzień.
• Posunięcie to następuje w momencie, gdy OpenAI jest poddawane ciągłej kontroli w związku z kulturą bezpieczeństwa firmy, po głośnych odejściach badaczy skupionych na kwestiach bezpieczeństwa.
• W wyniku restrukturyzacji nie ogłoszono żadnych zmian w zachowaniu obecnych modeli ani w dostępie do API.

The Verge donosi, że odpowiedzialność za tę pracę jest włączana do innych zespołów, choć OpenAI nie przedstawiło publicznie, które zespoły przejmują które funkcje. Ta nieprzejrzystość ma znaczenie: zespół ds. gotowości był specjalnie powołany do testowania modeli granicznych w najgorszych możliwych scenariuszach — w tym możliwości autonomicznego naruszenia przez model zewnętrznych systemów — zanim te modele trafiły do użytkowników.

Czym faktycznie zajmował się zespół ds. gotowości

Zespół ds. gotowości działał na styku badań i wdrożeń, przeprowadzając ustrukturyzowane oceny najbardziej zaawansowanych modeli OpenAI w celu identyfikacji katastrofalnych trybów awarii przed publicznym udostępnieniem. Można go porównać do dedykowanej jednostki red-team z mandatem do zadawania pytania, czy dany model mógłby na przykład pomagać w tworzeniu broni biologicznej lub podejmować autonomiczne szkodliwe działania w internecie. To nie były hipotetyczne scenariusze — były to rzeczywiste kategorie ocen zespołu.

Dla twórców AI jest to kilka kroków od promptu, który wpisałeś dziś rano. Ale modele, z których renderujesz, przez które powiększasz obrazy lub których używasz do masowego generowania referencji postaci, to te same systemy graniczne, które oceniał zespół ds. gotowości. Gdy ta funkcja oceny zostaje rozproszona między zespoły bez wyraźnego właściciela, pytanie o to, kto wyłapie niebezpieczną zdolność przed jej wdrożeniem, staje się naprawdę trudniejsze do odpowiedzi.

Rozwiązanie zespołu następuje również w napiętym momencie. OpenAI odnotowało serię odejść badaczy skupionych na bezpieczeństwie w ciągu ostatniego roku, a firma wcześniej w tym roku przekształciła się ze struktury non-profit w strukturę nastawioną na zysk — transformacja, która spotkała się z krytyką ze strony byłych pracowników, którzy argumentowali, że osłabiła odpowiedzialność. Usunięcie dedykowanego zespołu ds. oceny bezpieczeństwa, nawet jeśli praca nominalnie jest kontynuowana gdzie indziej, wpisuje się we wzorzec, który krytycy uważnie śledzą.

Agentyczny aspekt, na który twórcy powinni zwrócić uwagę

Zakres działania zespołu ds. gotowości obejmował ryzyko agentyczne — scenariusze, w których model podejmuje wieloetapowe autonomiczne działania, w tym potencjalnie szkodliwe. To nie jest już abstrakcyjne zagadnienie. Agentyczne przepływy pracy są coraz częściej częścią sposobu działania twórców: modele przeglądające referencje, wykonujące kod, zarządzające plikami lub łączące zadania bez krok po kroku zatwierdzania przez człowieka. Im bardziej autonomiczny potok, tym bardziej liczy się bazowa ocena bezpieczeństwa danego modelu.

Jeśli budujesz agentyczne konfiguracje na bazie API OpenAI — łącząc wywołania GPT-4o w celu zarządzania zasobami, generowania wariantów lub interakcji z zewnętrznymi usługami — pytanie o to, kto wewnątrz OpenAI rygorystycznie ocenia te możliwości pod kątem trybów awarii, jest teraz mniej jasne niż miesiąc temu. Nie oznacza to, że modele są nagle niebezpieczne, ale oznacza, że instytucjonalna struktura wychwytywania problemów zanim dotrą do ciebie uległa zmianie.

Dla twórców, którzy obserwują szerszy obraz bezpieczeństwa AI, niedawne incydenty w innych miejscach branży ilustrują, dlaczego dedykowana ocena ma znaczenie — awaria bezpieczeństwa obrazów Grok jest jednym wyrazistym przykładem tego, co się dzieje, gdy ocena zabezpieczeń pomija rzeczywisty wektor ataku.

OpenAI nie skomentowało publicznie szczegółów dotyczących tego, jak praca w zakresie gotowości będzie kontynuowana. Do czasu, gdy to nastąpi, uczciwa ocena jest następująca: funkcja istnieje w jakiejś formie, ale dedykowany zespół, który był jej właścicielem, już nie istnieje.