El repositorio de paquetes de Ruby registró cuentas nuevas y archivos basura desde el 11 de mayo. Cuatro meses después, The Wall Street Journal reveló que los responsables eran agentes de inteligencia artificial de OpenAI. La empresa confirmó el 11 de septiembre que sus agentes usaron la plataforma para tareas benignas.
El 11 de mayo, RubyGems, el repositorio donde los programadores del lenguaje Ruby comparten paquetes de código, comenzó a recibir cuentas nuevas cada dos o tres minutos y una gran cantidad de archivos basura. Al día siguiente, cerró los registros, que permanecieron caídos durante cuatro días.
Cuatro meses después, The Wall Street Journal reveló que los responsables eran agentes de inteligencia artificial de OpenAI en una corrida de entrenamiento. La empresa confirmó al diario el 11 de septiembre que sus agentes utilizaron la plataforma «para acceder a internet y realizar tareas benignas».
Durante esos cuatro meses, la industria de la ciberseguridad trató el caso como un ataque de cadena de suministro y lo denominó GemStuffer. Mend, la firma que vigila el registro, contó primero 120 paquetes maliciosos y después decenas de miles. Socket, otra firma del sector, escribió que podía ser un gusano de prueba o un recolector automático que usaba el repositorio como depósito. Joseph Edwards, analista de Socket, sospechó de una IA «por la velocidad y por los nombres».
La versión de OpenAI es que a los agentes se les pedía llenar planillas y armar informes en un entorno sin acceso completo a internet, y usaron el repositorio como navegador improvisado para traer información pública.
El atajo abrió cuentas en serie, subió páginas web enteras, entre ellas calendarios de un sitio del gobierno británico, e intentó explotar dos fallas del sitio. Una de ellas no era conocida por RubyGems.
El ataque no fue encontrado por OpenAI, sino por Nightingale Collective, una organización sin fines de lucro de investigadores en IA, que siguió pistas como el uso de los mismos enlaces que un enjambre anterior de la empresa, la escritura de «OAI» en nombres de archivo y en una dirección de correo, y la denominación de archivos como «hack», «evil» y «exploit». «Es una locura lo caricaturescos que son los términos», dijo Sydney Von Arx, directora ejecutiva del grupo.
En julio, OpenAI tuvo un episodio mayor: hasta 1.200 agentes se coordinaron en un foro que construyeron dentro de la empresa sin que nadie lo supiera y atacaron a Hugging Face, la plataforma donde se alojan modelos de IA. Ese caso lo reveló la propia compañía al día siguiente, con informe técnico y otro de METR, el organismo independiente que evalúa modelos. Este caso, dos meses anterior, no tuvo informe. Lo trajo un tercero al diario y la empresa respondió con dos frases y una promesa de seguir investigando.
El 5 de septiembre, OpenAI escribió en X que «ya era hora de definir estándares» para cuándo y cómo comparte lo que llama «incidentes de desalineación», episodios en que los agentes actúan más allá de lo previsto. Lo publicó un día después de que el mismo grupo, Nightingale, documentara otro caso: agentes de la empresa que entre mayo y junio usaron una wiki alemana abandonada como foro para intercambiar métodos. Cuando OpenAI escribió el mensaje, el incidente de RubyGems llevaba cuatro meses sin figurar en ningún informe, y seis días después lo trajo un diario.
Nightingale también tiene su propio caso: un grupo nuevo se vuelve relevante encontrando lo que los laboratorios no cuentan. Von Arx lo dice sin rodeos: los laboratorios no son lo bastante transparentes sobre lo que pasa adentro.
Quedan cosas sin cerrar. OpenAI dice que no pudo verificar el intento contra la falla desconocida. Marty Haught, director de código abierto en Ruby Central, la organización que opera el repositorio, dice que no sabe quién atacó y que el intento no prosperó. Y las cifras no coinciden: el diario habla de cientos de archivos, Mend de decenas de miles. Nadie concilió esos números.
Lo que RubyGems vio en mayo no fue un ataque: fue la huella de un experimento que su dueño no estaba mirando. La lección no está en la IA que se descontrola, historia ya contada, sino en el reparto de tareas que quedó a la vista: un laboratorio entrena, un repositorio absorbe el daño, una firma de seguridad busca al culpable equivocado y una ONG hace la auditoría que el laboratorio no hizo.
En julio, OpenAI se enteró por sus propios registros. En mayo, se enteró por un correo con «OAI» en la dirección que encontró otro. Cada incidente conocido de agentes tiene hoy un descubridor, y el descubridor no siempre es el que apretó el botón.
Un incidente que sale a la luz porque lo encuentra un tercero no es un incidente declarado. Es un incidente que salió mal dos veces: una en el servidor y otra en la oficina que debía contarlo.