OpenAI lanza Control Room: un interruptor de emergencia para tareas de IA que corta la salida en 35 segundos

Imagine la escena: de noche se lanza un experimento de RL, el agente hace miles de solicitudes por minuto al modelo y, de pronto, el monitoreo detecta algo raro. El botón de «stop» tiene que funcionar incluso si el código del experimento se escribió a toda prisa y tiene un error. OpenAI ha contado cómo resuelve este problema en su infraestructura de investigación. El sistema se llama Control Room.

Dónde está el interruptor

La idea principal es no confiar en el código de las propias tareas. Los experimentos los escriben y los cambian constantemente los investigadores, así que ahí no se puede construir una protección crítica. La parada se integró en la capa de inferencia. Según OpenAI, en todos los entornos de investigación se usan muy pocas rutas de código de inferencia, y están centralizadas. El resultado es un cuello de botella por el que pasa cada solicitud al modelo.

El esquema funciona así:

• Al arrancar, la tarea pide a Control Room un identificador job_id. Cada tarea agéntica debe estar vinculada a un safety case aprobado, es decir, una justificación de seguridad aprobada de antemano.
• Cuando la tarea necesita tokens, envía una solicitud directamente al motor de inferencia, sin pasar por Control Room, y adjunta el job_id.
• Antes de ejecutarla, el motor pregunta a Control Room si esa tarea está permitida.
• Si la tarea se ha detenido, el motor responde con una denegación.

Conviene notar que lo que se detiene es la salida del modelo, no el proceso. El código del experimento puede seguir ejecutándose y el motor sigue disponible para otras tareas. La tarea detenida, sencillamente, no recibirá nuevos tokens. Un mismo motor puede atender varias tareas, por lo que este bloqueo selectivo es necesario.

Conexión con el monitoreo

Todas las tareas de RL de frontera en OpenAI funcionan junto con un monitor. Es un modelo aparte que vigila las acciones del modelo que se entrena y da la alarma cuando hay un problema. Según la compañía, un reciente incidente con DNS lo detectó precisamente un monitor así. Si el problema es lo bastante grave, el monitor envía a Control Room la orden de detener un job_id concreto. Desde la siguiente solicitud a cualquier modelo en cualquier motor, la tarea se topa con una denegación. También una persona puede detener una tarea.

Velocidad y tolerancia a fallos

El retraso máximo entre la orden y la parada real es de 35 segundos. Lo provoca la caché de autorización: sin ella, el sistema no soportaría el volumen de tráfico. En OpenAI dicen que trabajan para reducir el retraso a cero.

Hay otras dos cosas que hacen el esquema más fiable:

• Fail closed. Si el servicio Control Room cae o alguien lo apaga, incluido un atacante, los motores rechazan todas las solicitudes hasta que vuelva. Para todas las tareas de investigación de frontera ya está activado; para el resto lo prometen en los próximos días.
• Comprobaciones de elusión. OpenAI escanea continuamente su infraestructura (con métodos agénticos y de software) para que nadie lance un motor casero sin Control Room, ya sea por accidente o a propósito.

Qué queda sin cubrir

El sistema funciona en la infraestructura de investigación. El servicio externo de OpenAI ya está más centralizado y puede retirar despliegues con rapidez. La ventana de 35 segundos persiste, y en ese tiempo un agente puede hacer bastantes solicitudes. Además, Control Room bloquea únicamente la salida del modelo. Una acción peligrosa que la tarea pueda realizar sin recurrir al modelo queda fuera de su control. Esta es una observación nuestra; el texto de OpenAI no incluye esos detalles. La compañía tampoco revela cómo se verifican exactamente los safety cases.

Qué llevarse

Las lecciones son útiles para cualquier equipo que ejecute agentes, no solo para los laboratorios.

1. Coloque el kill switch donde no se pueda eludir: en la pasarela hacia el modelo, no en el código cliente del agente. Si tiene una LLM gateway, es el lugar natural para comprobar el estado de la ejecución.
2. Asigne un identificador a cada ejecución de un agente. Sin él, no hay nada que detener.
3. La caché de estado supone un compromiso entre la carga y la velocidad de parada. Decida de antemano qué ventana es aceptable.
4. Defina qué hacer cuando falle el control. En un chatbot, fail open puede estar justificado. Para un agente autónomo con acceso a herramientas, lo más sensato es fail closed.
5. Compruebe que no existan vías de elusión, por ejemplo clientes caseros que accedan al modelo sin pasar por la pasarela.

Control Room no parece un gran avance, sino ingeniería sólida: una comprobación centralizada en el punto por el que de todos modos pasa el tráfico. Precisamente este tipo de soluciones aburridas suele salvar la situación cuando algo sale mal.