Es usted director de TI en una aseguradora de salud alemana sujeta a DORA y a la supervisión de BaFin. Su consejo acaba de remitirle el anuncio de la Comisión Europea del Paquete de Soberanía Tecnológica, adoptado el martes 3 de junio de 2026, con una sola frase: ¿qué significa esto para nuestra contratación cloud de 2027? La contratación asciende a 18 millones de € a cinco años. Su CIO quiere una nota de una página para el viernes.

La propuesta de Cloud and AI Development Act (CADA) es la pieza del paquete que afecta más directamente a su contratación. Clasificará a los proveedores cloud en cuatro niveles de soberanía. El nivel más alto — por la lógica jurídica de la propuesta — no es alcanzable por proveedores con sede en EE. UU. porque la CLOUD Act crea un conflicto estructural. Los datos financieros, judiciales y de salud de los gobiernos y de las organizaciones del sector público deberán operar en infraestructura del nivel más alto de soberanía. La propuesta es un reglamento al amparo del Artículo 114 TFUE, que produce efecto directamente aplicable sobre el mercado interior. Si se aprueba intacta, los Estados miembros no podrán debilitar su aplicación individualmente.

No se aprobará intacta, y no se aprobará antes de 2027. El trílogo tardará de 18 a 24 meses. El primer efecto práctico sobre su contratación no es el reglamento en sí; es el lenguaje contractual que los licitadores avispados ya están preparando. Su licitación de 18 millones de € que cierra en otoño de 2026 será leída por licitadores que se posicionan para la clasificación CADA que asumen que llegará en 2028 o 2029. Las respuestas de los licitadores le dirán quién se está tomando en serio la futura regulación y quién no.

Este artículo es la auditoría de lo que CADA propone, lo que los cuatro niveles realmente exigen, lo que su expediente de contratación debe asumir ya sobre la dirección del reglamento, y la pregunta concreta que la nota de una página de su CIO tiene que responder antes de que cierre la ronda presupuestaria.

Lo que propone el paquete

El Paquete de Soberanía Tecnológica contiene cuatro instrumentos. El primero es la Cloud and AI Development Act (CADA) con el marco de clasificación de soberanía. El segundo es Chips Act 2.0, que actualiza la norma de 2023 para elevar la cuota objetivo de la UE en la producción mundial de chips. El tercero es una Estrategia Open Source que formaliza el código abierto como elemento estructural de la política digital de la UE. El cuarto es una Hoja de Ruta Estratégica para la Digitalización y la IA en Energía, presentada con el Comisario Dan Jørgensen en el estrado junto a la Comisaria Henna Virkkunen.

El encuadre del paquete por parte de Virkkunen, en la rueda de prensa: «We want to be sure nobody has a kill switch» («Queremos asegurarnos de que nadie tenga un kill switch»). Ursula von der Leyen envolvió la política: «We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure» («No podemos permitirnos depender de otros para las tecnologías que mantienen nuestros hospitales funcionando, nuestras redes energéticas estables y nuestros servicios seguros»). El encuadre político fue la soberanía. El encuadre contractual — que es el encuadre con el que su licitación tiene que dialogar — es la clasificación, los requisitos obligatorios de nivel, y la base jurídica del Artículo 114 TFUE que confiere al reglamento efecto directamente aplicable sobre el mercado interior.

El componente cloud es el más sustantivo para las decisiones de contratación de hoy. El marco de cuatro niveles de CADA es una escalera graduada de separación estructural del control no-UE: el Tier 1 cubre las exigencias mínimas de residencia de datos; el Tier 2 establece independencia operativa respecto del control no-UE; el Tier 3 exige separación arquitectónica plena de dependencias no-UE; el Tier 4 reclama continuidad verificable bajo condiciones geopolíticas hostiles. El requisito de Tier 3 obligatorio para datos financieros, judiciales y de salud de la administración es la parte que afecta directamente a su contratación. Lo harán cumplir las autoridades nacionales designadas.

Lo que los cuatro niveles realmente exigen, en lenguaje operativo

El texto de la propuesta de la Comisión describe los niveles en lenguaje regulatorio. La traducción operativa es lo que su equipo de arquitectura necesita.

El Tier 1 es la exigencia de residencia de datos. Su proveedor se compromete, contractualmente, a mantener los datos en suelo de la UE. Esto es lo que reclaman la mayoría de las actuales ofertas de nube soberana europea — Microsoft Azure Sovereign Cloud, AWS European Sovereign Cloud, Google Cloud Sovereign — y lo que la mayoría de esas ofertas entregan. El Tier 1 es compatible con la operación de proveedores con sede en EE. UU. La mayoría de los contratos M365 existentes, con las cláusulas de residencia de datos ya en vigor, satisfarían el Tier 1 sin cambio arquitectónico alguno.

El Tier 2 añade independencia operativa respecto del control no-UE. Su proveedor se compromete no solo a la residencia en la UE, sino a que las decisiones operativas las tomen entidades con sede en la UE. Este es el nivel en el que las variantes de nube soberana de los proveedores con sede en EE. UU. cumplen o no cumplen según la estructura contractual. La arquitectura actual de Microsoft Sovereign Cloud está diseñada para cumplir el Tier 2 estructurando el control operativo a través de la filial irlandesa de Microsoft con una opción de residencia de datos en Polonia. Que esa cualificación sobreviva a la interpretación de «operational independence» («independencia operativa») en el trílogo es una de las preguntas abiertas.

El Tier 3 exige separación arquitectónica plena de dependencias no-UE. Este es el nivel del que la lógica jurídica de la propuesta excluye a los proveedores con sede en EE. UU. La CLOUD Act crea un conflicto estructural que ninguna estructura contractual puede eliminar. El Tier 3 es el terreno de OVHcloud, Outscale, StackIT de Schwarz Digits, IONOS, Open Telekom Cloud de T-Systems y la plataforma federal KIPITZ. Para la contratación de su aseguradora de salud, el Tier 3 es la restricción sustantiva: las cargas con datos financieros y de salud deberán, según la propuesta actual, operar allí.

El Tier 4 reclama continuidad verificable bajo condiciones geopolíticas hostiles. Los criterios para el Tier 4 aún no están enumerados en la propuesta pública. La continuidad bajo hostilidad es la propiedad que una organización tiene cuando puede seguir operando si cualquier proveedor individual, incluido el principal, deja de estar disponible. Operativamente, el Tier 4 exige portabilidad multiproveedor, infraestructura espejo fuera de la UE para las dependencias de distribución de código fuente, y un plan de continuidad que se haya ejercitado. Según la definición operativa que sugiere el texto de la propuesta, el Tier 4 es la propiedad que ningún proveedor europeo actual puede aún reclamar de forma creíble. La definición de criterios estará entre los elementos más disputados del trílogo.

Lo que su expediente de contratación debe asumir en 2026

Su licitación de 18 millones de € que cierra en otoño de 2026 se adjudicará a un entorno regulatorio que aún no existe. Tres asunciones, escritas en la licitación y en el expediente de contratación, determinarán si el contrato adjudicado en 2026 sobrevive a CADA cuando CADA aterrice.

Asuma Tier 3 para las cargas de datos de salud y financieros. Aunque CADA se suavice en el trílogo, la capa federal alemana de contratación, la capa supervisora de BaFin y el marco DORA convergen en la asunción de que los datos sensibles financieros y de salud no deben operar en infraestructura cloud con sede en EE. UU. Una contratación de 2026 que ate los sistemas centrales de su aseguradora de salud a una oferta Tier 1 de un proveedor estadounidense durante cinco años operará, en 2028, bajo un marco regulatorio que querrá migrarla. Incorpore la opcionalidad de migración en el contrato de 2026; es más barato negociar cláusulas de salida en la firma que en una addenda.

Exija a los licitadores que declaren su hoja de ruta CADA-tier. Su licitación debería pedir a cada licitador, formalmente, qué nivel CADA proyecta poder certificar para 2028 y qué cambios arquitectónicos ha comprometido para alcanzar ese nivel. Los licitadores con una hoja de ruta seria responderán por escrito con cambios técnicos concretos y nombrados. Los licitadores con una respuesta de posicionamiento entregarán lenguaje de marketing. La diferencia es el dato más informativo que su proceso de contratación extraerá.

Incorpore ya referencias a EVB-IT y al §58 VgV Nr. 4 en la licitación. La capa federal del derecho de contratación pública ya respalda el lenguaje que necesitará cuando CADA aterrice. Citar el §58 VgV Nr. 4 y las cláusulas EVB-IT de contrato de código abierto en la licitación de 2026 hace dos cosas: sienta precedente en su propio expediente de contratación, y señala a los licitadores que su oficina de contratación está comprometida con la capa federal de soberanía en lugar de reaccionar ante ella.

Lo que CADA no aborda

Los cuatro niveles cubren la infraestructura cloud y ciertas categorías de datos gubernamentales. No abordan, en la propuesta actual, las capas por debajo de la nube.

La infraestructura de alojamiento de código sigue mayoritariamente alojada en EE. UU. El código fuente del stack europeo de soberanía vive en GitHub — propiedad de Microsoft. El requisito de Tier 3 de separación arquitectónica de dependencias no-UE no se extiende, en una lectura estricta del texto de la propuesta, a la infraestructura de construcción y distribución de los componentes open source sobre los que opera la nube. Esta es la misma brecha que el lanzamiento de Euro-Office hace visible en otro lugar, y CADA no la cierra actualmente.

Cadenas de confianza criptográfica. Las autoridades de certificación y las operaciones de los servidores raíz del DNS siguen dominadas por EE. UU. Los niveles de soberanía de CADA no enumeran explícitamente criterios de cadena de confianza. Un proveedor clasificado como Tier 3 puede seguir dependiendo de autoridades de certificación cuyas claves raíz están bajo control estadounidense.

CI/CD y distribución de paquetes. GitHub Actions, npm, PyPI, Docker Hub, Maven Central — la infraestructura de compilación, empaquetado y distribución de la que todo depende sigue estando predominantemente alojada en EE. UU. Un proveedor puede ser Tier 3 en la dimensión de ejecución y Tier 1 en la dimensión de cadena de suministro. CADA no distingue actualmente.

Esto no es una crítica al alcance redactado. Es la observación de que CADA no entrega, por sí solo, soberanía de cadena de suministro en las capas por debajo de la infraestructura cloud. Su expediente de contratación debería reconocer el límite explícitamente. Un lector que celebre CADA como culminación del proyecto europeo de soberanía estará leyendo algo que la propuesta no afirma — y que su CIO se beneficiará de nombrar por escrito antes del próximo ciclo regulatorio.

Lo que este artículo no es

No es una afirmación de que CADA pasará tal como está redactada — el trílogo modificará la propuesta; la pregunta es por cuánto. No es una afirmación de que la Estrategia Open Source esté vacía — encuadra el OSS estructuralmente; si produce presupuesto es una pregunta separada decidida en el próximo ciclo del Marco Financiero Plurianual, no en junio de 2026. No es una afirmación de que la soberanía europea quede resuelta por el paquete. El paquete aborda una capa de dependencia, deja otras intactas, y depende de un proceso legislativo que se prolonga hasta 2027 o 2028.

La nota que su CIO necesita para el viernes

La nota de una página debe hacer tres afirmaciones y recomendar dos acciones.

Las tres afirmaciones: CADA será ley en 2028 o 2029; el requisito de Tier 3 más probable para cargas financieras y de salud sobrevivirá al trílogo sustancialmente en la forma propuesta; la capa de cadena de suministro no será abordada por CADA en este ciclo y requerirá atención contractual separada.

Las dos acciones recomendadas: redactar la licitación de otoño de 2026 con la obligación de que los licitadores declaren su hoja de ruta CADA-tier y el calendario de separación arquitectónica; construir auditoría de cadena de suministro e infraestructura espejo Codeberg-o-equivalente por el lado del cliente, con independencia del proveedor finalmente elegido, porque ese trabajo es necesario sea cual sea el nivel CADA que el proveedor acabe certificando.

Una nota que haga esas afirmaciones y recomiende esas acciones se lee, a nivel de consejo, como compromiso con la dirección regulatoria. Una nota que diga «la situación está evolucionando y la monitorizaremos» se lee como el tipo de preparación que no sobrevive a una auditoría de cumplimiento de BaFin en 2029. La licitación de otoño de 2026 es el expediente que se citará en esa auditoría si va bien, o sobre el que se escribirá en la prensa regulatoria si no.

Fuentes

Visión general del tema: Soberanía Digital en Europa Artículos relacionados: Cómo citar el §58 VgV Nr. 4, El proveedor escribió la prueba