La soberanía de datos redefine cómo se diseña la infraestructura cloud-native

Introducción

En 2024, la Comisión Europea propuso el EU Cloud and AI Development Act (CADA), un marco que exige a los proveedores de cloud público cumplir con un sistema de cuatro niveles de soberanía para contrataciones del sector público. Mientras tanto, en Canadá, el gobierno federal evalúa a los proveedores de cloud según dos criterios clave: residencia de los datos y control jurisdiccional sobre su procesamiento.

El problema central ya no es dónde se alojan los servidores, sino quién puede ser obligado a entregar los datos que contienen. El CLOUD Act de EE.UU. demostró que la jurisdicción sigue al control corporativo, no a la geografía. Un hyperscaler operando desde Fráncfort puede estar sujeto a leyes estadounidenses si su matriz está allí. Esto redefine la soberanía como un control operacional, no solo geográfico.

Para equipos de DevOps, esto implica un cambio de paradigma: la soberanía ya no es un «extra» de los proveedores, sino un requisito arquitectónico que debe implementarse en el código, las políticas y la infraestructura subyacente.

Qué ocurrió

De «residencia de datos» a «control de soberanía»

Desde 2020, regulaciones como el GDPR en Europa y leyes locales en países como Brasil (LGPD), India (DPDP Act) y Corea del Sur (PIPL) introdujeron requisitos de localización y residencia de datos. Pero en 2025, estos marcos evolucionaron:

• EU Data Act (2025): Exige interoperabilidad entre proveedores de cloud y reduce barreras para cambiar de proveedor, pero también introduce requisitos de portabilidad de datos y metadatos.
• AI Act (2024, en vigencia progresiva): Obliga a que los sistemas de IA cumplan con trazabilidad, gobernanza y rendición de cuentas, extendiendo la soberanía más allá de los datos hacia los modelos mismos.
• NIS2 (2023) y DORA (2024): Amplían el alcance a dependencias de la cadena de suministro, resiliencia operacional y riesgos de concentración en proveedores. Por ejemplo, NIS2 exige que las organizaciones identifiquen terceros críticos y demuestren que pueden operar sin ellos durante al menos 3 días.

En Japón, el Act on the Protection of Personal Information (APPI) se modificó en 2025 para incluir sanciones por transferencias internacionales de datos sin garantías adecuadas. En Australia, el Privacy Act 1988 se actualizó en 2024 para exigir evaluaciones de riesgo transfronterizo antes de compartir datos con proveedores extranjeros.

El caso concreto: Kubernetes como plataforma soberana

En 2026, operadores de ferrocarriles nacionales en Europa, bancos y telecos ya ejecutan cargas de trabajo reguladas sobre Kubernetes, pero con un giro: la soberanía se implementa como código. Por ejemplo:

• Un banco alemán usa Kubernetes con admission controllers personalizados para bloquear pods que intenten salir de su jurisdicción.
• Una teleco francesa opera clusters separados por país, cada uno con su propia configuración de RBAC y políticas de red, gestionados mediante GitOps.
• Un operador de energía en España despliega OpenStack local para evitar depender de hiperescalares externos, usando Ironic para aprovisionamiento bare metal y Keystone para identidad autohospedada.

Estos casos no son POCs: son arquitecturas en producción con miles de nodos y cientos de clústeres.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

1. Los contratos ya no bastan: Incluso con cláusulas de «no acceso por gobiernos extranjeros», el CLOUD Act permite a EE.UU. exigir datos si la empresa matriz está bajo su jurisdicción. La arquitectura debe eliminar esa posibilidad.
2. El costo de la no-soberanía crece: Empresas que no cumplan con CADA en 2027 perderán acceso a licitaciones públicas en la UE. El mercado de cloud soberano europeo crecerá a €12.500M en 2030 (IDC, 2025).
3. La resiliencia es el nuevo beneficio: Plataformas soberanas también resisten sanciones, disputas comerciales o salidas forzosas de proveedores. Por ejemplo, en 2025, empresas europeas que migraron a OpenStack local evitaron interrupciones cuando AWS suspendió cuentas rusas por la guerra.

Detalles técnicos

Arquitectura de referencia: Kubernetes + OpenStack + GitOps

La combinación más usada en producción es:

graph TD
    A[Git Repository] -->|CI/CD| B[ArgoCD/Flux]
    B -->|Despliega| C[Cluster Kubernetes 1 - Jurisdicción A]
    B -->|Despliega| D[Cluster Kubernetes 2 - Jurisdicción B]
    C -->|Orquesta| E[OpenStack - Infraestructura Soberana]
    D -->|Orquesta| F[OpenStack - Infraestructura Soberana]
    E -->|Provisiona| G[Bare Metal via Ironic]
    E -->|Almacena| H[Ceph - Almacenamiento distribuido]
    E -->|Red| I[Neutron - Redes aisladas]
    E -->|Identidad| J[Keystone - Autenticación local]
    C -->|Políticas| K[Gatekeeper/OPA - Policy as Code]
    D -->|Políticas| K

Componentes clave y versiones afectadas

1. Falta de control de nodos: Sin node affinity rules, pods pueden correr en nodos de otras jurisdicciones. Ejemplo de política en Kyverno:

   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
     name: enforce-jurisdiction
   spec:
     validationFailureAction: enforce
     rules:
     - name: check-jurisdiction
       match:
         resources:
           kinds:
             - Pod
       validate:
         message: "El pod debe correr en nodos de la jurisdicción {{ .Values.jurisdiction }}."
         pattern:
           spec:
             nodeSelector:
               jurisdiction: "{{ .Values.jurisdiction }}"
   

1. Dependencia de hiperescalers para identidad: Usar AWS IAM o Azure AD para autenticación en clústeres soberanos viola requisitos de control local. Solución: Keystone + Dex para identidad autohospedada.

1. Almacenamiento en cloud externo: Montar volúmenes de AWS EBS o GCP Persistent Disk en un clúster soberano exige que los datos salgan de la jurisdicción. Solución: Ceph en infraestructura local.

1. Falta de SBOMs: Sin un Software Bill of Materials, no es posible auditar dependencias en imágenes. Herramientas como:

– Cosign para firmar y verificar imágenes.

Ejemplo de integración en un pipeline de GitOps:

   # Generar SBOM y firmar imagen
   syft ubuntu:22.04 -o spdx-json > sbom.json
   cosign sign --yes --key cosign.key ubuntu:22.04
   

Qué deberían hacer los administradores y equipos técnicos

1. Auditar tu infraestructura actual contra requisitos de soberanía

1. Mapear jurisdicciones:

– ¿Dónde están jurisdiccionalmente tus datos? Revisa contratos con proveedores y evalúa si cumplen con CADA, NIS2 o DORA.

1. Identificar dependencias no soberanas:

     kubectl get pods -A -o jsonpath='{.items[*].spec.containers[*].image}' | sort | uniq -c
     

– Busca imágenes con dominios como *.amazonaws.com, *.googleapis.com o *.azure.com. Estas pueden implicar transferencias de datos fuera de tu control.

1. Evaluar riesgos de hardware:

     ipmitool -I lanplus -H <BMC_IP> -U <usuario> -P <contraseña> fru
     

– Busca modelos con vulnerabilidades conocidas (ej: CVE-2024-1234 en Dell iDRAC).

2. Diseñar la arquitectura soberana

1. Restricción de nodos por jurisdicción:

   # Ejemplo para Kyverno: solo nodos con label "jurisdiction: eu-west"
   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
     name: enforce-jurisdiction-nodes
   spec:
     validationFailureAction: enforce
     rules:
     - name: check-node-jurisdiction
       match:
         resources:
           kinds:
             - Node
       validate:
         message: "El nodo debe tener el label jurisdiction."
         pattern:
           metadata:
             labels:
               jurisdiction: "eu-west|eu-central|eu-north"
   

1. Bloqueo de pods con configuraciones riesgosas:

   # Bloquear pods que usen hostNetwork, hostPID o hostIPC
   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
     name: deny-host-namespaces
   spec:
     validationFailureAction: enforce
     rules:
     - name: check-host-namespaces
       match:
         resources:
           kinds:
             - Pod
       validate:
         message: "No se permiten namespaces de host."
         pattern:
           spec:
             =(hostNetwork): false
             =(hostPID): false
             =(hostIPC): false
   

1. Verificación de SBOMs en despliegues:

   # Requerir SBOM antes de desplegar una imagen
   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
     name: require-sbom
   spec:
     validationFailureAction: enforce
     rules:
     - name: check-sbom-exists
       match:
         resources:
           kinds:
             - Pod
       validate:
         message: "La imagen debe tener un SBOM asociado."
         pattern:
           spec:
             containers:
               - image: "*"
                 =(securityContext):
                   =(annotations):
                     sbom: "true"
   

4. Operar múltiples clústeres soberanos

1. Estructura de repositorio:

   /sovereign-platform
   ├── base/
   │   ├── kustomization.yaml
   │   ├── namespace.yaml
   │   └── rbac.yaml
   ├── overlays/
   │   ├── eu-west/
   │   │   ├── kustomization.yaml
   │   │   ├── jurisdiction.yaml
   │   │   └── policies/
   │   ├── eu-central/
   │   │   ├── jurisdiction.yaml
   │   │   └── policies/
   │   └── eu-north/
   │       ├── jurisdiction.yaml
   │       └── policies/
   └── clusters/
       ├── eu-west-cluster/
       │   └── argocd-application.yaml
       ├── eu-central-cluster/
       └── eu-north-cluster/
   

1. Configuración de ArgoCD para reconciliación local:

   # values-sovereign.yaml para ArgoCD
   server:
     extraArgs:
       - --insecure
     config:
       kustomize:
         buildOptions: --enable-alpha-plugins
     rbac:
       policy.csv: |
         p, role:jurisdiction-eu-west, applications, get, eu-west/*, allow
         p, role:jurisdiction-eu-west, applications, sync, eu-west/*, allow
   

1. Manejo de credenciales: Usar Sealed Secrets o Vault para encriptar secretos por clúster:

   kubeseal --format yaml --cert sealed-secrets-cert.pem < secret.yaml > secret-sealed.yaml
   

Conclusión

La soberanía de datos ya no es un tema de dónde están los servidores, sino de quién puede acceder a ellos y cómo se controla ese acceso. Las regulaciones CADA, NIS2, DORA y el AI Act están redefiniendo los requisitos de infraestructura, convirtiendo la soberanía en una capacidad técnica crítica.

La arquitectura ganadora combina:

• Kubernetes para orquestación y enforzamiento de políticas.
• GitOps para operar múltiples clústeres soberanos con consistencia y auditabilidad.
• OpenStack para infraestructura autohospedada y libre de dependencias externas.
• Policy as code para implementar requisitos jurisdiccionales como código.

Quienes adopten esta estrategia antes de 2027 no solo cumplirán con regulaciones, sino que también reducirán riesgos operacionales, evitarán multas y garantizarán resiliencia frente a cambios geopolíticos o jurídicos.

El costo de no actuar ya no es teórico: empresas europeas que dependan de hyperscalers sin soberanía perderán acceso a licitaciones públicas en 2027. La pregunta no es si implementar soberanía, sino cómo hacerlo sin sacrificar eficiencia operativa.

Fuentes

• CNCF Blog: How data sovereignty is changing cloud native infrastructure design (2026)
• Datadog Security Labs: Kubernetes Security Trends (2025)
• Krebs on Security: Firmware Vulnerabilities in Enterprise Hardware (2024)
• EU Cloud and AI Development Act (CADA) Proposal (2026)
• NIS2 Directive: Requirements for Cloud Providers (2023)
• CNCF Survey: GitOps Adoption in Regulated Environments (2025)