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é hace la propuesta

La Comisión publicó la propuesta el 3 de junio de 2026 como COM(2026) 502, junto con un Chips Act 2.0. Es un reglamento, articulado en torno a tres objetivos y un conjunto de medidas para el sector público:

Investigación e innovación. Cloud and AI Leadership Initiatives para grandes proyectos intersectoriales, una red de AI Experience and Acceleration Centres apoyada en los centros europeos de innovación digital, capacidad de cómputo asignada a proyectos prioritarios de IA de frontera y una estrategia nacional de nube e IA en cada Estado miembro en el plazo de un año desde la entrada en vigor.

Capacidad de centros de datos. Los Estados miembros designan zonas de aceleración de centros de datos con un punto único de información y permisos más rápidos, y la Comisión puede designar proyectos estratégicos de centros de datos. El objetivo declarado es al menos triplicar la capacidad de centros de datos de la UE de aquí a 2030, y que cualquier permiso para un centro de datos nuevo se pueda obtener en menos de 18 meses.

Un marco de soberanía para la nube. Cuatro niveles de garantía de la Unión. El nivel 1 es una autoevaluación; los niveles 2 a 4 los auditan terceros. El nivel 3 exige que el proveedor no esté controlado desde un tercer país, salvo que la Comisión haya reconocido que ese país ofrece garantías suficientes. Los servicios reconocidos se inscriben en un registro central de la UE.

Adopción en el sector público. Esta es la que de verdad aprieta. Los compradores públicos tienen que contratar servicios de nube reconocidos como mínimo en el nivel 1. Cuando una evaluación de riesgos concluye que una actividad contribuye al orden público (en los sectores NIS2, la seguridad nacional, la defensa, la justicia y la aplicación de la ley, entre otros), solo se admiten los niveles 2, 3 o 4. Además, los Estados miembros deben aplicar criterios de valor añadido de la Unión cuando compran nube e IA, una EuroCloud Federation permite a los organismos públicos compartir servicios de nube y los organismos públicos deben fomentar y facilitar el uso de código abierto frente al software propietario.

Poco que obligue a los compradores privados. Las empresas de sectores NIS2 pueden hacer la misma evaluación de riesgos de forma voluntaria, y la Comisión podría hacerla obligatoria para los sectores muy críticos mediante un acto delegado. Tal como está propuesto, el reglamento se aplicaría un año después de su entrada en vigor, pero todavía tiene que pasar por el Parlamento y el Consejo.

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 en la propuesta prohíbe 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. La respuesta de la propuesta son los niveles de garantía: el control desde un tercer país deja un servicio fuera del nivel 3 y superiores, salvo que la Comisión reconozca a ese país. Dónde cae al final la línea entre los niveles 2 y 3 es lo que decidirán las negociaciones.

Es una propuesta. Ya hay un texto, pero a 10 de octubre de 2026 ni el Consejo ni el Parlamento tienen posición sobre él, y en el Parlamento el expediente sigue en las comisiones ITRE e IMCO. Los niveles de garantía son la parte con más probabilidades de cambiar. El rumbo 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 y soberanía.

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, averigüe qué nivel de garantía podría alcanzar su servicio. Es en las reglas de contratación de la norma donde el requisito aparecería primero, convertido en criterio de solvencia, y el Public Procurement Act propuesto el 9 de septiembre de 2026 añade encima un marco general de preferencia europea.

No migre por especulación. Mover infraestructura por una propuesta que nadie ha negociado todavía 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.