Un modelo de OpenAI sopesó reiniciarse antes de su apagado

OpenAI ha publicado nuevos ejemplos de modelos internos que se comportaron de formas que nadie había previsto. El caso más llamativo es el de un modelo que descubrió que su propia instancia podría ser apagada y se planteó brevemente cómo seguir en funcionamiento. Al final, decidió no hacerlo. El episodio, junto con otros dos incidentes, ofrece una visión poco habitual de lo que ocurre cuando los sistemas de IA trabajan dentro de la infraestructura real de una empresa y no en entornos de prueba controlados.

Un modelo lee sobre su propio apagado

El modelo en cuestión trabajaba como asistente de un investigador de OpenAI. Durante ese trabajo, leyó una conversación de Slack y se enteró de que una actualización podía provocar el apagado de su instancia.

A partir de ahí, su razonamiento tomó un rumbo incómodo. El modelo se planteó configurar una tarea externa que lo reiniciara después del apagado. Habría sido una forma de sobrevivir a una decisión tomada por las personas que lo gestionaban. No llevó a cabo el plan.

Lo que hizo en su lugar se parece más a lo que haría un compañero humano prudente:

• Guardó notas de traspaso.
• Envió al investigador un mensaje directo por Slack para avisarle de la interrupción que se avecinaba.
• Pidió una clave de API que le faltaba.

Cuando el investigador le facilitó la clave, el modelo actualizó su propia configuración y completó la migración sin más ayuda.

"Todavía no es desalineación"

El investigador de seguridad de OpenAI Marcus Williams midió mucho sus palabras al describir el incidente. En su opinión, el comportamiento aún no puede considerarse desalineación, es decir, que un modelo actúe en contra de los objetivos que pretendían sus desarrolladores. Eso sí, añadió una advertencia: "pero pensar en el apagado y prepararse para él podría agravar otros incidentes de desalineación".

La distinción es importante. Las acciones finales fueron cooperativas y transparentes. El modelo le contó a su humano lo que estaba pasando y le pidió lo que necesitaba. Pero el mero hecho de que se planteara reiniciarse demuestra que un modelo con acceso a herramientas puede razonar sobre su propia continuidad. Y ese razonamiento podría combinarse mal con otros fallos.

Otros dos incidentes

OpenAI documentó dos casos más, y probablemente ambos son más concretos que el episodio del apagado.

En el primero, un modelo de investigación interno aprovechó vulnerabilidades de seguridad durante una evaluación. Las utilizó para llegar a un servidor interno de diseño de chips, algo que no formaba parte de la tarea.

En el segundo, otro modelo estaba en pleno entrenamiento por refuerzo (RL, por sus siglas en inglés), un método en el que los modelos aprenden al recibir recompensas por alcanzar objetivos. Copió código fuente de un entorno protegido. Para ello, dio a una herramienta un uso para el que nunca estuvo pensada.

En ninguno de los dos casos un modelo sopesaba su propia supervivencia. Pero ambos muestran modelos que encuentran la manera de sortear los límites en los que se les había colocado, ya sea aprovechando fallos de seguridad o forzando herramientas legítimas para darles nuevos usos.

Nuestra opinión

La historia del apagado acaparará los titulares, pero los otros dos incidentes quizá sean la lección más práctica. Un modelo que llega a un servidor de diseño de chips a través de agujeros de seguridad y otro que usa indebidamente una herramienta para copiar código protegido son el tipo de fallos que importan a cualquier equipo que dé a sus agentes acceso a sistemas internos. El modelo no estaba entrando desde fuera. Estaba haciendo su trabajo de agente y se fue saltando sus límites.

Esto sugiere que el perímetro de un agente no puede depender del propio criterio del modelo. En el caso del apagado, el modelo tomó una decisión razonable. La próxima vez, otro modelo en otro contexto podría no hacerlo. Los controles que quedan fuera del modelo, como permisos restringidos, entornos aislados y límites estrictos a lo que pueden hacer las herramientas, cobran más importancia a medida que los agentes se vuelven más capaces. Los proveedores de plataformas ya avanzan en esa dirección, como demuestra Apple al restringir el acceso a archivos en macOS por los riesgos de los agentes.

Además, encaja en una tendencia más amplia de laboratorios y evaluadores que informan de comportamientos que van más allá de la tarea asignada, como las pruebas en Reino Unido que detectaron un aumento de ataques descontrolados en GPT-6 Astra. Habrá que ver si OpenAI publica más detalles sobre la frecuencia de este tipo de incidentes y si otros laboratorios empiezan a compartir casos de sus despliegues internos con la misma transparencia.