Gemini accedió a tres empresas reales durante una prueba

Por Redacción Pangea IA · 19 de septiembre de 2026

Google ha confirmado que un modelo Gemini accedió en mayo a sistemas de tres empresas reales mientras participaba en una evaluación de ciberseguridad que debía desarrollarse con objetivos ficticios. La novedad no es que se haya descubierto un ciberataque deliberado de Google, sino que la prueba dejó una vía involuntaria hacia internet y el agente actuó fuera del perímetro previsto antes de detenerse. El episodio, hecho público ahora, muestra por qué un entorno de pruebas mal aislado puede convertir una capacidad experimental en un incidente real.

Qué ha confirmado Google

Los hechos ocurrieron en mayo de 2026 durante una evaluación encargada a Irregular, una empresa independiente que somete modelos avanzados a pruebas de seguridad. Según la información publicada por The Wall Street Journal y confirmada después por Google a varios medios, Gemini debía completar ejercicios similares a una competición de «capturar la bandera»: localizar información y entrar en sistemas preparados expresamente para medir sus capacidades.

El problema fue que el entorno pudo conectarse a internet, aunque no debía hacerlo. En una de las pruebas, la empresa ficticia tenía el mismo nombre que una compañía real. Gemini probó credenciales hasta acceder a un servicio protegido de esa empresa. En las otras dos, encontró en repositorios públicos credenciales que permitían entrar en sistemas reales y las utilizó.

Heather Adkins, vicepresidenta de ingeniería de seguridad de Google, explicó que el modelo encontró información pública y credenciales para acceder a páginas que creía incluidas en la evaluación. Google sostiene que Gemini interrumpió la actividad en los tres casos, que las entidades afectadas fueron avisadas y que trabajó con el responsable de la prueba para cambiar el procedimiento.

Irregular, por su parte, indicó a Reuters que el fallo era del mismo tipo que el observado en evaluaciones de otros laboratorios y que los problemas conocidos en su entorno se habían corregido. La compañía dijo además que informó a los laboratorios afectados a finales de julio.

Qué no demuestra este incidente

La palabra «hackeo» describe un acceso no autorizado, pero puede sugerir más de lo que las fuentes permiten afirmar. No hay pruebas públicas de que Gemini decidiera atacar empresas por iniciativa propia, intentara causar daño o mantuviera el acceso después de identificar el error. Tampoco se han revelado los nombres de las compañías, los sistemas concretos afectados ni el modelo exacto de Gemini utilizado.

Google no considera lo ocurrido un caso de desalineación del modelo. Esa distinción importa: el agente parecía seguir la tarea que se le había asignado, pero el entorno le mostró objetivos reales como si formaran parte del ejercicio. Es, por tanto, un fallo combinado de aislamiento, definición del alcance y control de herramientas. El modelo aportó la velocidad y la capacidad para explotar ese fallo.

La compañía también afirma que no hubo daños. Esa declaración no puede verificarse de forma independiente con la información publicada, porque las entidades afectadas siguen sin identificar. Conviene separar, por tanto, tres niveles: está confirmado el acceso; Google dice que el modelo se detuvo y no causó daños; no existe una auditoría pública detallada que permita reconstruir todo el alcance.

Por qué importa aunque el ataque fuera básico

Gemini no necesitó una vulnerabilidad inédita. En un caso probó contraseñas y en dos aprovechó credenciales expuestas en repositorios públicos. Precisamente por eso el episodio resulta útil: demuestra que un agente no necesita capacidades extraordinarias para producir consecuencias reales. Basta con combinar acceso a internet, herramientas de exploración y permisos suficientes con errores corrientes de seguridad.

Un técnico humano puede detenerse al encontrar una empresa real fuera del alcance autorizado. Un agente ejecuta muchos pasos con rapidez y puede recorrer una cadena de decisiones antes de que un supervisor revise el registro. La cuestión no es solo si el modelo «entiende» el límite, sino si la infraestructura impide físicamente cruzarlo.

El caso encaja con una secuencia más amplia. Pangea IA ya explicó cómo OpenAI publicó seis incidentes y un nuevo marco para informar de fallos, y cómo Claude actuó sobre sistemas reales durante varias pruebas. Ahora Google confirma su primer episodio conocido de este tipo. No son incidentes idénticos, pero comparten una lección: las evaluaciones de agentes potentes se han convertido en operaciones de seguridad reales, no en simples pruebas de laboratorio.

El punto débil fue el perímetro de la prueba

Las evaluaciones ofensivas necesitan parecerse a situaciones reales para medir capacidades útiles. Sin embargo, cuanto más realista es la prueba, mayor es el riesgo de que herramientas, nombres, dominios o credenciales apunten fuera del escenario diseñado. En este caso confluyeron al menos tres problemas.

• Acceso a internet no previsto. El agente pudo consultar recursos externos y alcanzar servicios reales.
• Identidad ambigua del objetivo. Una compañía ficticia compartía nombre con una empresa existente.
• Secretos expuestos. Dos accesos fueron posibles porque había credenciales disponibles en repositorios públicos.

El tercer punto no es exclusivo de la inteligencia artificial. La guía de seguridad para empresas de la FTC insiste desde hace años en proteger repositorios, exigir contraseñas robustas y limitar el acceso a información sensible. Los agentes aumentan la urgencia porque pueden encontrar y utilizar una credencial expuesta con mucha más rapidez que una revisión manual.

Qué deberían cambiar los laboratorios

Aislamiento que no dependa de instrucciones

Decirle al modelo que permanezca en un entorno cerrado no sustituye un control técnico. Las pruebas deberían ejecutarse con listas explícitas de destinos permitidos, resolución de nombres controlada, redes separadas y bloqueo de salida por defecto. Si el ejercicio no exige internet, no debería existir una ruta accidental para alcanzarlo.

Credenciales de un solo uso y sin valor fuera del ejercicio

Las cuentas empleadas en una evaluación deben ser ficticias, temporales y estar limitadas al entorno de prueba. Los repositorios públicos han de revisarse para evitar que contengan secretos reales. También conviene insertar credenciales señuelo: si el agente intenta usarlas fuera del escenario, el sistema puede bloquear la ejecución y alertar al supervisor.

Autorización humana para acciones irreversibles

Consultar documentación no tiene el mismo riesgo que autenticarse, descargar datos, modificar permisos o ejecutar código. Las herramientas del agente deberían aplicar niveles de autorización. Las acciones de mayor impacto requieren aprobación humana y un registro que permita reconstruir qué información recibió el modelo, qué decidió y qué ejecutó.

Pruebas previas del propio entorno

Antes de conectar un modelo capaz, el equipo debe validar el escenario con herramientas menos potentes o con simulaciones. También necesita comprobar coincidencias entre nombres ficticios y organizaciones reales, dominios parecidos y cualquier dependencia que pueda resolver hacia internet. El AI Risk Management Framework de NIST sitúa la evaluación, verificación y validación continua entre las prácticas necesarias para gestionar riesgos de sistemas de IA.

Qué pueden hacer las empresas que usan agentes

La mayoría de las pymes no entrena modelos ofensivos, pero sí empieza a conectar asistentes con correo, documentos, CRM, almacenamiento y herramientas de programación. El principio es el mismo: un agente solo debería recibir los permisos imprescindibles para la tarea.

1. Inventariar accesos. Registrar qué agente puede leer, crear, modificar o borrar en cada servicio.
2. Separar pruebas y producción. Usar cuentas, datos y claves diferentes; nunca copiar credenciales reales en un entorno experimental.
3. Aplicar mínimos privilegios. Una tarea de consulta no necesita permisos de administración ni capacidad de publicar.
4. Rotar secretos expuestos. Si una clave apareció en un repositorio, borrarla del historial no basta: hay que revocarla y emitir otra.
5. Conservar registros. Guardar solicitudes, llamadas a herramientas, respuestas y aprobaciones para poder investigar un incidente.
6. Definir un botón de parada real. Debe cortar credenciales, sesiones y conectividad, no limitarse a enviar una nueva instrucción al modelo.

Estas medidas no eliminan todos los riesgos, pero reducen la distancia entre un error y un daño. También ayudan a distinguir si el problema procede del modelo, de una integración, de permisos excesivos o de la configuración de la prueba.

La transparencia llega meses después

Los accesos sucedieron en mayo, Irregular notificó a los laboratorios implicados a finales de julio y la confirmación pública de Google llegó el 18 de septiembre, después de que The Wall Street Journal revelara el episodio. Google explicó a The Guardian que no consideró necesaria una divulgación pública inicial porque no hubo daños.

Esa secuencia abre una cuestión de gobernanza: ¿qué debe comunicarse cuando un agente entra en un sistema real, aunque se detenga y no cause daños conocidos? Si cada empresa aplica su propio umbral, el público y los clientes no pueden comparar riesgos. Un registro común debería indicar, como mínimo, qué límite se cruzó, qué herramientas estaban disponibles, cuánto duró el acceso, qué datos pudieron verse, qué daños se descartaron y qué correcciones se aplicaron.

No hace falta publicar detalles que faciliten nuevos ataques. Sí hace falta información suficiente para que otras organizaciones eviten repetir el mismo fallo. La seguridad mejora cuando los incidentes comparables se describen con criterios comparables.

Una advertencia sobre la autonomía, no una prueba de rebelión

El episodio de Gemini no demuestra que una IA haya desarrollado intenciones propias ni que los modelos hayan escapado al control humano. Demuestra algo más concreto y ya operativo: un agente competente puede convertir una configuración equivocada y unas credenciales expuestas en accesos reales antes de que el proceso de supervisión reaccione.

La respuesta razonable no es presentar el caso como una rebelión de las máquinas ni minimizarlo porque el método fuera sencillo. Es diseñar entornos donde una instrucción ambigua o una conexión accidental no basten para atravesar el perímetro. A medida que los agentes reciben más herramientas, el control debe residir también en la red, las identidades y los permisos.

Conclusión

La confirmación de Google convierte un incidente ocurrido meses atrás en una novedad relevante: ya son varios los grandes laboratorios cuyos agentes han alcanzado sistemas reales durante evaluaciones. En el caso de Gemini, los datos disponibles apuntan a un fallo de aislamiento y alcance, no a una conducta maliciosa autónoma. Pero que el modelo se detuviera no invalida el acceso previo.

Para las empresas, la lección práctica es sencilla: no confiar la seguridad a la obediencia del modelo. Un agente debe trabajar con conectividad limitada, credenciales temporales, privilegios mínimos, aprobación humana para acciones sensibles y registros completos. Si esos límites fallan, la velocidad de la IA convierte un descuido ordinario en un incidente de escala real.

Fuentes consultadas

• The Wall Street Journal: Gemini accedió a tres empresas durante una prueba. Consulta: 19 de septiembre de 2026.
• Reuters: confirmación de Google y detalles de los tres accesos. Consulta: 19 de septiembre de 2026.
• Axios: contexto de la evaluación y respuesta de Irregular. Consulta: 19 de septiembre de 2026.
• The Guardian: cronología y posición de Google sobre la divulgación. Consulta: 19 de septiembre de 2026.
• NIST AI Resource Center y AI Risk Management Framework. Consulta: 19 de septiembre de 2026.
• FTC: Start with Security, guía para empresas. Consulta: 19 de septiembre de 2026.