What does CADA mean for CTOs and cloud architects?

As proposed, the Cloud and AI Development Act (CADA) would turn cloud architecture from a purely technical exercise into a sovereignty and compliance manda

Summary As proposed, the Cloud and AI Development Act (CADA) would turn cloud architecture from a purely technical exercise into a sovereignty and compliance mandate. For CTOs and architects, that means designing systems that map to one of four "Union assurance levels" (Article 16, with criteria in Annex II) to meet public-sector procurement requirements, prioritising open-source solutions (Article 41), and exploring new routes to high-performance compute through the Cloud and AI Leadership Initiatives.

Detail

CADA targets the structural resilience of Europe's cloud and AI ecosystem. It establishes criteria for cloud sovereignty, encourages open-source adoption in the public sector, and creates pathways to critical compute.

The sovereignty framework as a design signal

Article 16 establishes a "Union cloud computing sovereignty framework" of four assurance levels. As proposed, cloud computing service providers must meet the cumulative criteria in Annex II to be recognised at each level. For architects, the levels are functional design constraints affecting infrastructure location, personnel, data residency and supply-chain control. In summary (per Annex II):

Level 1: the provider is established in the Union; its infrastructure and assets (and those of subcontractors involved in the service) are located in the Union unless the public sector body requires otherwise; and customer data — including metadata and telemetry — remains exclusively within the Union unless the public sector body explicitly requires otherwise. Verified by conformity self-assessment.
Level 2: adds that infrastructure, assets and personnel are located in the Union; that data generated by using the service is not used to train or fine-tune AI systems operated by a third country and is not transferred outside the Union; a cybersecurity certificate of at least "substantial" (or equivalent); and software supply-chain controls (SBOM, controls on third-country components). Personnel screening and Union-citizenship requirements apply only if the public sector body determines they are necessary.
Level 3: requires that personnel (including subcontractors involved in the service) are Union citizens; that the provider and those subcontractors are not subject to third-country control (with a narrow derogation for "associated third countries" under Article 18); and that technical and operational support is performed exclusively within the Union by Union residents.
Level 4: the highest tier — customer data identified as sensitive following a risk assessment remains exclusively in the Union; personnel are Union citizens; the provider and subcontractors are not subject to third-country control; support is performed within the Union by Union residents; and a cybersecurity certificate of at least "high" (or equivalent) applies.

Public-sector procurement is tied to these levels. Under Article 30, activities not identified as contributing to public order use at least level 1 (Article 30(2)), while activities identified as contributing to public order under the risk assessment in Article 29(1) must procure services recognised at levels 2, 3 or 4 (Article 30(3)). Architects building for government or critical-infrastructure clients must therefore design architectures that can be audited against these criteria — mapping data flows to prove data stays in the Union, and verifying the supply chain so no third-country entity can exercise control.

Open source first and reuse obligations

Article 41 requires the Union and Member States to encourage Union entities and public sector bodies to "use and facilitate the reuse of open standards and components released under an open source licence when building their cloud and AI ecosystem or stack," taking into account functionalities including security, total cost, and other duly justified criteria.

For CTOs, this signals a shift away from proprietary-only stacks for public-facing or government work. Proprietary solutions are not banned, but they must compete with open-source alternatives on security, total cost and functionality. Article 42 adds that when a Union entity or public sector body makes its software available for reuse under an open-source licence, it must do so via a catalogue or repository connected to the EU Open Source Solutions Catalogue (Article 43) — a practical obligation for delivery pipelines.

Compute access via the Leadership Initiatives

Compute scarcity has been a barrier to EU AI development. CADA addresses this through the Cloud and AI Leadership Initiatives (Title II). Article 3 sets the general objective of promoting research and innovation and achieving large-scale capacity, and Article 9 provides for the allocation of AI computing resources to "frontier AI priority projects" (defined under Article 8). For CTOs leading AI work, this opens potential routes to prioritised compute, reducing reliance on non-European hyperscalers.

What this means for you

Architect for auditability. Design for demonstrable compliance with the sovereignty criteria: rigorous data-residency controls, logging of data flows, and documented software supply chains. For levels 2–4, prepare for independent audits (Article 20).
Vendor and technology selection. Assess your current stack against the levels. If your provider cannot reach level 2 or higher due to third-country control or overseas data centres, you may lose eligibility for certain public-sector contracts. Prioritise open-source components to align with Article 41.
Compute strategy. If you develop frontier or industrial AI, assess eligibility for AI computing-resource allocation under Article 9 — potentially a route to scarce EU-based compute.

Common misconceptions

"CADA only applies to the public sector." The procurement mandates in Article 30 target contracting authorities and Union entities, but the sovereignty framework (Article 16) applies to providers serving Union entities and public sector bodies. Under Article 31, entities listed in Annex I to the NIS2 Directive (Directive (EU) 2022/2555) that are not public bodies may also carry out impact assessments, and public-sector standards will influence market expectations.
"Open source means free software." Article 41 promotes open source for sovereignty and security reasons and requires weighing functionality, security and total cost — not just price.
"I can ignore this until the law is finalised." CADA is a proposal, but it is already shaping the market: providers are designing "sovereign" offerings in anticipation. Architects who delay mapping their architectures to the assurance levels risk being locked into non-compliant stacks.

This is general information about a draft EU regulation, not legal advice.