Summary As proposed, the Cloud and AI Development Act (CADA) does not prohibit multi-cloud or hybrid architectures; however, it imposes a strict, service-by-service sovereignty assessment that treats each cloud component as an independent entity requiring its own recognized Union Assurance Level (UAL). Under Article 16 and Annex II, you cannot rely on a single "umbrella" certification for a hybrid stack. Every providerβ€”and their subcontractorsβ€”must meet specific, cumulative criteria for data residency, personnel location, and absence of third-country control corresponding to the assurance level mandated by your risk assessment. If a single component in a data flow fails to meet the required UAL, the entire workflow for that public-order-relevant activity may become non-compliant.

Detail

The proposed CADA fundamentally shifts the compliance burden for multi-cloud and hybrid environments from a provider-centric model to a granular, component-centric one. For CTOs and architects, this means that a hybrid architecture involving two EU-based providers and one global hyperscaler is not a single compliance unit. It is a collection of distinct services, each subject to individual scrutiny under the Union Cloud Computing Sovereignty Framework established in Article 16.

1. Service-by-Service Recognition is Mandatory

Under Article 17, cloud computing service providers must apply for recognition to offer a specific Union Assurance Level (UAL 1, 2, 3, or 4). Crucially, this recognition applies to the service as provided by that specific legal entity. Article 17(1) states that a provider "shall submit an application for recognition to the national competent authority of establishment." There is no provision in CADA for "aggregate" or "federated" recognition of a multi-cloud stack.

If your architecture uses Provider A for storage (UAL 2) and Provider B for compute (UAL 3), both must individually hold their respective recognitions. The Central Repository established under Article 22 will list recognized services, allowing public sector bodies to verify the status of each component in their hybrid stack. If Provider B loses its UAL 3 status, your entire hybrid workflow for that specific high-risk use case becomes non-compliant, even if Provider A remains certified. The recognition is tied to the specific service offering, not the corporate entity's general footprint.

2. The "Weakest Link" Principle in Hybrid Stacks

In a multi-cloud environment, data flows between services. CADA's criteria in Annex II are cumulative and strict regarding data residency and control. For example, Annex II, Section 2.1(c) (UAL 2) and Section 3.1(c) (UAL 3) require that customer data, including metadata and telemetry, "remain exclusively within the Union, unless the public sector body explicitly requires otherwise."

In a hybrid architecture, if an application layer (UAL 1) processes data and sends it to a database layer (UAL 2), the transfer must occur within the Union. If the UAL 1 provider routes data through a third-country peering point or uses a global load balancer that temporarily stores metadata outside the EU, it may breach the residency requirements of the higher-assurance tier it interacts with. Annex II, Section 2.1(d) further requires that if a public sector body determines that imposing additional personnel screening and Union citizenship requirements are necessary, the audited provider "should ensure that personnel meeting those requirements are available." This implies that the operational teams managing each leg of the hybrid architecture must independently satisfy the personnel criteria for their respective assurance levels.

3. Subcontractor and Third-Country Control Risks

Multi-cloud architectures often rely on subcontractors for specialized services (e.g., managed Kubernetes, AI inference engines). Annex II explicitly extends criteria to subcontractors. Annex II, Section 2.1(a) requires that subcontractors involved in the provision of the service are established in the Union. Section 2.1(b) requires their infrastructure, assets, and personnel to be located in the Union.

For UAL 3 and 4, the requirements intensify. Annex II, Section 3.1(g) states that the audited provider and its subcontractors "are not subject to the control of a third country or a legal entity established in a third-country." This is a critical hurdle for hybrid architectures using global hyperscalers. Even if the data resides in an EU data center, if the hyperscaler is subject to the extraterritorial laws of a third country (such as the US CLOUD Act), it cannot meet UAL 3 or 4 criteria unless a specific derogation under Article 18 applies. Article 18 allows the Commission to identify third countries as providing sufficient assurances, but this requires an implementing act. Currently, no such derogations are in place for major US hyperscalers, effectively barring them from UAL 3/4 contracts in hybrid setups for critical public order activities.

Furthermore, Annex II, Section 4.1(g) for UAL 4 reiterates that the provider and subcontractors "are not subject to the control of a third country or a legal entity established in a third-country." This strict "no control" rule applies to the entire supply chain. If a UAL 4 service relies on a third-country subcontractor for technical support, it fails the criteria unless that subcontractor is effectively separated and not subject to third-country control, a high bar to clear.

4. Risk Assessments Drive Architecture Choices

Article 29 obliges Member States and Union entities to conduct risk assessments to determine the required UAL for their public sector activities. This assessment must consider the sensitivity, criticality, and magnitude of data processed. If a risk assessment determines that a specific activity contributes to the preservation of public order (e.g., healthcare, defense, justice), Article 30(3) mandates that contracting authorities "shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3 or 4."

This means you cannot use a UAL 1 service for any component of a UAL 3 workflow. If your hybrid architecture includes a UAL 1 analytics tool that ingests data from a UAL 3 core system, the entire chain may be deemed non-compliant for that high-risk use case. The risk assessment must map every data flow and service interaction to the required assurance level. Article 30(2) clarifies that for activities not identified as contributing to public order, UAL 1 is the minimum requirement. However, for public-order activities, the "weakest link" rule applies: every service in the chain must meet the highest required level.

5. Data Residency and Flow Integrity

The criteria for data residency are absolute for UAL 2, 3, and 4. Annex II, Section 2.1(c) and Section 3.1(c) state that customer data "remain exclusively within the Union." This includes metadata and telemetry. In a hybrid setup, data flows must be engineered to ensure no accidental leakage occurs. For instance, if a UAL 3 service sends logs to a UAL 1 logging service located in the EU, the UAL 1 service must still ensure that the data does not leave the Union. However, if the UAL 1 service is subject to third-country control, it may fail the "absence of control" criteria required for the overall workflow if the data is considered sensitive.

Annex II, Section 3.1(d) and Section 4.1(d) introduce a specific personnel requirement for UAL 3 and 4: "the personnel, including the personnel of the subcontractors which are involved in the provision of the audited service are Union citizens." This is a mandatory requirement for UAL 3 and 4, whereas for UAL 2, it is conditional: "if the public sector body determines that imposing additional personnel screening and Union citizenship requirements are necessary." This distinction is vital for hybrid architectures; if a UAL 3 service relies on a UAL 2 subcontractor for support, that subcontractor must also ensure Union citizenship for its personnel if the public sector body has triggered the requirement.

What this means for you

For CTOs and architects designing multi-cloud or hybrid systems for EU public sector clients, the following actions are required:

  1. Map Your Stack to UALs: Create a detailed inventory of every cloud service, SaaS tool, and infrastructure component in your hybrid architecture. Identify the provider and their current UAL status in the Central Repository (once operational). Do not assume a provider's general "EU presence" equates to a specific UAL recognition for a specific service.
  2. Audit Data Flows: Ensure that data exchanges between components of different assurance levels do not violate residency or control criteria. For instance, avoid routing UAL 3 data through UAL 1 gateways that lack strict EU-only data handling guarantees. Verify that metadata and telemetry do not leave the Union.
  3. Scrutinize Subcontractors: Demand transparency from your providers regarding their subcontractors. Under Annex II, if a provider uses a third-country subcontractor for technical support or infrastructure management, they may fail to meet UAL 2-4 criteria. Verify that all subcontractors are EU-established, EU-located, and, for UAL 3/4, not subject to third-country control.
  4. Prepare for Migration: If your current hybrid architecture relies on global hyperscalers for critical workloads, you may need to migrate those workloads to EU-based providers that can achieve UAL 3 or 4. This is a significant architectural shift, not just a vendor swap. The "no control" rule in Annex II, Section 3.1(g) and 4.1(g) is a major barrier for non-EU controlled entities.
  5. Monitor Recognition Status: Recognitions are not permanent. Article 23 requires providers to report material changes that may affect their assurance level. If a provider in your hybrid stack loses its recognition, you must have a contingency plan to replace it without disrupting service continuity.
  6. Align Personnel Requirements: For UAL 3 and 4, ensure that all personnel, including those of subcontractors, are Union citizens. For UAL 2, be prepared to trigger the citizenship requirement if your risk assessment deems it necessary.

Common misconceptions

  • "If the data stays in the EU, I'm compliant." Incorrect. CADA's sovereignty framework goes beyond data residency. Annex II includes criteria on the absence of third-country control, personnel citizenship (for UAL 3/4), and subcontractor location. A US hyperscaler with EU data centers still fails UAL 3/4 due to third-country control risks.
  • "One certification covers my whole multi-cloud setup." Incorrect. Recognition is service-specific. Each provider in your hybrid stack must individually apply for and receive recognition for the specific assurance level they offer. There is no "multi-cloud certification."
  • "Hybrid clouds are automatically UAL 1." Incorrect. You can have a UAL 3 hybrid cloud if all components (including subcontractors) meet UAL 3 criteria. However, mixing UAL 1 and UAL 3 services in a single critical workflow is likely non-compliant for high-risk public order activities.
  • "Open source software is exempt from sovereignty checks." Incorrect. While Article 41 promotes open source, the cloud service delivering that software must still meet the UAL criteria. If the open source tool is hosted on a UAL 1 platform, it cannot be used for UAL 3 workloads.
  • "UAL 2 personnel rules are the same as UAL 3." Incorrect. For UAL 2, Union citizenship for personnel is conditional ("if the public sector body determines..."). For UAL 3 and 4, it is mandatory ("the personnel... are Union citizens").

Related

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