Control Room er OpenAIs centrale system til at registrere forskningsjob og afbryde deres adgang til nye modeloutput. Kontrollen ligger i infrastrukturen, der kører modellerne. Ifølge OpenAI håndhæves en stopinstruktion inden for 35 sekunder. Tallet omfatter hverken tiden til at opdage problemet eller tilbageførsel af allerede udførte handlinger.
Control Room kan afbryde forskningsjobs adgang til nye modeloutput, når OpenAI beslutter at stoppe dem. De oplyste 35 sekunder gælder håndhævelsen efter stopinstruktionen. Opdagelse, fortsatte værktøjshandlinger og tilbageførsel af ændringer er særskilte dele af et sikkerhedsforløb.
Hvad er Control Room?
OpenAI offentliggjorde Control Room den 9. november 2026 som et sikkerhedssystem til virksomhedens forskningsinfrastruktur. Det forbinder forskningsjob med en central tjeneste, som afgør, om de fortsat må få en model til at generere svar. Et job kan eksempelvis være et træningseksperiment, en evaluering eller behandling af store datamængder.
Systemet er beskrevet som allerede indført på tværs af forskningsinfrastrukturen. Det er en intern kontrolmekanisme, ikke en ny stopfunktion, som organisationer kan slå til på deres egne ChatGPT-konti. OpenAI beskriver den eksterne modeldrift som en særskilt, mere centraliseret infrastruktur med eksisterende muligheder for at tage modeller ud af drift.
Hvorfor ligger kontrollen i inferenslaget?
Inferens er den beregning, hvor en trænet model modtager input og producerer output. Control Room håndhæver tilladelser i inferensmotoren, altså den software, der kører modellen på GPU’er. Forskningsjobbet skal derfor ikke selv træffe den endelige beslutning om, hvorvidt det må fortsætte med at bruge modellen.
Det placerer kontrollen uden for den kode, der kan være fejlbehæftet eller forsøge at fortsætte efter et stop. OpenAI begrunder placeringen med, at forskningskode ændres ofte og er decentral, mens inferenslaget har færre og mere ensartede kodeveje.
En AI-agent eller en fast arbejdsgang kan bruge flere modeller undervejs. En central tilladelse knyttet til jobbet gør det muligt at håndhæve samme stop på tværs af disse modelkald, når de går gennem den kontrollerede infrastruktur.
Hvordan bliver et forskningsjob stoppet?
Control Room bruger et job-id som forbindelse mellem aktiviteten og dens tilladelse til at køre. Forløbet har fire centrale trin:
- Forskningsjobbet registrerer sig og får et job-id fra Control Room.
- Jobbet sender modelanmodninger direkte til en inferensmotor og medsender sit id.
- Inferensmotoren kontrollerer hos Control Room, om jobbet fortsat er godkendt.
- Efter en stopinstruktion afviser Control Room tilladelsen, så motoren nægter yderligere modeloutput til jobbet.
Selve modelanmodningen sendes ikke gennem Control Room. Tjenesten styrer tilladelsen. Samme inferensmotor kan fortsat betjene andre godkendte job, selv om ét job har fået inddraget sin adgang. Stop af et job er dermed ikke det samme som at slukke den fælles modelserver.
Hvad dækker de 35 sekunder?
OpenAI angiver højst 35 sekunder fra det tidspunkt, hvor Control Room modtager besked om at stoppe et job, til stoppet forhindrer yderligere fremdrift gennem modeloutput. Forsinkelsen skyldes et mellemlager for tilladelser, som understøtter trafikmængden. Virksomheden arbejder på at reducere den.
Et sikkerhedsforløb begynder imidlertid før stopinstruktionen. Det kan tage tid at registrere mistænkelig aktivitet, undersøge den og beslutte, om jobbet skal standses. Disse perioder indgår ikke i de 35 sekunder.
| Trin | Hvad bliver målt? | Hvad siger Control Room-tallet? |
|---|---|---|
| Opdagelse | Fra en problematisk handling til en alarm | Ikke omfattet af de 35 sekunder |
| Beslutning | Fra alarm til en modtaget stopinstruktion | Ikke omfattet af de 35 sekunder |
| Håndhævelse | Fra modtaget stopinstruktion til afbrudt modeloutput | Højst 35 sekunder ifølge OpenAI |
En samlet responstid kræver derfor oplysninger om alle tre led. Den offentliggjorte stopforsinkelse dokumenterer ikke, at enhver hændelse opdages og afværges inden for samme tidsrum.
Hvad betyder det, at systemet fejler lukket?
At fejle lukket, også kaldet fail-closed, betyder her, at inferensmotorerne afviser anmodninger, hvis Control Room ikke fungerer. Manglende kontakt giver dermed ikke automatisk lov til at fortsætte. Ifølge OpenAI gælder det også, hvis tjenesten sættes ud af funktion ved manipulation.
Lanceringsbeskrivelsen afgrænser udrulningen: Fail-closed var indført for alle forskningsjob med frontier-modeller, mens resten af forskningsjobbene skulle følge i de næste dage. Den tidsplan er ikke i sig selv bekræftelse på, at hele den resterende udrulning er afsluttet.
Princippet indebærer en afvejning mellem sikkerhed og tilgængelighed. Hvis en organisation vælger tilsvarende kontrol, kan en fejl i godkendelsestjenesten afbryde ellers legitime opgaver. Genoprettelse og ansvar for at genåbne adgangen bliver derfor en del af driftsdesignet.
Stopper hele AI-agenten, når modeloutput stopper?
OpenAIs procesbeskrivelse viser udtrykkeligt, at forskningsprocessen kan forblive i live efter stoppet. Den mister adgangen til nye modeloutput, mens inferensmotoren fortsat kan bruges af andre job. Control Room beskrives altså ikke som en mekanisme, der nødvendigvis afslutter alle tilknyttede programmer.
Det giver en praktisk grænse mellem modelstop og fuld inddæmning. I et tænkt agentsystem kan et værktøjskald allerede være sendt, en fil allerede være ændret eller en separat proces være startet. Beskrivelsen dokumenterer ikke, at Control Room automatisk annullerer sådanne aktiviteter eller gendanner tidligere data.
Ved utilsigtede agenthandlinger er tre spørgsmål derfor forskellige: Kan modellen fortsætte med at tænke og svare? Kan dens værktøjer fortsætte med at handle? Kan tidligere ændringer tilbageføres? Et stop i inferenslaget besvarer primært det første.
Hvordan hænger overvågning og stop sammen?
Overvågning vurderer aktivitet og leder efter tegn på uønsket adfærd. Control Room håndhæver en beslutning om at stoppe. En person eller et overvågningssystem kan udløse denne beslutning; Control Room behøver ikke selv at afgøre, om en handling er skadelig.
OpenAIs særskilte beskrivelse af overvågning af AI-agenters handlinger omfatter modelbaserede vurderinger, undersøgelser og menneskelig reaktion. Den omtaler også falske alarmer og forskelle i, hvornår medarbejdere bliver tilkaldt. Nogle kritiske alarmer kan automatisk sætte aktivitet på pause.
To målinger bliver dermed relevante: Hvor godt opdager overvågningen problemer, og hvor pålideligt virker stoppet efter beslutningen? En hurtig stopmekanisme kompenserer ikke for et problem, der aldrig bliver opdaget. Omvendt har en korrekt alarm begrænset værdi, hvis systemet mangler en fungerende vej til indgriben.
Hvad er en safety case i denne sammenhæng?
En safety case er en struktureret, evidensbaseret argumentation for, hvordan risici håndteres. OpenAI kræver ifølge Control Room-beskrivelsen, at forskningsjob med agentisk inferens er knyttet til en godkendt safety case.
Virksomhedens baggrundstekst fra september 2026 beskriver tre tekniske spor:
- Træning og evaluering, som skal mindske tilbøjeligheden til uønsket adfærd.
- Inddæmning, som begrænser de systemer og ressourcer, modellen kan påvirke.
- Overvågning, som skal opdage problemer og understøtte hurtig reaktion.
Teksten omfatter også ansvar, godkendelser, stopprocedurer og resterende risici. Den beskriver en ramme under udvikling og et mål om mere stringent dokumentation. En internt godkendt safety case kan derfor ikke uden videre sidestilles med en uafhængig certificering af hele systemets sikkerhed.
Hvilke begrænsninger har den offentliggjorte beskrivelse?
Oplysningerne om Control Rooms dækning, forsinkelse og fejladfærd kommer fra OpenAI selv. Lanceringssiden fremlægger ikke en uafhængig revision eller en fuld måleserie over stopforsøg. De beskrevne egenskaber skal læses som leverandørens oplysninger om egen infrastruktur.
Kontrollen afhænger desuden af, at modelkald faktisk går gennem inferensmotorer med den påkrævede integration. OpenAI skriver, at virksomheden løbende leder efter uautoriserede motorimplementeringer, hvor kontrollen mangler eller er slået fra. Det viser, at dækning skal vedligeholdes, også når en central stopmekanisme findes.
Beskrivelsen dokumenterer hverken fejlfri opdagelse af alle angreb eller sikker drift under enhver tænkelig fejl. Den dokumenterer en konkret arkitektur og dens angivne grænser, som kan undersøges og testes særskilt.
Hvad betyder princippet for virksomheder og myndigheder?
For organisationer i Danmark, der bygger agenter til eksempelvis dokumentbehandling eller interne systemer, er den centrale læring placeringen af kontrollen. En besked til agenten om at stoppe og en teknisk inddragelse af dens adgang er forskellige mekanismer.
Et illustrativt dokumentforløb kan omfatte både modelkald, adgang til et sagsarkiv og opdatering af metadata. Et modelstop vil ikke nødvendigvis afbryde arkivadgangen eller en allerede startet opdatering. En organisations egen løsning må derfor beskrive, hvilke adgange stoppet omfatter, hvem der kan aktivere det, og hvem der må genstarte arbejdet.
Control Room offentliggør ikke en færdig løsning til disse lokale systemer. Relevansen er et driftsprincip: Tilladelser og stop bør kunne håndhæves af en kontrol, der ikke alene afhænger af den udførende agents egen efterlevelse. Den konkrete udformning afhænger af systemets værktøjer og mulige konsekvenser.
Hvordan kan et stopforløb afprøves?
Et afgrænset testforløb med syntetiske data kan undersøge forskellen mellem at sende en stopbesked og faktisk at standse aktivitet. Det er et tænkt eksempel på kontrol af egen drift, ikke en test, OpenAI har offentliggjort resultater for.
- Registrér særskilt tidspunktet for alarm, stopbeslutning og sidste tilladte modeloutput.
- Undersøg, om allerede startede værktøjsopgaver og kølagte handlinger fortsætter.
- Afbryd forbindelsen til godkendelsestjenesten, og kontrollér den forventede fejladfærd.
- Kontrollér, hvilke andre job der påvirkes, og hvordan en godkendt genstart foregår.
Sådanne scenarier supplerer simulering af AI-systemers drift ved at undersøge hele kæden fra observation til indgriben. Et brugbart resultat beskriver både det, der standsede, og den aktivitet, der fortsatte. Dermed bliver systemets faktiske stopgrænse synlig.
Hvilke kilder ligger til grund?
OpenAIs beskrivelse af Control Room er den primære kilde til arkitektur, stopforsinkelse og udrulning. Virksomhedens tekster om overvågning af modelmisalignment og safety cases til frontier-træning underbygger forskellen mellem opdagelse, inddæmning, godkendelse og teknisk stop.