Summary Under the proposed Cloud and AI Development Act (CADA), public contracting authorities must include non-price award criteria to evaluate a tenderer's contribution to a European cloud and AI ecosystem. As proposed, providers must evidence this contribution by documenting the use of software and hardware designed or manufactured in the Union, demonstrating the integration of EU-developed technologies and R&D results, and showing how their innovation strengthens the security of supply. These criteria are strictly ancillary and not decisive, meaning they cannot override core technical or financial performance requirements. The proposal suggests a maximum weighting of 15 out of 120 points for this "Union added value" to ensure proportionality.

Detail

Article 32 of the CADA proposal (COM(2026) 502 final) establishes a mandatory framework for public procurement procedures involving innovative cloud computing services and AI systems. It requires contracting authorities to include non-price award criteria that allow them to evaluate a tenderer's contribution to the development of a European cloud and AI ecosystem. This mechanism is designed to incentivize domestic industrial capacity and reduce strategic dependencies on third-country providers, aligning with the Act's broader sovereignty objectives.

To successfully evidence this contribution, providers must address specific cumulative dimensions outlined in Article 32(3). These dimensions serve as the evidentiary basis for scoring under the "Union added value" criterion:

  1. Strengthening the EU Digital Technology Supply Chain (Article 32(3)(a)): Providers must demonstrate how their tender contributes to the resilience and autonomy of the EU digital supply chain. The text explicitly requires evaluating the extent to which the tenderer contributes to strengthening the digital technology supply chain in the Union. This specifically includes documenting the use of software or hardware designed or manufactured in the Union. Evidence might include supply chain maps, component origin certificates, and design location documentation proving that the intellectual property and physical manufacturing occur within the EU.

  2. Integration of EU-Developed Technologies (Article 32(3)(b)): Providers should highlight the integration of technologies developed in the Union. This includes leveraging research and development results stemming from Union-funded research and development programmes and making use of tools, such as standards, specifications, software, models, or other technology developed in the Union. Documentation of these integrations, such as technical specifications referencing EU-born standards, R&D project identifiers (e.g., from Horizon Europe or Digital Europe), or licensing agreements for EU-developed models, is crucial for scoring.

  3. Security of Supply and Ecosystem Development (Article 32(3)(c)): The innovation required to deliver the service must contribute to strengthening the security of supply and the development of a European cloud and AI ecosystem. Providers must articulate how their solution reduces single-point failures, mitigates third-country dependencies, or fosters the growth of the European industrial base. This dimension focuses on the strategic impact of the procurement beyond the immediate service delivery.

  4. Hardware Provenance and Feasibility (Article 32(3)(d)): To the greatest extent feasible, considering market availability and technical requirements, the service must be delivered through critical computing, storage, and networking hardware components designed and/or manufactured in the Union. The proposal acknowledges market realities: if this is not feasible, providers must demonstrate that hardware components from a third country are used in a manner that still contributes to strengthening the security of supply and the development of a European cloud and AI ecosystem. This creates a "feasibility exception" where third-country hardware is permissible if justified by technical necessity and if its use still supports the broader EU strategic goals.

It is critical to note that while these criteria are mandatory for inclusion in the evaluation methodology, they are strictly limited in weight. Article 32(2)(d) states that these non-price award criteria must be "ancillary and not decisive in the award of the contract." Contracting authorities are expected to preserve the primacy of technical and financial criteria directly connected to performance requirements. The Explanatory Memorandum (Recital 67) suggests that contracting authorities could consider a maximum weighting of 15 out of 120 points to be allocated to European added value, ensuring it remains proportionate and subordinate to core contract award criteria.

Providers must ensure that any evidence submitted is linked to the subject matter of the contract (Article 32(2)(a)), does not confer unrestricted freedom of choice on the authority (Article 32(2)(b)), and is expressly set out in the procurement documents (Article 32(2)(c)). This prevents arbitrary application and ensures transparency. The evidence must be verifiable, meaning providers should maintain robust records of their supply chain, R&D origins, and technology integrations that can be audited or reviewed during the procurement evaluation process.

What this means for you

For cloud service providers, data centre operators, and AI system developers, this provision shifts the procurement landscape from pure price-performance competition to one that values strategic autonomy. To compete effectively for public sector contracts under the proposed CADA, you must move beyond generic marketing claims of "European presence" (such as having an EU office) and provide granular, auditable evidence of your supply chain and technology origins.

Actionable Steps:

  • Audit Your Stack: Map your entire technology stack, identifying every software component and hardware element. Flag those designed or manufactured in the Union versus those from third countries. Prepare a "Bill of Materials" that explicitly states the country of design and manufacture for critical components.
  • Document R&D Origins: If your software, models, or tools utilize results from EU-funded programs (e.g., Horizon Europe, Digital Europe), explicitly document these connections. Provide project references, grant numbers, or standard numbers that trace the technology back to Union development.
  • Prepare Supply Chain Evidence: Develop clear documentation showing the origin of your critical hardware (compute, storage, networking). If you use third-country hardware, prepare a robust justification explaining how its use still contributes to security of supply (e.g., through multi-vendor strategies, specific contractual safeguards, or technical necessity where EU alternatives are unavailable).
  • Align with Procurement Documents: When bidding, ensure your technical proposal explicitly addresses each point in Article 32(3). Do not assume the evaluator will infer your contribution; make the link between your specific components and the EU supply chain explicit in your response.
  • Monitor Weighting: While the proposal suggests a 15/120 point cap, actual weighting may vary by contract. Always check the specific procurement notice to understand how heavily this criterion is weighted relative to technical and financial factors.

Failure to provide clear, documented evidence may result in a lower score, even if your technical solution is superior. The onus is on the provider to prove the "European" nature of their contribution.

Common misconceptions

Misconception 1: This criterion guarantees the contract award. Reality: Article 32(2)(d) explicitly states that these criteria are "ancillary and not decisive." They cannot override a superior technical or financial offer. A provider with a strong EU supply chain but poor technical performance will not win the contract.

Misconception 2: Only hardware counts. Reality: Article 32(3)(a) and (b) explicitly include software, standards, specifications, and models. Software design location and the integration of EU-developed tools are equally important as hardware manufacturing.

Misconception 3: Third-country components disqualify you. Reality: Article 32(3)(d) acknowledges market realities. It allows for third-country hardware if it is not feasible to use EU-designed/manufactured components, provided the overall solution still contributes to security of supply and ecosystem development. You must justify this choice, but you are not automatically excluded.

Misconception 4: Any EU presence suffices. Reality: Merely having an EU office, sales team, or data centre is insufficient. The evidence must relate to the design, manufacture, or development of the specific software, hardware, or technologies used in the tendered service.

Related

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