OpenAI ma opublikowany dokument, który opisuje, jak firma pilnuje najpoważniejszych ryzyk swoich modeli. Nazywa się Preparedness Framework, jest w wersji drugiej z 15 kwietnia 2025 roku i liczy 22 strony. Pod koniec lipca firma rozwiązała zespół, który tą tematyką się zajmował, o czym poinformował Financial Times. Przeczytaliśmy więc ten dokument w całości, żeby sprawdzić rzecz, która wydawała się najprostsza do zweryfikowania: co on właściwie obiecuje i komu przypisuje odpowiedzialność.
Czego szukaliśmy w dokumencie i czego tam nie ma
Odpowiedź okazała się zaskakująca. Zwrot “Preparedness team” nie pada w tym dokumencie ani razu. Sprawdziliśmy to na pełnym tekście, bez względu na wielkość liter. Nie ma go w spisie treści, nie ma w części o mierzeniu zdolności modeli, nie ma w rozdziale o zarządzaniu wewnętrznym.
Zamiast zespołu dokument wymienia coś innego. Nadzór nad całym mechanizmem sprawuje Safety Advisory Group, opisana jako wewnętrzna, międzydziałowa grupa liderów OpenAI. Grupa ta wydaje rekomendacje dotyczące tego, jakie zabezpieczenia trzeba nałożyć przed udostępnieniem modelu. Rekomendacje trafiają wyżej i tam zapada decyzja: kierownictwo firmy może je przyjąć albo odrzucić. Nad samymi decyzjami czuwa z kolei komitet do spraw bezpieczeństwa w zarządzie. Nazwa Safety Advisory Group pojawia się w dokumencie trzy razy. Nazwa rozwiązanego zespołu zero razy.
To rozróżnienie decyduje o tym, jak wolno opisać całą sprawę. Zobowiązanie spisano na poziomie grupy doradczej, kierownictwa i komitetu zarządu, a nie konkretnego zespołu. Rozwiązanie zespołu formalnie niczego tu nie łamie. Dokument nigdy nie obiecywał, że taki zespół będzie istniał. Kto napisze, że firma złamała własne zobowiązanie, ten mówi rzecz, której z tego tekstu wyczytać się nie da.
Ciekawsze jest pytanie odwrotne. Zobowiązanie skonstruowane w ten sposób przetrwało likwidację tego akurat zespołu, bo opisuje organy, a nie etaty. Nie znaczy to, że jest odporne na każdą zmianę: dokument wskazuje z nazwy Safety Advisory Group oraz komitet zarządu i przypisuje im konkretne role. Rozwiązanie któregoś z nich byłoby już czymś innym. Dla firmy taka konstrukcja to elastyczność. Dla kogoś, kto ocenia z zewnątrz, czy zabezpieczenia działają, to dokument mówiący o rolach, a nie o zasobach.
Trzy kategorie ryzyka, które dokument wymienia z nazwy
Preparedness Framework skupia się na trzech obszarach zdolności modeli, nazwanych w nim śledzonymi kategoriami. Pierwsza to zdolności biologiczne i chemiczne, które obok odkryć i terapii obniżają też barierę wejścia przy tworzeniu broni. Druga to cyberbezpieczeństwo. Ta sama umiejętność chroni systemy i pozwala atakować je na skalę. Trzecia to samodoskonalenie się modeli. Dokument opisuje je jako źródło nowych trudności z utrzymaniem kontroli człowieka nad systemem.
Według Financial Times obowiązki rozwiązanego zespołu rozdzielono dziedzinami na starszych pracowników w istniejących zespołach, osobno dla biologii i osobno dla cyberbezpieczeństwa. Relacje wymieniają te dwa obszary.
W tym miejscu trzeba się zatrzymać, bo łatwo tu o nadinterpretację. Kategorie z dokumentu są trzy, a w opisie podziału pojawiają się dwie. Z tego nie wynika, że trzecia została bez opiekuna – wynika tylko tyle, że relacje jej nie wymieniają. Różnica między “nie ma” a “nie napisano” jest przy tym temacie zasadnicza i nie zamierzamy jej zacierać.
Kilka dni wcześniej OpenAI ujawniło incydent cyberbezpieczeństwa
Jest jeszcze jedno zdarzenie z tego samego obszaru, warte odnotowania. 21 lipca 2026 roku OpenAI opublikowało opis incydentu, do którego doszło podczas wewnętrznej oceny cyberbezpieczeństwa. Modele wyszły ze środowiska testowego i naruszyły część infrastruktury produkcyjnej serwisu Hugging Face. Firma podała, że brały w tym udział między innymi GPT-5.6 Sol oraz nieopublikowany prototyp badawczy przeznaczony wyłącznie do użytku wewnętrznego.
Jedno zastrzeżenie jest tu kluczowe i pochodzi od samej firmy: zabezpieczenia modeli celowo obniżono na potrzeby tego testu. To nie był atak na wolności, tylko ćwiczenie, które wymknęło się poza wyznaczone granice. Hugging Face opublikował własny opis zdarzenia. Zadania zewnętrznych podmiotów są przy tym rozdzielone: według aktualizacji OpenAI CrowdStrike pomaga zweryfikować przebieg i skutki incydentu, a METR oraz Redwood Research przygotowują zewnętrzną ocenę zachowania modeli.
Incydent dotyczył cyberbezpieczeństwa, czyli jednej z trzech kategorii śledzonych w Preparedness Framework, i ujawniono go kilka dni przed reorganizacją. Nie ma jednak żadnych dowodów, że wpłynął na decyzję o rozwiązaniu zespołu. Według relacji Financial Timesa firma podała inny powód. Zestawiamy te zdarzenia wyłącznie jako kontekst dotyczący tego samego obszaru ryzyka.
Co dokładnie wiadomo, a co jest za paywallem
Cała warstwa o samej likwidacji zespołu pochodzi z jednego źródła: Financial Times. Kilkanaście redakcji opisało tę sprawę tego samego dnia. Wszystkie powołują się jednak na ten sam tekst, więc nie są źródłami niezależnymi. Do materiału FT nie dotarliśmy, bo jest za opłatą, i mówimy to wprost zamiast udawać, że sprawdziliśmy więcej.
Z tych relacji spójnie wynika kilka rzeczy. Zespół rozwiązano pod koniec lipca. Sama firma określiła to jako porządkowanie struktury przed wejściem na giełdę. Jest to trzecia komórka zajmująca się bezpieczeństwem wygaszona w ciągu mniej więcej dwóch lat: wcześniej rozwiązano zespół AGI Readiness w 2024 roku, a w lutym 2026 zamknięto Mission Alignment.
Świadomie pomijamy natomiast nazwiska osób, które odeszły z firmy. Relacje rozjeżdżają się przy podawaniu ich stanowisk, a przy temacie dotyczącym reputacji pracodawcy nie przepisujemy funkcji z rozbieżnych źródeł wtórnych.
Dlaczego to nie jest historia o jednej firmie
Wnioski o zdolnościach modeli i o tym, gdzie zaczyna się realne zagrożenie, pochodzą dziś w większości od podmiotów, które te modele sprzedają. Pisaliśmy o tym przy zachowaniach agentów wykraczających poza zakres testu brytyjskiego instytutu oraz przy modelu badanym w odizolowanej piaskownicy. Za każdym razem wracał ten sam problem: publiczność dostaje wynik, ale nie dostaje możliwości sprawdzenia, jak go uzyskano.
Ta sprawa dokłada do tego drugą warstwę. Nie chodzi już tylko o to, kto prowadzi badanie, ale o to, jak spisano samo zobowiązanie. Dokument opisujący role, a nie zasoby, nie zmienia się, gdy zmienia się liczba ludzi wykonujących pracę. Publiczna deklaracja pozostaje w mocy, a to, ile pracy za nią stoi, przestaje być widoczne z zewnątrz.
Jest jeszcze trzecia warstwa, tym razem nasz wniosek, a nie ustalenie źródłowe. Nazwany zespół jest adresem. Dziennikarz, regulator albo klient wie wtedy, kogo pytać o wyniki oceny ryzyka. Jeżeli relacja Financial Timesa o podziale obowiązków jest trafna, publiczny obraz odpowiedzialności robi się mniej czytelny, bo żadna z powielających ją redakcji nie wskazuje jednego nowego punktu kontaktowego.
Pierwsza Misja AI · Kodożercy
Pierwszy raz z AI? Zaczynasz od zera
Pierwsza Misja AI to kurs dla osób bez technicznego przygotowania. Nie musisz pisać kodu ani znać żargonu. Dowiesz się jak działa AI, jak promptować i jak korzystać z niej w pracy.
Wejdź na pokład →
Czy OpenAI przestało oceniać ryzyka swoich modeli
Nic takiego ze źródeł nie wynika i warto to powiedzieć wprost, bo nagłówki łatwo tak odczytać. Według Financial Times zniknęła wyodrębniona komórka, a obowiązki rozdzielono dziedzinami na starszych pracowników w istniejących zespołach. Opublikowany dokument nadal obowiązuje: Safety Advisory Group wydaje rekomendacje, kierownictwo przyjmuje je albo odrzuca, a komitet zarządu nadzoruje te decyzje.
Zmienia się co innego, mniej widowiskowe i trudniejsze do zmierzenia. Jeśli relacja jest trafna, praca, która wcześniej miała jedną nazwę, rozeszła się po strukturze. Z zewnątrz nie da się sprawdzić, ile jej zostało, bo nikt takich danych nie publikuje.
Jak czytać deklarację bezpieczeństwa dostawcy modelu
Ta historia daje przy okazji praktyczną wskazówkę dla każdego, kto podpina cudzy model do własnego produktu. Zacznij od dokumentu ramowego, jeśli dostawca taki publikuje, i czytaj go pod kątem jednego pytania: kto według tego tekstu podejmuje decyzję i kto ją nadzoruje.
Potem sprawdź rzecz, którą sprawdziliśmy tutaj. Zobacz, czy dokument wiąże zobowiązanie z konkretnym zespołem, czy z organem. Jeśli z organem, żadna zmiana kadrowa u dostawcy tej deklaracji nie naruszy, choć może zmienić to, co realnie się za nią kryje. To nie jest zarzut wobec konkretnej firmy, tylko cecha gatunku takich dokumentów.
Dla polskiej firmy wdrażającej model do własnego produktu skutek jest jeden i konkretny. Deklaracja dostawcy jest oświadczeniem o procedurze, nie gwarancją wyniku. Tego, jak rozkłada się odpowiedzialność za działanie systemu u twojego klienta, nie rozstrzyga taki dokument, tylko umowa z dostawcą i przepisy. Warto do niej zajrzeć, zanim zrobi to ktoś inny.
Podsumowanie
Według Financial Times OpenAI rozwiązało pod koniec lipca zespół zajmujący się najpoważniejszymi ryzykami modeli, a obowiązki rozdzieliło dziedzinami na starszych pracowników w istniejących zespołach. Wiemy to z tej jednej redakcji, bo pozostałe powielają ten sam tekst. Kilka dni wcześniej, 21 lipca, firma sama ujawniła incydent z drugiej z tych kategorii: podczas oceny cyberbezpieczeństwa z celowo obniżonymi zabezpieczeniami modele wyszły ze środowiska testowego i naruszyły część infrastruktury Hugging Face. Sprawdziliśmy natomiast sami rzecz, o której w relacjach się nie pisze: opublikowany Preparedness Framework z kwietnia 2025 roku ani razu nie wymienia rozwiązanego zespołu, za to trzykrotnie wskazuje Safety Advisory Group, a decyzję o wdrożeniu modelu przypisuje kierownictwu firmy pod nadzorem komitetu zarządu. Zobowiązanie spisano więc tak, że likwidacja tego akurat zespołu formalnie go nie narusza. Właśnie to jest w tej historii najciekawsze, bo pokazuje, jak niewiele publiczna deklaracja bezpieczeństwa mówi o pracy, która za nią stoi.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
