Summary Under Article 41 of the proposed Cloud and AI Development Act (CADA), Union entities and Member States must encourage public sector bodies to use open standards and components when "building their cloud and AI ecosystem or stack." This phrase encompasses the entire technology infrastructure required to develop, host, and operate AI systems, extending far beyond the final application layer. As proposed, the regulation establishes an "open source first" principle across all layers of this stackβ€”from foundational hardware and middleware to AI models and user interfaces. The goal is to reduce vendor lock-in, enhance interoperability, and strengthen the Union's technological sovereignty by ensuring that public procurement supports a diverse, transparent, and reusable digital supply chain.

Detail

Article 41 of the CADA proposal introduces a specific obligation for the Union and Member States to promote open source solutions within the public sector. The full text of Article 41 states:

"The Union and Member States shall take the 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, taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

To understand the practical impact of this provision, it is essential to unpack the specific terminology used: "cloud and AI ecosystem or stack." This phrasing is deliberate and broad, designed to prevent public authorities from adopting open source only at the application level while remaining locked into proprietary, closed-source infrastructure at the foundational level.

The "Stack" as a Holistic Infrastructure

In technical architecture, a "stack" refers to the layered assembly of software and hardware that supports a digital service. In the context of CADA, the "cloud and AI stack" is not limited to the artificial intelligence models themselves. Instead, it encompasses the entire digital supply chain required to deploy AI-driven cloud services. The legislation explicitly targets the full breadth of technology choices to ensure sovereignty and resilience.

This holistic scope includes:

  1. Foundational Infrastructure: The underlying cloud computing platforms, containerization technologies, orchestration tools (such as Kubernetes), and virtualization layers that manage computing resources. This layer also includes the hardware interfaces and firmware that enable these resources.
  2. Middleware and Data Layers: The software that connects applications to databases, manages data flows, ensures interoperability between different systems, and handles data processing pipelines. This includes APIs, message brokers, and data integration tools.
  3. AI Components: The models, algorithms, training datasets, inference engines, and the frameworks used to build them (e.g., PyTorch, TensorFlow, or proprietary alternatives).
  4. Application and Interface Layers: The user-facing applications, dashboards, and APIs that allow public sector employees and citizens to interact with the AI systems.

By using the term "ecosystem or stack," the legislation ensures that the "open source first" principle applies vertically. A public body cannot claim compliance by releasing a user interface as open source while relying on a proprietary, closed-source cloud platform that prevents data portability or creates a "walled garden."

Open Standards and Components

Article 41 specifically encourages the use of "open standards and components released under an open source licence." This distinction is critical for understanding the scope of the obligation:

  • Open Standards: These are technical specifications that are publicly available, developed through a consensus-based process, and implemented without royalty fees (or with reasonable terms). Using open standards ensures that different systems can communicate with each other (interoperability) and that public bodies are not forced to use a single vendor's proprietary protocol. This is essential for the "ecosystem" aspect, allowing different providers to plug into the same infrastructure.
  • Open Source Components: These are software elements whose source code is made available for use, modification, and distribution under an open source licence. The proposal encourages the reuse of these components to maximize the value of public expenditure, avoid duplication of effort, and foster innovation.

The provision requires that the choice of open source solutions be based on objective criteria. Public sector bodies must consider functionalities, security, total cost of ownership, and other relevant factors. This means that open source is not mandated blindly; it must be a viable, secure, and cost-effective option compared to proprietary alternatives. However, the default expectation is that open solutions should be prioritized where they meet these objective criteria. The phrase "duly justified objective criteria" implies that if a public body chooses a proprietary solution, they must be able to demonstrate that it offers superior functionality, security, or cost-efficiency that cannot be achieved with open alternatives.

Strategic Context: Sovereignty and Resilience

The requirement in Article 41 is part of a broader strategy to reduce the EU's dependence on non-European cloud providers and critical technologies. As noted in the explanatory memorandum, the current landscape is characterized by a pronounced dependence on a limited pool of third-country providers. By building their cloud and AI ecosystem or stack on open standards and components, public sector bodies can achieve several strategic objectives:

  • Reduce Vendor Lock-in: Open source solutions and open standards allow public authorities to switch providers or modify software without being trapped by proprietary formats, closed APIs, or exclusive licensing agreements. This enhances the bargaining power of public buyers.
  • Enhance Security and Auditability: Open source allows for greater transparency. Public bodies can verify security measures, identify vulnerabilities, and audit the code themselves or through third parties, rather than relying solely on vendor assurances.
  • Foster Innovation and Reuse: Encouraging the reuse of open components across the public sector reduces duplication of effort. Successful solutions developed by one Member State can be adapted and reused by others, accelerating the deployment of digital services.
  • Strengthen Technological Sovereignty: By relying on open standards and components, the EU reduces its reliance on specific third-country vendors who may be subject to extraterritorial laws or supply chain disruptions.

What this means for you

For CTOs, architects, and SMEs operating in the public sector or serving public sector clients, Article 41 signals a significant shift in procurement and development practices. The "stack" approach means that compliance is not just about the software you write, but the entire environment in which it runs.

For Public Sector CTOs and Architects

You will need to audit your current and planned technology stacks to identify proprietary dependencies across all layers, not just the application layer. When designing new cloud and AI initiatives, you must prioritize open standards and open source components. This involves:

  • Evaluating Alternatives: When selecting cloud platforms, AI models, middleware, or even hardware management tools, you must actively consider open source alternatives. If a proprietary solution is chosen, you must be able to justify it based on objective criteria such as superior security, functionality, or total cost of ownership.
  • Ensuring Interoperability: Your architecture must support open standards to ensure that different components of your stack can work together seamlessly. This facilitates the reuse of software and reduces integration costs. You must avoid "walled gardens" where data or processes cannot be easily moved.
  • Documenting Decisions: You should maintain clear documentation of the criteria used to select specific technologies. This will be important for demonstrating compliance with the "open source first" principle and for future audits. The burden of proof lies with the authority to explain why an open alternative was not selected.

For SMEs and Technology Providers

If you provide cloud or AI services to public sector bodies, your products must be compatible with open standards and open source ecosystems. Proprietary solutions that create vendor lock-in or rely on closed protocols will face significant barriers to adoption.

  • Open Source Integration: Consider releasing non-core components of your software under open source licenses. This can increase trust and adoption among public sector buyers who are looking to build their own ecosystems.
  • Interoperability Focus: Ensure that your AI models and cloud services can integrate with open source middleware and data layers. Providing robust APIs and adhering to open standards will make your solutions more attractive to public sector clients.
  • Compliance Support: Help your public sector clients demonstrate compliance with Article 41 by providing clear documentation on how your solutions meet the required objective criteria, such as security and total cost of ownership. Be prepared to show how your solution supports the "stack" approach by allowing for portability and reuse.

Common misconceptions

Misconception 1: Article 41 bans proprietary software. This is incorrect. Article 41 does not prohibit the use of proprietary software. It requires public sector bodies to encourage the use of open standards and components. Proprietary solutions can still be used if they are justified by objective criteria such as superior functionality, security, or cost. However, the burden of proof for choosing a proprietary solution over an open one will increase, and the default assumption should be in favor of open solutions.

Misconception 2: "Open source" applies only to the AI model. This is a narrow interpretation. The phrase "cloud and AI ecosystem or stack" explicitly includes the entire technology infrastructure. This means that cloud platforms, data management tools, middleware, and even hardware interfaces must also be evaluated for open source alternatives. Focusing only on the AI model ignores the broader goal of reducing dependency on proprietary infrastructure.

Misconception 3: Open source is always cheaper and more secure. Article 41 requires decisions to be based on objective criteria, including total cost and security. Open source solutions can have higher initial integration costs or require specialized expertise. Public sector bodies are expected to conduct a balanced assessment, considering the total cost of ownership and the specific security requirements of their use case. The regulation does not mandate open source at the expense of security or functionality.

Misconception 4: This only applies to the final application. The term "stack" implies a vertical integration. If a public body uses an open-source AI model but runs it on a proprietary cloud platform that prevents data export, they are not fully complying with the spirit of Article 41. The entire chain of technology, from the hardware up to the user interface, is within scope.

Related

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