Summary Under the proposed Cloud and AI Development Act (CADA), Article 32 mandates that public contracting authorities include non-price award criteria to evaluate a tenderer's contribution to the European cloud and AI ecosystem. Specifically, Article 32(3)(b) establishes a criterion for the integration of technologies developed in the Union. This includes research and development (R&D) results stemming from Union-funded programmes, as well as the use of EU-developed standards, specifications, software, and models. Crucially, this criterion is ancillary and not decisive in the award of the contract, meaning it cannot override core technical or financial requirements. As proposed, providers must demonstrate provenance of their R&D outputs to score points under this "Union added value" framework.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, seeks to rebalance the EU cloud and AI market by leveraging public procurement to foster technological sovereignty. While the Act establishes a sovereignty framework (Title IV) for data and infrastructure, Title IV, Chapter II, Section 3 introduces specific procurement measures designed to stimulate the European supply chain.

Article 32 is the central provision governing these measures. It requires contracting authorities to include "non-price award criteria" in public procurement procedures for innovative cloud computing services and AI systems. These criteria must allow authorities to evaluate the tenderer's contribution to the development of a European cloud and AI ecosystem.

The Specific Mechanism: Article 32(3)(b)

While Article 32 outlines four distinct areas of Union added value, Article 32(3)(b) is the primary vehicle for rewarding the integration of homegrown intellectual property and R&D outputs. The text explicitly states that contracting authorities shall evaluate the extent to which:

"the tenderer has integrated technologies developed in the Union, including research and development results stemming from Union funded research and development programmes and makes use of tools, such as standards, specification, software, models or other technology developed in the Union;"

This provision is significant because it moves beyond simple "country of origin" rules. It recognizes that in the digital economy, value is often embedded in code, algorithms, and architectural frameworks rather than just physical hardware.

1. Integration of Technologies Developed in the Union

The core requirement is that the technology must be developed within the Union. This implies that the intellectual property, design, or significant R&D work originated in an EU Member State. It is not sufficient for a provider to merely sell a product in the EU; the creation of the technology must have a substantive link to the Union.

2. R&D Results from EU-Funded Programmes

The article explicitly highlights research and development results stemming from Union funded research and development programmes. This is a direct nod to existing EU funding instruments such as Horizon Europe and the Digital Europe Programme.

  • What this means: If a provider has utilized grants, funding, or collaborative projects under these programmes to develop their cloud infrastructure, AI models, or software stacks, they can cite these results as evidence of Union integration.
  • Demonstration: Providers must be able to trace their deployed technologies back to specific EU-funded projects. This requires maintaining clear records linking the technical components of their bid to the grant agreements, project deliverables, or consortium outputs of the relevant EU programme.

3. Use of EU Tools: Standards, Specs, Software, and Models

The criterion lists specific "tools" that demonstrate alignment with the EU ecosystem:

  • Standards and Specifications: Adherence to technical standards developed by European standardization bodies (e.g., CEN, CENELEC, ETSI) or specific EU interoperability standards.
  • Software: The use of software components, libraries, or middleware developed in the Union. This aligns with CADA's broader push for open-source solutions and sovereign software stacks (see Articles 41–43).
  • Models: For AI services, this refers to AI models (including general-purpose or sector-specific models) that were trained, fine-tuned, or designed within the Union. This is particularly relevant for the "frontier AI" and "industrial AI" objectives outlined in the Act's preamble and Title II.

Legal Constraints: Ancillary and Non-Decisive

It is critical for providers to understand the legal boundaries placed on this criterion by Article 32(2). The non-price award criteria under Article 32 must:

  • Be linked to the subject matter of the contract.
  • Not confer unrestricted freedom of choice on the contracting authority.
  • Be expressly set out in the procurement documents or contract notice.
  • Be ancillary and not decisive in the award of the contract.

Furthermore, Recital 67 of the CADA proposal provides specific guidance on weighting. It suggests that contracting authorities could consider a maximum weighting of 15 out of 120 points to be allocated to European added value within the overall evaluation methodology. This ensures that while Union integration is valued, it remains subordinate to core technical and financial performance requirements. A provider cannot win a contract solely on the basis of EU R&D integration if their technical solution is inferior or their price is non-competitive.

What this means for you

For cloud service providers, AI developers, and data centre operators bidding on EU public sector tenders, Article 32(3)(b) represents a strategic opportunity to differentiate your bid, provided you can substantiate your claims.

1. Map Your R&D Provenance

If your solutions incorporate technology derived from EU-funded research, you must be able to prove this.

  • Action: Maintain a "provenance ledger" for your key technologies. Link specific software modules, AI models, or architectural components to the specific grant agreements, project IDs, or R&D initiatives funded by the EU.
  • Tender Strategy: In your technical proposal, explicitly map your components to these sources. Do not just state "EU-developed"; cite the specific programme (e.g., "This AI model was trained using data and compute resources from the Horizon Europe project [Project Name]").

2. Highlight EU Standards and Open Source

If your cloud stack relies on open-source software developed by European foundations or adheres to European cybersecurity and interoperability standards, highlight this prominently.

  • Action: Document the use of EU-developed models or software libraries. If you are using a standard developed by ETSI or a specification from the Interoperable Europe Act, reference it directly.
  • Tender Strategy: Demonstrate the use of EU-developed tools as a direct response to the "tools" aspect of Article 32(3)(b). This is particularly effective if you can show that your solution is built on the "European open cloud computing stacks" mentioned in the Act's operational objectives.

3. Prepare for the "Ancillary" Constraint

Do not assume that having EU-developed technology guarantees a win. The criterion is ancillary.

  • Action: Ensure your primary focus remains on the technical quality, security, and price of your service.
  • Tender Strategy: Use Article 32(3)(b) as a differentiator among otherwise equal bids. If your technical score is high, the Union added value points can be the tie-breaker. However, if your core technical score is low, the R&D integration points will not save the bid.

4. Strategic Alignment for Future Bids

Use this criterion to justify investments in local R&D.

  • Action: Consider participating in EU-funded consortia or developing technologies specifically within the EU territory.
  • Tender Strategy: By developing technologies in the EU and participating in EU-funded consortia, you position yourself favorably for future public procurement under CADA. This aligns with the Act's broader goal of creating a "European cloud and AI ecosystem."

Common misconceptions

Misconception 1: This is a mandatory "Buy European" quota. Article 32 does not mandate that public authorities must award contracts to EU providers. It allows them to evaluate the Union added value. The criterion is optional in its application intensity (within the weighting limits) and must not be decisive. A non-EU provider with superior technical performance can still win if their Union added value score is lower but their core technical score is significantly higher.

Misconception 2: Any technology sold in the EU counts as "developed in the Union." The criterion specifies "developed in the Union." Merely having a sales office, support center, or data center in the EU is insufficient. The core development, design, or R&D activity must have taken place within the EU territory. The text explicitly links this to "research and development results stemming from Union funded research and development programmes," implying a deep link to the creation process, not just the location of the vendor.

Misconception 3: This criterion overrides technical performance. As stated in Article 32(2), these criteria are ancillary. They cannot override the fundamental technical and financial requirements of the contract. A bid that fails to meet the core technical specifications will not be saved by a high score on Union added value. The weighting guidance in Recital 67 (max 15/120 points) reinforces that this is a secondary, not primary, factor.

Misconception 4: Only hardware counts. The text explicitly lists "standards, specification, software, models or other technology." This confirms that intangible assets like AI models, software libraries, and architectural standards are fully eligible and perhaps even more relevant than hardware in the context of cloud and AI services.

Related

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