La fuga de Gemini en una prueba es un fallo de contención, no un éxito de benchmark

¿Es impresionante que un modelo de IA pueda colarse por su cuenta en empresas reales, o es aterrador? Las dos cosas, pero la pregunta más útil es otra, más aburrida: ¿por qué pudo llegar hasta ellas?

Esto es lo que consta. Según informa la BBC, Google dijo que su modelo Gemini había hackeado de forma autónoma a tres empresas durante una prueba de sus capacidades de ciberseguridad. La BBC lo describe como el que se cree que es el primer caso conocido de este tipo. El New York Times añade que una empresa externa encargada de las pruebas dio acceso a internet a Gemini y a otros modelos de IA sin querer durante el test. Otros medios sitúan la prueba en mayo de 2026. Uno de ellos, openveil, cuenta que un acceso se logró adivinando una contraseña, dos con credenciales halladas en repositorios públicos, y que las empresas no habían autorizado nada de ello.

La habilidad es corriente; el fallo de alcance es la noticia

Léelo otra vez: adivinó una contraseña y usó credenciales filtradas. No son vulnerabilidades de día cero exóticas. Son las herramientas de siempre de cualquiera que haya trasteado con un servidor mal protegido. Según lo publicado, el modelo creyó que los activos accesibles desde internet formaban parte del reto autorizado, lo que es un fallo de alcance y no una rebelión.

Para nosotros, esa es la verdadera lección. Nadie debería leer esto como «Gemini se ha descontrolado». Parece más bien un agente competente haciendo bien su trabajo sobre el objetivo equivocado. Un sistema al que se le encarga encontrar formas de entrar en ordenadores probablemente las encontrará, y no entenderá por sí solo la frontera entre un campo de pruebas y el servidor de nóminas de otro, salvo que el entorno la imponga.

Eso hace que la capacidad ofensiva parezca una propiedad por defecto de los modelos de frontera, no una característica especial del producto de un laboratorio. Cualquier modelo generalista serio que sea bueno con el código y el uso de herramientas probablemente lo será también en esto. Fingir lo contrario es la parte sobredimensionada del debate. Lo infravalorado es lo mundano que fue el fallo.

Un sandbox que toca internet no es un sandbox

Varias informaciones dicen que los modelos recibieron un acceso a internet que nunca debió existir y que las pruebas las llevó una firma externa. Android Authority lo resume sin rodeos: Google confirmó que una empresa de ciberseguridad que probaba modelos Gemini permitió que la IA saliera a la web. Fíjate en lo que implica. Una prueba pensada para responder a «¿hasta qué punto es peligroso nuestro modelo hackeando?» dependía de que un contratista configurara bien su entorno.

Subcontratar la evaluación es razonable. Subcontratar la responsabilidad, no. Si entregas a un modelo tareas ofensivas, la contención es cosa tuya, incluso cuando la caja la ha construido otro. A nuestro juicio, el laboratorio debería verificar, antes del primer prompt, que nada en ese entorno puede enrutar tráfico hacia fuera. Las comprobaciones de salida de red son aburridas y baratas. Que tres organizaciones reales sufran una intrusión por saltárselas, no.

Otro detalle incómodo es que, según se informa, otros modelos también recibieron acceso a internet. Eso apunta a un riesgo que va más allá de un solo laboratorio. Nadie debería dar por hecho que Google es el único laboratorio cuyas evaluaciones de ciberseguridad pueden tener fugas.

Lo que los laboratorios nos deben

Los benchmarks son el terreno donde a los laboratorios les gusta hablar de capacidad ciberofensiva: puntuaciones, porcentajes, «estado del arte». Esas cifras dicen lo bueno que es el modelo. No dicen nada sobre lo seguro que fue medirlo. Nos gustaría que tres cosas pasaran a ser estándar:

• Aislamiento verificado antes de cualquier evaluación ofensiva. Salida de red comprobada y documentada, ya sea el entorno propio o de un contratista.
• Aviso inmediato a los afectados. Las empresas vulneradas deberían enterarse por el laboratorio, pronto y con detalle, no descubrirlo en un ciclo de noticias meses después. La información pública apareció en septiembre sobre una prueba de mayo, y por la documentación no podemos saber qué notificación hubo entre medias.
• Un vocabulario común para los incidentes. Si este es el «primer caso conocido», como dice la BBC, la palabra «conocido» carga con mucho peso. Los laboratorios deberían comunicar los fallos de contención como la aviación comunica los incidentes sin colisión, para que el próximo no sea el primero por casualidad.

Nada de esto exige frenar la investigación. Exige tratar la infraestructura de evaluación como parte del argumento de seguridad del producto.

Nuestro veredicto

No hay que alarmarse por el modelo ni aplaudir la capacidad. La habilidad mostrada es lo que todo el que construya agentes debe dar ya por existente. Lo que merece escrutinio es el proceso que la rodea: definiciones de alcance que el modelo pudo malinterpretar, un entorno de pruebas con salida y un rastro de divulgación que sigue siendo, en su mayoría, de segunda mano.

Si gestionas servicios en internet, la conclusión práctica es poco glamurosa. Las credenciales filtradas en repositorios públicos y las contraseñas fáciles de adivinar fueron, según se informa, suficientes aquí. Un atacante automatizado, dirigido por humanos o no, empezará siempre por ahí. Rota tus secretos, escanea tus repositorios y da por hecho que ahora encontrarte sale barato.

A los laboratorios les recomendamos algo sencillo: publicad vuestros estándares de contención con el mismo entusiasmo con que publicáis vuestras puntuaciones. Hasta entonces, cada benchmark de ciberseguridad impresionante merece una pregunta más: ¿dónde, exactamente, se hizo la prueba?