El Cloud and AI Development Act: qué está intentando arreglar Europa en realidad
El Cloud and AI Development Act es hasta la fecha la declaración más clara de en qué se ha convertido la política tecnológica europea. No es una ley de consumo ni una ley de seguridad: es política industrial dirigida a un solo problema, y es que Europa hace funcionar la mayor parte de su economía digital sobre infraestructura que no controla.
Eso es un tipo de regulación distinto del RGPD o del reglamento de IA, y le va a llegar por otra vía. Entender cuál es esa vía importa más que leerse los considerandos.
El problema al que responde
Las cifras de partida no las discute nadie. La inmensa mayoría del gasto europeo en nube va a proveedores no europeos. Los modelos de IA más grandes que usan las empresas europeas se entrenan y se alojan fuera de Europa. La capacidad europea de cómputo es una fracción pequeña del total mundial.
Durante una década esto se vio como un simple resultado de mercado. Desde 2022 se ve como una vulnerabilidad estratégica, por motivos que no tienen nada que ver con la tecnología: tensión comercial, controles a la exportación y el descubrimiento de que depender de la infraestructura de otro es darle capacidad de presión.
El Cloud and AI Development Act es el brazo legislativo de ese cambio de lectura. Va de la mano del Plan de Acción del Continente de la IA, de la iniciativa InvestAI, del programa de gigafábricas de IA y de la agenda de competitividad más amplia que salió del informe Draghi.
Qué se espera de él
La propuesta estaba prevista para la primera parte de 2026 como norma insignia del programa de trabajo de la Comisión. Los objetivos declarados se repiten en todos los anuncios:
Reforzar la capacidad europea de desarrollar, desplegar y escalar nube e IA. En la práctica esto va de cómputo, de centros de datos y de poder entrenar y servir modelos grandes dentro de la UE.
Cerrar lagunas regulatorias. El marco actual trata la nube sobre todo a través de las disposiciones de cambio de proveedor del reglamento de datos y de las obligaciones de seguridad de NIS2. Ninguna de las dos entra en la capacidad ni en la dependencia estratégica.
Impulsar la interoperabilidad. Rebajar el coste técnico de cambiar de proveedor, que es el mismo objetivo que el reglamento de datos persigue por la vía contractual.
Establecer una política de nube común a toda la UE para las administraciones públicas y la contratación pública. Esta es la que de verdad aprieta: un criterio común sobre cómo compran nube los organismos públicos de los Estados miembros, con una dimensión de preferencia europea.
Apoyar un ecosistema europeo de nube e IA seguro y competitivo. El cajón de sastre.
El mecanismo que de verdad le va a alcanzar
Aquí está la clave de este expediente. Casi toda la regulación tecnológica llega a las empresas privadas de forma directa: usted trata datos personales, luego se le aplica el RGPD. El Cloud and AI Development Act llegará a la mayoría de las empresas por la puerta de atrás, a través de la contratación pública.
El gasto tecnológico del sector público en la UE es enorme. Si a los organismos públicos de los Estados miembros se les obliga o se les empuja con fuerza a comprar nube europea, cambia el mercado al que puede aspirar cualquier proveedor que venda al sector público, y el efecto baja en cascada desde los contratistas principales hasta sus subcontratistas.
El patrón ya lo hemos visto con la accesibilidad. La directiva europea de accesibilidad impone obligaciones directas, pero en la práctica buena parte del trabajo de accesibilidad lo empujaron unos pliegos de contratación pública que dejaban fuera a los proveedores no conformes mucho antes de que la directiva se aplicara.
Cuente con lo mismo aquí. Si vende software a compradores públicos europeos, las preguntas sobre dónde se ejecuta su infraestructura, quién la controla y si se puede migrar van a pasar del cuestionario de seguridad a los criterios de solvencia.
Qué implica para la arquitectura
Ante una política de soberanía el instinto es o ignorarla o salir corriendo a migrar. Ninguna de las dos cosas sirve. Lo razonable es asegurarse de que la pregunta tiene respuesta.
Sepa dónde están de verdad sus datos y su cómputo
Parece trivial y no lo es. En un sistema con años encima, la respuesta honesta a «dónde se ejecuta esto» suele incluir una región principal, otra de respaldo, un CDN con ubicaciones de borde poco claras, una base de datos gestionada, tres dependencias SaaS con sus propios subencargados, un proveedor de observabilidad y una API de IA cuya ubicación de inferencia no está documentada en ninguna parte.
Levantar un mapa fiable es el primer trabajo de verdad, y es el mismo mapa que necesita para el análisis de transferencias del RGPD y para las preguntas de cadena de suministro de NIS2. Hágalo una vez y sirve para todo.
Separe lo portable de lo que no lo es
Casi todo sistema tiene un núcleo portable y un conjunto de dependencias atadas al proveedor. El núcleo portable suele ser la aplicación. Lo que no se mueve suelen ser los servicios gestionados: bases de datos propietarias, ejecución serverless, colas, identidad y, cada vez más, las API de modelos.
No hace falta eliminarlas. Lo que hace falta es saber cuáles son, porque esa lista es la respuesta honesta a cuánto costaría una migración y es justo lo que pregunta en el fondo un pliego de contratación.
Trate a los proveedores de modelos como una frontera de abstracción
Es lo más reciente y lo que más gente se salta. Las aplicaciones que llaman directamente a la API de un solo proveedor, con formatos de prompt y tratamiento de respuestas propios de ese proveedor repartidos por todo el código, han tomado una decisión de dependencia sin enterarse.
Una abstracción ligera sobre las llamadas a modelos cuesta muy poco de hacer y le deja la puerta abierta a enrutar hacia un proveedor europeo, hacia un modelo de pesos abiertos sobre infraestructura europea o hacia otro proveedor cualquiera. Con lo rápido que se mueve el panorama de modelos, sale a cuenta por motivos puramente comerciales.
Pruebe la salida, no se limite a documentarla
El reglamento de datos ya le reconoce el derecho a cambiar de proveedor de nube, y los cargos por cambio desaparecen del todo el 12 de enero de 2027. Muy pocos compradores ejercen ese derecho, y menos todavía comprueban si la exportación a la que tienen derecho serviría de verdad para reconstruir su servicio.
Lance la exportación. Intente interpretarla. En la distancia entre lo que el proveedor declara exportable y lo que resulta utilizable es donde se esconde la dependencia real, y esa distancia es también la respuesta honesta a cualquier pregunta sobre soberanía.
Lo que no es
Aquí toca algo de escepticismo, y más vale tenerlo claro ahora que llevarse la sorpresa después.
Esto no es una prohibición de la nube estadounidense. Nada de lo anunciado apunta a que se vaya a prohibir a las empresas privadas usar proveedores no europeos. El mecanismo es la preferencia en la compra pública y la creación de capacidad, no la prohibición.
La capacidad no aparece porque lo diga una ley. La capacidad europea de nube es limitada porque levantar centros de datos y entrenar modelos de frontera exige muchísimo capital y Europa no ha puesto capital a esa escala hasta hace bien poco. Los programas de financiación que repasamos en nuestra guía de financiación tecnológica de la UE son el instrumento de verdad. La norma es solo el marco que los rodea.
Una etiqueta de soberanía no es soberanía. Varias ofertas se venden como nube soberana mientras funcionan sobre tecnología no europea bajo licencia, con grados muy distintos de independencia operativa. Si eso basta o no para una futura norma de contratación es exactamente la pregunta que el texto tendrá que responder, y todavía no la ha respondido.
Es una propuesta. Hasta que haya un texto y posiciones del Consejo y del Parlamento sobre él, el detalle no se puede conocer. Lo que sí se conoce es el rumbo, y ese lleva tres años sin variar en la comunicación de la Comisión.
Cómo encaja con todo lo demás
El Cloud and AI Development Act es una pieza de un empujón coordinado, y leerlo por separado hace que parezca más flojo de lo que es.
El reglamento de IA regula cómo se comportan los sistemas de IA. El reglamento de datos ataca por vía contractual la dependencia del proveedor de nube. NIS2 hace bajar el escrutinio de la cadena de suministro hasta los proveedores. El reglamento de ciberresiliencia impone obligaciones de seguridad a los productos. InvestAI y el programa de gigafábricas ponen dinero en capacidad de cómputo. Y el Cloud and AI Development Act añade la capa de contratación e interoperabilidad.
Por separado cada uno parece una carga más. Juntos dibujan una apuesta bastante coherente: que Europa puede llegar a tener una base tecnológica propia combinando reglas de acceso al mercado con dinero público.
Preguntarse si esa apuesta va a salir bien es legítimo. Dudar de que se esté haciendo, no.
Qué hacer en los próximos doce meses
Levante el mapa de infraestructura. Dónde se ejecuta cada cosa, quién la opera y cuál es la vía contractual de salida. Le va a servir para otras cuatro cosas.
Identifique las dependencias que de verdad no son portables y póngale un precio honesto a la migración, aunque no piense hacerla nunca. Es la respuesta a la pregunta del pliego y, además, es simple higiene arquitectónica.
Ponga una abstracción sobre los proveedores de modelos si aún no la tiene. Barato ahora, caro después y útil por razones que nada tienen que ver con la política.
Si vende a compradores públicos europeos, siga la vía de la contratación más de cerca que la propia norma. Es ahí donde el requisito aparecerá primero, convertido en criterio de solvencia.
No migre por especulación. Mover infraestructura por una propuesta que ni siquiera está publicada es la manera clásica de quemar un año y un presupuesto grande en algo que al final no hacía falta.
Obtener ayuda
Diseñamos y montamos infraestructura de nube, plataformas de datos e integraciones de IA para empresas que operan en Europa, incluido ese trabajo poco lucido de conseguir que un sistema sea portable de verdad y no solo sobre el papel.
Si necesita un mapa de infraestructura y dependencias, una prueba de salida real contra su proveedor actual o una capa de abstracción sobre los proveedores de modelos, escriba a office@c9group.dev. Más sobre nuestro trabajo de infraestructura en la página de optimización de costes de AWS y sobre nuestro trabajo europeo en la página de entrada al mercado de la UE.
El panorama legislativo completo está en nuestra agenda legislativa digital de la UE, y el dinero que hay detrás de esta agenda lo desglosamos en la guía de financiación tecnológica de la UE.
Somos ingenieros, no asesores de políticas públicas. Esto es una lectura para planificar sobre una propuesta, no asesoramiento jurídico.