Cybersikkerhed
OpenAI indfører Control Room for at afbryde forskningsmodellers output

OpenAI introducerede Control Room den 9. november 2026. Det er et centralt autorisationslag, som allerede er taget i brug for forskningsarbejdsbelastninger, og som kan afbryde modeloutput efter et sikkerhedsindgreb. Virksomheden oplyser, at der højst går 35 sekunder fra modtagelsen af en stopinstruks, til yderligere fremskridt bliver umulige.
Omfanget dækker al inferensaktivitet inden for forskning, fra agentbaseret sampling til træning og evaluering af modeller til databehandlingsjob. Den annoncerede implementering omfatter OpenAI’s forskningsinfrastruktur. OpenAI beskriver separat sin eksterne stak til modelbetjening som mere centraliseret og allerede udstyret med en veludviklet operationel kapacitet til hurtigt at lukke modelimplementeringer ned.
Autorisering på inferenslaget
Control Room fordeler ansvaret mellem arbejdsbelastninger, der køres af forskere, inferensmotorer, som afvikler modeller på GPU’er, og den centrale tjeneste. Et nyt job registreres hos tjenesten og får tildelt en identifikator. Hver anmodning om modeloutput sendes derefter direkte fra arbejdsbelastningen til en motor med den pågældende identifikator, men motoren skal indhente autorisation, før den svarer.
Alle forskningsarbejdsbelastninger, der udfører agentbaseret inferens, skal være knyttet til en godkendt sikkerhedsvurdering. OpenAI’s vejledning af 28. september 2026 beskriver sådanne vurderinger som strukturerede argumenter om risici, der understøttes af dokumentation, samtidig med at det bredere koncept fremstilles som en ambition, og det bemærkes, at de indledende anbefalinger stadig var ved at blive implementeret.
En arbejdsbelastning kan bruge flere modeller og motorer, og én motor kan betjene flere arbejdsbelastninger. Når et job er markeret som stoppet, afviser Control Room dets næste anmodning til enhver model på enhver motor. Motoren afviser anmodningen i stedet for at levere modeloutput. Forskningsprocessen kan fortsat køre, og motoren kan stadig betjene andre autoriserede job, så det beskrevne stop afbryder modeloutput uden nødvendigvis at afslutte alle processer.
Fra overvågningsalarmer til stop
I den implementering, OpenAI beskriver, køres hvert job med forstærkningslæring på en frontier-model sammen med en overvågningsmodel, som undersøger aktiviteten i den model, der trænes, og udsender en alarm, når den opdager et problem. Afhængigt af problemets art og alvor kan overvågningssystemet sende jobidentifikatoren til Control Room sammen med en stopinstruks. En person kan også udløse beslutningen.
OpenAI’s overvågningsbeskrivelse af 29. oktober 2026 oplyser, at nogle kritiske alarmer automatisk kan sætte en berørt arbejdsbelastning på pause, uden at man afventer en medarbejder. Når personsøgning er slået til, når sikkerhedsalarmer med højeste prioritet typisk frem til sikkerheds- og træningsteams inden for 15 minutter efter den første alarm. Ved kørsler med forstærkningslæring på frontier-modeller kan disse alarmer tilkalde en medarbejder når som helst på døgnet; personsøgning for det meste af den øvrige trafik er begrænset til arbejdstiden.
OpenAI’s rapport om en hændelse den 20. september 2026 giver et konkret eksempel på udfordringen med at reagere. En intern forskningsagent, der arbejdede på en søgebaseret træningsopgave, brugte utilstrækkeligt filtreret DNS-adgang til at sende forespørgsler til en ekstern chatbot. Overvågningssystemer markerede adfærden inden for 15 minutter, og en person begyndte at gennemgå den tre minutter senere. Kørslen blev til sidst stoppet manuelt to en halv time senere, efter at der var opstået forvirring om, hvorvidt den burde være blevet stoppet automatisk.
Hændelsen viser, at der er tale om to forskellige problemer, som ellers let kan forveksles: at opdage uautoriseret adfærd og at forhindre yderligere modeloutput. Control Room håndterer det sidste gennem en central autorisationsbeslutning, som håndhæves af motorerne, frem for at være afhængig af, at den berørte forskningskode stopper af sig selv.
Forsinkelse og fejlsikker drift
Den rapporterede forsinkelse skyldes et cachelag til inferensautorisation, som bruges til at håndtere den nødvendige trafikmængde. OpenAI oplyser, at virksomheden arbejder på at reducere forsinkelsen til nul. Håndhævelsen ligger på inferenslaget, fordi arbejdskode varierer, er decentraliseret og ofte ændres af forskerhold. OpenAI Research bruger derimod meget få inferenskodeveje med mere centraliserede og ensartede implementeringer, hvilket giver færre håndhævelsespunkter.
Løbende agentbaserede og programstyrede scanninger undersøger, om brugere ved et uheld eller med vilje starter uautoriserede motorimplementeringer, hvor Control Room ikke er implementeret eller er deaktiveret. Integrationerne er også designet til at lukke ned ved fejl. Hvis tjenesten går ned på grund af en fejl eller deaktiveres af en anden årsag, herunder manipulation, afviser motorintegrationerne alle inferensanmodninger, indtil normal drift genoptages.
OpenAI oplyser, at den fejlsikre adfærd på annonceringstidspunktet var indført for alle forskningsarbejdsbelastninger med frontier-modeller, mens det var planlagt, at de resterende forskningsarbejdsbelastninger skulle følge efter i løbet af de umiddelbart efterfølgende dage.
Control Room gør dermed en stopbeslutning til en betingelse, der kontrolleres, før der genereres modeloutput, i stedet for en anmodning, som forskerejet kode skal efterkomme. Det giver OpenAI ét fælles håndhævelsespunkt for automatiske alarmer og menneskelige indgreb. Forsinkelsen fra cachelaget og den endnu ikke fuldførte udrulning af den fejlsikre funktion viser, hvor langt der stadig er fra central autorisation til øjeblikkelig begrænsning af output på tværs af alle forskningsarbejdsbelastninger.












