Soberanía empieza en el botón de apagado
Un botón en una diapositiva no es un interruptor de apagado
En abril de 2026, la Comisión Europea adjudicó un contrato de 180 millones de euros para la nube soberana a cuatro proveedores que prestan servicio a las instituciones, órganos, oficinas y agencias de la Unión. La licitación se gestionó a través del Sistema Dinámico de Adquisición Cloud III. Al explicar el resultado, la Comisión explicó también el instrumento que lo respalda: un Marco de Soberanía en la Nube con un Nivel de Garantía de Eficacia de la Soberanía y una puntuación global compuesta por 48 criterios en ocho categorías, entre ellas la estratégica, la jurídica y jurisdiccional, la de datos e IA, la operativa, la de cadena de suministro, la tecnológica, la de seguridad y cumplimiento, y la de sostenibilidad medioambiental.
Ese es un acontecimiento más interesante de lo que el adjetivo soberano suele sugerir. Una licitación tiene que convertir una palabra política en preguntas que puedan responderse con un expediente de contratación. ¿Quién puede acceder a los datos? ¿Quién puede operar la plataforma? ¿Qué ocurre cuando un proveedor cambia de propietario, cuando cambia una ley, cuando se retira un servicio o cuando una institución decide que el acuerdo ya no encaja? El marco de la Comisión no resuelve esas preguntas para todos los compradores. Hace algo más útil: admite que pertenecen a la misma sala.
La tentación es tratar la soberanía como un lugar. Ponga los servidores en Europa, firme con una filial europea, someta el contrato al derecho europeo y el problema parecerá resuelto. Cada uno de esos pasos puede importar. Ninguno de ellos es la propiedad completa. Un sistema puede estar físicamente cerca de las personas a las que sirve mientras sus claves decisivas, dependencias técnicas, autoridad operativa y exposición legal se encuentran en otro lugar. Una dirección europea puede ser verdadera y seguir siendo una respuesta incompleta.
Hay una prueba que hace visible esa brecha. Pregunte qué ocurre cuando la organización necesita detenerse. No porque detenerse sea deseable, ni porque se espere un fallo dramático, sino porque las instituciones serias deben poder cambiar de rumbo. ¿Puede una persona autorizada suspender el servicio? ¿Puede la organización inspeccionar el estado que se va a detener? ¿Puede conservar pruebas? ¿Puede trasladar la carga de trabajo? ¿Puede otro equipo asumir el control sin pedir al primer proveedor que siga siendo indispensable? Si la respuesta es vaga, la afirmación de soberanía sigue siendo un folleto.
Por eso la soberanía comienza en el interruptor de apagado. El interruptor no es un botón rojo teatral. Es una cadena de autoridad, acceso, conocimiento, equipos, contratos y alternativas. Tiene que funcionar un martes tranquilo, antes de que nadie haya preparado una nota de prensa. El resto de este artículo sigue esa cadena a través de la infraestructura de la nube, la política europea y la poco glamurosa ingeniería de la salida.
Cinco palabras que a menudo se hacen pasar unas por otras
La propiedad es el primer impostor. Nos dice quién tiene las acciones, nombra al consejo y recibe el beneficio económico. La propiedad puede ser importante para la soberanía, especialmente cuando el propietario controla la propiedad intelectual, las decisiones de inversión o la dirección a largo plazo de la empresa. No es lo mismo que el control operativo. Una organización de propiedad local puede depender de una plataforma operativa extranjera. Un servicio de titularidad pública puede no tener capacidad práctica para cambiar el software que lo ejecuta. Una filial puede estar constituida en un país mientras sus aprobaciones decisivas se toman en otro lugar.
La ubicación es el segundo. La residencia de los datos responde a una pregunta geográfica: ¿dónde se almacenan o procesan determinados datos, sistemas o instalaciones en virtud del acuerdo? Esa respuesta puede respaldar el cumplimiento legal, la planificación de la resiliencia o un presupuesto de latencia razonable. No responde quién puede administrar el entorno, qué ley puede obligar a un proveedor, qué subcontratistas pueden entrar en la cadena ni qué ocurre cuando un operador fuera de la ubicación tiene las credenciales privilegiadas.
La jurisdicción es el tercero. Tiene que ver con el orden legal que puede alcanzar a una organización, a su infraestructura o a sus datos. Un contrato puede elegir una ley aplicable, pero no puede hacer desaparecer otras facultades legales. Un servicio puede prestarse desde una instalación europea y aun así implicar a un proveedor sujeto a obligaciones en otro lugar. La cuestión no es declarar ilegítimo todo servicio transfronterizo. Se trata de dejar de tratar un marcador en el mapa como si fuera un análisis jurídico.
La autoridad operativa es el cuarto. Es la capacidad práctica de hacer que un sistema haga algo o deje de hacerlo: aprobar un lanzamiento, rotar una clave, aislar una red, restaurar una copia de seguridad, cambiar una política, eliminar a un administrador o transferir la responsabilidad a otro equipo. La autoridad operativa puede delegarse. Cuando se delega, la delegación tiene que ser visible, limitada y reversible. De lo contrario, el contrato otorga al cliente un control nominal mientras el proveedor conserva las únicas personas e interfaces capaces de ejercerlo.
La salida es el quinto. Es la capacidad de poner fin a un acuerdo y continuar la función necesaria en otro lugar o en una infraestructura que la organización controle. La salida no consiste simplemente en descargar una base de datos. Puede implicar configuración, identidades, claves de cifrado, modelos, contenedores, registros de auditoría, colas, integraciones, licencias, procedimientos operativos y el conocimiento necesario para reconstruir un servicio que funcione. Que se prometa que los datos pueden exportarse no es prometer que un servicio pueda reanudarse.
Estas palabras van juntas, pero no deben fundirse. La propiedad sin autoridad operativa es una escritura sin llave. La ubicación sin jurisdicción es una dirección sin un mapa del alcance legal. La autoridad operativa sin salida es un mando a distancia conectado a una máquina que nadie más puede reparar. La soberanía es la relación entre las cinco, puesta a prueba en el momento en que la conveniencia deja de decidir.
La prueba del interruptor de apagado
Una prueba útil del interruptor de apagado comienza con una instrucción deliberadamente poco llamativa: detener este sistema en un límite definido, de una manera definida y bajo una autoridad identificada. «Este sistema» tiene que ser específico. ¿Es un servicio, un inquilino, un trabajo de procesamiento, un flujo de datos, una cuenta de administrador, un punto final de modelo o toda una capacidad operativa? Un proveedor puede desactivar un punto final mientras los datos, las copias y las vías privilegiadas continúan en otro lugar. Un cliente puede cancelar un contrato y descubrir que la única exportación disponible es un conjunto de registros sin configuración utilizable.
Primero hay que preguntar quién está autorizado a ordenar la detención. La respuesta debe ser un rol, no la memoria de una persona. Un rol puede asignarse, comprobarse y cambiarse. Debe tener un desencadenante claro, una vía de escalado y un registro de la decisión. En una institución pública, la autoridad puede estar dividida entre la titularidad del servicio, la seguridad, la responsabilidad legal y un oficial de guardia. La división no es un defecto. Se convierte en un defecto cuando todos dan por hecho que otro puede actuar.
Después hay que preguntar qué credencial o mecanismo realiza realmente la detención. Un procedimiento documentado que termina con «contactar con el soporte» es una vía de escalado, no un interruptor de apagado. El soporte puede ser adecuado para una migración controlada, pero un servicio crítico también necesita una forma local o controlada de forma independiente de poner el sistema en un estado seguro. Eso no implica que cada cliente deba tener un botón físico de encendido. Significa que la organización debe conocer el límite de su propia autoridad, la autoridad del proveedor y el punto en el que se requiere una respuesta externa.
La siguiente pregunta es qué queda después de la detención. Una detención segura puede conservar los registros, retener las pruebas durante un periodo definido, cerrar las sesiones, revocar las credenciales, impedir nuevas escrituras y mantener una copia de solo lectura disponible para la investigación. También puede crear un estado peligroso si un proceso dependiente sigue enviando datos a un servicio que ya no se supervisa. Detener un componente no es lo mismo que detener la capacidad. El mapa de dependencias importa más que el color del botón.
Por último, hay que preguntarse si la organización puede reanudar la función sin volver a la misma dependencia por defecto. Un servicio puede detenerse para una acción de contención breve y luego reiniciarse. Eso es útil. La soberanía exige además una segunda vía: una ruta preparada hacia otro proveedor, un entorno local, un proceso manual conocido o un servicio deliberadamente reducido. La alternativa puede ser más lenta o menos elegante. No puede existir solo como una frase en un registro de riesgos.
Por tanto, la prueba del interruptor de apagado tiene cinco partes: autoridad, mecanismo, evidencia, dependencia y alternativa. Es una prueba institucional, no una característica de producto. Un proveedor puede ofrecer excelentes herramientas y aun así suspender la prueba si el cliente no puede ejercerlas. Un cliente puede tener un contrato y aun así suspenderla si nadie ha practicado el procedimiento. Una organización que ha ensayado la prueba puede descubrir las debilidades a tiempo, cuando aún son problemas de contratación e ingeniería y no emergencias públicas.
El control es una pila, no una pegatina
Imagina un sistema como una pila de habitaciones. En la base está la capa física: edificios, energía, refrigeración, rutas de red y hardware. Por encima se sitúan las capas técnicas: firmware, sistemas operativos, virtualización, almacenamiento, bases de datos, identidad y código de aplicación. Sobre ellas están las capas operativas: personas, procedimientos, supervisión, respuesta a incidentes y gestión de lanzamientos. Junto a ellas discurre una capa legal y económica: propiedad, contratos, licencias, jurisdicción, financiación y la capacidad de adquirir una alternativa.
La metáfora de la pila no afirma que todos los sistemas tengan cinco plantas perfectas. Es una forma de plantear una pregunta más precisa que «¿es esto soberano?». El control puede ser fuerte en una habitación y débil en otra. Una institución puede tener derecho a inspeccionar una aplicación sin tener ninguna visibilidad de la vía de administración física. Puede tener las claves de cifrado y carecer de la capacidad de sustituir el hardware que mantiene vivo el servicio de claves. Puede tener una cláusula de salida contractual y arrastrar una dependencia operativa de un equipo que solo emplea el proveedor.
No hay virtud en fingir que todas las capas deben ser europeas del mismo modo. La economía digital de Europa depende de cadenas de suministro internacionales, investigación, normas y mercados. La autonomía estratégica no es una fantasía de autosuficiencia total. La propia definición política de la Comisión Europea habla de la capacidad de actuar con independencia y, a la vez, reducir la dependencia de proveedores no europeos. Actuar con independencia puede significar tener una opción creíble, no fabricar cada componente tras una valla nacional.
La distinción práctica está entre una dependencia que es visible y acotada, y una dependencia que se confunde con control. Un comprador puede decidir que un procesador, un componente de software o un servicio externo concretos son aceptables. La decisión debe incluir el motivo, las medidas compensatorias, la ruta de sustitución y la autoridad para revisarla. Una dependencia que está registrada puede gestionarse. Una dependencia oculta tras una etiqueta europea solo se descubrirá cuando la etiqueta deje de abrir puertas.
La pila también explica por qué una puntuación de soberanía necesita algo más que la propiedad. El marco de 2026 de la Comisión sitúa unos junto a otros los criterios estratégicos, jurídicos y jurisdiccionales, de datos e IA, operativos, de cadena de suministro, tecnológicos, de seguridad y cumplimiento, y de sostenibilidad medioambiental. Una lista así no produce por arte de magia un servicio soberano. Sí reconoce que el control está distribuido. Eso ya es un punto de partida mejor que una única insignia.
Para los ingenieros, la pila invita a hacer un inventario de dependencias. Para los equipos de contratación, invita a plantear preguntas sobre subcontratistas, claves, formatos, interfaces, soporte y migración. Para los juristas, invita a trazar un mapa del alcance legal que sigue al proveedor y a la infraestructura, no al nombre comercial. Para los líderes, plantea una observación sutil: la dependencia más cara suele ser aquella que todos creían ya resuelta.
La ubicación es útil, e insuficiente
Un centro de datos es un lugar real. Sus muros afectan a la seguridad física, al consumo energético, a la latencia de red, a las condiciones laborales y a la resiliencia de un servicio. Un requisito de residencia puede impedir algunas transferencias y puede hacer que una auditoría sea más concreta. También puede ser una expresión sensata de la responsabilidad jurídica y política de un organismo público. No hace falta menospreciar la geografía para plantear el argumento del control.
El error está en pedirle a la geografía que responda a todas las demás preguntas. Un servidor en Róterdam no le dice por sí solo a un comprador quién tiene acceso administrativo. Un bucket de almacenamiento en Milán no indica qué telemetría se copia a un sistema de soporte. Una filial europea no revela la jurisdicción del grupo que suministra su plano de control. La ubicación de un edificio y el alcance de una organización son hechos relacionados, no hechos intercambiables.
La Ley de Datos hace explícita parte de esta distinción. El artículo 28 exige que los proveedores de servicios de tratamiento de datos pongan a disposición la jurisdicción a la que está sujeta la infraestructura utilizada para un servicio, junto con una descripción general de las medidas relativas al acceso gubernamental internacional o a la transferencia de datos no personales cuando ello pudiera entrar en conflicto con el Derecho de la Unión o de los Estados miembros. El requisito es valioso porque convierte una vaga garantía en información que un cliente puede archivar. No es una garantía de que ninguna autoridad vaya a solicitar jamás el acceso, ni sustituye a la propia evaluación jurídica y técnica del cliente.
La ubicación también cambia con el tiempo. Un proveedor puede trasladar una carga de trabajo, añadir un subcontratista, introducir una vía de soporte, modificar el diseño del plano de control o alterar su propiedad. Una declaración de residencia que era precisa el día de la firma puede quedar desactualizada. La soberanía necesita por tanto una señal de cambio: ¿a quién se notifica, qué cambio activa la revisión y quién puede pausar el servicio mientras se realiza la revisión? Sin esa señal, una afirmación sobre la ubicación es una instantánea que se hace pasar por una propiedad.
Consideremos una organización de investigación europea hipotética que exige que su conjunto de datos principal permanezca dentro de la Unión. El requisito puede cumplirse mientras un flujo de trabajo de soporte envía material de diagnóstico a un tercer país, mientras un servicio de identidad controlado por el proveedor administra el clúster, o mientras un formato propietario hace imposible su sustitución. Ninguna de esas posibilidades se afirma como un hecho sobre una organización concreta. Son la razón por la que un control de ubicación debe unirse a un mapa de accesos, un mapa de jurisdicción y un ensayo de salida.
La afirmación más honesta es sencilla: la ubicación puede reducir una clase de riesgo. No puede sostener por sí sola todo el argumento de la soberanía. Un edificio es una capa. El control es la pila.
La jurisdicción no es una nota a pie de página
La jurisdicción entra en la conversación siempre que una promesa se encuentra con un poder. Un contrato puede indicar dónde se resolverán los litigios y qué ley rige la relación. Eso es importante para la previsibilidad y la ejecución. No significa que un proveedor, su matriz, su personal o su infraestructura sean invisibles para cualquier otro sistema jurídico. La pregunta para un comprador no es si se puede nombrar una jurisdicción. Es qué vías legales pueden alcanzar a las personas, los sistemas y los datos implicados, y qué se le exigiría al proveedor si esas vías se utilizaran.
No se trata de un argumento para tratar toda conexión extranjera como prohibida. Es un argumento para sustituir la etiqueta de nacionalidad por un análisis documentado. Un proveedor puede tener una empresa europea, operaciones europeas y una cadena de suministro que cruce varias fronteras. Un comprador puede aceptar ese acuerdo porque el servicio es resiliente, los controles de acceso son sólidos, los datos pertinentes son limitados y existe una alternativa preparada. La decisión es defendible cuando la dependencia y el riesgo residual son visibles.
La palabra control también requiere cuidado aquí. Un proveedor puede decir que el cliente controla sus datos porque el cliente elige los permisos. Eso puede ser cierto dentro del servicio. No significa automáticamente que el cliente controle al proveedor, la ruta de mantenimiento de la plataforma o la respuesta legal a una orden externa. La palabra debe matizarse: control del acceso, control de las claves, control de la configuración, control de las operaciones o control de la decisión empresarial. La precisión es menos llamativa que un logotipo de soberanía, pero resiste mejor una auditoría.
El marco de la Comisión sitúa las cuestiones legales y jurisdiccionales junto a las cuestiones operativas y de cadena de suministro. Esa disposición importa. La exposición legal no puede reducirse a un párrafo de un contrato, y el control técnico no puede reducirse a un diagrama. Si un sistema está pensado para respaldar una función pública, la institución necesita pruebas suficientes para explicar tanto cómo opera como qué autoridades pueden afectarlo. Las pruebas pueden ser incompletas. No deberían ser imaginarias.
Un expediente de jurisdicción práctico debe identificar las entidades jurídicas de la cadena de servicio, la ubicación y el papel de la infraestructura pertinente, las vías de acceso disponibles para el personal del proveedor y los subcontratistas, las leyes aplicables y vigentes que el proveedor haya declarado, y el procedimiento de notificación y respuesta ante solicitudes gubernamentales. También debe indicar qué hará el cliente si las respuestas cambian. Esa última frase es donde la soberanía empieza a volverse operativa en lugar de descriptiva.
El experimento de contratación de la Comisión
La contratación de nube soberana de la Comisión es útil porque hace observable la palabra. La explicación pública indica que se seleccionó a cuatro proveedores para un contrato de 180 millones EUR al servicio de las entidades de la Unión. Describe dos medidas complementarias: un Nivel de Efectividad de la Garantía de Soberanía, con umbrales para la soberanía de datos, la autonomía tecnológica y la soberanía plena, y una puntuación global basada en 48 criterios definidos agrupados en ocho categorías.
Hay una disciplina pequeña pero importante en esa redacción. El marco es un instrumento de evaluación. No convierte a un proveedor en un objeto soberano por declaración. Una puntuación puede hacer visibles las compensaciones, ayudar a un comprador a comparar ofertas y crear un registro de por qué se adjudicó un contrato. También puede ser manipulada o quedar obsoleta si nadie verifica las pruebas que la respaldan. La pregunta sensata no es si el marco es la respuesta definitiva. Es si los criterios sobreviven al contacto con las operaciones.
Tomemos la categoría llamada soberanía operativa. Debería suscitar preguntas como quién puede cambiar una ruta de red, quién puede rotar una clave, quién puede leer un registro de incidentes, con qué rapidez puede un cliente asumir una función y qué acciones requieren la participación del proveedor. Esas no son cualidades abstractas. Pueden demostrarse en un ejercicio controlado. Si el ejercicio es imposible porque el proveedor no puede exponer el estado relevante o porque el cliente no tiene autoridad para iniciarlo, la debilidad forma parte de la puntuación, no es un detalle incómodo que deba dejarse en un anexo.
Lo mismo ocurre con las categorías de cadena de suministro y tecnológicas. Un comprador no necesita exigir una prueba de pureza imposible. Sí necesita saber qué dependencias son esenciales, cuáles pueden sustituirse, cuáles tienen bloqueo contractual o técnico y cómo sería una interrupción. «Tenemos un equipo de soporte europeo» y «podemos continuar esta función cuando un componente upstream crítico no esté disponible» son afirmaciones distintas. La primera trata sobre personas. La segunda trata sobre resiliencia y elección.
La contratación pública es especialmente adecuada para este trabajo porque una licitación puede exigir pruebas antes de que un servicio se convierta en la opción predeterminada. Una licitación puede solicitar un formato portable, un registro de dependencias actualizado, un procedimiento de notificación de cambios, un ensayo de salida y una matriz de autoridad. Puede puntuar las respuestas y rechazar un servicio que no pueda mostrarlas. También puede pagar por la capacidad de mantener la alternativa, porque una salida que solo existe en un documento inactivo se deteriorará.
La publicación de la Comisión presenta su marco como un punto de referencia para organizaciones públicas y privadas. Es una invitación, no un respaldo a que cada organización copie todos los pesos. Un servicio pequeño y una plataforma de ámbito continental tendrán riesgos diferentes. El método que merece la pena trasladar es el hábito de descomponer la soberanía en criterios, pruebas y umbrales. La contratación puede decir que no. Ese es uno de los pocos poderes que se debilita después del despliegue.
La salida es una propiedad de ingeniería
Los contratos de nube suelen describir la salida como si fuera un párrafo final cortés. La Ley de Datos la trata como un proceso. El artículo 23 exige que los proveedores de servicios de procesamiento de datos eliminen los obstáculos que impiden a un cliente rescindir un contrato, celebrar un contrato nuevo, portar datos exportables y activos digitales, lograr la equivalencia funcional cuando corresponda o desagregar servicios cuando sea técnicamente viable. Los artículos 25 a 30 detallan después las obligaciones contractuales, de información, de cooperación, de cargos y técnicas.
Los detalles son inusualmente prácticos. En el caso ordinario, un contrato debe prever un plazo máximo de preaviso de dos meses y un período transitorio obligatorio de no más de 30 días naturales, durante el cual el proveedor continúa el servicio y respalda la continuidad. Si el proveedor alega que el período de 30 días es técnicamente inviable, debe notificarlo al cliente en un plazo de 14 días hábiles, justificar la alegación e indicar un período transitorio alternativo de no más de siete meses. El cliente dispone de un período de recuperación de al menos 30 días naturales después del período transitorio, y el contrato debe abordar el borrado tras un cambio exitoso.
El artículo 29 también fija la dirección de las tarifas de cambio de proveedor. A partir del 12 de enero de 2027, los proveedores no podrán imponer tarifas por el proceso de cambio. Durante la transición, solo podrán aplicarse tarifas reducidas dentro de los límites establecidos por el Reglamento, y los clientes potenciales deberán ser informados de las comisiones y penalizaciones que puedan corresponder. El artículo 30 aborda las interfaces abiertas, las especificaciones de interoperabilidad y la exportación en formato legible por máquina. No son detalles decorativos. Son las piezas con las que debe ensamblarse un servicio de sustitución.
Un derecho legal no es lo mismo que un camino ensayado. Un cliente puede recibir una exportación conforme y aun así carecer de las personas, las herramientas o el tiempo para restaurar el servicio. Los datos pueden ser portables mientras el significado de un identificador no lo es. Un modelo puede copiarse mientras su conjunto de evaluación, la política de indicaciones, las reglas de acceso y el historial de supervisión quedan atrás. Un contenedor puede trasladarse mientras los supuestos de identidad y gestión de claves impidan que se inicie. La ley mejora el suelo. La ingeniería decide si alguien puede caminar sobre él.
Por eso la salida debe probarse por capas. Comience con una muestra de los datos exportables y reconstrúyala en un entorno separado. Luego restaure las identidades y los permisos con el principio de mínimo privilegio. Reconstruya el servicio a partir de la configuración documentada, no de la memoria de un ingeniero. Reproduzca cargas de trabajo representativas y compare los resultados, incluidos los casos que deberían fallar. Compruebe que los registros de auditoría conservan su significado. Repita el ejercicio tras un cambio material. Si el ejercicio requiere una intervención no declarada del proveedor, registre esa dependencia en lugar de calificar el ejercicio de independiente.
La expresión equivalencia funcional también merece contención. La Ley de Datos la define en torno a un resultado materialmente comparable para las funciones compartidas en el mismo tipo de servicio. No promete que dos proveedores tengan arquitecturas, precios, rendimiento o soporte idénticos. Un comprador debe especificar qué debe seguir siendo equivalente, qué puede degradarse temporalmente y qué puede cambiar. Una ruta de salida que preserve todas las comodidades puede ser imposible. Una ruta de salida que preserve la función pública puede ser suficiente, siempre que la institución haya elegido esa compensación de antemano.
El interruptor de apagado pertenece a una institución
Es tentador colocar el interruptor de apagado en una demostración del producto. Pulse un control, observe cómo un indicador verde se vuelve gris y llame gobernable al sistema. La autoridad real es más incómoda. Reside en una institución con descripciones de puestos, delegaciones, vacaciones, prioridades contrapuestas y personas que quizá no sepan que son quienes deben actuar.
Eso no significa que todos los empleados deban poder detener todos los sistemas. Significa que la autoridad debe diseñarse. El propietario del servicio decide para qué sirve la función. Seguridad puede identificar un desencadenante de contención. Los equipos jurídico y de privacidad pueden identificar restricciones sobre las pruebas y el acceso. Operaciones puede ejecutar el procedimiento. La dirección puede resolver un conflicto entre continuidad y retirada. Los roles pueden combinarse en una organización pequeña, pero las decisiones deben seguir siendo explícitas.
Consideremos un servicio público regional hipotético que utiliza una plataforma alojada para tramitar solicitudes. Nadie tiene que inventar una historia de fallo para ver la cuestión de gobernanza. Si un proveedor cambia una ruta de acceso crítica, ¿quién la revisa? Si la monitorización muestra un comportamiento inexplicado, ¿quién puede pausar los nuevos envíos? Si se rescinde el contrato, ¿quién es el propietario de la exportación, quién verifica que esté completa y quién decide si un proceso manual es lo bastante seguro para ejecutarse mientras se construye un reemplazo? Una política que nombre los roles antes de que llegue la presión es más útil que una promesa posterior al incidente de mejorar la coordinación.
La misma disciplina se aplica a los sistemas automatizados. Un componente de IA puede detenerse mientras el flujo de trabajo circundante sigue produciendo decisiones a partir de resultados en caché, reglas de respaldo o suposiciones humanas. Por tanto, la organización necesita definir la unidad de autoridad. ¿El interruptor de apagado corresponde al modelo, al servicio de decisiones, a la cola, al paso de publicación o a todo el proceso? Un interruptor limitado puede ser más seguro que un apagado total, pero solo si se conoce su límite y su efecto es observable.
La evidencia forma parte del interruptor institucional. Una acción de detención debe dejar un registro de quién actuó, bajo qué autoridad, a qué hora, con qué estado observado y qué paso siguiente. El registro no es un adorno burocrático. Permite que la organización distinga una acción de contención deliberada de una degradación silenciosa y permite que un equipo de reemplazo entienda lo que ha heredado. Esta es la misma razón por la que la Ley de Datos pide a los proveedores que ofrezcan información sobre formatos, procedimientos y limitaciones. Un sistema que no puede describir su estado no puede transferirse de forma responsable.
También hay un punto de dignidad humana. Cuando las organizaciones dicen que un proveedor es indispensable, a menudo quieren decir que un pequeño número de personas entiende el acuerdo. Eso es una dependencia de conocimiento, no un hecho de la naturaleza. La documentación, la formación, las operaciones en pareja y los ejercicios periódicos pueden hacer que la autoridad sea menos personal y más duradera. El resultado puede parecer menos mágico. Suele ser más resiliente.
Un archivo de soberanía que pueda sobrevivir a una reunión
Un archivo de soberanía debe ser algo que un responsable de contratación, un ingeniero, un abogado y un líder responsable puedan leer todos sin traducir el documento a cuatro lenguajes privados diferentes. No debe ser un paquete de garantías de cien páginas que responda a todas las preguntas excepto a la que un responsable de decisiones está a punto de formular. Un archivo compacto puede remitir a evidencia más profunda mientras hace visible el límite de control.
Empiece con la definición del servicio. Nombre la función, los datos, los usuarios, las decisiones o acciones respaldadas, la interrupción aceptable y las consecuencias de una continuación insegura. Marque lo que es crítico y lo que es meramente conveniente. Esto evita que la organización negocie la soberanía de un panel mientras pasa por alto el servicio de identidad que permite que cualquiera llegue a él.
Después registre el mapa de control. Para cada componente material, identifique quién es su propietario, quién lo opera, quién puede inspeccionarlo, quién puede cambiarlo, quién puede detenerlo y quién puede reemplazarlo. Use los nombres reales de entidades y roles del contrato y del modelo operativo. Si un campo dice «proveedor» o «cliente» sin una responsabilidad nombrada, es una invitación a hacer otra pregunta.
Registre a continuación el mapa legal y jurisdiccional. Incluya las entidades contratantes, las entidades proveedoras relevantes, las jurisdicciones de infraestructura reveladas en virtud del acuerdo, los subcontratistas aplicables, las rutas de acceso y los procedimientos de notificación. Indique dónde la evidencia está actualizada y cuándo debe revisarse. Un mapa con fecha es más honesto que una frase de garantía perpetua.
La sección de salida debe contener un inventario, no solo una intención. Enumere los datos exportables, los activos digitales, la configuración, las identidades, las claves, los registros, los modelos, el material de evaluación, las licencias y las dependencias que no se pueden trasladar. Para cada elemento, indique su formato, propietario, método de recuperación, prueba de validación y regla de retención o borrado. Si un elemento no es exportable, explique por qué y describa el sustituto. La cuestión no es castigar a un proveedor por tener secretos comerciales protegidos. La cuestión es evitar que la capacidad de trabajo del cliente se confunda con la maquinaria interna del proveedor.
Por último, adjunte un registro de ejercicio. Debe mostrar la fecha, el alcance, los participantes, las suposiciones, las deficiencias observadas, las acciones correctivas y el próximo desencadenante de revisión. Una pequeña salida de muestra puede ser más informativa que un gran plan teórico. El ejercicio puede revelar que un formato está técnicamente disponible pero es lento de interpretar, que una clave es portátil pero no utilizable por el entorno alternativo, o que una autoridad existe sobre el papel pero no es accesible fuera del horario laboral. Esos son descubrimientos solucionables. Son mucho más amables que las sorpresas.
El archivo también debe contener una condición de rechazo. ¿Qué evidencia haría que la organización decline el servicio, retrase el despliegue o limite los datos que envía? Aquí es donde la soberanía se convierte en una elección de contratación en lugar de un deseo. Un comprador no necesita rechazar todas las dependencias. Necesita saber qué dependencia haría que el servicio fuera inaceptable y quién tiene la autoridad para decirlo.
Qué cuesta la soberanía y qué cuesta la dependencia
La soberanía no es gratuita. Las claves controladas requieren personal y procedimientos. Los formatos portátiles pueden limitar la comodidad de una función propietaria. La capacidad redundante cuesta dinero antes de que se necesite. Un proveedor alternativo puede ser menos pulido. Una ruta operativa local puede ser más lenta. Una institución pública que insiste en la evidencia puede recibir menos ofertas y tardar más en decidir. Estos son costes reales, y ocultarlos bajo una bandera no es más honesto que ocultar la dependencia bajo un descuento.
La comparación relevante no es la soberanía frente a un mundo sin fricciones. Es un coste deliberado frente a una dependencia sin precio. Un servicio que es barato de adoptar puede ser caro de inspeccionar, caro de migrar o imposible de suspender sin consecuencias públicas. Un proveedor que es técnicamente excelente puede seguir creando un riesgo de concentración si el cliente no puede cambiar una interfaz crítica. Una ruta controlada localmente puede costar más hoy y preservar la capacidad de elegir mañana. Ninguna de las dos opciones es automáticamente correcta. La institución debería poder explicar qué coste aceptó.
La evaluación de riesgos de la nube de ENISA es lo bastante antigua como para haber sobrevivido a varias arquitecturas de moda. Eso es parte de su utilidad. Su marco trata la computación en la nube como un modelo de negocio y tecnología con beneficios y riesgos, incluido el bloqueo y la exposición legal, y recomienda evaluar esos riesgos en lugar de asumir que la nube es liberación o peligro. Se necesita el mismo temperamento para la soberanía. La cuestión no es si un acuerdo es puro. Es si sus dependencias son conocidas, limitadas y reemplazables lo suficiente para la función en juego.
La redundancia a menudo se malinterpreta como poseer dos copias idénticas. A veces la mejor alternativa es una implementación diferente, un respaldo manual o un servicio reducido que preserve la función pública más importante. La elección depende de las consecuencias de la interrupción. Una carga de trabajo de investigación puede tolerar una ejecución retrasada. Un servicio de información pública puede necesitar una ruta de publicación estática. Un flujo de trabajo relacionado con la seguridad puede necesitar una compuerta humana y un procedimiento probado en lugar de un segundo punto final idéntico. La soberanía es la capacidad de elegir el respaldo antes de que el sistema principal lo elija por usted.
También hay un coste social. Si solo unas pocas personas pueden operar un sistema, la organización ha comprado una dependencia de su memoria. Si la contratación pública trata cualquier salida del proveedor actual como algo irresponsable, enseña al mercado que la salida es un teatro. Si las instituciones financian alternativas solo hasta que se complete la primera licitación, crean una demostración en lugar de capacidad. Pagar por el conocimiento operativo, la interoperabilidad y el mantenimiento es menos emocionante que anunciar una plataforma. También es así como las decisiones sobreviven al segundo ciclo presupuestario.
Nuestra pequeña nota al pie
En Dweve, nuestro informe público The Sovereignty Illusion presenta un argumento relacionado a través de cinco puertas prácticas: propiedad, tecnología, capital, infraestructura y exposición legal. El informe es nuestro propio análisis, no una norma legal ni un sustituto del marco de contratación de la Comisión ni de la Ley de Datos. Su valor aquí es simplemente el hábito que fomenta: cuando alguien dice que un sistema es soberano, pregunte qué puerta tiene el control y qué puerta permanece abierta. Esa es la escala en la que preferimos hablar de nuestro propio trabajo, después de la evidencia y antes de la presentación.
La prueba ocurre antes de la emergencia
El momento más revelador para la soberanía rara vez es el lanzamiento. Los lanzamientos están llenos de diagramas preparados, equipos con nombre y buen tiempo. El momento revelador es un cambio de rumbo: un contrato debe terminar, un proveedor debe ser cuestionado, un alcance legal debe revisarse, una dependencia debe reemplazarse o un operador debe detener una función antes de que todos los hechos sean cómodos.
Por eso el interruptor de apagado es un mejor punto de partida que la bandera. Exige autoridad en lugar de atmósfera. Pregunta qué puede inspeccionar la organización, no qué puede prometer el proveedor. Pregunta si los datos y los activos digitales pueden moverse, si la función puede continuar y si la evidencia sobrevivirá al movimiento. Convierte la soberanía en un conjunto de acciones ensayables.
El marco de 2026 de la Comisión Europea demuestra que la contratación pública puede hacer legibles estas acciones. La Ley de Datos demuestra que la portabilidad y la información jurisdiccional pueden ser obligaciones en lugar de favores. El trabajo de riesgo de ENISA nos recuerda que el bloqueo y la exposición legal no son sorpresas nuevas, incluso cuando la arquitectura cambia de nombre. Ninguna de estas fuentes dice que Europa pueda operar sin dependencias. Ofrecen algo más serio: una manera de decidir qué dependencias son aceptables y qué sucede cuando no lo son.
Una institución europea no necesita poseer cada chip, escribir cada sistema operativo o construir cada servicio para actuar con soberanía. Necesita conservar una capacidad creíble para entender el acuerdo, establecer límites, cambiar los términos, detener el camino inseguro y continuar la función esencial. A veces eso significa elegir un proveedor europeo. A veces significa una interfaz abierta, un custodio de claves separado, un segundo operador, una ruta manual o un servicio más pequeño. La respuesta pertenece al riesgo y a la responsabilidad pública, no a un eslogan.
Antes del próximo anuncio de nube soberana, haga cinco preguntas sencillas. ¿Quién puede detener esto? ¿Quién puede ver lo que sucedió? ¿Quién puede cambiarlo? ¿Hacia dónde puede moverse? ¿Qué puede reemplazarlo? Si las respuestas están escritas, probadas y son propias, la palabra soberanía puede estar haciendo un trabajo útil. Si las respuestas terminan en un logotipo y una dirección, el sistema aún no ha encontrado su interruptor de apagado.
Fuentes
- Explicación del marco de la nube soberana, Comisión Europea, Dirección General de Servicios Digitales.
- Reforzar la soberanía tecnológica de Europa, Comisión Europea, Configurar el futuro digital de Europa.
- Reglamento (UE) 2023/2854 (Ley de Datos), EUR-Lex, especialmente el capítulo VI sobre el cambio entre servicios de procesamiento de datos.
- Evaluación de riesgos de la computación en la nube, Agencia de la Unión Europea para la Ciberseguridad.
- The Sovereignty Illusion, Dweve.