Aire, grupo al que pertenece Stackscale, celebró el 8 de julio de 2026 el primer webinar de Despeja tu Cloud, una serie de sesiones dedicada a explicar los cambios regulatorios, técnicos y geopolíticos que están modificando la forma de contratar infraestructura. Zigor Gaubeca, CIO de Aire, y David Aibar Carretero, Head of Sales, plantearon una pregunta que debería llegar a cualquier comité de dirección: si un juez preguntase hoy bajo qué jurisdicción se encuentran los datos críticos de la empresa, ¿habría una respuesta clara y documentada?
La respuesta no depende únicamente del país donde esté ubicado el centro de datos. Una carga puede ejecutarse físicamente en Madrid, París o Fráncfort y seguir expuesta a normas de terceros países por la nacionalidad, la estructura societaria o el control efectivo del proveedor. Por eso la soberanía cloud empieza a formar parte de la continuidad de negocio, junto con la ciberseguridad, los backups, la alta disponibilidad y el Disaster Recovery.
Soberanía cloud: las claves en 20 segundos
- Alojar los datos en Europa no garantiza por sí solo que estén sometidos únicamente a legislación europea.
- La jurisdicción también depende de la empresa que presta el servicio, su matriz, los subcontratistas y quién posee, custodia o controla la información.
- El CLOUD Act estadounidense puede alcanzar datos almacenados fuera de Estados Unidos cuando están bajo el control de un proveedor sujeto a esa legislación.
- Esto no permite un acceso arbitrario a cualquier información. Debe existir una solicitud legal válida, específica y vinculada a un procedimiento.
- El Data Act europeo, aplicable con carácter general desde el 12 de septiembre de 2025, obliga a reducir barreras contractuales, comerciales y técnicas al cambio de proveedor cloud.
- Desde el 12 de enero de 2027 no podrán cobrarse los gastos de cambio definidos por el Data Act, aunque las migraciones seguirán teniendo costes técnicos y operativos.
- La Comisión Europea presentó el 3 de junio de 2026 la propuesta del Cloud and AI Development Act, CADA, que introduce un marco común para evaluar diferentes niveles de soberanía cloud y de Inteligencia Artificial.
- La soberanía no exige abandonar los hiperescalares. Exige conocer las dependencias, diversificar cuando exista un riesgo real y disponer de una alternativa viable.
- Un plan de salida que nunca se ha probado todavía no es un plan operativo.
La ubicación del centro de datos no determina toda la jurisdicción
Durante años, muchas decisiones de infraestructura se han cerrado después de comprobar que el proveedor ofrecía una región europea. Era un criterio razonable: mantener los datos dentro de la Unión Europea facilita su proximidad a usuarios y sistemas, puede reducir la latencia y ayuda a cumplir determinados requisitos de residencia.
Pero la ubicación física solo responde a una parte de la pregunta.
También importa qué sociedad firma el contrato, dónde está constituida su matriz, desde qué países puede administrarse el servicio, quién controla las claves de cifrado, qué subcontratistas participan y a qué legislaciones está sometido el grupo empresarial.
El CLOUD Act, aprobado en Estados Unidos en 2018, establece que los proveedores de servicios de comunicaciones electrónicas o computación remota deben preservar, respaldar o entregar la información que se encuentre bajo su «posesión, custodia o control», con independencia de que esté almacenada dentro o fuera del territorio estadounidense.
Esto no significa que una autoridad pueda acceder sin causa a todos los datos alojados por un proveedor. Debe existir una orden, un requerimiento o un procedimiento jurídico válido referido a información concreta. Los proveedores también pueden impugnar determinadas solicitudes y recurrir a los mecanismos previstos en la legislación aplicable.
El riesgo para una compañía europea aparece en el cruce entre jurisdicciones. Por una parte, debe cumplir el Reglamento General de Protección de Datos (RGPD), las normas sobre transferencias internacionales y sus obligaciones contractuales. Por otra, puede depender de un proveedor sujeto a requerimientos procedentes de un tercer país.
La residencia europea sigue siendo importante, pero no basta para describir la exposición jurídica de una plataforma.
Una evaluación completa debería responder, como mínimo, a estas preguntas:
| Área | Pregunta que debe responder la empresa |
|---|---|
| Ubicación | ¿En qué países y centros de datos se almacenan, procesan y replican los datos? |
| Proveedor | ¿Qué sociedad firma el contrato y dónde están constituidas su matriz y sus filiales relevantes? |
| Jurisdicción | ¿Qué legislaciones extranjeras pueden afectar al servicio o al proveedor? |
| Operación | ¿Desde qué países puede acceder el personal de soporte y administración? |
| Cifrado | ¿Quién genera, controla, almacena y puede recuperar las claves? |
| Subcontratación | ¿Qué terceros participan en la prestación y desde qué territorios operan? |
| Acceso público | ¿Cómo responde el proveedor ante solicitudes de autoridades nacionales o extranjeras? |
| Portabilidad | ¿Qué datos, imágenes, configuraciones, registros y metadatos pueden exportarse? |
| Salida | ¿Qué plazos, costes, formatos y limitaciones se aplican al finalizar el servicio? |
La respuesta no debería estar fragmentada entre contratos, anexos técnicos, políticas de privacidad y presentaciones comerciales. Tecnología, seguridad, cumplimiento, compras y dirección necesitan un mapa común que permita conocer dónde están los datos, quién puede administrarlos y qué ocurriría si fuera necesario moverlos.
Qué cambia con el Data Act europeo
El Data Act introduce obligaciones concretas para facilitar el cambio entre proveedores de servicios de procesamiento de datos. Entre ellos se incluyen servicios IaaS, plataformas cloud y otros modelos en los que una empresa procesa o almacena información mediante recursos contratados a un tercero.
La norma exige eliminar obstáculos comerciales, técnicos, contractuales y organizativos que impidan cambiar a otro proveedor, trasladar los datos a una infraestructura propia o utilizar varios proveedores simultáneamente.
Los contratos deben especificar las categorías de datos y activos digitales que pueden portarse, los formatos disponibles, las limitaciones técnicas conocidas y el periodo durante el cual la información podrá recuperarse después de finalizar la transición. También deben contemplar la colaboración del proveedor de origen para mantener la continuidad y apoyar la estrategia de salida del cliente.
Como regla general, el periodo máximo de transición es de 30 días naturales, una vez concluido el preaviso contractual, que no puede superar los dos meses. Si ese plazo resulta técnicamente inviable, el proveedor debe justificarlo y proponer un periodo alternativo que no exceda de siete meses.
El 12 de enero de 2027 desaparecerán los denominados switching charges: los gastos que el proveedor de origen impone por las actuaciones que el Data Act le obliga a realizar durante el cambio.
Eso no convierte una migración cloud en gratuita.
La empresa seguirá asumiendo los costes de consultoría, ingeniería, transferencia, ancho de banda, adaptación de aplicaciones, doble operación, pruebas, nuevas licencias y formación. La norma tampoco elimina automáticamente las penalizaciones por terminar anticipadamente un contrato ni el precio de trabajos adicionales que queden fuera del proceso regulado.
El Data Act reduce barreras, pero no puede deshacer por sí solo una arquitectura construida sobre servicios exclusivos de una plataforma. Cuanto mayor sea el uso de bases de datos propietarias, funciones serverless, herramientas de identidad, colas, APIs o servicios gestionados específicos, más compleja será la salida.
La norma también obliga a los proveedores a publicar la jurisdicción a la que está sometida la infraestructura utilizada para cada servicio y una descripción general de las medidas técnicas, organizativas y contractuales adoptadas frente a accesos gubernamentales internacionales que entren en conflicto con el Derecho europeo.
En este punto conviene distinguir entre tipos de información. Las disposiciones del Data Act sobre accesos gubernamentales internacionales se centran en los datos no personales. Los datos personales siguen sujetos al RGPD y al resto de la normativa europea de privacidad.
CADA y los nuevos niveles de soberanía europea
La Comisión Europea presentó el 3 de junio de 2026 la propuesta del Cloud and AI Development Act. CADA busca ampliar la capacidad europea de centros de datos, cloud e Inteligencia Artificial, facilitar el desarrollo de nueva infraestructura y reducir dependencias consideradas de riesgo.
La propuesta introduce un marco europeo de soberanía con cuatro niveles de aseguramiento. El primero se basa en que los datos sean tratados y almacenados en infraestructura situada dentro de la Unión. Los niveles superiores añaden requisitos sobre independencia respecto a terceros países, transparencia de la cadena de suministro de software, propiedad y control europeos o ausencia de interferencias externas.
La diferencia entre esos niveles refleja una idea central: la localización sigue siendo relevante, pero no equivale al control.
CADA también prevé criterios comunes para la contratación pública, un mayor apoyo a tecnologías open source y medidas para acelerar el despliegue de infraestructura cloud y de centros de datos. La Comisión plantea, además, triplicar al menos la capacidad europea de centros de datos durante los próximos cinco a siete años.
Se trata todavía de una propuesta legislativa. Su contenido puede modificarse durante la tramitación en el Parlamento Europeo y el Consejo. Sin embargo, la dirección política está definida: la dependencia de infraestructuras y proveedores de terceros países ya no se analiza únicamente como una cuestión de competencia o privacidad, sino también como un riesgo para la resiliencia de administraciones, hospitales, bancos, industrias y servicios esenciales.
El proveedor cloud deberá evaluarse cada vez más por una combinación de criterios: seguridad, portabilidad, interoperabilidad, jurisdicción, control operativo, sostenibilidad y capacidad para mantener el servicio ante cambios legales o geopolíticos.
Soberanía operativa: diseñar la salida antes de necesitarla
Una de las ideas más útiles del webinar fue separar la soberanía como concepto institucional de la soberanía operativa que necesita una empresa.
La soberanía operativa puede medirse. Una organización dispone de mayor control cuando puede decidir dónde ejecuta cada aplicación, conoce quién administra sus datos y mantiene una alternativa viable si cambian las condiciones.
Ese cambio puede deberse a una interrupción, un ciberataque, una subida de precios, una adquisición empresarial, una modificación del modelo de licencias, un nuevo requisito regulatorio o una decisión geopolítica.
Como explicó David Aibar durante la sesión, muchas empresas calculan con detalle cuánto cuesta entrar en el cloud, pero pocas estiman cuánto costaría salir. La comparación utilizada fue la del alquiler de una oficina: además de la renta y la adaptación inicial, conviene prever el coste de abandonar el espacio y entregarlo en las condiciones acordadas.
En infraestructura cloud, el coste de salida puede incluir la extracción de datos, la conversión de máquinas virtuales, la reconstrucción de redes, la sustitución de servicios gestionados, las pruebas de rendimiento, la operación simultánea de dos plataformas y la validación funcional de las aplicaciones.
No todas las cargas presentan la misma dificultad. Una máquina virtual basada en formatos comunes puede trasladarse con un esfuerzo razonable. Una aplicación construida con numerosos servicios exclusivos de una plataforma exigirá más ingeniería, pruebas y cambios en el código.
La soberanía no consiste en evitar toda tecnología propietaria. Consiste en conocer el coste de la dependencia y decidir de forma consciente dónde resulta aceptable.
Una estrategia híbrida, no una migración por principios
La soberanía tampoco obliga a sacar todas las cargas de AWS, Microsoft Azure o Google Cloud. Los hiperescalares ofrecen presencia internacional, servicios avanzados, capacidad bajo demanda y acceso rápido a tecnologías de analítica e Inteligencia Artificial.
Pueden ser una buena opción para aplicaciones globales, entornos temporales, proyectos con demanda muy variable o cargas cuyo nivel de sensibilidad y dependencia se haya evaluado previamente.
Otros sistemas requieren más control: bases de datos de clientes, plataformas transaccionales, propiedad intelectual, servicios internos esenciales, backups, sistemas sujetos a regulación sectorial o aplicaciones con un consumo estable y predecible.
Un modelo híbrido permite asignar cada carga según sus necesidades:
| Tipo de carga | Posible enfoque |
|---|---|
| Desarrollo, pruebas y proyectos temporales | Cloud público flexible |
| Aplicaciones globales con demanda variable | Hiperescalar o arquitectura multicloud |
| Sistemas empresariales con consumo estable | Cloud privado con recursos dedicados |
| Datos sensibles o sujetos a regulación | Infraestructura con jurisdicción y operación claramente definidas |
| Bases de datos con uso intensivo de recursos | Bare-metal o infraestructura dedicada |
| Backups y recuperación | Proveedor o ubicación independiente de la producción |
| Cargas críticas | Alta disponibilidad, replicación y procedimientos probados |
Utilizar varias plataformas tampoco genera soberanía por sí solo. Un multicloud sin diseño puede duplicar herramientas, aumentar costes y complicar la seguridad. La diversificación debe responder a riesgos concretos y apoyarse en procedimientos, identidades, redes, monitorización y políticas comunes.
El papel de Stackscale en una estrategia de soberanía operativa
Stackscale puede actuar como infraestructura europea dedicada dentro de un modelo híbrido o multicloud. Sus soluciones de cloud privado combinan equipamiento exclusivo, almacenamiento en red, conectividad privada, soporte especializado y virtualización con Proxmox VE o VMware.
Proxmox VE permite construir plataformas de virtualización sobre tecnologías open source como KVM y LXC. Para muchas empresas puede ser una alternativa con la que reducir la dependencia de determinados modelos de licenciamiento y mantener un mayor control sobre el coste total de propiedad. La decisión debe partir de una evaluación de compatibilidad, disponibilidad, backups, red, almacenamiento y capacidades operativas, no solo del precio del hipervisor.
El bare-metal resulta adecuado cuando una carga necesita rendimiento dedicado, baja latencia, aislamiento, acceso directo al hardware o un comportamiento más predecible. El cloud privado añade una capa de virtualización y gestión sobre recursos asignados, lo que facilita consolidar aplicaciones sin compartir la capacidad física con otros clientes.
En entornos de misión crítica, Stackscale dispone de almacenamiento con georreplicación síncrona entre dos centros de datos de Madrid separados por más de diez kilómetros. El servicio publicado está diseñado con RPO y RTO iguales a cero, sistemas de almacenamiento independientes y redundantes, backups basados en snapshots y soporte técnico 24/7.
La estrategia puede completarse con infraestructura reservada para Disaster Recovery. Este modelo permite mantener un cold spare en una ubicación remota, activarlo durante pruebas periódicas y utilizarlo para restaurar aplicaciones después de un fallo de hardware, un ciberataque u otra emergencia.
Estas capacidades encajan en diferentes diseños: producción en cloud privado y backups en otra ubicación, servicios desplegados en un hiperescalar con recuperación en Stackscale, clústeres Proxmox VE con almacenamiento en red, plataformas VMware que necesitan una segunda localización o migraciones progresivas desde entornos on-premise y cloud público.
El objetivo no debería ser trasladar toda la infraestructura a un único destino. La prioridad es construir una alternativa que pueda utilizarse cuando sea necesaria.
Un plan de salida cloud en 90 días
Una primera evaluación no requiere iniciar una migración completa. Puede organizarse en tres meses:
| Fase | Trabajo necesario | Resultado |
|---|---|---|
| Inventario | Identificar máquinas, datos, servicios, redes y dependencias | Mapa actualizado de la plataforma |
| Clasificación | Ordenar las cargas por criticidad, sensibilidad y regulación | Prioridades de actuación |
| Jurisdicción | Revisar proveedor, matriz, subcontratistas y países implicados | Mapa de exposición jurídica |
| Portabilidad | Documentar formatos, APIs, imágenes y herramientas de exportación | Barreras técnicas conocidas |
| Costes | Calcular transferencia, ingeniería, licencias y doble operación | Presupuesto inicial de salida |
| Destino | Seleccionar una infraestructura alternativa | Capacidad de recuperación disponible |
| Piloto | Migrar o restaurar una carga representativa | Procedimiento probado |
| Continuidad | Definir RTO, RPO y tolerancia a interrupciones | Objetivos medibles |
| Seguridad | Revisar identidades, claves, cifrado y registros | Control durante la transición |
| Pruebas | Repetir exportaciones, restauraciones y conmutaciones | Plan vigente y verificable |
Durante el primer mes, la empresa puede completar el inventario y clasificar las cargas. En el segundo, seleccionar un sistema representativo, preparar el destino y ejecutar una primera migración o restauración. El tercer mes debe servir para medir tiempos, documentar excepciones y presentar a dirección los costes y riesgos detectados.
El resultado no tiene que ser una migración inmediata. Saber que existe una alternativa, cuánto cuesta, cuánto tarda y qué dependencias deben resolverse ya mejora la capacidad de decisión.
La soberanía cloud se vuelve útil cuando deja de ser un concepto político y se traduce en arquitectura, contratos, procedimientos y pruebas. Entrar en una plataforma es una decisión técnica y económica. Conservar la capacidad de elegir cómo y cuándo salir es una decisión de continuidad de negocio.
Preguntas frecuentes
¿Alojar los datos en una región europea evita la aplicación del CLOUD Act?
No necesariamente. La ubicación física es relevante, pero también debe comprobarse si el proveedor está sujeto a la jurisdicción estadounidense y si posee, custodia o controla la información.
¿El Data Act obliga a que una migración cloud sea gratuita?
No. Desde el 12 de enero de 2027 elimina los gastos de cambio definidos por el reglamento, pero la empresa seguirá asumiendo costes de ingeniería, adaptación, transferencia, pruebas y operación.
¿Una estrategia de soberanía obliga a abandonar los hiperescalares?
No. Puede combinar cloud público, cloud privado, bare-metal, proveedores europeos y una ubicación independiente para backups o recuperación. Cada carga debe situarse según su riesgo, criticidad y dependencia técnica.
¿Cuál es el primer paso para reducir la dependencia de un proveedor?
Inventariar las cargas y sus dependencias, revisar la jurisdicción aplicable y realizar una prueba real de exportación, migración o restauración en una infraestructura alternativa.
Fuentes:
- Webinar Despeja tu Cloud, celebrado por Aire el 08/07/2026.
- Reglamento (UE) 2023/2854, Data Act, especialmente sus artículos 23 a 32.
- Código de Estados Unidos, título 18, sección 2713, sobre el alcance territorial del CLOUD Act.
- Comisión Europea, propuesta del Cloud and AI Development Act, presentada el 03/06/2026.
- Stackscale, soluciones de cloud privado con Proxmox VE y VMware.
- Stackscale, almacenamiento con georreplicación síncrona.
- Stackscale, infraestructura reservada para Disaster Recovery.
