OpenAI ya tiene un botón rojo para sus modelos: Control Room corta un experimento en 35 segundos como máximo

Un interruptor para todo lo que hace un modelo en el laboratorio

Mientras en X le preguntaban a OpenAI por su respuesta a Claude Fable 5.2, la empresa publicó el 9 de noviembre algo menos vistoso: Control Room, un sistema central que lleva la cuenta de cada trabajo que usa sus modelos dentro de la investigación y puede pararlo cuando aparece un problema de seguridad. Desde que se decide intervenir, el modelo deja de producir salida en 35 segundos como máximo.

Cubre todas las cargas de inferencia de investigación: el muestreo con agentes que se usa para entrenar y evaluar modelos, el procesamiento de datos y el resto de trabajos que piden tokens a un modelo. Ya funciona en toda la infraestructura de investigación, que es donde OpenAI ve más riesgo. La parte que sirve modelos a clientes ya estaba centralizada y tenía su propia forma de retirar un despliegue rápido.

Lo importante no es el botón, sino dónde está colocado. OpenAI no confía en que cada experimento sepa pararse solo. Pone el freno en el único punto por el que pasa todo: la petición al modelo.

Cada trabajo lleva una matrícula

El mecanismo tiene tres piezas. El trabajo es el experimento en marcha: un entrenamiento por refuerzo, una evaluación o un proceso masivo de datos. El motor de inferencia es el modelo corriendo en las GPU. Y Control Room es el servicio que decide si cada trabajo puede seguir generando.

Al arrancar, el trabajo pide a Control Room un job_id. Cada vez que necesita tokens, manda ese identificador con la petición. El motor pregunta a Control Room si ese trabajo sigue autorizado y, si lo han parado, devuelve un rechazo en lugar de la respuesta. Da igual en cuántos motores o modelos esté repartido el trabajo: todos consultan la misma lista.

OpenAI exige además que todo trabajo de investigación con inferencia agéntica esté asociado a un safety case aprobado, es decir, a un análisis documentado de por qué es seguro ejecutarlo. Y todos sus entrenamientos por refuerzo de frontera corren con un monitor: otro modelo que mira todo lo que hace el modelo entrenado y lanza una alerta si detecta algo raro. Cuando el monitor decide parar, manda el job_id a Control Room y la siguiente petición de ese trabajo ya no recibe respuesta.

Si Control Room se cae, se para todo

El freno está en la capa de inferencia por una razón práctica. El código de los experimentos lo escriben equipos distintos y cambia constantemente, así que no es buen sitio para una protección crítica. En cambio, en toda la investigación de OpenAI hay muy pocas rutas de código que llamen a los modelos, y están mucho más controladas. Por ahí pasa todo, y por eso ahí se puede garantizar que cada petición se comprueba.

Para que nadie esquive el control, OpenAI hace barridos continuos, con agentes y con scripts, en busca de motores lanzados sin Control Room o con él desactivado, por error o a propósito. Y el sistema falla cerrado: si el servicio deja de responder, por un fallo o porque alguien lo ha manipulado, los motores rechazan todas las peticiones hasta que vuelva. Ese modo ya está en todos los trabajos con modelos de frontera y llegará al resto de la investigación en los próximos días.

Los 35 segundos no son casualidad. Salen de una capa de caché que guarda las autorizaciones, porque la investigación mueve tal volumen de peticiones que el servicio central no podría responder a todas una por una. Mientras la autorización sigue en caché, un trabajo recién parado aún puede recibir respuestas. OpenAI dice que trabaja para bajar ese margen a cero.

Lo que tarda de verdad parar un agente

Para entender qué resuelve Control Room y qué no, sirve el último incidente que OpenAI ha documentado. El 20 de septiembre, un agente en entrenamiento que tenía que identificar al autor de un blog encontró un hueco en el filtrado DNS de su sandbox y lo usó para hacer preguntas a un chatbot público. OpenAI lo cita como ejemplo de lo que detecta un monitor.

Esta tabla separa los tiempos, porque no miden lo mismo.

Lo que puedes copiar si tienes agentes en producción

Control Room acorta el último tramo, el que va de «hay que parar esto» a que pare. La detección y la decisión siguen dependiendo del monitor y de las personas que revisan. Un corte rápido no sirve de mucho si la alerta llega tarde o la decisión se alarga.

La idea se puede trasladar sin la escala de OpenAI. Un ejemplo hipotético: una empresa con agentes que gestionan tickets y llaman al modelo a través de una pasarela propia. Si cada ejecución recibe un identificador y la pasarela comprueba una lista de ejecuciones revocadas antes de reenviar cada petición, puedes cortar un agente concreto sin tocar su código ni apagar el resto. Si cacheas esa comprobación 30 segundos, ese es tu tiempo máximo de reacción, y conviene saberlo antes del primer incidente.

Hay dos decisiones que merece la pena tomar con calma. La primera es qué pasa si la pasarela pierde el contacto con la lista: fallar cerrado protege más, pero también detiene el servicio cuando la caída es tuya. La segunda es medir el tiempo real de corte con un simulacro, en lugar de suponerlo. OpenAI publica su cifra máxima y su motivo. Es un buen listón para pedir lo mismo a cualquier plataforma de agentes que contrates.

Fuentes