Tecnología

Una nube no es soberana solo por guardar datos cerca: exige ocho controles

|Autor: Equipo editorial de QUASA|5 lectura mínima| 1
Una nube no es soberana solo por guardar datos cerca: exige ocho controles

Una nube soberana no es simplemente un servicio que almacena datos en España o en otro país de la Unión Europea. Para sostener esa etiqueta debe ofrecer control verificable sobre ocho ámbitos: estrategia, jurisdicción, datos e IA, operaciones, cadena de suministro, tecnología, seguridad y cumplimiento, y sostenibilidad.

La residencia responde principalmente a dónde se almacenan y procesan los datos. La soberanía añade quién puede acceder a ellos, quién custodia las claves, desde dónde se administra la plataforma, qué leyes alcanzan al proveedor y sus matrices, de qué terceros depende el servicio y si el cliente puede migrarlo o mantenerlo sin asistencia externa.

Ocho dimensiones, no una certificación automática

La explicación de la Comisión Europea describe dos mecanismos complementarios: los niveles SEAL y una puntuación calculada sobre 48 criterios, distribuidos entre las ocho categorías. El sistema distingue desde la ausencia de soberanía hasta el control digital pleno; el nivel global SEAL queda limitado por el objetivo que obtenga la valoración más baja.

El marco nació para una contratación de servicios de nube de las instituciones europeas. No convierte automáticamente en «certificado» a cualquier producto que adopte la palabra soberano ni fija el mismo nivel para todas las cargas: permite definir un umbral, pedir documentación comparable y descubrir dependencias que una declaración de residencia no muestra.

Los ocho controles que debe superar el proveedor

Evaluación de las ocho categorías europeas con pruebas legales, técnicas, operativas y de proveedores antes de aprobar una nube soberana.

La guía de implementación del marco detalla qué examina cada categoría y advierte que la revisión debe atravesar todas las capas técnicas, proveedores y subcontratistas. Estas son las preguntas que permiten trasladar ese esquema a una evaluación contractual.

  1. Control estratégico. ¿Dónde se encuentra la autoridad final para decidir sobre la empresa y la evolución del servicio? Hay que identificar propiedad, financiación, centros de decisión, riesgo de adquisición y capacidad de continuar si un fabricante crítico retira soporte o actualizaciones.
  2. Control legal y jurisdiccional. ¿Qué leyes gobiernan al proveedor, su matriz, el contrato y la propiedad intelectual? La revisión debe determinar la exposición a normas extraterritoriales y si existen vías legales, contractuales o técnicas para que una autoridad no europea exija acceso a datos o sistemas.
  3. Control de datos e IA. ¿Dónde se almacenan, procesan, replican y eliminan datos, metadatos, registros y copias? El cliente debe conocer quién controla materialmente las claves criptográficas, cómo se auditan los accesos y qué dependencias externas intervienen en modelos y canalizaciones de IA.
  4. Control operativo. ¿Desde qué países trabajan administradores y equipos de soporte, y bajo qué jurisdicción? También importa que existan documentación, conocimientos y personal capaces de operar, mantener y recuperar la plataforma sin depender necesariamente de equipos ajenos a la UE.
  5. Control de la cadena de suministro. ¿Quién aporta centros de datos, hardware, firmware, software, identidad, actualizaciones y soporte? La lista debe incluir proveedores y subproveedores críticos, su procedencia y jurisdicción, el procedimiento para comunicar cambios y el alcance real de los derechos de auditoría.
  6. Control tecnológico. ¿Puede otra entidad integrar, auditar, mantener o sustituir componentes? Deben revisarse la documentación de arquitectura y flujos, las interfaces y protocolos, el uso de estándares abiertos, las licencias y cualquier dependencia propietaria que dificulte una sustitución.
  7. Control de seguridad y cumplimiento. ¿Quién controla registros, alertas, respuesta a incidentes, parches y auditorías? Una certificación aporta evidencia sobre su ámbito concreto, pero no demuestra por sí sola que las operaciones de seguridad estén bajo jurisdicción europea ni que puedan continuar sin un proveedor extranjero.
  8. Control ambiental. ¿Qué dependencias físicas condicionan la continuidad a largo plazo? El marco considera consumo y procedencia de la energía, uso de agua, escasez de materiales, eficiencia, emisiones y reutilización o retirada del hardware.

La promesa comercial debe convertirse en evidencia

Trazabilidad de un servicio de nube y sus subcontratistas mediante contratos, registros de acceso y evidencias de auditoría.

Una respuesta útil relaciona cada requisito con una prueba concreta: cláusulas contractuales, mapa de jurisdicciones, diagrama de flujos, inventario de subencargados, política de claves, registros de acceso privilegiado, informes de auditoría y procedimientos de borrado. Las afirmaciones deben desglosarse por servicio, porque una región europea no demuestra que telemetría, soporte, copias o plano de control respeten la misma frontera.

La evidencia también debe cubrir las excepciones y situaciones adversas: cambio de subcontratista, adquisición del proveedor, retirada de una licencia, pérdida de conectividad o terminación del contrato. Sin derechos de notificación, auditoría y revisión periódica, una arquitectura inicialmente aceptable puede cambiar mientras la etiqueta comercial permanece intacta.

Portabilidad y desconexión prueban la autonomía

Prueba de portabilidad que restaura una carga regulada con configuraciones, identidades, metadatos y registros en infraestructura controlada por el cliente.

Una prueba de salida no termina al descargar archivos. Debe comprobar si aplicaciones, configuraciones, identidades, metadatos, registros y dependencias pueden reconstruirse en el destino. El Reglamento europeo de Datos obliga a retirar obstáculos al cambio hacia otro proveedor o una infraestructura local y exige información contractual sobre datos exportables, formatos, interfaces y limitaciones técnicas; aun así, el cliente debe verificar que la carga recupera la funcionalidad necesaria.

La operación desconectada plantea una prueba todavía más estricta para determinadas cargas críticas: revela si identidades, administración y servicios esenciales continúan sin conexión con una nube pública. La documentación de Microsoft sobre su nube privada soberana describe entornos administrados por el cliente con control de infraestructura, residencia y operaciones, además de implementaciones totalmente desconectadas para componentes concretos. Es un ejemplo de capacidad técnica, no una prueba de que toda configuración supere los ocho controles.

Cómo emitir una decisión justificable

La evaluación debe empezar por la carga, no por la etiqueta del catálogo. Para cada uno de los ocho ámbitos conviene registrar el nivel requerido, la evidencia aportada, las excepciones, el responsable contractual y una comprobación repetible durante la vigencia del servicio.

Una dependencia puede aceptarse si el riesgo, la compensación y el plazo de revisión quedan documentados. Lo que la residencia local no permite es omitir el análisis: una oferta solo puede considerarse soberana para una carga determinada cuando sus controles jurídicos, operativos, tecnológicos y de suministro son verificables.

Lee también:

Compartir:

Suscríbete a nuestro boletín

Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.

0