Los anuncios de Google, Microsoft, IBM y AWS en octubre de 2026 muestran cómo evoluciona la infraestructura de IA soberana. El reto práctico es determinar dónde se ejecutan los modelos, quién controla el entorno y qué dependencias persisten.
Una organización regulada quiere que un asistente de IA busque en informes confidenciales y documentos internos.
Guarda todos los archivos en un país aprobado. Pero el asistente envía solicitudes a un modelo de IA alojado en otro lugar, usa un proveedor de identidad externo y depende de administradores remotos para mantener su infraestructura.
Los datos pueden estar almacenados localmente, pero el sistema de IA completo no está necesariamente bajo control operativo local.
Esta es la diferencia entre la residencia de datos y la soberanía operativa.
La residencia de datos se refiere a dónde se almacena o se procesa la información. La soberanía operativa se refiere también a quién puede acceder a los sistemas y controlarlos, dónde funcionan los servicios esenciales y qué ocurre cuando las dependencias externas dejan de estar disponibles.
Los anuncios recientes de Google Cloud, Microsoft e IBM, junto con un ejercicio operativo de AWS, ilustran cómo los proveedores abordan distintas partes de este problema.
1. Los seis límites de la IA soberana
Un despliegue de IA soberana no es simplemente un modelo instalado en un centro de datos local.
Piensa en el asistente de búsqueda de documentos. Para responder una pregunta, debe autenticar al usuario, recuperar los documentos pertinentes, quizá crear o consultar embeddings, ejecutar la inferencia del modelo y registrar los eventos operativos.
Cada paso introduce una posible dependencia.
Datos
Dónde se almacenan y procesan los documentos, los prompts, los embeddings, las respuestas, los registros (logs) y las copias de seguridad.
La ubicación del almacenamiento no basta por sí sola si el procesamiento tiene lugar en otro sitio. Por ejemplo, si el asistente envía el contenido de los documentos a un servicio de embeddings externo, que los archivos de origen estén almacenados localmente no garantiza un procesamiento local.
Modelo
Dónde se ejecuta la inferencia y si las solicitudes llegan a servicios de modelos externos.
Plano de control
Quién puede desplegar, configurar, modificar o detener el entorno.
Si la inferencia se ejecuta localmente pero el plano de control necesita que un servicio externo siga disponible, la aplicación tiene una dependencia operativa fuera de su entorno de procesamiento.
Identidad y claves
Quién gestiona los permisos, las credenciales y las claves de cifrado.
Una aplicación alojada localmente puede seguir dependiendo de un acceso operativo remoto.
Operaciones
Quién se encarga del mantenimiento, las actualizaciones, el soporte, la supervisión y la recuperación.
Determina cómo funcionan las actualizaciones, la supervisión, el soporte del proveedor y la recuperación ante desastres. Identifica cualquier servicio externo necesario para el funcionamiento normal o para la restauración.
Continuidad
Qué servicios siguen funcionando si fallan la conectividad externa o las dependencias.
Si es esencial seguir funcionando sin conectividad externa, prueba esa condición.
| Límite | Qué debe establecer una organización |
|---|---|
| Datos | Dónde se almacenan y procesan los documentos, los prompts, los embeddings, las respuestas, los registros (logs) y las copias de seguridad |
| Modelo | Dónde se ejecuta la inferencia y si las solicitudes llegan a servicios de modelos externos |
| Plano de control | Quién puede desplegar, configurar, modificar o detener el entorno |
| Identidad y claves | Quién gestiona los permisos, las credenciales y las claves de cifrado |
| Operaciones | Quién se encarga del mantenimiento, las actualizaciones, el soporte, la supervisión y la recuperación |
| Continuidad | Qué servicios siguen funcionando si fallan la conectividad externa o las dependencias |
Estos límites son un marco de evaluación arquitectónica, no una definición jurídica universal de la soberanía.
También explican por qué mantener los documentos en una región aprobada no satisface automáticamente los requisitos de una organización.
Por ejemplo, si el asistente envía el contenido de los documentos a un servicio de embeddings externo, que los archivos de origen estén almacenados localmente no garantiza un procesamiento local.
Si la inferencia se ejecuta localmente pero el plano de control necesita que un servicio externo siga disponible, la aplicación tiene una dependencia operativa fuera de su entorno de procesamiento.
Que esas dependencias sean aceptables o no depende de los requisitos jurídicos, contractuales, de seguridad y de continuidad específicos de cada organización.
2. ¿Qué cambió en octubre de 2026?
Cuatro novedades ilustran enfoques distintos de la infraestructura soberana y la IA.
| Proveedor | Novedad | Qué demuestra |
|---|---|---|
| Google Cloud | Amplió las capacidades de IA de Google Distributed Cloud air-gapped, incluidos Gemini 3.5 Flash y la búsqueda empresarial | Ejecución local de modelos y recuperación dentro de un entorno aislado |
| Microsoft | Amplió los controles de Sovereign Cloud en entornos públicos, privados y operados por el cliente | Opciones por carga de trabajo para la administración, las claves y el funcionamiento desconectado |
| IBM | Anunció una arquitectura validada que combina Sovereign Core y Fusion | Integración de la infraestructura con una gobernanza operada por el cliente |
| AWS | Informó de los resultados de un ejercicio de independencia de European Sovereign Cloud realizado el 24 de octubre | Prueba del funcionamiento continuado sin determinados sistemas globales de AWS |
Estas novedades no son productos equivalentes ni clasificaciones establecidas de forma independiente.
Google Cloud: El 20 de octubre, Google describió Gemini 3.5 Flash en Google Distributed Cloud air-gapped como disponible de forma general. Su experiencia de búsqueda empresarial con tecnología de Gemini estaba en versión preliminar. Google afirma que el flujo de búsqueda mantiene la indexación, los prompts y la recuperación dentro del perímetro soberano. Se trata de un diseño de producto documentado, no de una prueba de que cada despliegue cumpla automáticamente todos los requisitos de soberanía.
Fuente: Google Cloud, 20 de octubre de 2026
Microsoft: Su anuncio del 20 de octubre describía controles sobre el acceso de los operadores, la gestión de claves de cifrado, la infraestructura operada por el cliente y los entornos conectados o desconectados. Las funciones tienen distintos niveles de madurez. La gestión externa de claves con Azure Managed HSM estaba disponible de forma general, mientras que la posibilidad de pasar cargas de trabajo entre el funcionamiento conectado y el desconectado entraba en versión preliminar pública.
Fuente: Microsoft, 20 de octubre de 2026
IBM: El 22 de octubre, IBM anunció una arquitectura de despliegue validada que combina el software Sovereign Core con la infraestructura Fusion. Su objetivo es simplificar la integración de cómputo, almacenamiento, redes y gobernanza en entornos operados por el cliente. Un despliegue más rápido y unas operaciones más sencillas son los beneficios que declara IBM, no resultados demostrados de forma independiente para cada cliente.
Fuente: IBM, 22 de octubre de 2026
AWS: El 1 de noviembre, AWS informó de un ejercicio realizado el 24 de octubre en el que su European Sovereign Cloud siguió funcionando después de que se desconectaran dos sistemas globales. Según AWS, las cargas de trabajo de los clientes siguieron disponibles.
No fue un ejercicio de aislamiento total de la red (air gap). El tráfico que normalmente circula por la red troncal global de AWS se desvió por internet pública. La prueba respalda una conclusión más limitada sobre la independencia respecto de determinados sistemas globales, no una afirmación de aislamiento completo de la red ni de resiliencia ante cualquier condición de fallo.
Fuente: AWS Security Blog, 1 de noviembre de 2026
3. ¿Qué deberían verificar realmente las organizaciones?
Volvamos al asistente de búsqueda de documentos de la organización regulada.
Antes de elegir una plataforma de IA soberana, sus equipos de arquitectura y de seguridad deberían seguir el recorrido de una solicitud completa: desde la autenticación del usuario hasta la recuperación de documentos, la inferencia del modelo, la generación de la respuesta y el registro de eventos.
La revisión debería establecer dónde se ejecuta cada paso y qué partes pueden acceder a él o administrarlo.
Hay cuatro comprobaciones especialmente útiles.
Verifica el movimiento de los datos. Confirma si los documentos, los embeddings, los prompts, las respuestas y los registros permanecen dentro del límite exigido. La ubicación del almacenamiento no basta por sí sola si el procesamiento tiene lugar en otro sitio.
Verifica la autoridad administrativa. Identifica quién puede cambiar configuraciones, acceder a las cargas de trabajo, administrar los sistemas de identidad y gestionar las claves de cifrado. Una aplicación alojada localmente puede seguir dependiendo de un acceso operativo remoto.
Verifica las dependencias operativas. Determina cómo funcionan las actualizaciones, la supervisión, el soporte del proveedor y la recuperación ante desastres. Identifica cualquier servicio externo necesario para el funcionamiento normal o para la restauración.
Prueba las condiciones de fallo exigidas. Si es esencial seguir funcionando sin conectividad externa, prueba esa condición. Un ejercicio exitoso de aislamiento de la red troncal realizado por un proveedor no puede sustituir la prueba que haga un cliente con una aplicación totalmente desconectada.
La evidencia esperada puede incluir documentación de arquitectura, registros de configuración, registros de acceso, compromisos contractuales y resultados de pruebas observados.
Los requisitos de la organización determinan qué evidencia importa. No todos los sistemas necesitan resistir los mismos fallos ni prohibir las mismas formas de acceso externo.
4. Una mayor independencia tiene costos operativos
Unos controles de soberanía más estrictos pueden aumentar las responsabilidades operativas de la organización.
Un entorno de IA aislado de la red (air-gapped) puede requerir aceleradores dedicados, almacenamiento local, artefactos de modelos, infraestructura de red y soporte especializado.
Los parches de software y las actualizaciones de modelos necesitan una entrega controlada dentro del entorno restringido. La supervisión, las copias de seguridad y la recuperación también deben funcionar dentro de los límites operativos permitidos.
Algunos servicios disponibles en una nube pública conectada pueden no estar disponibles o funcionar de otra manera cuando hay desconexión.
Estos costos importan porque el aislamiento máximo no es automáticamente la mejor arquitectura.
Una organización cuyos requisitos permiten servicios de nube regionales controlados puede ganar poco manteniendo una plataforma de IA totalmente desconectada.
Otra organización que maneja información muy restringida puede no tener ninguna alternativa aceptable.
La decisión debería partir de los requisitos, en lugar de empezar por un proveedor preferido o por una etiqueta de soberanía.
5. La soberanía debe demostrarse, no suponerse
Las novedades de octubre muestran avances en la inferencia de IA local, la infraestructura operada por el cliente, los controles administrativos y la independencia operativa.
Pero responden a requisitos distintos, y la evidencia que las respalda varía.
Un servicio disponible de forma general, una capacidad en versión preliminar, una arquitectura validada por un proveedor y un ejercicio operativo comunicado no deberían tratarse como pruebas equivalentes.
Disponible de forma general
El 20 de octubre, Google describió Gemini 3.5 Flash en Google Distributed Cloud air-gapped como disponible de forma general. La gestión externa de claves con Azure Managed HSM estaba disponible de forma general.
Versión preliminar
La experiencia de búsqueda empresarial con tecnología de Gemini estaba en versión preliminar. La posibilidad de pasar cargas de trabajo entre el funcionamiento conectado y el desconectado entraba en versión preliminar pública. Las funciones tienen distintos niveles de madurez.
Arquitectura validada
El 22 de octubre, IBM anunció una arquitectura de despliegue validada que combina el software Sovereign Core con la infraestructura Fusion. Un despliegue más rápido y unas operaciones más sencillas son los beneficios que declara IBM, no resultados demostrados de forma independiente para cada cliente.
Ejercicio comunicado
El 1 de noviembre, AWS informó de un ejercicio realizado el 24 de octubre en el que su European Sovereign Cloud siguió funcionando después de que se desconectaran dos sistemas globales.
No fue un ejercicio de aislamiento total de la red (air gap). El tráfico que normalmente circula por la red troncal global de AWS se desvió por internet pública. La prueba respalda una conclusión más limitada sobre la independencia respecto de determinados sistemas globales, no una afirmación de aislamiento completo de la red ni de resiliencia ante cualquier condición de fallo.
No equivalentes
Un servicio disponible de forma general, una capacidad en versión preliminar, una arquitectura validada por un proveedor y un ejercicio operativo comunicado no deberían tratarse como pruebas equivalentes.
Para la organización que construye el asistente de búsqueda de documentos, la decisión práctica es definir los límites que necesita, elegir una arquitectura que los respalde y verificar los controles que importan.
La IA soberana es una propiedad del sistema desplegado completo, no simplemente del país donde se almacenan sus datos ni de la etiqueta asignada a su infraestructura.
Referencias y lecturas adicionales
- Google Cloud, Enabling the next era of sovereign AI. 20 de octubre de 2026.
- Google Cloud, Managed RAG search inside the sovereign perimeter. 20 de octubre de 2026.
- Microsoft, Advancing digital sovereignty with greater control and choice. 20 de octubre de 2026.
- IBM, IBM Sovereign Core on IBM Fusion simplifies sovereign AI deployment. 22 de octubre de 2026.
- AWS Security Blog, Inside a successful AWS European Sovereign Cloud exercise. 1 de noviembre de 2026.
Revisión de fuentes: 4 de noviembre de 2026. Las afirmaciones sobre la disponibilidad de los productos y sobre las operaciones deberían volver a verificarse antes de la publicación. Este artículo describe consideraciones de arquitectura, no una certificación de cumplimiento legal.