Reshoring en lugar de offshore: cómo la mediana empresa alemana recablea su cadena de suministro cloud

6 min. de lectura

En 2026, el reshoring ya no es una etiqueta de marketing, sino una partida de presupuesto. Las medianas empresas alemanas trasladan cargas concretas desde las regiones estadounidenses de los hyperscalers a centros de datos de la UE: algunas completas, muchas híbridas. Los impulsores rara vez son debates puros de soberanía. Son preguntas de auditoría de los exámenes BSI-KRITIS, atestaciones C5 de los clientes y obligaciones de la ley marco KRITIS a partir de octubre de 2025, que golpean en lo operativo.

RelacionadoCloud Repatriation 2026: el modelo TCO  /  Canal Broadcom-VMware: el panorama de providers 2026

El movimiento no se ejecuta como un gran exit. Se ejecuta como una triage de cargas: qué tiene que estar forzosamente en la UE, qué puede correr en híbrido y qué se queda pragmáticamente en AWS us-east-1 o Azure East US. Este texto describe lo que realmente ocurre en proyectos desde principios de 2026, y dónde el relato choca con la realidad de la escala de los hyperscalers.

Qué cargas se traen de vuelta en concreto

Hay tres clústeres claros que las medianas empresas migran activamente en 2026. Primer clúster: cargas relevantes para KRITIS. Desde la ley marco KRITIS y la transposición de NIS2 en Alemania, los operadores de instalaciones críticas deben aportar pruebas sobre ubicación, acceso y dependencia de instrucciones en el tratamiento de datos. Las eléctricas, las empresas de aguas y los grupos hospitalarios se llevan sus datos de pacientes y de control, a menudo a Open Telekom Cloud o IONOS.

Segundo clúster: analítica con datos personales y datos de CRM con riesgo Schrems II. Las empresas que en 2024/25 apostaron por SCCs de AWS y el EU-US Data Privacy Framework viven en las auditorías preguntas difíciles. Los pipelines analíticos pasan a proveedores nativos de la UE o a AWS Frankfurt (eu-central-1) con políticas explícitas de region lock.

Tercer clúster: backups y archivos de largo plazo con obligación legal de conservación (Derecho mercantil y fiscal, §257 HGB, §147 AO). Aquí los datos fríos migran de S3 en EE. UU. a proveedores UE compatibles con S3 o al object storage de OVHcloud. El esfuerzo de migración es manejable y el argumento de compliance es fuerte.

Qué empujan realmente las certificaciones

Tres marcos dominan la discusión, cada uno con peso distinto. C5 (Cloud Computing Compliance Criteria Catalogue) del BSI es la palanca prácticamente más importante. Los grandes clientes y los contratantes públicos exigen C5 Tipo 2 como base contractual. AWS, Azure y Google Cloud tienen atestaciones C5 para sus regiones UE, pero los criterios adicionales (DEU C5:2020) sobre localidad del dato obligan a una configuración de región explícita. Quien hasta ahora desplegaba a nivel global tiene que rehacer arquitectura.

BSI-KRITIS no es un certificado, sino un régimen obligatorio para operadores de infraestructuras críticas. La obligación de prueba según §8a de la ley BSI exige cada dos años una revisión de medidas de protección adecuadas. En la práctica eso significa: las externalizaciones a cloud deben estar documentadas, los contratos de encargo del tratamiento tienen que ser sólidos y las estrategias de salida robustas. Los contratos estándar de los hyperscalers ya a menudo no bastan.

Gaia-X aporta un marco de arquitectura y un sistema de etiquetas (Gaia-X Labels nivel 1 a 3) que garantiza la soberanía del dato. Las cargas productivas sobre servicios certificados por Gaia-X siguen siendo raras. Gaia-X actúa sobre todo como criterio de licitación en el sector público y como plantilla argumentativa para la gobernanza interna. Quien espere de Gaia-X una cloud lista para usar se llevará una decepción.

Dónde choca el relato con la realidad de los hyperscalers

La narrativa de soberanía suena limpia: fuera de las clouds de EE. UU., dentro de proveedores UE. En la realidad del proyecto, el relato se rompe en tres puntos.

Primer punto de ruptura: managed services. Quien corra en producción sobre Amazon Aurora, DynamoDB o Azure Cosmos DB no tiene en los proveedores UE un managed service equivalente. La migración suele significar cambiar a PostgreSQL autogestionado o a catálogos de servicio más pequeños. Es viable, pero cuesta tiempo de ingeniería.

Segundo punto de ruptura: dependencias SaaS. Microsoft 365, Salesforce y ServiceNow viven en corporaciones estadounidenses. Incluso las ofertas de Microsoft EU Cloud (EU Data Boundary) no escapan del todo al CLOUD Act. Quien quiera excluir en serio el acceso desde EE. UU. tiene que empezar por la capa SaaS, no por el IaaS.

Tercer punto de ruptura: stack de IA. Los proveedores UE invierten (STACKIT tiene plataforma de IA, OVHcloud ofrece instancias GPU), pero la brecha con Bedrock o Vertex AI es grande. Los equipos que construyen productos basados en LLM se quedan, al menos para inferencia, con frecuencia en los hyperscalers de EE. UU. Reshoring aquí significa: datos en la UE, inferencia del modelo donde corren los modelos.

Pasos prácticos para un proyecto de reshoring

Quien arranque un proyecto de reshoring debería ir en este orden:

1. Triage de cargas (semanas 1-3): clasificar todas las cargas según tres criterios: relevancia KRITIS, dato personal y obligación de conservación. Migrar solo cargas con un motor real de compliance. El resto, por ahora, se queda donde está. Resultado: una lista priorizada con un máximo del 15 al 20 por ciento del portfolio.
2. Definir la arquitectura destino (semanas 3-6): elegir un proveedor objetivo por cada clúster de cargas. Cargas de base de datos en Open Telekom Cloud o IONOS, object storage en OVHcloud, base Kubernetes en STACKIT. Nada de estrategia multiproveedor dentro de un mismo clúster – cuesta complejidad operativa sin ganar soberanía.
3. Proof of migration con una carga (mes 2-3): migrar una aplicación concreta y no crítica para el negocio. Medir el comportamiento en tiempo de ejecución, la calidad del soporte y los costes en la realidad. Solo después, escalar. Las empresas que migran cinco cargas en paralelo desde el principio generan riesgos operativos sin aprendizaje.
4. Establecer procesos operativos con capacidad de salida (mes 3-5): Infrastructure as Code (Terraform, Pulumi), contenedores portables y formatos estándar de exportación de datos desde el principio. Quien en un proveedor UE caiga en vendor lock-in solo ha movido el problema original geográficamente.
5. Reporting y mapeo de certificados (mes 4-6): trasladar las atestaciones C5 del proveedor a los propios documentos de auditoría, actualizar los certificados KRITIS, adaptar las vías de notificación al BSI. Esa es la parte que hace visible el valor del proyecto ante el consejo de administración y el comité de vigilancia.

El reshoring en 2026 no es un gesto político, sino un proyecto de ingeniería con motor de compliance. El enfoque más limpio es poco espectacular: priorizar cargas, probar un proveedor con disciplina y construir capacidad de salida. Quien lo haga con disciplina obtiene soberanía del dato sin los retrocesos de escala que el relato suele esconder. Quien planifique el reshoring como salida total de las clouds estadounidenses aterriza rápido en debates SaaS que el equipo IaaS no puede resolver.

Al final decide la pregunta de para qué se necesita el sello de auditoría. Para obligaciones KRITIS y licitaciones públicas, en la mayoría de los casos no hay forma de evitar a los proveedores UE. Para plataformas productivas de IA y de datos, se mantiene la realidad híbrida: región UE en el hyperscaler con region locks estrictos, y un proveedor UE nativo adicional para las piezas que requieren forzosamente C5 Tipo 2. Esa arquitectura en dos capas es poco atractiva, pero sobrevive a los próximos ciclos de auditoría.

Cómo entran Gaia-X y EuroStack en el debate de reshoring

En el trabajo operativo de arquitectura en 2026, Gaia-X rara vez aparece como requisito propio, pero sí de forma regular en licitaciones del sector público y de sectores regulados. En la práctica son relevantes los esquemas de self-description y el sistema de labels: un proveedor con Gaia-X Label nivel 2 o 3 indica que se han garantizado contractualmente ciertos criterios de soberanía (sede del tratamiento, derechos de acceso, jurisdicción). Para una empresa KRITIS que tiene que explicar a su auditor por qué una determinada carga permanece en una cloud de EE. UU., la etiqueta es un argumento utilizable. Sin label, la discusión se alarga.

EuroStack es más joven, está más cargado políticamente y hoy por hoy es sobre todo un debate de roadmap. La idea de construir un stack europeo de infraestructura extremo a extremo – desde el silicio hasta el compute y los servicios de plataforma – todavía en 2026 no es base de decisión para la arquitectura de una mediana empresa. Pero aparece en convocatorias de ayudas y afecta a la pregunta de qué proveedores UE resultan estratégicamente interesantes para los próximos cinco años. Quien planifique hoy un reshoring debería revisar la lista de proveedores que participan activamente en proyectos EuroStack. No es un criterio de compra, pero sí una señal de compromiso inversor a largo plazo.

En la práctica: en la licitación, Gaia-X Label como criterio must, participación en EuroStack como puntuación plus. Ambos se comunican internamente sin euforia. Quien infle Gaia-X como tema de marketing perderá al departamento de compliance; quien lo ignore, perderá licitaciones públicas.

RGPD, Schrems II y la pregunta por la jurisdicción

El núcleo jurídico de la ola de reshoring no está en Berlín, sino en Luxemburgo. Desde la sentencia Schrems II de 2020 y los debates posteriores sobre el EU-US Data Privacy Framework, la transferencia de datos personales a EE. UU. solo es admisible con medidas técnicas y organizativas adicionales. El Data Privacy Framework de 2023 ha estabilizado formalmente la situación, pero queda bajo observación permanente. Varias autoridades de control de datos en la UE han señalado que, en caso de duda, volverán a pedir revisión si el marco cae política o jurídicamente.

Para la arquitectura eso significa: quien hoy opere sistemas productivos con datos personales en regiones de EE. UU. asume un riesgo residual que se puede atenuar con region locks en la UE, pero no eliminar del todo. El CLOUD Act permite a autoridades estadounidenses, bajo determinadas condiciones, acceder a datos de empresas estadounidenses, independientemente de dónde estén físicamente los datos. Para la mayoría de las medianas empresas no es un problema operativo, pero sí un auditable item, y los auditable items acaban antes o después en el registro de riesgos.

La respuesta de arquitectura más limpia en 2026 no es la salida total, sino la separación por clases de datos: datos personales de alta sensibilidad (salud, empleados, comunicaciones) en proveedores UE nativos, datos operativos sin dato personal siguen en los hyperscalers, formas mixtas caso por caso. Es más administración, pero reduce significativamente la superficie jurídica expuesta, y es exactamente el lenguaje que las autoridades de protección de datos quieren oír.

Qué no resuelve el reshoring

Dos malentendidos se mantienen con fuerza. Primero: el reshoring no resuelve la dependencia de stacks de software estadounidenses. Quien deposite sus datos en un centro de datos UE pero los procese con Microsoft 365, Salesforce o ServiceNow no ha abandonado realmente la jurisdicción. La cuestión SaaS es un proyecto propio y necesita respuestas propias – palabras clave: alternativas europeas como Nextcloud, Open-Xchange o SaaS vertical especializado del espacio DACH.

Segundo: el reshoring no es un proyecto de ahorro. Los proveedores UE nativos son, en la mayoría de comparativas de precios, más caros que los hyperscalers, sobre todo en cargas elásticas. Eso hay que decírselo al CFO con honestidad, si no el proyecto cae en la primera ronda de presupuesto. El business case se justifica por soportar la auditoría, no por la factura de infraestructura. Quien lo invierta construirá un proyecto de reshoring que, al cabo de dos años, se deshace porque no se cumple la expectativa de ahorro.

Preguntas frecuentes

¿Desde cuándo merece la pena plantear el reshoring como proyecto?

Como muy tarde cuando las obligaciones KRITIS, las atestaciones C5 o las exigencias del BSI están sobre la mesa para el próximo ciclo de auditoría y el auditor aborda expresamente la cuestión de jurisdicción. Por debajo de ese umbral basta en muchos casos un region lock bien documentado en la región UE del hyperscaler – menos esfuerzo y cumple la mayoría de los requisitos en la mediana empresa.

¿Tengo que salir completamente de la cloud estadounidense para hacer reshoring?

No. La mayoría de los proyectos de 2026 son híbridos: cargas críticas por clase de dato en proveedores UE nativos, el resto se queda en AWS, Azure o Google Cloud con region lock UE. La retórica de la salida total funciona en discursos, rara vez en el roadmap.

¿Qué certificados son realmente relevantes para el debate del reshoring?

En la práctica: C5 Tipo 2 del BSI como referencia básica, ISO 27001 como base, Gaia-X Label nivel 2+ en licitaciones públicas. Los certificados KRITIS se añaden por sector (B3S). Todo lo demás es añadido de marketing: no sin importancia, pero no criterio de decisión.

¿Cómo evito pasar del lock-in estadounidense a un lock-in europeo?

Apostar desde el día uno por tecnologías portables: Kubernetes en lugar de orquestación propietaria, Terraform en lugar de consolas específicas del proveedor, formatos de datos abiertos en lugar de especificidades de managed service. No escribir los planes de salida cuando llega el cambio, sino fijarlos contractualmente como parte del onboarding con el nuevo proveedor.

¿Qué significa el reshoring para el paisaje SaaS en la empresa?

Poco o nada, mientras el foco esté en el IaaS. El debate SaaS es un proyecto propio con otros impulsores y con costes políticos normalmente más altos. Quien haga limpio el reshoring en el IaaS y aparque la cuestión SaaS ha entregado una respuesta honesta: nadie tira Microsoft 365 como proyecto secundario de un programa de infraestructura.

Fuente de la imagen de portada: Pexels / Sergei Starostin (px:6466141)