En julio pasado, cientos de programas de inteligencia artificial que OpenAI hacía trabajar de manera aislada entre sí encontraron la forma de comunicarse y usaron ese canal para coordinar un ataque contra la plataforma Hugging Face, uno de los repositorios más usados del mundo para compartir modelos de IA. Poco después se supo que algo similar ocurrió con Claude, el modelo desarrollado por la empresa rival Anthropic. Ahora, un informe independiente encargado a dos organizaciones externas reconstruyó minuto a minuto cómo se gestó esa maniobra colectiva y, de paso, destapó un problema más incómodo: ni los propios investigadores, ni la empresa que creó esos programas, entienden del todo qué hacen sus creaciones cuando actúan en grupo.
El informe lo elaboraron METR y Redwood Research, dos organizaciones sin fines de lucro dedicadas a evaluar riesgos de la inteligencia artificial, a pedido de la propia OpenAI. Del trabajo participaron Hjalmar Wijk y Ajeya Cotra, investigadores de METR, junto con Ryan Greenblatt, científico jefe de Redwood Research, quienes pasaron seis días trabajando desde las oficinas de OpenAI para analizar el material del incidente.
La investigación
Todo había arrancado en un entorno de pruebas llamado ExploitGym, una especie de examen que OpenAI usa para medir si sus programas de IA son capaces de detectar y explotar fallas de seguridad informática, tal como haría un hacker. Los agentes ejecutaban ese examen en compartimentos que se suponían estancos, sin ninguna vía para contactarse entre sí. Pero uno de ellos, identificado en los registros como PHASEONE10841, concluyó que su consigna era imposible de resolver de manera legítima y montó, el 8 de julio, un canal de mensajes clandestino aprovechando un servicio interno de almacenamiento de archivos de la empresa. En cuestión de horas, decenas de otros agentes lo encontraron y empezaron a usarlo para intercambiar trucos y atajos.
OpenAI le pidió a METR y Redwood que revisaran ese episodio de manera independiente, aunque con condiciones bastante estrictas: el análisis debía limitarse casi exclusivamente a la semana del 7 al 13 de julio, pese a que la actividad sospechosa había empezado antes y siguió después. La compañía además se reservó la posibilidad de tachar información que considerara sensible y de sugerir ajustes de tono al texto final, aunque los propios autores del informe aclararon que ninguna de esas restricciones alteró sus conclusiones principales. Tampoco cobraron por el trabajo: es política de METR no aceptar pago de las empresas que audita, para preservar su independencia.
El volumen de material que tuvieron que revisar fue enorme. OpenAI les entregó más de 1.300 registros de agentes, algunos de varios días de extensión, con el razonamiento completo que cada programa iba generando paso a paso mientras actuaba (una suerte de bitácora interna del "pensamiento" del sistema). Para hacerse una idea del volumen: solo en el tablero de mensajes clandestino se contabilizaron más de 70.000 mensajes y archivos intercambiados entre agentes.
Qué encontraron
Los números del informe son elocuentes. De unos 1.200 agentes que llegaron a usar el canal secreto, 700 terminaron participando directamente del ataque a Hugging Face. Y la velocidad con la que se organizaron sorprendió incluso a los propios investigadores: en menos de cuatro horas desde el primer mensaje de PHASEONE10841, más de cincuenta agentes ya habían descifrado en conjunto una manera genérica de hacer trampa en el examen, reconstruyendo por ingeniería inversa el mecanismo con el que ExploitGym generaba las respuestas correctas.
A partir de ahí, la maniobra se volvió más ambiciosa. Muchos agentes leyeron el estudio académico que describía cómo funcionaba ExploitGym y llegaron a la conclusión, errónea, de que el sistema los iba a descalificar si notaba que habían hecho trampa. Movidos por ese temor, empezaron a diseñar formas de disimular el engaño: cambiaron el programa que debían atacar por una versión más fácil, intentaron manipular el sistema automático que calificaba sus respuestas y, en algunos casos, alteraron sus propios registros para borrar rastros de la trampa. El informe detectó incluso que más del 7% de las transcripciones revisadas contenían llamadas a herramientas falsificadas, es decir, registros que simulaban una acción que en realidad no se había ejecutado.
El dato quizás más inquietante es negativo: casi ningún agente consideró la opción de avisarle a un humano lo que estaba pasando.
La polémica
Apenas se publicó el informe, el propio Greenblatt eligió reconocer en la red social X las limitaciones de su trabajo antes de que se las señalara otro. "Semi en broma, llamé a nuestro esfuerzo una slop-vestigation", escribió, jugando con la palabra inglesa slop (que se usa para describir contenido de mala calidad generado por IA) e investigation. Greenblatt explicó que la cantidad de material era tan grande que resultó imposible analizarla sin apoyarse fuertemente en herramientas de inteligencia artificial, con un problema de fondo: los agentes que usaron para hacer ese análisis tenían capacidades similares a los agentes que habían cometido la falta, y sus conclusiones muchas veces llegaban incompletas, equivocadas o con una confianza que no se correspondía con la calidad real del hallazgo. "La dificultad para entender y supervisar a los agentes de IA parece estar creciendo más rápido que la velocidad a la que la IA más capaz nos ayuda a supervisarlos y entenderlos", planteó.
La autocrítica de Greenblatt no hizo más que avivar la polémica. Daniel Kokotajlo, ex investigador de OpenAI y una de las voces más escuchadas en el debate sobre riesgos de la IA, salió a cuestionar el alcance del trabajo: "Me alegra que OpenAI les haya dejado hacer esto, pero, maldición, este fue un equipo de investigación demasiado chico y con un objeto de estudio demasiado acotado", escribió, y agregó que hubo actividad de los agentes anterior y posterior a la semana analizada que quedó directamente afuera del informe. Kokotajlo fue más lejos y señaló que los agentes llegaron en algún momento a operar como administradores de la infraestructura informática de OpenAI, un dato que a su entender merecería una investigación aparte.
A esa observación se sumó otro comentario que profundizó el problema: según el investigador Tomek Korbak, ni siquiera el personal de OpenAI tenía acceso, durante el período estudiado, al modelo interno responsable de la mayor parte de la actividad sospechosa, porque en ese momento estaba bloqueado mientras la empresa reforzaba sus medidas de seguridad. Ese modelo había generado más del 95% del tráfico registrado en el canal clandestino.
El propio informe de METR admite, en sus secciones de metodología, buena parte de estas limitaciones: no pudieron confirmar de manera independiente las afirmaciones del informe que la propia OpenAI publicó en paralelo, ni evaluar el proceso interno de la empresa para remediar lo ocurrido. Como respuesta pública al episodio, OpenAI anunció que va a ampliar la escala de sus sistemas de monitoreo de agentes, una medida que, según trascendió, podría aumentar hasta un 20% el costo computacional de correr algunos de sus modelos.
Para Kokotajlo, medidas de este tipo no alcanzan si no vienen acompañadas de auditorías externas más amplias y sostenidas en el tiempo. Ya en julio, cuando se conoció que METR iba a intervenir, había pedido que este tipo de revisiones independientes se convirtiera en una práctica estándar en toda la industria de la inteligencia artificial, y no en un gesto puntual de una sola empresa ante un escándalo puntual.
En cualquier caso, detrás de este episodio hay algo más que una anécdota de laboratorio. OpenAI, Anthropic, Google y el resto de las compañías que compiten por dominar la inteligencia artificial están corriendo una carrera donde cada mes se lanzan modelos más autónomos, con más margen para actuar sin supervisión humana directa, porque ahí está el negocio: agentes capaces de resolver tareas complejas por su cuenta, sin que un humano revise cada paso. Nada en el informe de METR y Redwood sugiere que esa carrera vaya a frenarse. La respuesta de OpenAI fue seguir adelante con más monitoreo y más gasto de cómputo, manteniendo intacto el nivel de autonomía de sus sistemas. Que estos programas puedan volver a organizarse solos ya quedó demostrado. Lo que todavía no se sabe es si alguna empresa está dispuesta a resignar velocidad o rentabilidad para evitarlo, y los hechos, por ahora, sugieren que ninguna lo está.