CADA: El Camino Hacia la Autonomía Tecnológica Europea

Bruselas vuelve a poner la nube en el centro de su política industrial. La Comisión Europea ha adoptado una propuesta bajo el paraguas del Cloud and AI Development Act (CADA) con una idea bastante clara: aumentar la capacidad europea de computación, centros de datos y servicios cloud para sostener el despliegue de la inteligencia artificial en la UE. No es un matiz menor. Si la IA necesita músculo computacional, la Comisión ha decidido hablar menos de promesas y más de infraestructura.

Conviene frenar aquí una tentación habitual: leer cualquier iniciativa industrial europea como una orden inmediata para las empresas. No lo es. Lo que hay, según la fuente disponible, es una propuesta de la Comisión orientada a reforzar el ecosistema europeo de nube y datos, ampliar capacidad y facilitar el desarrollo y uso de IA. Lo que no hay —al menos no en el material que se ha puesto sobre la mesa en esta pieza— es un articulado verificable que permita afirmar obligaciones concretas ya vigentes para empresas, ni mucho menos un catálogo cerrado de controles técnicos, auditorías o sanciones.

Y eso importa. Mucho. Porque una cosa es analizar la dirección política de Bruselas y otra vender como derecho positivo lo que de momento es impulso regulatorio, estrategia industrial o señal de mercado. En compliance, confundir esas tres capas suele salir caro.

Lo que sí dice la propuesta: capacidad, ecosistema y despliegue de IA

La base política del movimiento es reconocible. Europa quiere más capacidad digital propia para soportar cargas de trabajo intensivas, entre ellas las asociadas a sistemas de IA. La fuente habla de fortalecer el ecosistema europeo, ampliar capacidad de nube y centros de datos y apoyar el despliegue de la IA. Esa combinación ya dibuja una prioridad: si quieres competir en IA, no basta con regular modelos; necesitas infraestructura, energía, capacidad de procesamiento, conectividad y operadores capaces de escalar.

El dato relevante no es una supuesta guerra comercial camuflada, porque la fuente no formula el objetivo en esos términos. El dato relevante es otro: Bruselas está conectando política tecnológica e infraestructura de forma mucho más explícita. Durante años, Europa reguló mejor de lo que construyó. Ahora intenta hacer ambas cosas a la vez. Veremos si llega a tiempo, pero al menos el diagnóstico parece menos ingenuo que en fases anteriores.

Para las empresas, esto no significa todavía “migra ya” ni “cambia de proveedor antes de fin de año”. Significa algo más prosaico y más útil: seguir de cerca cómo evoluciona la propuesta, identificar dependencias críticas de capacidad cloud y computacional y prepararse para un entorno donde la disponibilidad de infraestructura en territorio europeo gane peso en decisiones tecnológicas, de riesgo y de contratación.

Lo que no puede afirmarse todavía: obligaciones cerradas, artículos concretos y controles técnicos

Aquí es donde conviene limpiar el terreno. No puede sostenerse, con la fuente aportada, que el CADA contenga ya un “art. 12” sobre medidas de seguridad robustas en la nube, ni que ese supuesto artículo incluya cifrado de datos o controles de acceso estrictos. Esas exigencias pueden ser perfectamente razonables desde un punto de vista de seguridad. De hecho, aparecen en múltiples marcos normativos y de buenas prácticas. Pero una cosa es que sean razonables y otra que estén verificadas en esta propuesta concreta.

Tampoco puede afirmarse que exista un “art. 15” del CADA que obligue a realizar evaluaciones de impacto para cualquier nueva implementación de tecnología cloud, ni que el mismo artículo trate interoperabilidad, ni que imponga auditorías periódicas a proveedores cloud. Cuando un mismo artículo sirve para tres cosas distintas en un texto periodístico, normalmente no estamos ante una joya legislativa, sino ante una alarma de fact-checking bastante obvia.

Lo mismo ocurre con un supuesto “art. 18” sobre gestión de terceros, auditorías independientes o interoperabilidad, y con un “art. 22” que exigiría auditorías internas anuales verificadas por auditores externos certificados. La fuente no permite verificar nada de eso. Por tanto, no debería presentarse como contenido normativo del CADA.

Este tipo de corrección no resta profundidad. La mejora. Separar lo que está en la propuesta de lo que proyectamos sobre ella es precisamente lo que distingue un análisis útil de una pieza inflada con jerga regulatoria.

Entonces, ¿por qué debería importarle a una empresa ahora?

Porque las propuestas de la Comisión rara vez son ruido inocuo cuando encajan con una tendencia política más amplia. Y aquí encajan. La UE lleva tiempo reforzando un patrón regulatorio y operativo que premia tres cosas: resiliencia, trazabilidad y control sobre dependencias críticas. No hace falta inventarse artículos del CADA para verlo; basta con leer otras normas que sí están vigentes o cerradas.

En el sector financiero, DORA dedica los arts. 28 a 30 a la gestión del riesgo asociado a terceros proveedores de servicios TIC. Ahí la obligación no consiste en usar proveedores europeos por defecto, sino en identificar dependencias, fijar cláusulas contractuales, asegurar derechos de acceso, auditoría y salida, y mantener un registro de acuerdos. Eso ya está en el derecho aplicable. Si además la Comisión empuja una agenda de capacidad cloud europea, el resultado práctico para bancos, aseguradoras y firmas de inversión no será una orden binaria de migración, sino una presión creciente para justificar mejor sus concentraciones de riesgo tecnológico.

En ciberseguridad general, NIS2 obliga a adoptar medidas de gestión de riesgos y seguridad de la cadena de suministro en su art. 21. Otra vez: la norma no te dice “compra europeo”, pero sí te obliga a tomarte en serio la dependencia de proveedores y los efectos en continuidad operativa. Si la política industrial europea incrementa la oferta local o incentiva determinados despliegues, muchas organizaciones revisarán su arquitectura no por patriotismo digital, sino por gestión del riesgo.

Y en protección de datos, el GDPR sigue marcando la línea dura. El art. 32 exige medidas técnicas y organizativas apropiadas; el art. 33 impone notificación de brechas a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo máximo de 72 horas; el art. 35 exige evaluaciones de impacto cuando un tratamiento pueda entrañar alto riesgo. Ninguna de esas obligaciones nace del CADA. Todas seguirán operando sobre cualquier estrategia cloud o de IA que una empresa despliegue en Europa.

La consecuencia es menos épica de lo que algunos titulares sugieren, pero más útil: el CADA, tal como está descrito en la fuente, no sustituye marcos existentes; se superpone a ellos como acelerador político e industrial.

La trampa habitual: confundir una propuesta industrial con un checklist de compliance

Hay una manía bastante extendida en el mercado: convertir cada anuncio de Bruselas en una tabla de “obligaciones inmediatas”. Sirve para webinars, vende powerpoints y crea la agradable ficción de que todo cabe en una matriz de semáforos. El problema es que luego llega el verificador de hechos, mira el texto fuente y descubre que la mitad del supuesto checklist se ha escrito con rotulador imaginario.

Con el CADA, la lectura prudente es otra. Hoy no puede sostenerse, con la base disponible, que las empresas de la UE “deberán adaptarse a nuevas exigencias del CADA” si por eso entendemos obligaciones ya definidas y exigibles. Lo correcto es decir que la propuesta apunta a una dirección regulatoria e industrial que puede influir en futuras exigencias, en criterios de contratación pública, en incentivos de inversión o en prioridades supervisoras. No es poca cosa. Pero tampoco es lo mismo que una obligación aplicable mañana por la mañana.

Tampoco puede afirmarse que las organizaciones “posiblemente tendrán que migrar a soluciones que cumplan estándares europeos” si la fuente no impone esa consecuencia operativa concreta. Podría ocurrir en algunos sectores, proyectos financiados o marcos posteriores. Podría no ocurrir de forma general. Presentarlo como desenlace natural hoy sería adelantar el guion.

Qué deberían hacer ahora los equipos de compliance, riesgo y tecnología

Si esperabas una lista de veinte controles inventados, mala suerte. Lo que toca hacer es bastante más serio.

Primero, mapear dependencias reales de infraestructura y capacidad computacional. No en abstracto, sino servicio por servicio: entrenamiento, inferencia, almacenamiento, backup, observabilidad, gestión de identidades, recuperación y servicios administrados. Si no sabes dónde está tu concentración de riesgo, cualquier debate sobre soberanía tecnológica será postureo.

Segundo, revisar cómo encaja esa dependencia con obligaciones que sí existen. En financiero, vuelve a DORA arts. 28 a 30. En ciberseguridad horizontal, mira NIS2 art. 21. En datos personales, GDPR arts. 28, 32, 33 y 35, según el caso. La pregunta útil no es “¿me obliga ya el CADA?”, sino “¿mi arquitectura actual resistiría una revisión seria de terceros críticos, continuidad, portabilidad, seguridad y gobernanza de datos?”.

Tercero, introducir el factor infraestructura europea en la estrategia de compras y de riesgo, pero sin dogmas. Eso implica evaluar localización de datos, jurisdicciones aplicables, dependencia técnica, capacidad de salida, condiciones de subcontratación y transparencia operativa del proveedor. No porque la propuesta disponible imponga todavía un estándar cerrado, sino porque todo apunta a que la resiliencia de la cadena digital va a seguir subiendo posiciones en la agenda supervisora.

Cuarto, vigilar el proceso legislativo y político real. Comisión, Consejo, Parlamento, textos de compromiso, versiones consolidadas, declaraciones de impacto y documentos de implementación. Suena obvio, pero demasiadas decisiones internas se toman a partir de resúmenes comerciales de terceros que convierten una propuesta en una caricatura.

Quinto, no contaminar programas internos con referencias legales dudosas. Si tu memo interno ya cita un “art. 12 del CADA” inexistente o no verificable, no tienes un programa de compliance: tienes una futura corrección dolorosa delante del auditor, del supervisor o del consejo.

El cruce con IA: aquí está el verdadero ángulo

La parte más interesante de esta propuesta no es la nube como commodity, sino la nube como condición material para la IA. Europa ha dedicado mucha energía a gobernar riesgos de la inteligencia artificial. Ahora empieza a asumir algo bastante elemental: sin capacidad de computación y centros de datos suficientes, la conversación sobre IA se queda en una mezcla de principios nobles y dependencia operativa ajena.

Ese giro tiene implicaciones estratégicas. Las empresas que desarrollan o despliegan IA en Europa no solo tendrán que mirar el cumplimiento del AI Act cuando proceda, sino también la disponibilidad y la arquitectura de la infraestructura que sostiene esos sistemas. Si la oferta europea crece o si los incentivos públicos empujan determinados entornos, veremos movimientos de mercado. No porque la Comisión haya decretado una migración general, sino porque la infraestructura dejará de ser una decisión puramente técnica para convertirse en una variable regulatoria, financiera y reputacional.

La ironía es evidente: durante años, medio sector trató la infraestructura como una capa invisible siempre que la factura fuese asumible y el SLA quedase bonito en la presentación. Ahora esa capa invisible se ha vuelto política industrial.

Lo que este debate no es

No es una obligación sanitaria ligada a HIPAA. La referencia a HIPAA 45 CFR 164.312 no tiene base en la fuente ni encaja de forma automática en una propuesta europea de nube e IA. Si una entidad sanitaria opera bajo normativa estadounidense, tendrá sus propias obligaciones en ese ámbito. Pero mezclar HIPAA con el CADA sin soporte documental solo añade ruido y falsa precisión.

No es tampoco una pieza sobre eIDAS 2.0. Introducir una referencia concreta al art. 10 de eIDAS sobre identidad digital y servicios de confianza, sin respaldo de la fuente y sin desarrollo real del vínculo jurídico, solo dispersa la atención. Las regulaciones europeas se cruzan, sí. Pero citar por citar no da profundidad; da sensación de pegote normativo.

Y no es, desde luego, un nuevo código cerrado de seguridad cloud con artículos numerados listos para copiar en una política interna. Quien necesite controles técnicos hoy debe ir a los marcos vigentes y verificables aplicables a su sector y tratamiento, no a un articulado que esta pieza no puede demostrar.

La lectura correcta: menos fantasía normativa, más preparación estratégica

La propuesta de la Comisión merece atención, pero no por las razones exageradas que suelen circular al primer golpe de titular. Lo relevante es que consolida una idea: la competitividad europea en IA va unida a la capacidad cloud y de centros de datos, y esa capacidad deja de ser un asunto neutro. Eso puede traducirse, con el tiempo, en nuevas reglas, incentivos, prioridades de financiación o expectativas supervisoras. Hoy, con la fuente disponible, lo honesto es no ir más allá.

Para las empresas, el mensaje práctico sigue siendo exigente. No porque exista ya un paquete de obligaciones cerradas del CADA verificables artículo por artículo, sino porque el viaje regulatorio europeo apunta en una dirección coherente: menos tolerancia a dependencias opacas, más presión sobre resiliencia operativa y más escrutinio sobre la base material que sostiene la digitalización y la IA.

Si tu organización depende de infraestructura cloud para cargas críticas, esta propuesta no te obliga todavía a reescribir todos tus contratos. Pero sí te da una pista bastante seria sobre qué preguntas van a ganar peso en los próximos años. Dónde corre tu tecnología, de quién dependes, cómo sales si algo falla y qué capacidad tienes dentro del perímetro regulatorio europeo. Lo demás —los artículos inventados, las cifras de ahorro milagrosas y las auditorías fantasma— conviene dejarlo donde corresponde: fuera del documento final.