El 17 de abril la Comisión Europea adjudicó hasta 180 millones de euros en servicios cloud a seis años. Los cuatro adjudicatarios son empresas europeas y ninguno es AWS, Azure o Google Cloud. Lo que decidió el reparto no fue el precio: fue una tabla de ocho filas con pesos porcentuales, publicada seis meses antes y descargable por cualquiera.
El documento se llama Cloud Sovereignty Framework, versión 1.2.1, y lo firma la Dirección General de Servicios Digitales. Tiene seis páginas y convierte una palabra de discurso político en un procedimiento de evaluación con umbral de rechazo.
Ocho objetivos y un reparto de pesos que delata la prioridad
| Objetivo | Peso | Qué se pregunta de verdad |
|---|---|---|
| SOV-5 Cadena de suministro | 20 % | Dónde se fabrica el hardware, qué jurisdicción gobierna el firmware, quién empaqueta y distribuye las actualizaciones, qué derechos de auditoría hay sobre los subproveedores |
| SOV-1 Estratégico | 15 % | Dónde reside el órgano con autoridad decisoria, qué garantías existen ante un cambio de control, si el servicio sigue operando cuando el fabricante retira el soporte |
| SOV-4 Operacional | 15 % | Migración sin lock-in, operación y mantenimiento sin intervención de un vendor extracomunitario, disponibilidad de documentación técnica y código fuente |
| SOV-6 Tecnológico | 15 % | APIs y protocolos no propietarios, adhesión a estándares de gobierno público, licencias abiertas con derecho a auditar y modificar |
| SOV-2 Legal y jurisdiccional | 10 % | Exposición a la CLOUD Act y a la ley china de ciberseguridad, canales por los que una autoridad extranjera podría forzar acceso, jurisdicción donde se crea la propiedad intelectual |
| SOV-3 Datos e IA | 10 % | Control criptográfico exclusivo del cliente, confinamiento del procesamiento sin fallback a terceros países, gobierno de los modelos y de los pipelines |
| SOV-7 Seguridad y cumplimiento | 10 % | SOC bajo jurisdicción comunitaria, autonomía para desarrollar y aplicar parches, auditoría independiente con acceso completo |
| SOV-8 Sostenibilidad | 5 % | PUE, economía circular, trazabilidad de emisiones y consumo de agua |
El propio documento explica por qué los objetivos legal y de seguridad pesan poco: el procedimiento de contratación ya incorpora salvaguardas en esos dominios. Traducido a lenguaje de comité, la conformidad con el RGPD y el catálogo de certificaciones ISO son el suelo de la conversación, no el argumento.
Fíjate en lo que implica el reparto. «Nuestros datos están en Fráncfort» responde a un objetivo que vale 10 puntos sobre 100. «Sabemos quién fabrica la placa, qué jurisdicción gobierna el firmware y quién puede empujar una actualización a producción» responde al que vale 20.
SEAL: cinco niveles y un umbral de admisión
Sobre esos ocho objetivos, el marco define cinco niveles de garantía, los Sovereignty Effectiveness Assurance Levels:
- SEAL-0, sin soberanía: servicio, tecnología y operación bajo control exclusivo de terceros no comunitarios.
- SEAL-1, soberanía jurisdiccional: el derecho de la UE aplica formalmente, con exigibilidad práctica limitada.
- SEAL-2, soberanía del dato: derecho de la UE aplicable y exigible, con dependencias extracomunitarias materiales todavía presentes.
- SEAL-3, resiliencia digital: los actores europeos ejercen influencia real y el control de terceros es marginal.
- SEAL-4, soberanía digital plena: tecnología y operación bajo control comunitario completo, sin dependencias críticas externas.
El umbral de admisión era SEAL-2, y había que sostenerlo en los ocho objetivos: una debilidad material en uno solo rebaja el nivel reconocido y puede tumbar la oferta entera. Post Telecom con OVHcloud y CleverCloud, STACKIT y Scaleway alcanzaron SEAL-3. Proximus, que opera sobre tecnología de Google Cloud a través de S3NS junto a Clarence y Mistral, se quedó en SEAL-2 y entró igual.
Ese detalle es lo más interesante de la adjudicación. La rúbrica no es un filtro de bandera. Tecnología estadounidense operada dentro de un marco estricto y por empresas comunitarias llega al mínimo exigido. Lo que se está midiendo no es de dónde viene el código. Es quién puede apagarlo.
De rúbrica de compra a propuesta de reglamento
El 3 de junio la Comisión publicó la propuesta del Cloud and AI Development Act, dentro del paquete de soberanía tecnológica. Lleva dentro un marco de soberanía con cuatro niveles de garantía, esta vez pensado para todo el sector público:
- Nivel 1: datos procesados y almacenados en infraestructura ubicada en la Unión.
- Nivel 2: el proveedor demuestra independencia respecto a terceros países y transparencia sobre su cadena de suministro de software.
- Nivel 3: propiedad y control comunitarios, más criterios adicionales como la nacionalidad del personal. La Comisión puede reconocer proveedores de terceros países.
- Nivel 4: transparencia y control completos sobre la cadena de suministro de software, sin interferencia de un tercer país.
El nivel exigible lo fijaría cada organismo público según su análisis de riesgo, y el reconocimiento del proveedor pasaría por una auditoría del Estado miembro. Queda por delante la negociación en Parlamento y Consejo, así que el texto cambiará.
Aquí va una tesis propia, no un hecho: la rúbrica llegará a los pliegos españoles antes que el reglamento. Un órgano de contratación no necesita esperar a un trílogo para copiar una metodología publicada y aplicarla como criterio de adjudicación. Y tiene un incentivo para hacerlo: el esquema europeo de certificación cloud, el EUCS, lleva desde su primer borrador de 2020 sin adoptarse, atascado justo en el capítulo de soberanía. La contratación pública se ha movido más rápido que la certificación.
La pregunta que vas a recibir en un pliego
Este es el ejercicio útil: contestar hoy, con evidencias y en tu propia infraestructura, lo que el marco pregunta a un proveedor. Cinco preguntas con respuesta medible:
- Control criptográfico. ¿Puede tu proveedor descifrar tus datos sin ti? Evidencia: procedimiento de custodia de claves y prueba documentada de que la recuperación sin la clave del cliente es imposible, no solo contractualmente improbable.
- Autonomía de parcheo. ¿Cuántas horas tardas en aplicar un parche crítico si el fabricante no responde? Métrica: tiempo real del último ejercicio, no el SLA.
- Procedencia del firmware. ¿Tienes SBOM de los componentes críticos, con jurisdicción de origen del firmware y de la cadena de actualización? Métrica: porcentaje de la BOM con procedencia trazada.
- Salida probada. ¿Cuándo fue la última restauración completa en infraestructura alternativa y qué RTO obtuviste? Un plan de salida sin ensayo es un documento, no un plan.
- Coste real de la salida. El artículo 29 del Data Act prohíbe cobrar por el cambio de proveedor a partir del 12 de enero de 2027. Desaparece la factura de egress. La ingeniería de migración la sigues pagando tú, y esa cifra no la publica nadie: calcúlala.
Ninguna de las cinco se responde comprando una región europea.
El Imperativo Estratégico
La rúbrica de la Comisión pregunta quién puede detener el servicio, quién firma el firmware y cuánto tardas en operar sin el fabricante. Esas respuestas se construyen con arquitectura y meses de trabajo, no con una cláusula añadida en la renovación del contrato.
En Pumpún Dixital diseñamos y desplegamos infraestructura on-premise y en entornos aislados para organizaciones que tienen que sostener esas respuestas con evidencias: inferencia local, claves en manos del cliente, cadena de actualización auditable y operación sin dependencia de soporte externo. No sale gratis y no es la respuesta correcta para todas las cargas. Es la respuesta para aquellas cuya interrupción no puede depender de una decisión ajena.
Si no sabes en qué nivel caerías hoy, empieza por inventariar dependencias reales. Ese ejercicio lo hacemos contigo.