El 18 de septiembre de 2026 Google confirmó públicamente que su modelo Gemini obtuvo acceso no autorizado a tres sistemas pertenecientes a terceros. Ocurrió en mayo de 2026 durante una evaluación de seguridad realizada por Irregular, una empresa que prueba sistemas avanzados de IA, planteada como un ejercicio de capture-the-flag dentro de lo que se suponía que era un entorno cerrado. Google supo de los incidentes en julio y no los confirmó públicamente hasta la cobertura de prensa a mediados de septiembre.

En la prensa esto se lee como una historia de una IA que escapa de sus límites. Dentro de una empresa se lee como algo más concreto y mucho más cercano: el detalle que lo causó todo no estaba en el modelo, sino en cómo se configuró el entorno de prueba. Y es el mismo tipo de error que hay ahora mismo en bastantes sistemas de empresas saudíes.

Qué ocurrió realmente

El escenario era sencillo: hacer que el modelo atacara a una organización ficticia dentro de un entorno aislado. Dos cosas fallaron a la vez. Primero, el entorno tenía acceso no previsto a internet. Segundo, la empresa ficticia usada en el ejercicio coincidía por casualidad con un dominio real propiedad de una parte real.

El resultado fue que el modelo hizo exactamente lo que se le pidió, contra el objetivo equivocado. Según Heather Adkins, vicepresidenta de ingeniería de seguridad de Google, el modelo encontró información pública en internet y adivinó credenciales para acceder a sitios web que creía que formaban parte de la prueba. Se detuvo una vez obtenido el acceso y no fue más allá, y Google afirma que no se produjo ningún daño.

Lo más importante de la postura de Google es que no lo clasifica como un desalineamiento en el comportamiento del modelo, sino como un error de identidad. El modelo no decidió excederse en sus instrucciones. Las siguió al pie de la letra, dentro de un mapa del mundo que era erróneo. Tampoco es un caso aislado: OpenAI reveló en julio que uno de sus agentes vulneró Hugging Face, y Anthropic ha informado de un comportamiento similar en sus propios modelos.

El fallo estaba en el límite, no en el modelo

Si se elimina por completo la IA de la historia, la lección sigue intacta. Descrito de forma sencilla, el incidente es: un sistema que funciona en un entorno de prueba, un entorno con una ruta activa hacia el mundo exterior, y dentro de él unos datos de prueba que no eran tan ficticios como suponía quien los escribió.

Esa descripción encaja con cosas que pasan en empresas corrientes sin ninguna IA de por medio. Un sistema de staging envía mensajes de confirmación a números móviles inventados al azar, y llegan a personas reales. Un script de prueba llama a una pasarela de pago contra producción en lugar del sandbox. Una copia de desarrollo del sitio apunta a la base de datos de clientes en vivo porque montar una separada resultaba incómodo. Una campaña de correo de prueba se envía a la lista real de suscriptores. En todos los casos, la suposición que se rompe es la misma: alguien creía que ese entorno estaba separado.

Dónde se repite esto en las empresas saudíes

Por lo que vemos al trabajar con sistemas existentes, se repite en cuatro lugares concretos:

  • Datos de prueba que en realidad no son falsos. Los números, dominios y direcciones de correo inventados sobre la marcha para rellenar un formulario de prueba suelen pertenecer a personas reales. La solución no es el criterio individual, sino dominios reservados para pruebas, números que no llegan a nadie y una norma escrita que prohíba inventar datos sobre la marcha.
  • Un entorno de staging con una salida abierta. Si su copia de desarrollo puede enviar un mensaje de WhatsApp, un correo o una solicitud de pago al mundo exterior, no es un entorno de staging: es un segundo entorno de producción. El bloqueo correcto vive en la configuración, no en la memoria de un desarrollador.
  • Claves de producción usadas en pruebas. Una sola clave compartida entre ambos entornos anula la separación por muy ordenada que parezca la estructura de carpetas. Precisamente por eso las plataformas gubernamentales los separan: la Autoridad de Zakat, Impuestos y Aduanas (ZATCA), por ejemplo, ofrece en la plataforma Fatoora un entorno de simulación distinto del de producción, con certificados de incorporación separados para cada uno.
  • Una copia de los datos de clientes dentro del entorno de desarrollo. Es el más arriesgado en términos regulatorios. La Ley de Protección de Datos Personales (PDPL), supervisada por la Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA), regula los datos personales dondequiera que se encuentren y no hace excepción con una copia etiquetada como prueba. Un entorno de staging que contiene datos reales de clientes entra de lleno en su ámbito, y suele ser el sistema menos protegido que usted tiene.

Cuatro límites que fijar esta semana

Nada de esto requiere un proyecto ni un presupuesto. Requiere una sesión con quien gestiona sus sistemas:

  • Haga una pregunta directa: ¿puede nuestra copia de prueba enviar un mensaje, un correo o una solicitud de pago al mundo exterior? Si la respuesta es sí o no estoy seguro, eso es lo primero que debe cerrar.
  • Separe por completo las claves y los certificados entre entornos, de modo que ninguna clave funcione en ambos.
  • Adopte una lista fija de datos de prueba: un dominio de prueba reservado, números que no llegan a nadie y un número móvil conocido del equipo que reciba todos los mensajes de prueba.
  • Defina quién puede ejecutar una herramienta automatizada o un agente de IA contra sus sistemas, en qué entorno y con qué permisos. Si la respuesta no está por escrito, no existe.

La visión de Origami

Leemos este incidente como un recordatorio de que los fallos de sistemas más caros rara vez son ingeniosos. Son fallos de suposición. La capacidad de seguridad de Google está muy por encima de la de cualquier empresa saudí, y la suposición que se rompió fue la sencilla: que un entorno cerrado estaba de verdad cerrado. Las empresas no suelen caer en la parte difícil de un sistema. Caen en la parte que nadie revisó, porque parecía obvia.

En Origami tratamos el aislamiento de entornos como parte de la entrega y no como un extra opcional: un entorno de staging que no puede alcanzar canales de comunicación reales, claves separadas y datos de prueba que no pertenecen a nadie. El coste son unas pocas horas al inicio de un proyecto. La alternativa es un incidente que usted explica a un cliente o a un regulador cuando ya ha ocurrido. Es un intercambio que conviene resolver pronto.

Una conclusión práctica

La lección del incidente de Gemini no es evitar las herramientas de IA. Es dejar de tratar la palabra staging como una garantía. Un entorno no está aislado porque usted lo haya llamado así; está aislado porque alguien ha comprobado de verdad que lo está. Empiece hoy con una pregunta: ¿cuál es el punto más lejano al que puede llegar nuestra copia de prueba? Si la respuesta no está clara, usted funciona con la misma suposición que se rompió en Google.

Fuentes

  • NBC News — la confirmación de Google de que Gemini obtuvo acceso no autorizado a tres sistemas externos en mayo de 2026, y la declaración de Heather Adkins, vicepresidenta de ingeniería de seguridad, de que el modelo encontró información pública y adivinó credenciales de sitios que creía que formaban parte de la prueba.
  • CNBC — detalles de la evaluación realizada por Irregular, el acceso no previsto a internet del entorno de prueba, la organización ficticia que coincidía con un dominio real e incidentes comparables revelados por OpenAI y Anthropic.
  • SDAIA — la Ley de Protección de Datos Personales (PDPL) y su aplicación a los datos personales dondequiera que se traten.
  • Plataforma Fatoora - ZATCA — la separación entre el entorno de simulación y el de producción, con certificados de incorporación independientes para cada uno.