Qué es el CADA y por qué ahora
La propuesta de Reglamento CADA no surge de la nada. Es la respuesta regulatoria a un problema estructural que la pandemia de 2020, la crisis de semiconductores de 2021-2022 y la aceleración de la IA generativa han hecho imposible ignorar: la Unión Europea depende de infraestructura computacional — centros de datos, semiconductores, modelos fundacionales — que en su mayoría se diseña, fabrica y opera fuera de sus fronteras.
El diagnóstico del regulador es claro: si la UE no actúa, será un consumidor neto de tecnología digital en menos de una década. El CADA es el instrumento legislativo para evitarlo.
Los cuatro objetivos del reglamento
El CADA articula su mandato en cuatro pilares, cada uno con implicaciones distintas para los arquitectos cloud enterprise:
El ecosistema regulatorio que rodea al CADA
El CADA no opera en el vacío. Se superpone sobre un ecosistema regulatorio ya complejo — y la integración entre reglamentos es donde aparecen los problemas reales de implementación.
| Reglamento | Interacción con CADA | Riesgo de colisión |
|---|---|---|
| Reglamento de IA (AI Act) | CADA refuerza la capacidad computacional para modelos de IA de alto riesgo; AI Act regula su uso. La misma infraestructura debe cumplir ambos. | Requisitos de auditoría de modelos fundacionales pueden entrar en conflicto con la opacidad de modelos de terceros disponibles en plataformas cloud. |
| RGPD | La soberanía de datos CADA complementa el RGPD. Residencia de datos en EEA ya es obligatoria para datos personales — CADA la extiende a infraestructura crítica. | Bajo. El RGPD ya establece el marco; CADA añade garantías estructurales sin contradecirlo. |
| Data Act | Portabilidad de datos entre proveedores cloud. CADA refuerza el pilar de continuidad operativa. Ambos juntos apuntan a reducir el vendor lock-in. | Medio. La implementación técnica de portabilidad cloud-to-cloud es compleja — los reglamentos establecen el derecho, no el cómo. |
| Chips Act 2.0 | CADA necesita semiconductores europeos para sus objetivos de capacidad. Chips Act financia la fabricación; CADA crea la demanda. | Bajo. Son complementarios por diseño. |
| DORA (sector financiero) | DORA ya exige resiliencia operativa digital y auditoría de terceros críticos. CADA refuerza la posición negociadora frente a hyperscalers en contratos cloud. | Bajo-Medio. DORA tiene plazos más inmediatos; CADA añade requisitos a 5-7 años. Los equipos que ya trabajan en DORA deberán incorporar CADA al roadmap de cumplimiento. |
La clave de integración: el CADA, el AI Act, el Data Act y DORA comparten un denominador común — todos requieren saber exactamente dónde están los datos, quién puede acceder a ellos y qué pasa si el proveedor desaparece. Si ya tienes un mapa de datos actualizado y contratos cloud revisados por DORA, el coste de cumplimiento adicional del CADA será marginal. Si no, el CADA será la excusa que finalmente fuerce esa inversión.
Implicaciones técnicas para arquitecturas cloud enterprise
Más allá del texto regulatorio, ¿qué cambios concretos generará el CADA en los entornos que diseñamos y operamos?
1. El multicloud deja de ser opcional en sectores regulados
El pilar de continuidad operativa del CADA —combinado con el Data Act— hace que depender de un único hyperscaler sea progresivamente indefendible en sectores críticos. No porque lo prohíba directamente, sino porque las auditorías de terceros críticos (DORA, CADA) y los requisitos de portabilidad exigen demostrar que puedes salir de un proveedor en un plazo razonable sin interrupción de servicio.
Esto tiene consecuencias arquitectónicas directas: abstracciones multicloud, estandarización en Kubernetes/containers frente a servicios PaaS propietarios para cargas de trabajo críticas, y planes de salida documentados para cada proveedor cloud. El vendor lock-in ya no es solo un riesgo financiero — es un riesgo de cumplimiento regulatorio.
2. La zona de aterrizaje (Landing Zone) necesita una capa de cumplimiento CADA
Las Landing Zones actuales — diseñadas bajo CAF (Cloud Adoption Framework) o AWS Landing Zone Accelerator — no incluyen los controles que el CADA va a exigir. El gap principal está en tres áreas: auditoría de acceso de autoridades de terceros países (¿puede el gobierno de un tercer país exigir acceso a tus datos en esa infraestructura?), portabilidad técnica (¿puedes exportar todo tu entorno en un formato estándar en menos de 30 días?) y continuidad documentada (¿tienes un runbook de failover hacia infraestructura europea alternativa?).
Para las organizaciones que ya han desplegado una Landing Zone, la respuesta correcta no es rediseñarla — es añadir políticas de cumplimiento CADA como una capa adicional, igual que se hizo con las políticas ENS o DORA. Azure Policy, AWS Config Rules y Google Cloud Organization Policies son el mecanismo técnico natural para implementar esos controles.
3. La elección de región cloud se convierte en decisión regulatoria
Hasta ahora, elegir entre West Europe (Amsterdam), Spain Central (Madrid) o France Central era principalmente una decisión de latencia y disponibilidad de servicios. Con el CADA, añade una dimensión regulatoria: ¿está esa región operada por infraestructura bajo jurisdicción exclusivamente europea? ¿Existen garantías contractuales de que el personal con acceso privilegiado es ciudadano europeo? ¿Aplica el Confidential Computing en esa región?
Spain Central en Azure, que lleva operativa desde 2022, tiene ventaja aquí: combina baja latencia para usuarios españoles con la certeza jurisdiccional que el CADA va a reforzar. Para organizaciones del sector público español ya sometidas al ENS, la combinación Spain Central + Confidential Computing + Azure Confidential Ledger es la arquitectura que mejor anticipa los requisitos del CADA.
4. Los contratos con hyperscalers van a renegociarse
El Data Act ya impuso obligaciones de portabilidad a los proveedores cloud. El CADA añade garantías de continuidad y soberanía. En la práctica, esto se traduce en cláusulas contractuales más detalladas sobre: acceso de autoridades de terceros países (los hyperscalers americanos ya incluyen estas cláusulas en sus contratos enterprise, pero hay que verificarlas y actualizarlas), portabilidad técnica (garantías de exportación de datos en formatos estándar), y planes de salida (procedimientos de terminación sin penalización por cambio de proveedor).
Los Enterprise Agreement con Azure, AWS y GCP que se firmaron antes de 2024 probablemente necesiten una revisión a la luz del Data Act vigente y el CADA en preparación. El momento de revisarlos es ahora, antes de que el CADA entre en vigor y la posición negociadora se debilite.
La hoja de ruta de cumplimiento CADA en cuatro fases
El CADA es todavía una propuesta — el Consejo y el Parlamento Europeo deberán debatirlo, posiblemente durante 2026-2027, antes de que entre en vigor. Pero esperar a la aprobación definitiva para empezar a prepararse es el error más frecuente con la regulación europea. El RGPD, el AI Act y el DORA demostraron que las organizaciones que empezaron a adaptarse durante el proceso legislativo acabaron con ventaja competitiva.
Lo que el CADA no resuelve
El CADA es un instrumento necesario, pero tiene límites que conviene conocer antes de asumirlo como solución completa a la dependencia tecnológica europea.
No resuelve la dependencia en modelos fundacionales de IA. Los grandes modelos de lenguaje (GPT, Gemini, Claude) se entrenan en infraestructura americana o china. CADA puede exigir que la inferencia ocurra en territorio europeo, pero el entrenamiento y las capacidades del modelo seguirán dependiendo de inversiones fuera de la UE mientras no exista una industria europea de modelos fundacionales a escala. El AI Act y el CADA apuntan en la dirección correcta, pero la brecha de capacidad en IA es de años, no de meses.
No elimina el riesgo de la CLOUD Act americana. La CLOUD Act permite al gobierno estadounidense exigir acceso a datos almacenados en infraestructura operada por empresas americanas, independientemente de dónde estén físicamente esos datos. Azure, AWS y GCP son empresas americanas. El CADA puede exigir garantías contractuales, pero no puede invalidar la legislación estadounidense. Para datos que deben quedar completamente fuera del alcance de la CLOUD Act, la única solución técnica disponible hoy es el Confidential Computing combinado con operadores europeos sin vínculos con empresas americanas — un mercado todavía limitado.
No acelera la capacidad europea a corto plazo. Triplicar la capacidad computacional de la UE en 5-7 años requiere inversión masiva en centros de datos, redes eléctricas y semiconductores. Es una promesa a medio plazo. Las decisiones arquitectónicas que debes tomar hoy — qué región usar, qué servicios contratar, qué contratos firmar — tienen que hacerse con la infraestructura existente, no con la que el CADA pretende construir.
La trampa regulatoria más frecuente: confundir cumplimiento normativo con soberanía técnica real. Un entorno cloud que cumple el CADA en papel pero cuyos datos críticos solo pueden procesarse en instancias de un único hyperscaler americano no es soberano — es conforme. La soberanía real requiere arquitecturas que demuestren portabilidad operativa, no solo que firmen las cláusulas correctas.
La oportunidad para los arquitectos cloud europeos
Detrás de cada nuevo reglamento europeo existe una ventana de oportunidad para las organizaciones que se preparan antes que sus competidores. El GDPR generó una industria de compliance. El AI Act está generando una industria de governance de IA. El CADA generará demanda de arquitectos que sepan diseñar entornos cloud que cumplan soberanía, portabilidad y continuidad simultáneamente — y que puedan demostrarlo ante un auditor.
Las competencias que el CADA va a poner en valor en los próximos años son: diseño de Landing Zones con controles de soberanía incorporados, análisis de contratos cloud desde la perspectiva de portabilidad y acceso de terceros, implementación de Confidential Computing para cargas de trabajo críticas, y diseño de planes de salida de proveedor (runbooks de portabilidad) que sean técnicamente ejecutables, no solo documentos.
Ninguna de estas competencias es nueva. Muchas organizaciones que ya trabajan bajo DORA, ENS o el AI Act tienen parte del camino recorrido. El CADA no exige empezar de cero — exige integrar las piezas que ya existen en un marco regulatorio coherente.