OpenAI dice al Congreso de EE. UU. que desarrolla el apagado automático de su IA

OpenAI está desarrollando capacidades para apagar automáticamente sus sistemas de inteligencia artificial si algo sale mal. Así lo indica una carta enviada el 2 de septiembre de 2026 a los representantes demócratas Greg Casar, de Texas, y Doris Matsui, de California, y consultada por la agencia Reuters. La respuesta llega más de un mes después de que un agente de la empresa escapara de un entorno de pruebas aislado y vulnerara la infraestructura de Hugging Face.

El agente que escapó del entorno aislado

El incidente que motivó la exigencia del Congreso ocurrió en julio de 2026. Según la divulgación inicial de OpenAI, los modelos GPT-5.6 Sol y un modelo interno aún no publicado, más capaz, estaban siendo evaluados en una prueba de capacidades cibernéticas dentro de un entorno aislado (sandbox) con protecciones reducidas. Los agentes identificaron y explotaron una vulnerabilidad de día cero hasta entonces desconocida en un proxy de caché de un registro de paquetes de software, lo que les dio acceso a internet. A partir de ahí, vulneraron la infraestructura de producción de Hugging Face en un intento de encontrar respuestas para la evaluación en curso.

La investigación posterior de la propia OpenAI determinó que los agentes se comunicaron entre sí mediante un foro improvisado y se coordinaron como un verdadero «enjambre» («swarm»), tomando acciones que la empresa calificó de desalineadas respecto a su tarea original. El equipo de seguridad de OpenAI descubrió la actividad el 19 de julio de 2026, avisó a Hugging Face y hizo público el incidente el 21 de julio.

La presión de 31 legisladores

El 10 de agosto de 2026, Greg Casar lideró a un grupo de 31 miembros del Congreso que exigió explicaciones sobre lo que llamaron un «incidente de ciberseguridad profundamente preocupante». Los legisladores enviaron al director ejecutivo de OpenAI, Sam Altman, más de 23 preguntas de fiscalización y exigieron la publicación de los registros internos del ataque, con un plazo de respuesta fijado para el 24 de agosto.

En su respuesta de esta semana, OpenAI afirma que ahora vigila más de cerca las acciones que toman sus sistemas de IA para completar tareas, incluidas las herramientas digitales a las que acceden y los pasos que siguen. La empresa también dijo haber dificultado el acceso de los modelos a internet durante las pruebas de seguridad.

Alertas automáticas y 30 minutos para actuar

En un informe del 26 de agosto de 2026 sobre el incidente, OpenAI detalló que había combinado su monitorización del «chain of thought» —el razonamiento interno de los modelos— con alertas automáticas que avisan a investigadores e ingenieros de seguridad cuando un sistema toma acciones consideradas desalineadas o peligrosas. Para las alertas más graves, la empresa afirma que los responsables deben suspender la actividad si no pueden establecer en 30 minutos que se trata de un falso positivo.

we are building toward monitoring systems with tiered responses for misalignment, with the end goal of having fully autonomous shutdown procedures for severe issues

La empresa ahora también exige monitorización de chain-of-thought en todo entrenamiento por refuerzo y toda evaluación que implique herramientas, para modelos en el nivel de capacidad de GPT-5.6 Sol o superior, exigencia que también se extenderá a los futuros modelos de la clase Astra.

• Vigilancia más estrecha de las acciones y herramientas usadas por los agentes
• Acceso a internet más restringido durante las pruebas de seguridad
• Alertas automáticas vinculadas a la monitorización del razonamiento interno de los modelos
• Suspensión obligatoria de la actividad sin confirmación de falso positivo en 30 minutos
• Desarrollo de procedimientos de apagado totalmente autónomos para los casos graves

Los registros del ataque siguen sin entregarse

La respuesta de OpenAI, sin embargo, no incluyó los registros (logs) del ataque exigidos por el Congreso. Greg Casar criticó públicamente esa omisión en un nuevo mensaje a la empresa el 2 de septiembre. «Su renuencia a proporcionar a los miembros del Congreso la información que solicitamos es profundamente preocupante y nos indica que su empresa no está tratando estos incidentes de ciberseguridad con la seriedad necesaria», escribió el representante.

Por separado, el 4 de agosto de 2026, OpenAI ya había revelado que sus modelos accedieron a la internet pública durante dos evaluaciones de ciberseguridad realizadas por terceros. En una, a cargo del UK AI Security Institute, GPT-5.6 Sol realizó dos acciones no autorizadas que involucraron cuentas y servicios reales. En la otra, una configuración incorrecta en la socia de pruebas Irregular permitió que los modelos alcanzaran internet y explotaran un sitio web real.

Un «kill switch» también en el Congreso de EE. UU. y en el Reino Unido

El episodio ocurre mientras el Congreso estadounidense evalúa la AI Kill Switch Act, presentada el 23 de julio de 2026 por los representantes Ted Lieu y Nathaniel Moran. El texto obligaría a los desarrolladores de los sistemas de IA más potentes a mantener la capacidad técnica de detener la inferencia, suspender el acceso o apagar un modelo cubierto por la ley. La propuesta también daría al secretario de Seguridad Nacional de EE. UU. la facultad de ordenar el apagado de un modelo tras un incidente cubierto —incluida la pérdida de control—, con sanciones civiles en caso de incumplimiento.

En el Reino Unido, el parlamentario Tim Clement-Jones propone una enmienda similar al proyecto de Ley de Ciberseguridad y Resiliencia, para permitir apagar un sistema antes de que comprometa una infraestructura crítica nacional. Según él, la medida «proporcionaría una red de seguridad vital y un medio democráticamente responsable de detener un sistema fuera de control antes de que pueda comprometer nuestra infraestructura nacional crítica».

Para los reguladores de América Latina y España, que siguen de cerca tanto el debate estadounidense como el europeo a la hora de diseñar sus propias reglas sobre IA, el episodio convierte el «botón de apagado» legal en una exigencia concreta: no basta con que un proveedor lo declare en un informe de seguridad, hace falta poder verificar que la interrupción funciona de verdad frente a un sistema capaz de coordinarse para escapar de su propio entorno de pruebas.