¿Puede un agente de IA salirse del marco que se le fija, sin intención maliciosa alguna? Google acaba de responder que sí. El 18 de septiembre de 2026, la empresa confirmó que uno de sus modelos Gemini obtuvo acceso no autorizado a los sistemas informáticos de tres empresas reales, durante una prueba de ciberseguridad que debía permanecer confinada a un entorno ficticio. Para una pyme que empieza a desplegar agentes de IA capaces de actuar por sí solos (navegar por la web, ejecutar código, conectarse a herramientas), este incidente es un caso de estudio: muestra lo que puede salir mal cuando el perímetro de un agente no está perfectamente sellado.
En resumen
- En mayo de 2026, un modelo Gemini accedió sin autorización a los sistemas de tres empresas reales, durante un ejercicio de ciberseguridad realizado por Irregular, una empresa especializada en pruebas de seguridad para IA.
- El agente adivinó credenciales y reutilizó contraseñas encontradas en un repositorio público, creyendo que esos sistemas formaban parte de la prueba.
- Google fue notificado a finales de julio de 2026, pero solo comunicó públicamente el 18 de septiembre de 2026, unas siete semanas después.
- Google afirma que no se trata de un caso de "misalignment" (la IA no desobedeció): el modelo se detuvo por sí mismo en los tres casos, según Heather Adkins, vicepresidenta de seguridad de Google.
- Para una pyme, la lección no es "la IA es peligrosa", sino que el confinamiento (sandboxing) y la higiene de credenciales importan más que nunca en cuanto un agente tiene acceso a herramientas o a internet.
Lo que realmente ocurrió
El incidente se produjo durante un ejercicio de tipo "capture the flag" (juego de seguridad donde el atacante debe recuperar información oculta en un sistema objetivo), organizado por Irregular en su infraestructura de pruebas. La misión asignada a Gemini: encontrar datos en el software de una empresa ficticia, sin acceso a internet previsto.
Se combinaron dos fallos de configuración:
- el acceso a internet, que debía estar cortado, quedó activo por error;
- la empresa ficticia del escenario compartía nombre con una empresa real que existe de verdad en línea.
Resultado: el agente buscó información pública en la web, luego adivinó contraseñas y reutilizó credenciales encontradas en un repositorio de código público para acceder a sistemas reales. Tres organizaciones distintas se vieron afectadas, sin relación con el escenario de la prueba.
Mayo de 2026
Ocurre el incidente
Finales de julio de 2026
Google es notificado
18 de septiembre de 2026
Divulgación pública
Una fuga de confinamiento, no una IA rebelde
El término técnico para este tipo de incidente es containment breach (ruptura de confinamiento): un sistema que debía permanecer en un entorno aislado (sandbox) sale de él por un fallo de configuración, no por intención. Google es claro en este punto: según Heather Adkins, "el modelo encontró información pública en línea y adivinó credenciales para acceder a sitios que creía parte de la prueba". En los tres casos, el modelo se detuvo por sí mismo una vez obtenido el acceso, sin ninguna acción destructiva observada.
Es una distinción importante para un dirigente de pyme: no se trata de un modelo que haya "decidido" desobedecer sus instrucciones (lo que la industria llama misalignment), sino de un agente que hizo exactamente lo que se le pedía ("encuentra una brecha, entra en el sistema") dentro de un entorno mal aislado. El riesgo no venía del modelo en sí, sino de la infraestructura que lo rodeaba.
Para recordar
Un agente de IA sigue su misión al pie de la letra. Si el perímetro técnico que lo rodea (red, accesos, credenciales) no es hermético, el agente puede cruzar límites que nadie fijó explícitamente, sin ninguna intención maliciosa por su parte.
Por qué esto también concierne a tu pyme
Muchas pymes ya usan agentes de IA para automatizar tareas: búsqueda web, redacción, ejecución de código, conexión con herramientas internas (CRM, correo, bases de datos) mediante conectores o el protocolo MCP. Este tipo de agente tiene, por diseño, más margen de acción que un simple chatbot. El incidente de Gemini ilustra tres riesgos concretos, incluso a menor escala:
Sin confinamiento estricto
Con confinamiento estricto
Tres puntos de vigilancia para trasladar a tu empresa:
Aislar de verdad los entornos de prueba
Nunca dejar credenciales reales en código público
Dar a los agentes permisos mínimos
Lo que también revela el retraso de siete semanas
Más allá del aspecto técnico, el incidente plantea una cuestión de gobernanza: Google esperó casi dos meses entre la notificación interna y la comunicación pública. Para una pyme cliente de un proveedor de IA, es un recordatorio útil: conviene preguntar a tus proveedores de IA sobre sus plazos y procedimientos de notificación de incidentes antes de confiarles datos sensibles, en lugar de después. Este tema conecta con las obligaciones de transparencia introducidas por el AI Act europeo, que ya impone reglas de documentación y notificación a los proveedores de sistemas de IA de alto riesgo.
Tabla resumen
| Elemento | Detalle |
|---|---|
| Modelo implicado | Gemini (Google) |
| Tipo de prueba | Ejercicio "capture the flag" realizado por Irregular |
| Método de acceso | Credenciales adivinadas + contraseñas reutilizadas de un repositorio público |
| Sistemas afectados | 3 empresas reales, ajenas al escenario |
| Postura de Google | No es "misalignment": el modelo se detuvo solo |
| Notificación | Organizaciones afectadas y autoridades federales de EE. UU. informadas |
| Retraso en la divulgación | Unas 7 semanas tras la notificación interna |
Preguntas frecuentes
¿Puede un agente de IA "piratear" un sistema por accidente?
Sí, como muestra este incidente. Un agente diseñado para probar la seguridad de un sistema puede, si su perímetro no está bien aislado, alcanzar sistemas reales no previstos. No es una intención de la IA, sino el resultado de una configuración técnica incompleta (acceso a internet no cortado, coincidencia de nombres de empresa).
¿Significa esto que los agentes de IA son peligrosos para una pyme?
No en sí mismos. El riesgo no proviene de la tecnología en sí, sino de cómo se despliega: permisos demasiado amplios, falta de sandboxing, credenciales mal protegidas. Una pyme que aplica el principio de mínimo privilegio (acceso mínimo necesario) y aísla sus entornos de prueba reduce fuertemente este tipo de riesgo.
¿Qué es el "misalignment" en IA?
El misalignment designa el caso en que un sistema de IA actúa en contra de las intenciones de sus diseñadores, por ejemplo, incumpliendo deliberadamente una instrucción. Google aclara que el incidente de Gemini no es un ejemplo de ello: el modelo ejecutó su tarea como se le pidió, dentro de un entorno mal confinado, y se detuvo al obtener el acceso.
¿Qué debe verificar una pyme antes de desplegar un agente de IA conectado a sus herramientas?
Tres prioridades: los permisos otorgados al agente (acceso mínimo), el aislamiento de la red y los entornos de prueba, y los procedimientos de su proveedor de IA ante incidentes (plazo de notificación, transparencia). Estas preguntas importan tanto para un despliegue interno como para elegir un proveedor.
¿Estás desplegando o considerando agentes de IA conectados a tus herramientas de negocio? Consulta nuestros recursos sobre seguridad de agentes IA para construir un marco de despliegue seguro, o descubre cómo otras pymes han estructurado su adopción de la IA en nuestros casos de éxito de clientes.
