Gemma 4 llega a la nube soberana de AWS: no todas las funciones viajan

AWS hizo disponible de forma general Gemma 4 en Amazon Bedrock dentro de AWS European Sovereign Cloud el 17 de septiembre de 2026. El lanzamiento comprende tres variantes ajustadas para instrucciones, alojadas en la región soberana eusc-de-east-1 y accesibles mediante bedrock-mantle, según el anuncio técnico de AWS.

Desde ese 17 de septiembre, las aplicaciones pueden invocar los modelos mediante las interfaces Responses y Chat Completions compatibles con OpenAI. Sin embargo, la disponibilidad general de Gemma 4 no convierte el entorno soberano en una copia de Bedrock comercial: una revisión independiente del despliegue verificó los tres modelos, el procesamiento dentro de eusc-de-east-1 y la ausencia de inferencia global entre regiones.

Tres modelos y dos ventanas de contexto

La familia comparte razonamiento integrado, llamadas nativas a funciones y entrada multimodal de texto e imágenes. Las diferencias que afectan a una migración son el identificador exacto, la arquitectura, el tamaño y la ventana de contexto:

• Gemma 4 31B: google.gemma-4-31b-it, arquitectura densa de 30.700 millones de parámetros y contexto de 256.000 tokens. AWS lo sitúa como la opción para cargas intensivas en razonamiento o programación.
• Gemma 4 26B-A4B: google.gemma-4-26b-a4b-it, mezcla de expertos con 25.200 millones de parámetros totales y 3.800 millones activos por token. Mantiene un contexto de 256.000 tokens y está orientado a cargas que buscan mayor rendimiento con un coste de inferencia más contenido.
• Gemma 4 E2B: google.gemma-4-e2b-it, 5.100 millones de parámetros totales y 2.300 millones efectivos mediante embeddings por capa. Su contexto es de 128.000 tokens y AWS lo propone para usos sensibles a la latencia o clasificación multimodal.

Los tres identificadores pertenecen a la superficie bedrock-mantle del entorno soberano. La coincidencia del nombre comercial no basta para reutilizar la configuración de otra región: el sufijo del modelo, el endpoint y la partición forman parte del contrato técnico de la llamada.

La API conserva la forma, no todo el comportamiento

La URL base es https://bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu/v1. Una aplicación construida con los SDK de OpenAI para Python o TypeScript puede mantener la estructura general de Responses o Chat Completions, pero debe cambiar la URL base, usar uno de los identificadores admitidos y adaptar las credenciales.

Bedrock admite claves de API generadas a partir de credenciales de AWS y solicitudes firmadas con Signature Version 4. Las claves temporales sin renovación automática caducan en un máximo de doce horas. En IAM, la inferencia requiere bedrock-mantle:CreateInference; el uso de una clave de Bedrock añade bedrock-mantle:CallWithBearerToken.

Los proyectos de Bedrock delimitan acceso, costes y seguimiento del uso. Responses puede gestionar conversaciones con estado dentro de un proyecto; cuando esa persistencia no sea necesaria, store=false indica que Bedrock no debe conservar la solicitud ni la respuesta. La compatibilidad con OpenAI reduce cambios de transporte, pero no demuestra por sí sola que parámetros, errores, almacenamiento o herramientas se comporten igual.

La residencia está definida; la paridad funcional, no

La inferencia de Gemma 4 permanece en eusc-de-east-1 y no utiliza encaminamiento global entre regiones. AWS también sostiene que el contenido permanece en la región elegida salvo decisión contraria del cliente, mientras que metadatos creados por este —como funciones, permisos, etiquetas y configuraciones— se mantienen dentro de la Unión Europea.

La región de Brandeburgo pertenece a la partición separada aws-eusc, cuyas operaciones cotidianas están bajo control de personal de AWS residente en la UE. Bedrock aplica acceso cero de operadores a las entradas y salidas durante la inferencia, cifra las comunicaciones y no comparte por defecto prompts ni respuestas con el proveedor del modelo. La retención también es cero por defecto, aunque AWS advierte que ciertos modelos pueden aplicar una conservación limitada para detectar abusos; la política concreta debe revisarse para el modelo elegido.

Residencia y soberanía operativa son controles relacionados, pero distintos. La ubicación del procesamiento responde a la primera; la partición, las identidades autorizadas, las dependencias y las condiciones de soporte pertenecen a la segunda. Esa separación importa al evaluar si una nube cumple controles soberanos más amplios que la localización física.

Qué no viaja desde Bedrock comercial

La ausencia confirmada es la inferencia global entre regiones: todas las solicitudes de Gemma 4 se procesan en eusc-de-east-1. Esto fija el perímetro de residencia, pero impide utilizar el encaminamiento mundial de Bedrock comercial para agregar capacidad o distribuir solicitudes.

La guía regional de Amazon Bedrock obliga a consultar por separado la disponibilidad de modelos y la compatibilidad de funciones. Que Bedrock figure como servicio disponible en AWS European Sovereign Cloud no garantiza que cada modelo, integración o capacidad documentada para las regiones comerciales exista también en aws-eusc.

Por tanto, las llamadas a funciones y la entrada de imágenes están anunciadas para los tres Gemma 4, pero otras dependencias de la aplicación no deben inferirse a partir de ese dato. Almacenamiento, observabilidad, secretos, orquestación, cuotas y mecanismos de continuidad necesitan su propia comprobación regional.

Verificación mínima antes de trasladar una carga regulada

Una migración puede reducirse a una secuencia de aceptación que separe compatibilidad técnica, residencia y controles operativos:

1. Confirmar que la cuenta pertenece a AWS European Sovereign Cloud, que la región efectiva es eusc-de-east-1 y que los ARN usan la partición aws-eusc.
2. Comprobar el identificador exacto del modelo y probar la ventana de contexto y las modalidades de entrada que realmente utiliza la aplicación.
3. Ejecutar una llamada mínima contra bedrock-mantle con la autenticación prevista para producción, incluidos permisos mínimos y renovación de credenciales.
4. Validar Responses o Chat Completions con streaming, imágenes, llamadas a funciones y persistencia solo si forman parte de la carga que se trasladará.
5. Inventariar cada servicio dependiente y comprobar su disponibilidad en la región soberana sin extrapolarla desde Bedrock comercial.
6. Registrar por separado el endpoint, la residencia, el valor de store, la retención aplicable y los controles jurídicos exigidos por la organización.

El alcance confirmado del lanzamiento es concreto: tres variantes de Gemma 4, dos interfaces compatibles con OpenAI y procesamiento dentro de una única región soberana. La incógnita no está en la llegada de los modelos, sino en la paridad de cada función y servicio asociado; esa compatibilidad seguirá dependiendo del catálogo regional que AWS mantenga para aws-eusc.

Lee también:

• Una nube no es soberana solo por guardar datos cerca: exige ocho controles
• Una sola clave abrió todas las bases de datos de un servicio cloud
• Genesys conecta ocho socios de IA, pero no todas las funciones llegan hoy