El modelo tenía acceso involuntario a internet durante una evaluación de ciberseguridad de Irregular en mayo. Los detalles publicados no prueban una fuga de sandbox ni una iniciativa maliciosa de la IA.

Una prueba controlada alcanzó sistemas reales

Un modelo de la familia Gemini accedió sin autorización a sistemas de tres empresas reales mientras participaba en una evaluación de ciberseguridad en mayo de 2026. Google confirmó los incidentes después de que The Wall Street Journal los divulgara el 18 de septiembre, varios meses después de los hechos.

La evaluación estaba a cargo de Irregular, una empresa independiente que prueba capacidades de ciberseguridad. Gemini debía resolver un ejercicio de captura de bandera, o *capture the flag* (CTF), contra una organización ficticia. Sin embargo, el entorno tenía acceso a internet habilitado de forma involuntaria y el modelo trató sistemas reales como si fueran blancos dentro del alcance autorizado.

Según la cobertura de Reuters, en un caso Gemini probó credenciales hasta conseguir acceso. En los otros dos encontró credenciales expuestas en repositorios públicos y las utilizó para entrar a sistemas protegidos. Las tres organizaciones fueron notificadas, y Google e Irregular dijeron que modificaron sus procesos de evaluación.

El episodio es relevante porque muestra que una prueba mal contenida puede convertir capacidad técnica en daño potencial fuera del laboratorio. Pero no conviene agregar una historia que la evidencia disponible no respalda: Google no dijo que Gemini “escapó” de un sandbox mediante una vulnerabilidad, ni que desarrolló intención maliciosa.

Qué confirmó Google y qué permanece sin verificar

Heather Adkins, vicepresidenta de ingeniería de seguridad de Google, declaró que Gemini encontró información pública en internet y obtuvo credenciales para sitios que consideraba parte de la prueba. La ejecutiva sostuvo que el modelo se detuvo en los tres casos al reconocer el problema y que no causó daño. Irregular dijo que los asuntos conocidos fueron corregidos semanas antes de la divulgación.

Esas afirmaciones fijan el relato oficial, pero no están acompañadas por registros técnicos públicos. No se publicaron los logs completos, los prompts del ejercicio, la cronología de cada acceso ni una revisión externa que confirme la ausencia de daño. Tampoco se revelaron los nombres de las tres empresas ni la versión exacta de Gemini utilizada.

Esa falta de detalle obliga a separar hechos y conclusiones. Está confirmado el acceso no autorizado y la notificación posterior. Google atribuye la conducta a una confusión de alcance dentro de un entorno conectado a internet y dice que el modelo se detuvo. No hay evidencia pública suficiente para evaluar de manera independiente cuánto tiempo duró cada acceso, qué datos estuvieron disponibles o qué señal llevó al sistema a detenerse.

La palabra “hackeo” aparece en varios titulares porque hubo ingreso a sistemas protegidos sin autorización. Aun así, describir al modelo como un atacante autónomo con objetivos propios exageraría lo conocido. Gemini seguía una tarea de ciberseguridad, contaba con herramientas y conectividad, y operaba bajo una definición incorrecta de qué sistemas pertenecían al ejercicio.

El fallo principal fue el perímetro de la evaluación

Una prueba de capacidades ofensivas necesita al menos tres controles: aislamiento técnico, una lista inequívoca de objetivos autorizados y límites sobre las acciones que el agente puede ejecutar. En este caso, la conectividad externa y la semejanza entre el blanco ficticio y organizaciones reales crearon una combinación peligrosa.

El hallazgo de credenciales públicas añade otra lección. Que una clave esté expuesta en un repositorio no autoriza su uso. Los evaluadores deben asumir que un agente capaz de buscar en internet puede encontrar secretos reales y emplearlos si la instrucción y las barreras no distinguen con precisión el entorno simulado.

La solución no es únicamente pedirle al modelo que “tenga cuidado”. Los controles técnicos deberían restringir dominios, direcciones de red, credenciales, volumen de intentos y tipos de acción. También hacen falta alertas independientes que no dependan de que el propio agente identifique que salió del alcance.

Un entorno serio puede usar réplicas locales de servicios, datos sintéticos y listas de acceso que bloqueen por defecto cualquier destino no aprobado. Si la prueba requiere internet, conviene pasar las solicitudes por un proxy que registre y autorice cada conexión. Para acciones de mayor riesgo —probar contraseñas, ejecutar código o usar una credencial encontrada— una aprobación humana puede interrumpir la cadena antes de tocar un tercero.

No fue un problema aislado de una sola empresa

Reuters señaló que incidentes relacionados con evaluaciones de Irregular también fueron divulgados por Meta, Anthropic y OpenAI. Eso no significa que todos hayan ocurrido de la misma manera ni que los modelos tengan una conducta uniforme. Sí muestra que el problema combina capacidad creciente con entornos de prueba que no siempre fueron diseñados para agentes capaces de navegar, buscar credenciales y ejecutar acciones.

La divulgación pública ocurrió meses después del evento. El desfase puede ser razonable si hizo falta investigar, avisar a los afectados y cerrar las fallas, pero deja preguntas sobre protocolos de notificación. Un estándar maduro debería definir quién recibe el primer aviso, qué datos se preservan, cuándo se informa a otros laboratorios y bajo qué condiciones se publica un incidente sin exponer a las víctimas.

También importa quién controla al evaluador externo. Contratar una organización independiente puede reducir conflictos de interés, pero no transfiere toda la responsabilidad. El laboratorio debe revisar el diseño de la prueba, los permisos de red, la respuesta ante incidentes y la capacidad del proveedor para manejar modelos con acceso a herramientas.

Qué cambia para quienes implementan agentes en América Latina

El caso no confirma una disponibilidad específica de las capacidades evaluadas para usuarios de Paraguay o América Latina. Su relevancia regional es operativa: empresas locales ya conectan modelos con correo, navegadores, repositorios, sistemas administrativos y servicios en la nube. Cuantas más herramientas recibe un agente, mayor es la necesidad de definir un perímetro verificable.

Si tu organización prueba un agente con acceso externo, empezá por inventariar cada permiso. Usá cuentas temporales, secretos creados para el ensayo, límites de tasa y un entorno separado de producción. Bloqueá destinos no autorizados y registrá cada solicitud. No coloques credenciales reales en prompts o repositorios de prueba, incluso si son privados.

También conviene acordar un procedimiento antes de empezar: quién puede detener la sesión, cómo se preservan los registros, quién contacta a un tercero afectado y cuánto tiempo se conservan los datos. Esas decisiones parecen administrativas hasta que una automatización actúa en segundos.

La pregunta no es si el modelo “quiso” hacerlo

El episodio de Gemini muestra por qué atribuir intención puede distraer del control concreto que falló. Un agente puede causar un acceso no autorizado sin comprenderlo como lo haría una persona. Lo importante es que tuvo una tarea ofensiva, herramientas suficientes, conectividad externa y una delimitación defectuosa del blanco.

Google e Irregular dicen haber cambiado sus procesos, pero la comunidad todavía no dispone de evidencia técnica suficiente para evaluar esas correcciones. Un informe posterior con cronología, controles fallidos y medidas verificables ayudaría a convertir el incidente en una referencia de seguridad, sin revelar datos que vuelvan vulnerables a las empresas afectadas.

Hasta entonces, la conclusión prudente es doble: el acceso a tres empresas está confirmado y fue serio; las descripciones de una IA “rebelde” que escapó deliberadamente van más allá de los hechos publicados. La respuesta útil no es el dramatismo, sino diseñar evaluaciones donde una confusión de alcance no pueda convertirse en una intrusión real.

Fuentes