Summary Under the proposed Cloud and AI Development Act (CADA), the "open source first" principle in Article 41 and the cloud computing sovereignty framework in Articles 16–21 are complementary but legally distinct mechanisms. Article 41 encourages Union entities and public sector bodies to prioritize open standards and open-source components to reduce vendor lock-in and enhance digital autonomy, as noted in Recital 81. However, this preference does not automatically confer a specific Union Assurance Level. Sovereignty tiers are determined by strict, auditable criteria regarding data localization, personnel citizenship, and the absence of third-country control, not merely by the licensing model of the underlying software. A service can be fully open source yet fail to meet Level 2, 3, or 4 requirements if the provider is controlled by a third-country entity or if data leaves the Union.

Detail

The proposed CADA establishes a dual-track approach to strengthening Europe's cloud ecosystem: one track focuses on the technical and legal architecture of the software stack (open source), while the other focuses on the operational and jurisdictional control of the service delivery (sovereignty). Understanding the interaction between Article 41 and the sovereignty tiers defined in Articles 16 through 21 is critical for compliance officers managing public sector cloud contracts.

The "Open Source First" Principle (Article 41)

Article 41 of the CADA proposal mandates that the Union and Member States take necessary measures 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. Crucially, this obligation is not absolute; public bodies must consider functionalities, including security, total cost, and "other relevant, duly justified objective criteria."

Recital 81 of the explanatory memorandum provides the strategic context for this obligation. It states that "open source plays an important role in ensuring transparency, security and efficiency in the use of digital technologies by the public sector." It further explains that "access to the source code enables auditability, fosters collaboration and reuse and reduces dependency on a single vendor, thereby limiting the risk of vendor lock-in." Consequently, the proposal links the adoption of open source directly to the reduction of vendor lock-in and the strengthening of the Union's "digital autonomy."

However, Article 41 is framed as an encouragement and a requirement to "take necessary measures to encourage" usage. It establishes a preference for open-source solutions in the public sector's technological stack but does not define the legal status of the cloud service itself regarding sovereignty. It is a policy driver for the composition of the stack, not a certification of the service provider.

The Sovereignty Framework (Articles 16–21)

The sovereignty framework, detailed in Title IV, Chapter I (Articles 16–21), establishes a harmonised set of criteria for "Union assurance levels" (Levels 1 through 4). These levels determine whether a cloud computing service is sufficiently trusted to be procured by public sector bodies, particularly those handling sensitive data or critical public order functions.

Recognition of a Union assurance level is not automatic based on software licensing. Instead, it requires a rigorous assessment process:

  • Level 1: Requires a conformity self-assessment by the provider (Article 19).
  • Levels 2–4: Require independent third-party audits (Article 20) and formal recognition by national competent authorities (Article 17).

The criteria for these levels, set out in Annex II, focus on operational and jurisdictional factors rather than code accessibility. Key determinants include:

  1. Establishment and Location: The provider and its subcontractors must be established in the Union, and infrastructure/assets must be located within the Union (Annex II, Section 2.1(b)).
  2. Data Localization: Customer data, including metadata and telemetry, must remain exclusively within the Union (Annex II, Section 2.1(c)).
  3. Personnel and Citizenship: For Levels 3 and 4, personnel involved in service provision must be Union citizens, and for Level 4, they may require national security clearance (Annex II, Sections 3.1(d) and 4.1(d)). Note that for Level 2, Union citizenship is only required if the public sector body explicitly demands it (Annex II, Section 2.1(d)).
  4. Absence of Third-Country Control: Providers must demonstrate they are not subject to the control of a third country or a legal entity established in a third country (Annex II, Sections 3.1(g) and 4.1(g)). For Level 3, derogations are possible only if the Commission has adopted a specific implementing act for that third country under Article 18 (often mis-cited as Article 19 in drafts; the text confirms Article 18).

Interaction Between Open Source and Sovereignty Tiers

While open source supports the goal of sovereignty by enhancing transparency and reducing technical dependency, it is not a proxy for sovereignty compliance. A cloud service built entirely on open-source software can still fail to achieve Union Assurance Level 2, 3, or 4 if the provider is controlled by a third-country entity, if data is processed outside the Union, or if the personnel lack the required citizenship status.

Conversely, a proprietary software solution could theoretically meet the sovereignty criteria if the provider is fully EU-established, operates exclusively within EU borders, and meets all personnel and data localization requirements.

Article 41 requires public bodies to consider open source when building their ecosystems, but Article 30 (Public Procurement) dictates that the choice of provider must align with the risk assessment results. If a risk assessment (Article 29) determines that a public order-relevant activity requires Union Assurance Level 3, the contracting authority must procure from a provider recognized at that level. The fact that a Level 1 provider uses open source does not exempt them from the higher assurance requirements if the use case demands them.

Furthermore, Annex II explicitly addresses open-source software within the audit criteria for Levels 2, 3, and 4. Providers must demonstrate that they have implemented controls to prevent the use of remote features or mechanisms in open-source components that could tamper with or disrupt the service (Annex II, Sections 2.1(j), 3.1(j), and 4.1(j)). This means that using open source introduces specific audit obligations regarding supply chain security and code integrity, rather than simplifying the sovereignty assessment. The audit evidence required includes testing procedures to prove the absence of remote tampering mechanisms (Annex III, Section 10).

What this means for you

For in-house counsel and compliance officers in the public sector, the interaction between Article 41 and the sovereignty framework creates a layered compliance obligation:

  1. Procurement Strategy Alignment: When drafting tender specifications, you must simultaneously apply the "open source first" encouragement of Article 41 and the mandatory assurance levels derived from Article 29 risk assessments. You cannot use a preference for open source to justify procuring a service that does not meet the required Union Assurance Level for the specific use case. If a risk assessment mandates Level 3, a Level 1 open-source provider is non-compliant.
  2. Audit Readiness for Providers: If you are a cloud provider seeking recognition under CADA, do not assume that using open-source stacks will streamline your audit for Levels 2–4. Auditors will specifically examine your controls over open-source components (Annex II) to ensure no remote tampering mechanisms exist. You must document these controls rigorously, including migration plans in the event a third-country vendor fails (Annex II, Section 2.1(i)).
  3. Risk Assessment Documentation: Ensure your risk assessments (Article 29) clearly distinguish between technical risks (mitigated by open source auditability) and sovereignty risks (mitigated by jurisdictional and operational controls). The Commission's guidance on mapping assurance levels to data sensitivity will be critical here.
  4. Deadlines and Penalties: Member States must designate national competent authorities by the date of entry into force plus one year (Article 25). Cloud providers must submit applications for recognition to these authorities. Failure to comply with transparency obligations (Article 23) or providing misleading information can lead to penalties under Article 24, which must be "effective, proportionate and dissuasive."

Common misconceptions

  • "Open source equals sovereign." This is incorrect. Sovereignty under CADA is defined by jurisdictional control, data location, and personnel status, not by code visibility. A non-EU controlled entity using open source is still subject to third-country control risks and cannot achieve Level 3 or 4 without a specific Commission derogation under Article 18.
  • "Article 41 mandates open source for all contracts." Article 41 encourages the use of open source and requires Member States to take measures to promote it. It allows for exceptions based on security, total cost, and other justified objective criteria. It is not an absolute mandate that excludes proprietary solutions if they are technically superior or more secure in a specific context.
  • "Sovereignty tiers replace cybersecurity certification." The CADA sovereignty framework complements, but does not replace, cybersecurity requirements. Annex II explicitly requires Union Assurance Levels 2–4 to obtain a European cybersecurity certificate of at least 'substantial' assurance level (for Levels 2 and 3) or 'high' assurance level (for Level 4) under the Cybersecurity Act, where available. Note that L3 is "substantial," same as L2; only L4 is "high."

Official sources

Related

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