El Cloud & AI Development Act — CADA, en breve — convierte un debate estratégico en un requisito auditable: cuatro niveles de garantía de la Unión acumulativos, desde la ubicación de los datos hasta el control efectivo sobre cada componente de software. Llevamos su entorno cloud, sus evidencias y sus contratos a esos niveles.
Cifras de la exposición de motivos del Cloud & AI Development Act, propuesta COM(2026) 502 final de 3 de junio de 2026. La norma está en tramitación legislativa: criterios y plazos pueden cambiar.
Durante años, «soberano» fue una promesa de las presentaciones comerciales. El Cloud & AI Development Act (CADA) lo convierte en una lista de criterios que un organismo de auditoría puede marcar — y en una condición para acceder a la contratación pública.
El CADA desplaza el criterio: ya no basta con saber dónde residen los datos, sino quién puede disponer de ellos, de la operación y del software llegado el caso. Las entidades públicas deben determinar uno de los cuatro niveles CADA por caso de uso y solo pueden contratar servicios reconocidos; las entidades críticas en el sentido de la Directiva NIS2 pueden aplicar la misma lógica. La soberanía pasa a ser algo que se documenta, se audita y se asegura por contrato — justo ahí trabajamos.
Hablar de ubicaciones de centros de datos cubre un tercio del tema. Las otras dos deciden los niveles CADA superiores.
¿Dónde residen los datos del cliente, incluidos metadatos y telemetría? ¿Quién accede, con qué privilegios, y queda registrado sin lagunas? El cifrado solo cuenta cuando la gestión de claves está resuelta.
¿Quién opera realmente el servicio? Desde el nivel 2 cuentan la ubicación del personal y las vías de soporte; desde el nivel 3, la nacionalidad del equipo y, si hay información clasificada, la habilitación nacional.
¿Quién suministra el código y quién podrá modificarlo mañana? El nivel más alto exige demostrar control efectivo sobre diseño, mantenimiento, correcciones de seguridad y evolución de cada componente relevante.
Cada nivel del Cloud & AI Development Act contiene al anterior y lo endurece. Elija un nivel: la matriz muestra qué criterio aparece en ese punto.
A partir de aquí audita un organismo independiente. Novedades: personal y soporte exclusivamente desde la Unión, certificado europeo de ciberseguridad al menos «sustancial», prohibición de usar datos operativos para entrenar IA de terceros países y una SBOM completa con auditorías de código para componentes de terceros países.
nuevo en este nivelse mantiene sin cambios
La residencia de datos es un buen comienzo y cubre exactamente el nivel CADA más bajo. Esta comparación evita muchos malentendidos en las licitaciones.
Tres preguntas, una primera orientación. La asignación vinculante corresponde a la evaluación de riesgos del artículo 29 del Cloud & AI Development Act.
Esta estimación no sustituye al asesoramiento jurídico ni a una evaluación de riesgos. Muestra el corredor en el que probablemente se encuentra; la evidencia sólida la construimos juntos.
Seis bloques alineados con el Cloud & AI Development Act, contratables por separado y diseñados para que cada evidencia sirva más de una vez.
Inventariamos su entorno cloud y lo evaluamos en las tres dimensiones: datos, operación y tecnología. Incluidas las preguntas que rara vez aparecen en los cuestionarios de proveedores: flujos de metadatos, vías de soporte, estructura de propiedad.
Resultado: Perfil de soberanía por carga de trabajo con asignación provisional de nivel
Comparamos la situación actual con el nivel objetivo, cuantificamos la brecha y priorizamos por esfuerzo, dependencia y vigencia contractual. No un programa máximo, sino un orden de trabajo ejecutable.
Resultado: Plan de acción priorizado con esfuerzo, secuencia y responsables
Construimos la cadena SBOM que exige el nivel 2, marcamos componentes de terceros países, definimos el tratamiento de las auditorías de código y documentamos las funciones remotas que deben desactivarse.
Resultado: Documentación auditable que también sirve al CRA
Un plan de migración documentado ante el fallo de un proveedor no es solo un criterio del nivel 2: es gobierno de externalización. No solo lo redactamos, lo probamos con usted.
Resultado: Un plan de salida probado en lugar de una declaración de intenciones
Formulamos los requisitos de soberanía vinculados al objeto del contrato, documentados y por tanto defendibles: desde la localización de datos incluida la telemetría hasta derechos de auditoría y cláusulas de separación.
Resultado: Cláusulas contractuales sólidas y criterios de adjudicación sostenibles
Le preparamos para la auditoría que llega: BSI C5 como atestación consolidada, BSI C3A para la dimensión de soberanía y el trabajo previo para un futuro esquema europeo.
Resultado: Un expediente de evidencias que resiste una revisión independiente
El marco de soberanía del Cloud & AI Development Act se apoya en normas que usted ya cumple y pide en gran medida las mismas evidencias.
La asignación de niveles sigue la lógica sectorial de la Directiva NIS2. Si ya está clasificado allí, conoce su ámbito.
Ver servicioDORARegistros, estrategias de salida y riesgo de concentración cubren una parte sustancial de las evidencias de soberanía.
Ver servicioCRALa obligación de SBOM es la misma que ya trae el Cyber Resilience Act. Una implantación, dos normas atendidas.
Ver servicioBSI C5Una atestación C5 aporta buena parte de las evidencias que un auditor querrá ver para los niveles 2 a 4.
Ver servicioBSI C3AEl catálogo C3A aborda justo las preguntas de control que planteará el marco europeo.
Ver servicioEU AI ActLos sistemas de IA alojados y operados en remoto cuentan expresamente como servicios cloud: la lógica de niveles también aplica a la IA gestionada.
Ver servicioSeis pasos que compensan con independencia del resultado del proceso legislativo del CADA, porque NIS2, DORA y el CRA ya exigen las mismas evidencias.
No solo «qué servicio, qué región», sino: quién es el dueño del proveedor, dónde está el personal de operación, qué subcontratistas hay en la pila.
Asigne sus casos de uso a los cuatro niveles como ejercicio. En pocas horas verá para cuáles no habría hoy un proveedor conforme.
Listas de ubicaciones, registros de acceso, diagramas de flujo, SBOM: las evidencias del anexo III son muy concretas y, en la mayoría de organizaciones, incompletas.
Localización de datos incluidos metadatos, vías de soporte, separación de filiales en terceros países, derechos de auditoría. Toca en la próxima negociación, no en la siguiente.
Un plan nunca ensayado no vale más que una declaración de intenciones en una auditoría. Un ejercicio al año marca la diferencia.
Agrupar evidencias, nombrar responsables, documentar la pista de auditoría, para que la primera licitación no se convierta en una carrera por justificantes.
Lo que más nos preguntan los responsables sobre el CADA y la soberanía en la nube.
No. La Comisión presentó la propuesta el 3 de junio de 2026 y sigue el procedimiento legislativo ordinario. Según el borrador, el reglamento entra en vigor a los veinte días de su publicación en el Diario Oficial y se aplica un año después. Los criterios y plazos pueden cambiar; la preparación, no.
Las entidades públicas y de la Unión están obligadas directamente. Las entidades en el ámbito de NIS2 pueden realizar evaluaciones comparables de forma voluntaria y la Comisión podrá hacerlo obligatorio para determinados sectores altamente críticos. Además, el marco fija un estándar de mercado: lo que se exige en licitaciones acaba en los cuestionarios privados de proveedores.
Ayuda mucho, pero no cubre todo el marco. C5 aborda la seguridad de la información en la operación cloud; el marco de soberanía añade propiedad, control, ubicación del personal y cadena de suministro de software. Para la dimensión de control, el catálogo BSI C3A es la referencia más cercana.
Hasta hoy no se ha adoptado un esquema europeo específico para servicios cloud; las negociaciones se consideran bloqueadas. La propuesta lo resuelve con una regla transitoria: mientras no exista esquema de la Unión se aplican los nacionales y, a falta de estos, el proveedor debe demostrar los estándares más altos del Derecho de la Unión. En la práctica: construir atestaciones nacionales ahora, pensando en la compatibilidad europea.
Para un entorno cloud de tamaño medio contamos entre dos y cuatro semanas hasta el perfil de soberanía, según lo sólida que sea ya su documentación contractual y operativa. El análisis de brechas se encadena directamente.
Por regla general no, y desde luego no con prisas. Lo sensato es ordenar sus cargas de trabajo, mejorar la base de evidencias y construir su posición negociadora para el próximo ciclo contractual. Cambiar es una opción entre varias, no el punto de partida.
Fuentes primarias del Cloud & AI Development Act y nuestras páginas de conocimiento para profundizar.
Treinta minutos, su cartera real y una lectura honesta: contrastamos su entorno cloud con los cuatro niveles de garantía del Cloud & AI Development Act y señalamos las brechas que ya puede cerrar.
