Summary As proposed, the Cloud and AI Development Act (CADA) fundamentally shifts public sector cloud architecture from a purely technical exercise to a compliance-driven design process. Under Article 30, cloud architects must align their infrastructure with specific "Union assurance levels" determined by national risk assessments, meaning non-sovereign services are excluded from critical public order activities. Furthermore, Article 32(3)(d) introduces "Union added value" criteria that prioritize hardware designed or manufactured in the EU, forcing architects to evaluate supply chains for European integration rather than just performance or cost. To be eligible, services must be formally recognized under Article 17 and listed in the central repository under Article 22.

Detail

The proposed CADA establishes a dual framework for public sector cloud procurement: mandatory sovereignty baselines and incentivized European technological integration. For cloud architects, this means designing systems that are not only functionally robust but also legally recognizable under the new sovereignty framework. The regulation creates a direct link between the risk profile of a public activity and the technical architecture required to support it.

Mandatory Assurance Levels and Architectural Boundaries (Article 30)

Article 30 of the proposed regulation dictates that public procurement of cloud computing services is no longer open to all providers. Instead, it is strictly stratified by the risk profile of the public sector activity as determined by the risk assessment under Article 29. This creates a binary architectural requirement:

  1. Baseline Requirement (Union Assurance Level 1): All contracting authorities whose activities have not been identified as contributing to the preservation of public order must, as a minimum, procure services recognized as offering Union assurance level 1. This establishes a floor for data localization and basic operational autonomy across the entire public sector. For architects, this means ensuring that customer data remains exclusively within the Union and that the provider is established in the EU, unless the public sector body explicitly requires otherwise.
  2. Critical Sector Requirement (Union Assurance Levels 2–4): Contracting authorities whose activities contribute to the preservation of public orderβ€”specifically in sectors falling under Annex I or II of the NIS2 Directive, or in areas of national security, internal security, external border management, defence, justice, or law enforcementβ€”must only procure services recognized as offering Union assurance levels 2, 3, or 4.

For architects, this creates a hard architectural boundary. If a public sector body operates in a critical sector, the cloud architecture cannot rely on global hyperscalers that do not hold the appropriate Union assurance recognition. The architecture must be built on infrastructure that has passed the rigorous audit criteria for the specific assurance level required by the Member State's risk assessment. This includes stricter requirements on personnel (Union citizenship may be required), infrastructure location, and the absence of third-country control.

EU Added Value and Hardware Criteria (Article 32)

While Article 30 sets the mandatory floor for eligibility, Article 32 introduces evaluation criteria that influence which providers win tenders. Contracting authorities must include non-price award criteria that evaluate the tenderer's contribution to the European cloud and AI ecosystem.

Crucially, Article 32(3)(d) specifies that authorities shall evaluate the extent to which:

"the service is delivered, to the greatest extent feasible with regard to market availability and technical requirements, through critical computing, storage and networking hardware components designed and/or manufactured in the Union, or, where this is not feasible, through hardware components from a third country that contributes to strengthening the security of supply and the development of a European cloud and AI ecosystem."

This provision moves beyond software sovereignty to hardware sovereignty. Architects must now consider the origin of physical components (servers, storage, networking gear) as part of the procurement value proposition. It signals a preference for supply chains that reduce dependency on third-country hardware manufacturers, thereby strengthening the EU's industrial base. While not an absolute ban on non-EU hardware, it makes EU hardware a decisive factor in the "Union added value" score, which can be weighted up to 15 points in the evaluation methodology.

Designing for Recognition (Articles 17 and 22)

For a cloud architecture to be eligible for these procurements, the underlying service must be formally recognized. Article 17 outlines the mechanism for this recognition. Providers must submit an application to the national competent authority of their establishment.

  • For Level 1: Providers conduct a conformity self-assessment and issue an EU statement of conformity (Article 19). SMEs benefit from automatic recognition across all Member States.
  • For Levels 2–4: Providers must undergo independent third-party audits (Article 20) to obtain a "positive" audit opinion. The audit criteria are detailed in Annex II, covering establishment, infrastructure location, personnel, cybersecurity certification (at least "substantial" for levels 2 and 3, "high" for level 4), and software supply chain transparency.

Once recognized, the service is registered in a central repository maintained by the Commission under Article 22. Architects must verify that the services they design into their public sector solutions are listed in this central repository. A service that is technically compliant but not formally recognized and listed cannot be legally procured under the mandatory requirements of Article 30. The repository serves as the single source of truth for eligibility.

What this means for you

For CTOs and cloud architects in the public sector (or those serving public sector clients), the practical implications of CADA's procurement rules are immediate and structural. The era of selecting cloud providers based solely on performance, price, or feature sets is ending for public sector projects.

1. Conduct a Sovereignty Gap Analysis Map your current cloud architecture against the four Union assurance levels. If your organization operates in a sector identified as critical (e.g., healthcare, energy, transport, justice, law enforcement), you must determine if your current provider holds Union assurance levels 2, 3, or 4. If not, you face a mandatory migration requirement. Article 29(6) states that where a risk assessment requires migration to another cloud computing service, the Member State or Union entity shall migrate within a reasonable transition period that shall not exceed 12 months. Architects must plan for this migration immediately if their current stack does not meet the assurance criteria.

2. Redefine "Best Value" in Architecture Design Article 32(3)(d) means that the lowest-cost or highest-performance bid may no longer win if it lacks EU hardware integration. When designing new infrastructure, evaluate the supply chain of your hardware. Prioritize solutions that utilize processors, accelerators, and networking equipment designed or manufactured in the EU. Document this integration, as it will be a scoring criterion in tenders. Architects should work with procurement teams to ensure that technical specifications explicitly request evidence of EU hardware design and manufacturing to maximize the "Union added value" score.

3. Verify Repository Status Before Contracting Before finalizing any architecture design, verify that your chosen cloud service provider is listed in the central repository established under Article 22. Do not assume compliance based on marketing claims or existing certifications like ISO 27001. The legal validity of your procurement depends on the provider's formal recognition status under Article 17. If a provider is not listed in the repository for the required assurance level, they cannot be used for the relevant public sector activities, regardless of their technical capabilities.

4. Plan for Multi-Cloud or Multi-Vendor Strategies Article 29(9) encourages Member States and Union entities to consider whether a multi-vendor or multi-cloud strategy is appropriate to enhance resilience. Architects should design architectures that are portable and interoperable, avoiding vendor lock-in. This aligns with the Data Act's switching provisions and supports the CADA goal of reducing dependencies on single third-country providers. Designing for portability ensures that if a provider loses their recognition status, the public sector body can migrate to an alternative recognized provider without service disruption.

5. Engage Early with Procurement Teams Architects must collaborate with procurement officers to ensure that technical specifications reflect the sovereignty requirements. The technical architecture must be designed to meet the specific assurance level mandated by the risk assessment. This requires early dialogue to ensure that the technical design supports the legal compliance framework. For example, if a project requires Level 4, the architecture must support Union citizens for all personnel and "high" cybersecurity certification, which may impact the choice of operating systems, hypervisors, and management tools.

Common misconceptions

Misconception 1: CADA replaces the AI Act or GDPR. CADA does not replace existing laws. It complements them by adding a sovereignty and autonomy layer. While the GDPR protects personal data privacy and the AI Act regulates AI safety and fundamental rights, CADA focuses on the operational autonomy and data sovereignty of the cloud infrastructure itself. Architects must comply with all three frameworks simultaneously. The AI Act governs the system running on the cloud; CADA governs the cloud itself.

Misconception 2: Only EU-based providers can win. CADA allows for third-country providers to qualify for Union assurance level 3 if the Commission adopts a decision recognizing the third country as providing sufficient safeguards under Article 18. This requires an adequacy decision and specific legal safeguards against unauthorized access or service disruption. However, for levels 2 and 4, and generally for level 1, the criteria heavily favor EU-established providers with EU-located infrastructure and personnel. For critical public order activities, the "no third-country control" rule in Annex II is strict, making Level 4 effectively exclusive to EU-controlled entities.

Misconception 3: Hardware origin is optional. Article 32(3)(d) makes EU hardware design/manufacturing a key evaluation criterion, but it is not an absolute ban on non-EU hardware. It states "to the greatest extent feasible with regard to market availability and technical requirements." However, in a competitive tender, a solution with higher EU hardware integration will score higher on the "Union added value" criterion. Architects should treat EU hardware as a competitive advantage, not just a compliance checkbox. If a specific high-performance chip is only available from a third country, the architecture must document why it is not feasible to use an EU alternative.

Misconception 4: Recognition is automatic. Recognition under Article 17 is not automatic. Providers must actively apply, submit evidence, and undergo audits (for levels 2–4). Architects cannot assume a provider is compliant because they are a large, established brand. They must verify the specific recognition status for the specific service offering. A provider may be recognized for Level 1 but not for Level 3, meaning they cannot be used for critical public order activities.

Official sources

Related

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