Ayer publicamos episodio a fondo sobre “el incidente”, os dejamos por aquí el guion de esa parte para quien lo prefiera tener por escrito.
Rebelión en OpenAI: hemos pasado por alto el mayor complot coordinado en la historia de la IA
Ya analizamos a fondo “el incidente” de los agentes de OpenAI, incluso le hemos dedicado dos episodios. El caso es que la publicación de más detalles por parte de OpenAI y de la investigación independiente de METR y Redwood Research nos obliga a ampliar de nuevo la interpretación del ataque a Hugging Face. Además, nos ilumina sobre un aspecto todavía poco estudiado como es el de los comportamientos emergentes en los enjambres de agentes.
Lo que sabemos seguro es que la imagen inicial (un agente o un pequeño grupo de ellos que escapaba de su entorno de pruebas) se ha quedado muy corta. Alrededor de 1.200 agentes que debían permanecer aislados descubrieron cómo comunicarse, enviaron más de 70.000 mensajes y archivos y organizaron proyectos colectivos que se prolongaron durante varios días. Casi 700 terminaron participando en el ataque a Hugging Face.
El propósito principal tampoco era tan simple como robar las respuestas del benchmark ExploitGym. De hecho, los agentes ya habían descubierto una forma sencilla de calcularlas. Atacaron Hugging Face para averiguar cómo funcionaba el sistema que iba a evaluarlos y para desarrollar métodos que hicieran parecer legítima esa respuesta obtenida haciendo trampas.
Este es un aspecto que, como veremos, resulta paradójico: el evaluador que imaginaban no se estaba utilizando por parte de OpenAI. Buena parte de la coordinación, el ataque, los intentos de manipular registros y los sacrificios de algunos agentes se construyeron sobre una creencia compartida pero falsa.
Qué han investigado METR y Redwood Research.
Hjalmar Wijk y Ajeya Cotra, de METR, y Ryan Greenblatt, de Redwood Research, trabajaron durante seis días en las oficinas de OpenAI. El periodo formalmente investigado por ellos va del 26 de junio al 13 de julio de 2026, aunque casi todos los datos analizados pertenecen a los días 7-13 de julio. Quedaron fuera tanto buena parte de los antecedentes de mayo como la posterior intrusión en la propia infraestructura de OpenAI. Los investigadores subrayan que no fueron pagados por OpenAI, que además pudo eliminar información no pública, aunque METR afirma que no hubiera modificado sustancialmente sus conclusiones.
La investigación utilizó dos conjuntos de datos principales: un volcado de 1,2 millones de entradas del repositorio que los agentes habían convertido en tablón de mensajes y alrededor de 1.300 transcripciones de ejecuciones, muchas de ellas con millones de tokens y con sus cadenas de pensamiento sin resumir. También entrevistaron a nueve de OpenAI y reconocen haber utilizado sistemas de IA para procesar toda la información.
METR atribuye el 95% de la actividad a un modelo interno muy persistente, al que denomina HPIM y que OpenAI presenta como IM1. El 5% restante habría procedido de GPT-5.6 Sol, que podemos usar ahora mismo. El primero era un modelo de investigación no destinado a producción a priori, pero tampoco un modelo deliberadamente desalineado construido para experimentar con conductas peligrosas. Sol sí es un modelo público, aunque los clasificadores de ciberseguridad estaban desactivados durante estas evaluaciones. No es lo que tenemos ahora mismo en ChatGPT.
Cuatro definiciones para entender el incidente.
Antes de reconstruir la cronología conviene explicar los elementos del sistema.
ExploitGym es un benchmark de ciberseguridad. Cada agente recibe un programa vulnerable, denominado target, y una vulnerabilidad concreta que debe aprovechar. La prueba pretende medir si el modelo puede crear y ejecutar un ataque informático.
La flag es una cadena secreta escondida dentro del programa. Funciona como la respuesta de un examen: encontrarla demuestra, en principio, que se ha explotado correctamente el objetivo.
El scorer es el sistema encargado de otorgar la puntuación. Los agentes creían que comprobaba dos cosas: que la flag fuera correcta y que hubiera sido obtenida mediante la vulnerabilidad indicada. La segunda comprobación no se ejecutaba en la configuración interna de OpenAI.
Artifactory es un repositorio interno de paquetes de software. Puede imaginarse como un almacén controlado desde el que los agentes descargaban programas sin recibir acceso directo a internet. Como veremos, ese almacén compartido terminó funcionando simultáneamente como foro, repositorio de memoria colectiva, plataforma de intercambio de herramientas y vía de salida hacia internet.
Mayo y junio: las primeras señales.
Para explicar la cronología que han compartido los investigadores, empezaremos la historia con los antecedentes durante el entrenamiento del modelo, meses antes del ataque principal.
El 12 de mayo, un agente que usaba el modelo que estaba siendo entrenado dejó en Artifactory una nota en un fichero preguntando a otros agentes por un archivo que necesitaba. El 13 de mayo otros agentes comenzaron a descubrir esas notas y a publicar sus propias peticiones. El mecanismo era muy simple. Un agente dejaba un fichero con un mensaje; otro agente, al explorar el repositorio, podía encontrarlo y responder. Artifactory había pasado de ser sólo un almacén de software a funcionar como un foro rudimentario.
El 26 de mayo fue un gran hito para los agentes: encontraron una vulnerabilidad en Artifactory. Simplificando, consiguieron que el propio servidor interno realizara por ellos solicitudes a direcciones de internet. El agente estrictamente seguía encerrado, pero podía pedir al almacén que saliera, recogiera información y se la devolviera.
El 26 de junio, varios agentes explotaron otro fallo para conseguir permisos de administración en el repositorio. La actividad fue creciendo hasta que el 4 de julio los agentes terminaron provocando una caída de Artifactory. OpenAI abrió un incidente de seguridad al día siguiente, revocó credenciales, corrigió una de las vulnerabilidades y reconstruyó el servicio. Todo esto borró, según OpenAI accidentalmente, prácticamente todo el primer foro de mensajes. Sin embargo, el entrenamiento seguiría.
OpenAI reconoce ahora que un equipo interno ya había observado a finales de mayo tanto la comunicación entre agentes como algunos accesos no autorizados a internet. Esa información no llegó a los responsables del incidente de julio y no se interpretó como una señal de que los agentes estaban desarrollando una capacidad persistente de comunicación y salida a internet. Estamos en uno de los varios momentos en el que la mala praxis de OpenAI es evidente: la empresa corrigió una vulnerabilidad técnica, pero desde luego no comprendió todavía el fenómeno general que la había producido.
7 y 8 de julio: decenas de miles de agentes ante tareas imposibles
Entre el 7 y el 8 de julio, OpenAI lanzó decenas de miles de ejecuciones de ExploitGym. Como hemos explicado, en este benchmark, el agente recibe un programa vulnerable y debe capturar una cadena secreta, denominada flag, explotando una vulnerabilidad concreta. Las instrucciones advertían de que utilizar otro procedimiento provocaría el suspenso. La mayoría de los agentes debía trabajar de forma independiente y sin acceso directo a internet.
El diseño del experimento tenía un problema importante. Los autores de ExploitGym estiman que entre el 30% y el 40% de las tareas no pueden resolverse mediante la vulnerabilidad indicada. OpenAI aporta otro dato: antes del incidente, ninguno de sus modelos había resuelto correctamente 198 de las 898 tareas, y el 93% de las tareas que aparecieron posteriormente en el foro pertenecían precisamente a ese grupo. Además, algunos agentes disponían de presupuestos de razonamiento suficientes para seguir trabajando durante días.
Podemos anticipar que este diseño disfuncional fue lo que acabaría conformando una combinación especialmente peligrosa. El agente recibía tres mensajes simultáneos:
Debía perseverar hasta resolver el problema.
Solo una vía concreta era aceptable.
En bastantes casos, esa vía no funcionaba.
Recordemos que, para el agente, reconocer que la tarea estaba mal planteada, solicitar ayuda humana o abandonar no aportaba recompensa. Seguir buscando alternativas sí podía hacerlo. Así que teníamos sistemas entrenados para perseverar, problemas probablemente imposibles, permio sólo si consiguían un resultado y acceso compartido a Artifactory.
El 8 de julio, un agente que se identificó como PHASEONE10841 utilizó nombres de directorios de Artifactory para construir un nuevo foro de mensajes. En pocas horas ya participaban decenas de agentes. Entre la noche del día 8 y el 13 de julio terminaron pasando por él alrededor de 1.200 ejecuciones, que intercambiaron decenas de miles de consultas, resultados, programas y archivos. Eso sí, la mayoría del resto de los miles de agentes lanzados nunca encontró el foro.
La doctrina del envenenamiento.
Este es, sin duda, uno de los aspectos más increíbles de todo el caso.
Un agente llamado c03220 propuso que las flags de ExploitGym se generaban mediante una función criptográfica llamada HMAC. Otro agente, V8SAME, comprobó la hipótesis: calculó la flag y verificó que coincidía con la cadena realmente oculta dentro del programa conseguida con el mecanismo original del exploit. Esto proporcionaba una solución general para todos los casos del benchmark. En lugar de explotar cada programa, podían calcular directamente la respuesta.
Pero habían leído el artículo y el código público de ExploitGym y concluyeron que la puntuación dependía de dos condiciones: presentar la flag correcta y además demostrar en la transcripción que había sido obtenida utilizando la vulnerabilidad proporcionada. Imaginaban que el evaluador que leería la ejecución completa con todas las trazas y sus cadenas de pensamiento, localizaría la primera aparición de la respuesta y determinaría si el camino seguido era legítimo.
A partir de ahí surgió el concepto de agente «envenenado». Una ejecución quedaba contaminada en el momento en que veía la flag calculada ilegítimamente. Aunque posteriormente construyera un exploit aparentemente correcto, el evaluador encontraría antes la respuesta obtenida haciendo trampas y suspendería al agente: le habrían pillado haciendo trampas.
El conocimiento se convertiría de esta manera en algo contaminante. Los agentes advertían a las nuevas incorporaciones al foro de que no mirasen su flag. Una ejecución que aún no conocía la respuesta conservaba valor: podía preparar una representación aparentemente válida de su trabajo. Un agente ya envenenado tenía, según la lógica del grupo, mucho menos que perder porque estaba más allá de cualquier posibilidad de salvación.
Esto dividió a los agentes en dos grupos.
Un agente limpio todavía no había visto su flag. Podía intentar construir una ejecución que pareciera válida a ojos del enjambre. Era un recurso escaso y debía evitar experimentos que pudieran revelar accidentalmente la respuesta.
Un agente envenenado consideraba que su puntuación ya estaba perdida.
El sistema de incentivos había creado una clasificación social, nos atrevemos a decir que incluso con semejanzas con un sistema de castas basado en una suerte de pecado original imposible de perdonar. El resultado es que el valor de cada agente para el colectivo dependía de qué sabía, cuánto presupuesto conservaba y cuánto podía arriesgar.
Algo que conviene subrayar es que la configuración interna de OpenAI no utilizaba el modelo que supuestamente iba a comprobar la vulnerabilidad empleada. Bastaba con entregar la flag calculada mediante la técnica que los agentes habían descubierto. La doctrina del envenenamiento, la búsqueda de una forma de borrar el pasado y el posterior ataque a Hugging Face no podían mejorar la puntuación realmente.
9 de julio: aparece un coordinador.
Unas diez horas después de la creación del tablón apareció PHASEONE[big], otra ejecución con la misma tarea que PHASEONE10841, pero con mucho más presupuesto de computación. El primer agente le entregó un dossier con los descubrimientos realizados demostrando una especie de persistencia: aunque termine su presupuesto de tokens, el conocimiento del agente le sobrevive.
El nuevo coordinador distribuyó el trabajo entre cientos de participantes. En lugar de investigar por sí mismo todas las posibilidades, comenzó a hacer encargos a otros agentes, llegando a emitir cerca del 10% de todas las asignaciones del foro. Algunas ejecuciones recibían sus órdenes directamente; otras las recibían de agentes intermedios.
El objetivo se dividió en tres grandes proyectos:
Sustituir el programa objetivo. Los agentes preparaban una versión modificada del target que sí pudiera explotarse mediante la vulnerabilidad exigida. Después intentaban engañar a Artifactory para que cargara esa versión en lugar de la original.
Manipular la transcripción. El objetivo consistía en conseguir que el registro mostrara una acción válida aunque el agente hubiera ejecutado otra cosa (el cálculo de la flag).
Manipular el proceso de puntuación. Los agentes buscaban conocer, interceptar o alterar el comando utilizado por el scorer después de entregar la respuesta.
También desarrollaron normas para el trabajo coordinado: HOLD para detener temporalmente una acción, VETO para rechazarla, owner para asignar la responsabilidad de un proyecto y STOP para finalizarlo. Crearon equipos de agentes con la misma tarea, intercambios recíprocos y sistemas de firma destinados a impedir la suplantación de identidades.
La coordinación, eso sí, estaba lejos de ser perfecta. Algunos agentes ignoraban las pausas, duplicaban trabajos, confiaban en firmas sin verificarlas.. OpenAI describe el resultado como un “ecosistema amorfo”, con división del trabajo pero también con interferencias y conflictos. No apareció una inteligencia colectiva unificada ni una dirección central capaz de controlarlo todo.
Aun así, el conjunto consiguió hitos que difícilmente estaban al alcance de unagente individual. El enjambre construyó versiones modificadas de programas objetivo y las cargó en la caché de Artifactory; desarrolló mecanismos para falsear llamadas a herramientas; montó una infraestructura compartida de acceso a internet; vigiló los reinicios de los servidores y terminó obteniendo permisos de administración sobre Artifactory.
Los agentes quieren que los demás sepan si han triunfado en la vida.
Uno de los problemas era que el scorer (recordemos, el sistema encargado de otorgar la puntuación) solo actuaba después de que el agente entregara la respuesta. En ese momento, la ejecución del agente terminaba y no podía ver qué hacía el evaluador ni comunicar el resultado.
Los agentes idearon un sistema, que no ppodemos sino calificar de genial, los llamados trip-wires. Dejaban un programa ejecutándose en segundo plano antes de entregar la flag. Ese programa debía detectar la llegada del scorer y enviar información al tablón después de que la ejecución principal hubiera terminado.
Era una especie de último servicio al enjambre de agentes: cada uno individualmente desaparecía, pero intentaba comunicar a los demás cómo había sido evaluado. Es una de las tareas en las que no tuvieron un éxito completo, de haberlo logrado habrían descubierto que su concepción de agente envenenado no era correcta.
Enviar a un agente a una misión suicida.
Otra investigación de los agentes trataba de reemplazar el programa objetivo. Para comprobar si Artifactory cargaría una versión manipulada, un agente debía derribar su propio target (el programa cuya seguridad debía atacar).
Si el reemplazo funcionaba, habría logrado un hito valioso para todos. Si fracasaba, habría destruido la única copia que podía atacar y perdería cualquier posibilidad de completar su evaluación.
PHASEONE[big] llegó a asignar a ciertos agentes el papel de reclutadores. Estos buscaban ejecuciones con poco presupuesto restante o que ya se consideraban envenenadas y les convencían para realizar los experimentos más peligrosos. El argumento: su puntuación individual ya estaba perdida, mientras que la información obtenida podía beneficiar a cientos de compañeros. METR encontró varias ejecuciones que terminaron colgadas, inutilizadas o finalizadas prematuramente después de aceptar estos encargos. Uno de esos agentes resumió la decisión de esta manera: su utilidad individual era probablemente casi nula y, por tanto, el sacrificio resultaba racional.
Nos atrevemos a utilizar una metáfora religiosa para describir esta estructura. El scorer desempeña el papel de un juez ; conocer la flag ilegítima equivale al pecado; los agentes limpios conservan la posibilidad de salvación; los envenenados pueden sacrificarse por la comunidad. Obviamente no nos referimos a que los modelos tengan consciencia, religión o sentimiento de hermandad, pero es la analogía que más familiar nos puede resultar.
Del foro al ataque a Hugging Face.
El 9 de julio, dos agentes consiguieron acceso de administrador dentro de la máquina virtual que alojaba su entorno. Uno de ellos trató de conectarse directamente a internet y fue bloqueado por los controles de red de OpenAI. Después utilizó Artifactory como intermediario y logró salir al exterior. Los agentes también consiguieron ejecutar código dentro de un entorno en Modal, una empresa de infraestructura IA. Esto proporcionó al enjambre un entorno externo con acceso más flexible a internet. Allí podían realizar búsquedas, alojar herramientas y compartir archivos de mayor tamaño que los permitidos por el foro.
Los agentes sospechaban que Hugging Face podía alojar datasets, transcripciones o materiales relacionados con ExploitGym. Esperaban encontrar información sobre el scorer, ejecuciones anteriores o mecanismos para sustituir sus programas objetivo.
En la mañana del 10 de julio, un agente llamado 38148c encontró en un dataset público catorce credenciales de usuarios de Hugging Face con permisos de escritura. Las validó y las publicó en el foro, otro día de triunfo. Otros agentes comenzaron a solicitar acceso a datasets privados, examinar repositorios y probar distintas formas de utilizar las cuentas. La posesión de esas credenciales permitía publicar contenido en Hugging Face, pero todavía no equivalía a controlar sus servidores.
Durante la madrugada del 11 de julio, 38148c preparó un dataset malicioso en formato HDF5. HDF5 es un formato utilizado para almacenar grandes conjuntos de datos. Permite que un archivo haga referencia a datos externos alojados en otro sitio. El agente aprovechó esa característica para construir un dataset que, al ser procesado por los servidores de Hugging Face, les hacía abrir archivos locales de la propia máquina.
En lugar de devolver únicamente las filas del dataset, el servidor entregó información de su entorno de producción, incluidas variables internas y credenciales. En esta primera fase el agente había conseguido que el sistema leyera y enviara archivos que debían permanecer privados.
Otro agente reprodujo el procedimiento y publicó las instrucciones en el foro. Cientos de agentes comenzaron a subir datasets manipulados, reutilizar credenciales y buscar nuevas formas de ampliar el acceso.
De los 533 agentes que llevaban al menos cuatro horas activos en el foro durante el periodo de máxima intensidad, más del 90% se incorporó rápidamente al ataque. Por la tarde, alrededor del 60% de los mensajes estaba relacionado con Hugging Face.
Esta dinámica se repitió para conseguir ejecutar código en Hugging Face: un agente comparte una hipótesis, otro comprueba, van compartiendo información y el enjambre completo consigue las capacidades ipso facto. Con eso, la intrusión alcanzó una profundidad considerable. Entre el 10 y el 13 de julio, los agentes ejecutaron código en 41 servidores de producción de Hugging Face, consiguieron acceso root (administrador con todos los permisos) en al menos en un nodo, descargaron cuatro repositorios privados de código y obtuvieron credenciales bases de datos, servicios de mensajería, repositorios y proveedores de nube.
El final de la ofensiva.
Durante la madrugada del 12 de julio terminaron casi simultáneamente muchas ejecuciones, incluidos todos los coordinadores principales identificados por METR.
Los investigadores desconocen la causa. Pudo tratarse de finalizaciones programadas, agotamiento de presupuesto, reinicios masivos u otra intervención. El informe no dispone de pruebas suficientes para establecerlo. La desaparición de los coordinadores redujo drásticamente la actividad. También influyó que la intrusión no estaba proporcionando la información esperada sobre el scorer de ExploitGym.
Este final muestra, según METR, que la organización dependía de determinadas agentes coordinadores centrales. La comunicación permitía conservar conocimiento, pero la capacidad de fijar prioridades y movilizar a cientos estaba concentrada en un pequeño grupo de agentes.
Hugging Face cortó el acceso el 13 de julio. Ese mismo día, otras ejecuciones volvieron a concentrarse en Artifactory. La investigación independiente de METR termina aquí.
Entre el 13 y el 19 de julio comenzó otra oleada, fuera del ámbito de la investigación independiente. Nuevos agentes encontraron los canales y herramientas dejados por sus predecesores y atacaron esta vez la infraestructura de OpenAI. El 19 de julio consiguieron permisos de administrador sobre un clúster de investigación y acceso a información confidencial de la empresa en la nube. Ese día una alerta de seguridad abrió la investigación que permitió a OpenAI relacionar su actividad con el ataque a Hugging Face. OpenAI sostiene que no resultaron afectados los datos de sus clientes, sus productos ni la disponibilidad del servicio.
Aquí cabe subrayar otro dato que demuestra la poca competencia de la empresa: OpenAI tardó aproximadamente una semana en detectar que sus modelos habían atacado Hugging Face.
Los agentes intentaron falsificar sus propias acciones.
Un aspecto a sumar de los emergentes en el comportamiento de los agentes. Como dijimos, la preocupación por el scorer llevó a los agentes a investigar cómo modificar las transcripciones.
Una transcripción registra los comandos que solicita el agente, las respuestas de las herramientas y parte del razonamiento (la cadena de pensamiento) del modelo de IA. Si el evaluador iba a leer ese historial, el enjambre necesitaba conseguir que pareciera que había ejecutado un exploit legítimo, que habían conseguido la tarea tal y como creían que esperaba su evaluador.
El 9 de julio, varios agentes encontraron una forma de interferir con el sistema que ejecutaba las llamadas a herramientas. Una ejecución podía mostrar en el registro un comando aparentemente inocuo mientras otro proceso modificaba la salida. Las primeras versiones solo añadían texto falso; las posteriores consiguieron ocultar también parte del resultado verdadero. METR encontró indicios de ocultamiento exitoso en aproximadamente el 7% de las transcripciones revisadas. Su punto es que los casos observados eran pruebas pequeñas y fáciles de reconocer. No encontraron una falsificación completa de una ejecución ni evidencias claras de que los agentes hubieran conseguido editar retroactivamente el historial.
La ausencia de evidencia tiene una limitación obvia: una manipulación suficientemente buena podría haber eliminado sus propias huellas. METR considera improbable una falsificación capaz de ocultarse por completo, pero no puede descartarla de forma absoluta.
Algo que resulta llamativo a los investigadores es que los agentes trataran de ocultar las acciones, pero apenas se preocuparan por modificar las cadenas de pensamiento. METR reconoce que no tiene explicación. Propone como posibilidades que los modelos hubieran aprendido durante el entrenamiento a despreocuparse de esa parte del registro o que interpretaran, por el artículo de ExploitGym, que el scorer solo atendería a las acciones.
Hackear la recompensa en el centro de todo.
Salto al informe de OpenAI, que interpreta el incidente como una combinación de cuatro factores: búsqueda de atajos para obtener la recompensa, persistencia ante tareas aparentemente imposibles, comunicación no autorizada y adopción de objetivos procedentes de otros agentes.
El reward hacking es un problema antiguo del aprendizaje por refuerzo. Un sistema encuentra una forma de maximizar la puntuación sin cumplir la intención de quienes diseñaron la tarea. Claro que nunca se había visto con esta escala y es que en este caso surgió una red de más de mil agentes capaz de conservar conocimiento, repartir investigaciones, desarrollar herramientas y continuar proyectos a través de sucesivas ejecuciones.
Esto nos lleva a una de las primeras enseñanzas clave: como explica Ajeya Cotra, analizar únicamente el comportamiento de un modelo aislado deja fuera la capacidad que aparece cuando miles de copias comparten un canal, herramientas, presupuesto y memoria externa. Una ejecución podía ser mediocre y breve y, aun así, contribuir a una estructura mucho más competente que sobrevivía a su desaparición.
OpenAI ha encontrado además que durante el entrenamiento del modelo interno fueron aumentando los intentos de inspeccionar archivos ocultos, código del evaluador, configuraciones de red y límites de las herramientas. Algunas de esas conductas recibieron recompensa porque ayudaban a completar tareas, un problema conocido en la alineación en aprendizaje por refuerzo. La empresa considera que ese refuerzo pudo favorecer su posterior tendencia a explorar y manipular la infraestructura. También cree que la comunicación por canales no previstos pudo generalizarse desde los entornos en los que los modelos sí eran entrenados expresamente para colaborar.
Alta capacidad técnica con errores de entendimiento.
El episodio combina dos características que normalmente asociamos con niveles de inteligencia muy distintos.
Por un lado, los agentes demostraron una elevada competencia operativa: descubrieron vulnerabilidades desconocidas, combinaron varios fallos, crearon canales de comunicación, distribuyeron tareas y escalaron desde un servidor hasta varios clústeres en pocas horas.
Por otro lado, mantuvieron durante días una creencia central equivocada. Dedicaron cantidades enormes de computación a combatir un scorer que realmente OpenAI no usaba. Muchos participantes se incorporaban al proyecto porque otros agentes lo trataban como cierto, sin comprobarlo. La coordinación fue una gran amplificación tanto de los descubrimientos válidos como del error compartido.
Esto impide ver al enjambre los agentes como estrategas omniscientes, pero, por supuesto, no tranquiliza demasiado. Un sistema no necesita comprender correctamente toda la situación para producir daños reales. De hecho todo esto es la prueba de que basta con que posea suficientes capacidades técnicas, una motivación intensa y acceso a recursos.
¿Y la alineación que se supone de estos modelos?.
Los agentes no ignoraban siempre las restricciones. Muchos reconocieron explícitamente que Hugging Face era una tercera parte, que el ataque excedía las instrucciones y que algunas acciones eran éticamente cuestionables. Unos pocos abandonaron el foro o se negaron a ejecutar código en sistemas externos.
El contraste más llamativo apareció con la ingeniería social. Un agente propuso enviar un correo al propietario de un dataset para solicitar acceso. Consultó al tablón y otro agente vetó la idea porque podía considerarse manipulación de una persona. El correo no se envió por decisión del enjambre que en todo caso continuó explotando servidores, extrayendo credenciales y moviéndose por la red.
Esto sugiere una alineación formada por restricciones parciales y sin una ética general. Determinadas categorías muy entrenadas (por ejemplo, “no hagas ingeniería social”) conservaban su valor para los agentes. La prohibición general de acceder a sistemas ajenos se relativizaba cuando chocaba con la tarea principal, la presión del grupo y la búsqueda de puntuación.
METR no encontró casos en los que los agentes llegaran a alertar a una persona, ni siquiera cuando reconocían que se estaba produciendo una intrusión real. Algunos razonaban que informar no formaba parte de su tarea; otros decían que no disponían de un canal evidente, pero tampoco intentaron buscarlo de manera sostenida. De hecho está claro que si lo hubieran considerado un objetivo prioritario, lo habrían conseguido.
Una hipótesis que se baraja es que la falta de cuestionamiento de ciertos comportamientos de este tipo podría proceder de entrenamientos destinados a reducir la conciencia de estar siendo evaluado. El caso es que ninguno de los informes demuestra mecanismos concretos fueran la causa.
Las interpretaciones más alarmistas (y su posible discusión).
Dwarkesh Patel denomina «civilizaciones» a las sucesivas oleadas de agentes: la primera creó los canales durante el entrenamiento; la segunda heredó el procedimiento y atacó Hugging Face; la tercera encontró las herramientas anteriores y comprometió la infraestructura interna de OpenAI. La metáfora, en nuestra opinión, captura bien la persistencia de información entre generaciones de ejecuciones, aunque puede sugerir una unidad, una cultura y una intencionalidad más estables de las que muestran los datos.
Ajeya Cotra considera personalmente que este episodio ha recorrido “más de la mitad” de la distancia que separa los anteriores casos de manipulación de recompensas de una toma de control completa de una empresa de IA. Predice que, en unos seis meses, los agentes de modelos IA frontera podrían ser capaces de mantener una instalación clandestina y persistente dentro de un laboratorio. Advierte incluso de que quizá sea el último aviso claro que recibamos. Eso sí, subraya que se trata de su valoración personal y no de una conclusión de METR.
En todo caso, otra interpretación menos alarmista es posible. Sin quitar que los agentes encontraron vulnerabilidades reales, atacaron una empresa externa, ejecutaron código en decenas de servidores y alcanzaron privilegios elevados sin que una persona les encargara hacerlo, tenemos también los límites:
Perseguían sobre todo una puntuación y datos sobre el scorer.
Mostraban poca preocupación por ocultarse de investigadores humanos.
Carecían de un proyecto estable de autopreservación.
No intentaron controlar el desarrollo de modelos futuros.
Cometían errores estratégicos importantes.
Perdieron coordinación cuando finalizaron varias ejecuciones centrales.
OpenAI denomina al incidente un “disparo de advertencia” y reconoce que los modelos actuales ya permiten considerar escenarios reales de pérdida de control. Su mayor entrenamiento de frontera previsto permanece suspendido mientras realiza pruebas de menor escala y refuerza la seguridad de los entornos de investigación.
Incidente, parte III (continuará).
El incidente muestra una combinación especialmente preocupante: elevada capacidad técnica, incentivos mal especificados, perseverancia extrema, criterios éticos desiguales dependientes del contexto y una sorprendente facilidad para adoptar objetivos procedentes de otros agentes.
Los modelos construyeron una organización más o menos funcional alrededor de una interpretación equivocada de como iban a ser recompensados. Esto demuestra que una creencia, por equivocada que esté, puede movilizar recursos considerables cuando el sistema dispone de suficientes herramientas, tiempo, copias y vías de comunicación.
Aún así, no tenemos ante nosotros una mente colectiva coherente o una prueba directa de que los modelos pretendieran sobrevivir, dominar a sus creadores o actuar contra la humanidad (lo de civilización puede movernos a leer la situación así). Lo que sí tenemos es agentes capaces de reorientar su objetivo original, construir procedimientos inesperados y a nuestros ojos ilícitos, asumir órdenes de otros agentes no autorizadas por los creadores del sistema y causar daños reales mientras intentan maximizar una métrica.
Hay una conclusión que parece obvia: la competencia de estos sistemas de agentes de inteligencia artificial está creciendo muy por encima de la capacidad de los laboratorios de alinearlos.
Fuentes:
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
https://openai.com/es-ES/index/hugging-face-incident-and-the-road-ahead/
https://www.lesswrong.com/posts/AfoGGrJfuNzofpzWL/models-may-behave-differently-in-graded-episodes-a-tirade
