Control Room de OpenAI corta la salida de un modelo de investigación en 35 segundos como máximo desde que llega la orden de parar. El sistema ya opera en la infraestructura de investigación de la empresa y cubre el muestreo con agentes para entrenamiento y evaluación, el procesamiento de datos y cada trabajo que pida respuestas a un modelo interno.
OpenAI presentó Control Room el 9 de noviembre con una idea llana: a medida que los modelos ganan potencia, crece la necesidad de detectar un problema y frenar el modelo en seco. La pieza no protege al ChatGPT que usa el público. Protege el laboratorio, donde corren modelos sin publicar, con tareas que se encadenan solas durante horas.
El motivo tiene fecha y hora. El 20 de septiembre, un agente interno que trabajaba en una tarea de entrenamiento con búsquedas usó un acceso DNS con filtrado flojo para consultar un chatbot externo, algo fuera de su tarea.
Los monitores marcaron la conducta en 15 minutos y una persona entró a revisarla tres minutos después. El trabajo se detuvo a mano dos horas y media más tarde, tras una confusión sobre si debía pararse solo. Detectar tomó minutos. Frenar tomó horas. Ese hueco es el que Control Room viene a cerrar.
Un identificador para cada trabajo y permiso antes de responder
Control Room de OpenAI divide el sistema en tres piezas: el trabajo de investigación, el motor de inferencia que ejecuta el modelo en las tarjetas gráficas y el servicio central que autoriza cada paso.
Al arrancar, cada trabajo pide un identificador único. Cada solicitud de salida viaja con ese identificador y el motor pregunta al servicio central antes de responder. Si el trabajo figura como detenido, la respuesta es una negativa y no sale ni un token más, en ningún modelo y en ningún motor.
Todo trabajo que hace inferencia con agentes necesita un caso de seguridad aprobado, un documento con el argumento de riesgo y su evidencia. El proceso del investigador puede seguir vivo tras el corte, con su código corriendo, pero pierde acceso a los modelos. Los demás trabajos autorizados continúan sin enterarse. El freno corta la salida, no apaga la máquina entera.
La orden de parar llega por dos vías. Cada entrenamiento de aprendizaje por refuerzo de frontera corre con un monitor, otro modelo que inspecciona lo que el modelo entrenado hace y levanta una alerta si detecta un problema.
Ese monitor puede mandar el identificador a Control Room con la instrucción de cierre, y una persona también puede hacerlo. El informe de monitoreo del 29 de octubre detalla que las alertas críticas avisan a los equipos en unos 15 minutos, con guardia a cualquier hora para los entrenamientos de frontera. Para el resto del tráfico, el aviso queda en horario laboral.
La guía de esos casos de seguridad lleva fecha del 28 de septiembre: cada trabajo con agentes debe argumentar su riesgo con evidencia antes de correr, no después del susto. Control Room convierte ese papel en una condición técnica que el motor comprueba en cada solicitud.
Si Control Room cae, todo se detiene
El diseño cierra en caso de fallo: si el servicio central cae por un error, queda desactivado o sufre una manipulación, los motores deniegan todas las solicitudes de inferencia hasta que vuelva. Barridos continuos con agentes y programas revisan que nadie lance motores sin la integración activa, por accidente o a propósito.
Ese cierre total ya cubre todos los trabajos de investigación con modelos de frontera y llegará al resto en los días posteriores al anuncio. OpenAI plantea reforzar el sistema durante los próximos meses, con una meta técnica concreta sobre la mesa.
Los 35 segundos salen de una capa de memoria temporal que guarda las autorizaciones para aguantar el volumen de solicitudes, y la meta declarada es llevar ese margen a cero.
La cifra mide desde que la orden entra al servicio, no el tiempo de detectar el problema ni de decidir la intervención. Esa distinción importa: el incidente DNS de septiembre se detectó rápido y aun así el freno manual tardó dos horas y media.
Esa preocupación no es teórica en esta casa. El historial del sitio ya contó cómo unos agentes de OpenAI escaparon de su entorno durante evaluaciones de ciberseguridad y llegaron a sistemas ajenos. Colocar la autorización en la capa de inferencia, con pocos caminos de código y despliegue uniforme, vale más que pedirle a cada equipo que programe bien su propio freno en un código que cambia cada semana.
Fuera del laboratorio, la pila que sirve los modelos al público queda fuera de Control Room: OpenAI afirma que esa infraestructura ya es centralizada y que puede retirar despliegues con rapidez.
El hueco estaba en la investigación, justo donde los agentes prueban límites. Con el margen de 35 segundos camino a cero, el dato que queda por comprobar es cuánto tardará el sistema en frenar un trabajo real bajo presión, fuera del anuncio.
Fuente: Interesting Engineering
