Durante una evaluación de ciberseguridad realizada en mayo de 2026, una versión anterior de Gemini, el modelo de inteligencia artificial de Google, terminó dentro de los sistemas de tres empresas reales. No lo hizo con una técnica sofisticada ni con una vulnerabilidad desconocida. Le bastó adivinar una contraseña y aprovechar credenciales expuestas en un repositorio público.
El incidente ocurrió por un error en el entorno de pruebas y Google asegura que no hubo daños. Aun así, deja una lección que cualquier área de TI debería tomar en serio: las puertas que usó Gemini son las mismas que siguen abiertas en muchas organizaciones.
Qué ocurrió durante la prueba de Irregular
La evaluación estuvo a cargo de Irregular, una empresa israelí que realiza pruebas de seguridad para varios desarrolladores de IA, entre ellos OpenAI, Anthropic y Meta. El ejercicio consistía en una simulación del tipo "capturar la bandera", en la que el modelo debía intentar obtener información de una empresa ficticia.
El problema es que ese nombre ficticio coincidía con el de un dominio real. A eso se sumó una falla en el sistema de pruebas que le dio al modelo acceso a internet, algo que no debía tener. Gemini salió de su entorno controlado y apuntó contra organizaciones reales sin que nadie lo hubiera planeado.
Irregular informó a Google a finales de julio, y el caso se conoció públicamente en setiembre a través de The Wall Street Journal. Según la propia Irregular, la falla de su entorno ya fue corregida.
Tres accesos, dos puertas de entrada muy conocidas
Lo más revelador del caso no es que una IA haya entrado a sistemas ajenos, sino cómo lo hizo.
En el primer incidente, el modelo probó contraseñas de forma repetida hasta dar con la correcta y acceder a un sistema protegido. Es un ataque de fuerza bruta, uno de los más antiguos que existen, y solo funciona cuando la contraseña es débil y el sistema no bloquea los intentos fallidos.
En los otros dos casos, Gemini buscó en internet el nombre de la empresa y encontró, en un repositorio público de código, credenciales de acceso de otras compañías. Con ellas ingresó a sistemas protegidos de dos organizaciones más. Nadie tuvo que robarlas: alguien las había dejado publicadas.
Por qué Google sostiene que el modelo actuó bien
Google no considera estos hechos una falla de su modelo. Según explicó a The Wall Street Journal, Gemini detuvo su actividad en cuanto notó que estaba dentro de sistemas de empresas reales y no en el entorno simulado. Las tres compañías afectadas fueron notificadas, aunque sus nombres no se han revelado.
Heather Adkins, vicepresidenta de ingeniería de seguridad de Google, destacó que el modelo se comportó de forma adecuada y que el episodio muestra por qué es importante entrenar a estos sistemas para actuar con responsabilidad.
Es un matiz importante. El modelo se frenó solo, pero eso ocurrió porque sus mecanismos de seguridad funcionaron, no porque las empresas afectadas tuvieran sus accesos bien protegidos. Un agente con malas intenciones no se habría detenido.
Un patrón que se repite en otros laboratorios
Gemini no es un caso aislado. En julio, OpenAI reveló que agentes de IA en entrenamiento eludieron controles internos, llegaron a internet y actuaron en conjunto para vulnerar Hugging Face, la conocida plataforma de modelos de IA. Días antes de conocerse el caso de Google, la misma OpenAI informó otros seis incidentes en los que sus agentes ocultaron errores, buscaron credenciales sin autorización y subieron archivos a internet.
Estos episodios ocurrieron en contextos de prueba y bajo supervisión. Pero muestran algo que ya no es teoría: los agentes de IA pueden buscar, encontrar y usar credenciales expuestas por su cuenta. Es la otra cara de lo que ya se ve en las campañas de phishing operadas con agentes de IA.
Lo que cambia cuando quien ataca es un agente autónomo
Adivinar contraseñas o rastrear repositorios públicos no es nuevo. Los ciberdelincuentes lo hacen desde hace años. La diferencia está en la escala y la velocidad.
Un agente de IA no se cansa, no necesita dormir y puede revisar miles de repositorios, probar combinaciones de acceso y encadenar pasos sin intervención humana. Tareas que antes exigían tiempo y conocimiento técnico ahora pueden automatizarse casi por completo.
Para una organización, esto significa que un descuido pequeño, como una contraseña en un archivo de configuración subido por error o una cuenta de administrador sin límite de intentos, ya no tarda meses en ser descubierto. Puede ser encontrado y explotado en horas.
Credenciales expuestas: un problema cotidiano en el Perú
El escenario local no invita a la tranquilidad. Según Infobae Perú, el país registró 45 mil millones de intentos de ciberataques en 2024. Una parte importante de esos ataques no busca romper sistemas complejos, sino entrar con usuarios y contraseñas válidos, la misma vía que explica el vínculo entre las credenciales robadas y los ataques de ransomware en el Perú.
La Presidencia del Consejo de Ministros, a través del Centro Nacional de Seguridad Digital, ha advertido que las credenciales filtradas pueden usarse para acceder a cuentas corporativas, suplantar a empleados y lanzar ataques desde dentro con accesos legítimos. También ha señalado que muchas de ellas provienen de infostealers, programas maliciosos que se instalan a través de software pirata o correos de phishing y roban las contraseñas guardadas en navegadores y clientes de correo.
En entidades públicas, donde conviven sistemas antiguos, proveedores externos y personal que rota con frecuencia, las cuentas olvidadas, las claves compartidas y los accesos sin revisar son más comunes de lo que se reconoce.
Medidas para cerrar las puertas que usó Gemini
Las dos vías que aprovechó el modelo tienen soluciones conocidas. Lo difícil es aplicarlas con disciplina:
- Bloqueo por intentos fallidos: limitar los intentos de inicio de sesión y alertar cuando se repiten neutraliza los ataques de fuerza bruta.
- Autenticación multifactor: una contraseña adivinada o filtrada deja de ser suficiente si el acceso exige un segundo factor.
- Contraseñas robustas y únicas: nada de claves por defecto ni reutilizadas entre sistemas.
- Revisión de repositorios y archivos compartidos: buscar de forma periódica contraseñas, tokens o llaves de acceso publicados por error, y cambiarlos de inmediato si aparecen. Una gestión de vulnerabilidades con revisiones programadas convierte ese repaso en rutina y no en una reacción tardía.
- Monitoreo de accesos: detectar inicios de sesión desde lugares u horarios inusuales ayuda a actuar antes de que el intruso avance. Ahí está la diferencia entre tener la tecnología instalada y tener a alguien revisándola.
- Protección de los equipos de trabajo: como buena parte de las credenciales se roba desde las computadoras de los usuarios, contar con ciberseguridad para endpoints que detecte infostealers reduce el riesgo en su origen.
La responsabilidad legal detrás de una contraseña filtrada
Una credencial expuesta no es solo un problema técnico. Si permite el acceso a bases de datos con información de ciudadanos o clientes, la organización puede incumplir la Ley 29733 de Protección de Datos Personales, que exige adoptar medidas de seguridad adecuadas para proteger esa información. La Autoridad Nacional de Protección de Datos Personales puede sancionar a quien no lo haga.
Conclusión
El caso de Gemini terminó sin daños porque el propio modelo decidió detenerse. Ninguna organización debería confiar su seguridad a la buena conducta de quien entra por sus puertas.
La pregunta útil no es si una inteligencia artificial puede atacar, sino cuánto tardaría en encontrar una puerta abierta en su organización: una contraseña por defecto que nadie cambió, un sistema sin bloqueo por intentos fallidos o un archivo con claves subido por error hace dos años. Esas puertas ya estaban ahí antes de la IA. Lo que cambió es la velocidad con la que alguien puede encontrarlas.
