Summary As proposed in the Cloud and AI Development Act (CADA), operational objective 2 is a supply-side industrial policy designed to strengthen the Union's technological autonomy. Under Article 3(2)(b) and Article 4(2), this objective mandates the development of "secure, resilient and performant open cloud computing stacks" and the promotion of "AI-optimised servers and baseline software based on processors, accelerators and quantum accelerators designed and manufactured in the Union." Crucially, this objective focuses on creating viable European alternatives to reduce structural dependencies. It is legally and functionally distinct from the Union assurance levels (Title IV), which are demand-side procurement rules based on risk, data location, and third-country control, rather than the geographic origin of the underlying hardware or software components.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, adopts a dual-pillar strategy to secure Europe's digital future. The first pillar, established in Title II, focuses on supply-side capacity building through the Cloud and AI Leadership Initiatives. The second pillar, in Title IV, establishes a demand-side framework for cloud sovereignty. Operational objective 2 sits firmly within the first pillar, addressing the architectural and hardware foundations of the cloud stack to ensure the Union is not structurally dependent on third-country technologies.

The Legal Basis: Articles 3 and 4

The mandate for this objective is explicitly grounded in Article 3(2)(b) of the proposal. This article lists the operational objectives of the Cloud and AI Leadership Initiatives, stating that the initiatives shall pursue the goal of "supporting the development and deployment of cloud computing stacks supporting the Union's technological autonomy."

While Article 3 sets the strategic direction, Article 4(2) provides the specific, actionable measures required to realize this autonomy. The provision translates the abstract concept of "technological autonomy" into concrete technological and industrial targets. These measures are designed to bridge the gap between the Union's advanced research capabilities and their sustainable market exploitation, ensuring that European providers can offer competitive, sovereign alternatives to non-EU incumbents.

Key Components of Operational Objective 2

Under Article 4(2), the proposal outlines five specific actions to support technological autonomy:

  1. Open Cloud Computing Stacks: The proposal requires the development and piloting of "secure, resilient and performant open cloud computing stacks." As detailed in Article 4(2)(a), these stacks must cover the entire infrastructure spectrum, including "on-device edge, connectivity, data and AI tools, backend and service layers for strategic sectors." The focus is on creating end-to-end alternatives that are robust enough for high-value industrial and public sector use cases.
  2. EU-Designed Hardware: A critical component of autonomy is hardware sovereignty. Article 4(2)(b) explicitly calls for the development of "AI-optimised servers and baseline software based on processors, accelerators and quantum accelerators designed and manufactured in the Union." This includes next-generation ultra-high density and long-term data storage. By incentivizing the use of EU-designed chips, the proposal aims to reduce reliance on third-country semiconductor supply chains.
  3. Open-Source Foundations: To prevent vendor lock-in and foster a collaborative ecosystem, Article 4(2)(d) mandates fostering the creation of "open-source software foundations supporting open-source components." This aligns with the broader EU Open Source Strategy, treating open source as a lever for sovereignty and competitiveness.
  4. European Data Spaces: Article 4(2)(c) links technological autonomy to data availability. It supports boosting data availability for AI via "open-source middleware platforms underpinning common European data spaces." This ensures that the hardware and software stacks are supported by accessible, interoperable data infrastructures.
  5. Catalogue of Solutions: Finally, Article 4(2)(e) requires the establishment of a "catalogue of European open cloud computing solutions developed under points (a) to (d) of this paragraph." This creates visibility and market access for European alternatives, helping to scale up the ecosystem.

Distinction from Sovereignty Assurance Levels

It is legally critical for compliance officers and policymakers to distinguish between technological autonomy (operational objective 2) and Union assurance levels (Title IV of CADA). These are two different regulatory mechanisms addressing different parts of the value chain.

  • Technological Autonomy (Supply-Side): Operational objective 2 is an industrial policy tool. Its primary function is to incentivize the creation and deployment of European technology stacks. It does not mandate that public authorities must buy EU-designed hardware or software. Instead, it funds and supports the development of such hardware so that it exists as a viable, competitive option in the market. The goal is to ensure that if a public body wants to procure a sovereign solution, the technology actually exists.
  • Sovereignty Assurance Levels (Demand-Side): The sovereignty framework (Articles 16–24) establishes four assurance levels (1–4) based on risk, data location, and third-country control. These levels are defined in Annex II and focus on where data is stored, who controls the provider, and whether the service can be disrupted by third-country laws.
    • A cloud service can meet Union assurance level 1, 2, 3, or 4 regardless of whether the underlying processors are EU-designed. For example, a cloud service using non-EU hardware might still achieve assurance level 1 if it meets the criteria in Annex II (e.g., provider established in the Union, data remaining in the Union, and no third-country control).
    • Conversely, a service using EU-designed hardware might fail to achieve higher assurance levels if it does not meet the strict control and data residency criteria (e.g., if the provider is subject to third-country control or if data leaves the Union).

Therefore, operational objective 2 expands the supply of sovereign-capable infrastructure, while the assurance levels dictate the procurement rules for public sector bodies based on risk assessments. The former builds the market; the latter regulates the purchase.

What this means for you

For in-house counsel, compliance officers, and strategic planners in the technology, semiconductor, and cloud infrastructure sectors, operational objective 2 signals a significant shift in EU industrial policy.

  • Funding and Project Eligibility: If your organization is involved in cloud infrastructure, semiconductor design, or open-source software development, you should monitor calls for expression of interest related to the Cloud and AI Leadership Initiatives. Projects that demonstrate the integration of EU-designed processors, accelerators, or open cloud stacks may qualify for support under the "grand challenges" framework outlined in Annex I. This could include funding for pilot lines, test beds, or the development of new AI-optimized servers.
  • Supply Chain Strategy: Companies relying on third-country hardware for their EU cloud offerings should anticipate increased competition from European alternatives. While there is no immediate ban on non-EU hardware, the proliferation of EU-designed stacks may influence future procurement preferences, especially if combined with the "Union added value" criteria in public procurement under Article 32. Public bodies may increasingly favor solutions that contribute to the digital supply chain in the Union.
  • Open Source Governance: Organizations participating in or providing components to open cloud stacks should ensure robust open-source governance. Article 4(2)(d) emphasizes the creation of foundations supporting these components. Compliance with open-source licensing and contribution models will be critical for participation in these initiatives and for ensuring that the resulting stacks remain truly open and interoperable.
  • No Immediate Procurement Mandate: Unlike the sovereignty framework, which imposes mandatory procurement rules on public sector bodies (e.g., Article 30 requiring assurance levels 2–4 for public-order activities), operational objective 2 does not create direct legal obligations for private entities to switch suppliers. However, public sector buyers may increasingly specify requirements that align with the outputs of these initiatives, particularly for high-assurance levels where the availability of EU-designed hardware becomes a strategic enabler.

Common misconceptions

"Operational objective 2 mandates the use of EU-designed hardware."

  • Correction: No. Article 4(2) supports the development and deployment of such hardware. It does not prohibit the use of third-country processors. The sovereignty assurance levels (Title IV) do not require EU-designed hardware; they require specific controls over data and service continuity. A provider can achieve Union assurance level 4 using non-EU hardware if they meet the strict control and separation criteria in Annex II.

"Technological autonomy is solely about software."

  • Correction: Article 4(2)(b) explicitly includes hardware. The development of "AI-optimised servers and baseline software based on processors, accelerators and quantum accelerators designed and manufactured in the Union" is a core component. The proposal recognizes that software sovereignty is undermined by hardware dependencies.

"This objective applies only to the public sector."

  • Correction: The Cloud and AI Leadership Initiatives (Title II) are supply-side measures aimed at the entire ecosystem, including private providers. The goal is to create a competitive European supply base that can serve both public and private sectors. The demand-side measures (Title IV) are what primarily target public sector procurement.

"Technological autonomy and sovereignty assurance levels are the same thing."

  • Correction: They are distinct. Technological autonomy (Article 4) is about building the technology. Sovereignty assurance levels (Article 16) are about buying the technology based on risk. A service can be "autonomous" in its stack but fail the "assurance" test if it is controlled by a third country.

Related

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