On-premise vs. nube europea para agentes de IA: la matriz de decisión para empresas en Europa

Los seis criterios en detalle: sensibilidad de los datos y cumplimiento normativo (RGPD, normativa sectorial), costes (CapEx/OpEx, economía de GPU frente a economía de tokens), latencia, escalado, esfuerzo operativo y know-how, y disponibilidad de modelos. Este artículo ofrece la matriz de decisión y recomendaciones concretas para cada escenario.

Residencia de datos frente a soberanía de datos: la distinción clave

La confusión conceptual más frecuente en las conversaciones con clientes de la región DACH (Alemania, Austria y Suiza) afecta a dos términos que no significan lo mismo. La residencia de datos es el lugar físico donde se almacenan y procesan los datos. La soberanía de datos es la jurisdicción legal que rige sobre los datos, incluido el alcance extraterritorial, como el de la CLOUD Act estadounidense de 2018. Una nube soberana cumple ambas cosas: el operador, la infraestructura y el control jurídico se encuentran en la jurisdicción elegida. Por tanto, la residencia es necesaria, pero no suficiente.

En la práctica, esto significa que, aunque los datos estén exclusivamente en Fráncfort, el operador de un hiperescalador estadounidense sigue siendo una persona jurídica estadounidense sujeta a la CLOUD Act. La soberanía en sentido estricto presupone uno de tres modelos: la nube soberana dedicada de un hiperescalador (por ejemplo, la AWS European Sovereign Cloud, disponible desde enero de 2026 en Brandeburgo, o la Microsoft Sovereign Cloud), un stack operado por un socio (T-Systems con Google, Bleu con Microsoft en Francia) o un proveedor no estadounidense. Las nubes soberanas de los hiperescaladores trasladan la operación y el acceso a la UE, pero su protección frente a la CLOUD Act sigue siendo jurídicamente controvertida. Microsoft France admitió el 10 de junio de 2025, bajo juramento ante el Senado francés, que no puede garantizar que los datos nunca se entreguen a las autoridades estadounidenses si estas lo ordenan.

A esto se suma una particularidad de la región DACH: en las pymes, on-premise rara vez significa el servidor en la oficina, sino casi siempre un entorno dedicado en un centro de datos de colocation neutro respecto a operadores en Alemania, Austria o Suiza (Equinix Frankfurt, Interxion, Digital Realty Zürich, NTT Vienna). El bare metal real propiedad del cliente sigue siendo relevante para grandes grupos industriales, organizaciones vinculadas a la defensa y clientes BFSI con una instrucción explícita del supervisor.

Los seis criterios de decisión

1. Sensibilidad de los datos y cumplimiento normativo

Los datos maestros de clientes, los datos de empleados, los historiales médicos o la propiedad intelectual sujeta a control de exportaciones empujan la arquitectura hacia lo soberano o lo on-premise. Además del RGPD y de la FADP/revDSG suiza (en vigor desde el 1 de septiembre de 2023), se aplican normas sectoriales: BaFin/FINMA para BFSI, KRITIS/NIS2 para infraestructuras críticas, TISAX para automoción, y DigiG y § 393 SGB V para datos sanitarios. Una fecha concreta y vinculante: desde el 1 de julio de 2025, BSI C5 Tipo 2 es obligatorio para el tratamiento en la nube de datos de pacientes. Algunos servicios de hiperescaladores aún no cuentan con esta atestación, algo que hay que comprobar en el proceso de compra. Esta indicación no sustituye al asesoramiento jurídico.

2. Costes: CapEx/OpEx, GPU frente a tokens

Con carga sostenida, el autoalojamiento es más barato por token; las API gestionadas son más baratas para cargas de trabajo con picos y exploratorias. Una GPU ociosa es el CapEx más caro. Los factores arquitectónicos de coste on-premise son la amortización de los servidores GPU (normalmente 3-4 años), la electricidad (tarifas industriales en la región DACH de unos 0,18-0,35 EUR/kWh), la refrigeración (PUE de 1,2-1,4 en centros de datos modernos de la región DACH), la conectividad, la operación y las licencias de software. Un solo rack de 130 kW consume del orden de 1,1 GWh al año a plena carga.

3. Latencia

La inferencia coubicada (motor en la misma región que la orquestación de agentes) ofrece una latencia de red de un solo dígito en milisegundos. Las llamadas transatlánticas cuestan unos 80-120 ms de ida y vuelta más el handshake TLS, y en agentes de varios pasos que llaman a herramientas esa cifra se multiplica. Como referencia: para los 30 días hasta el 30 de julio de 2026, Microsoft registra una mediana de 94 ms de ida y vuelta entre Germany West Central (Fráncfort) y East US (estadísticas de latencia de Azure). Para una UX por debajo del segundo con varias rondas de llamadas a herramientas, las llamadas transatlánticas no son viables.

4. Escalado

Las API gestionadas escalan de forma elástica sin planificación de capacidad. Los stacks autoalojados necesitan capacidad reservada: el cálculo de memoria de GPU determina el hardware. Un modelo de 70 B necesita en BF16 unos 140 GB solo para los pesos, en FP8 unos 70 GB y en AWQ-INT4 unos 35 GB. Para baja concurrencia basta 1x H200 (141 GB); para tamaños de lote de producción suelen hacer falta 2x H100 o 2x MI300X. Los modelos de la clase de 405 B exigen paralelismo tensorial multi-GPU (por ejemplo, 8x H200 o un nodo GB200 NVL72). Los modelos de billones de parámetros quedan fuera de casi todas las infraestructuras de las pymes de la región DACH; aquí el camino pasa por API gestionadas o por bursting de GPU soberano.

5. Esfuerzo operativo y know-how

Operar vLLM, SGLang, Triton o NVIDIA NIM a escala de producción requiere una profundidad en ingeniería de plataformas que la mayoría de las pymes de la región DACH no tiene en plantilla. Un equipo de guardia 24x7 que domine los bloqueos de NCCL y los modos de fallo de las GPU escasea en la región DACH. Nota sobre la elección del motor de inferencia: Hugging Face pasó TGI a modo de mantenimiento el 11 de diciembre de 2025 y remite los nuevos despliegues a vLLM o SGLang (datos de 2026).

6. Disponibilidad de modelos

Las API gestionadas ganan cuando la variedad de modelos es crítica. Solo Azure AI Foundry añadió en 2025, entre otros, DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5 y Llama 4. Las API soberanas (IONOS AI Model Hub, Open Telekom Cloud AI Foundation Services, Swisscom Swiss AI Platform, Infomaniak) sirven modelos de código abierto como Teuken-7B, Llama 3/4, Mistral, DeepSeek y el modelo abierto suizo Apertus (EPFL/ETH/CSCS, publicado el 2 de septiembre de 2025). Quien necesite un modelo concreto como open weight permisivo puede operarlo de forma idéntica mediante contenedores NIM u OCI en distintas nubes y on-premise.

La matriz de decisión: criterio frente a modelo operativo

La heurística complementaria para la decisión en profundidad: las API gestionadas encajan con datos públicos/internos, carga con picos, gran variedad de modelos y ausencia de un equipo de plataforma. El autoalojamiento encaja con datos confidenciales/regulados, carga continua alta, una latencia de cola inferior a 500 ms y una soberanía estricta.

Ejemplo de cálculo concreto: el punto de equilibrio de costes

Una regla general que circula entre los equipos de plataforma de la región DACH hace tangible la decisión (datos de 2026): a partir de una carga de inferencia sostenida de unas 8-12 GPU equivalentes a H100, el autoalojamiento en nube soberana u on-premise suele salir más barato por token que la economía de las API gestionadas. Por encima de unos 30 equivalentes de H100, la diferencia se amplía rápidamente.

Migrar de la API gestionada al autoalojamiento tiene sentido cuando se cumplen al menos dos de las siguientes condiciones:

• El gasto mensual en API gestionadas supera el coste operativo (run rate) de unas 10 H100 en nube soberana.
• Una nueva instrucción del supervisor (BaFin/FINMA/BSI) exige un control demostrable e indelegable.
• El modelo sobre el que se basa tu agente pasa a estar disponible como open weight permisivo (Llama, Mistral, Apertus).
• La hoja de ruta exige un fine-tuning que no es posible en la API gestionada.
• Una revisión legal clasifica al proveedor como riesgo de concentración (DORA).

En ese caso, planifica la migración con unos 6-9 meses de antelación.

Por debajo del punto de equilibrio de 8-12 H100, las API gestionadas dominan en términos de TCO. Los precios concretos por token y el cálculo H100 frente a H200 frente a B200 corresponden a un análisis FinOps aparte.

Recomendación por escenario

Pymes (200-2.000 empleados, sensibilidad de datos mixta, entorno M365, sin equipo de plataforma de ML): según la experiencia, el modelo híbrido cubre más del 70 por ciento de los proyectos greenfield de pymes en la región DACH. Recomendación: Azure West Europe o Germany West Central con Azure OpenAI en un despliegue Data Zone EUR, una capa RAG on-premise o en colocation con una base de datos vectorial para documentos confidenciales, conectada mediante ExpressRoute y Private Endpoint. Los fragmentos confidenciales nunca salen de Alemania; solo los extractos ya anonimizados pasan a formar parte del prompt del LLM. Una capa de gateway LiteLLM autoalojada controla los presupuestos y permite el fallback a una plataforma europea como Mistral La Plateforme. No es adecuado para sistemas core de BFSI, PI clasificada ni datos de pacientes después del 1 de julio de 2025.

Sector regulado (BFSI, sanidad, sector público, ámbito de la defensa, soberanía total): la nube soberana como vía principal. Recomendación: STACKIT u Open Telekom Cloud / T Cloud Public con contrato con una entidad jurídica alemana y control del operador. LLM mediante PhariaAI-as-a-Service en STACKIT o modelos abiertos (Llama 3/4, Mistral, Teuken-7B, Apertus) mediante vLLM/NIM en instancias GPU dedicadas. Base de datos vectorial (Weaviate, Qdrant, pgvector) en la misma nube soberana, secretos en HashiCorp Vault con HSM seal sobre un HSM de Utimaco, tráfico de salida denegado por defecto con allowlist. Para la categoría de datos más alta, opcionalmente inferencia on-premise mediante NVIDIA NIM sobre Red Hat OpenShift AI en el centro de datos del cliente. Trade-off real: la brecha de funcionalidades que aún existe frente a los hiperescaladores y que T-Systems quiere cerrar antes de finales de 2026 (compromiso de hoja de ruta).

Gran corporación (DAX 40, SMI 20, ATX prime, política formal de salida de la nube según DORA/MaRisk/FINMA): resiliencia multicloud con una capa soberana. Nube principal (Azure Alemania/UE) para el grueso de las cargas, nube secundaria (AWS o Google) para la resiliencia, y las API de modelos abstraídas mediante un gateway de IA. Portabilidad de modelos mediante modelos abiertos (Llama 4, Mistral, Apertus, Teuken) como contenedores NIM/OCI que funcionan de forma idéntica en todas las nubes y on-premise. Capa soberana opcional (STACKIT o T Cloud Public) para las cargas de trabajo más sensibles, con rutas de migración documentadas. Es la categoría de costes más alta y casi nunca encaja con una pyme.

Nota sobre Suiza: la FADP/revDSG no es el RGPD y no deben mezclarse. El endurecimiento de la autoridad de supervisión suiza («privatim») de noviembre de 2025 recomienda a los organismos públicos usar SaaS internacional para datos sensibles solo con cifrado de extremo a extremo y claves en poder del cliente. La exposición a la CLOUD Act se mantiene para los proveedores estadounidenses incluso con residencia de datos en Suiza.

Para agencias y responsables de decisiones B2B

La elección entre on-premise, nube europea e híbrido no es una cuestión puramente de TI, sino una decisión de negocio y de cumplimiento normativo que se toma al principio del proyecto y que marca durante años la arquitectura, los costes y la capacidad de venta. Para las agencias que desarrollan agentes de IA para clientes en Europa, separar con claridad la residencia de datos y la soberanía de datos es el argumento más sólido en las negociaciones con compras y con el departamento jurídico.

Blck Alpaca acompaña a empresas B2B de toda Europa desde la matriz de decisión hasta el stack en producción, con residencia de datos en la UE y soberanía demostrable. En una prueba de concepto compacta aclaramos, a partir de tu caso de uso real, las categorías de datos, el presupuesto de latencia, el punto de equilibrio de costes y el modelo operativo adecuado antes de que inviertas en infraestructura. Escríbenos para una PoC B2B.