Summary Under the proposed Cloud and AI Development Act (CADA), contracting authorities are generally required to procure cloud services recognized at Union assurance levels 1, 2, 3, or 4. However, Article 30(4) allows for a derogation on an exceptional basis and where duly justified. To document this legally, you must explicitly identify which of the three specific grounds applies: (a) market unavailability in the central repository, (b) a failed similar procurement within the last year, or (c) disproportionate cost. Crucially, you must first verify the central repository (Article 22) and prove that any lack of recognized services is not the result of "artificially narrowing" your procurement parameters.

Detail

The proposed CADA establishes a strict link between public procurement and the Union cloud computing sovereignty framework. Article 30 mandates that contracting authorities procure services recognized at Union assurance level 1 for standard activities, and at levels 2, 3, or 4 for activities identified as contributing to the preservation of public order under the risk assessment in Article 29.

While these rules are mandatory, the proposal acknowledges that rigid application may occasionally be impossible. Article 30(4) provides a narrow derogation mechanism. It states that, "on an exceptional basis and where duly justified," a contracting authority may decide not to procure recognized services if one or more of the following circumstances apply:

The Three Grounds for Derogation

To successfully invoke a derogation, the authority must substantiate at least one of the following conditions found in Article 30(4):

  1. Ground (a): Market Unavailability and No Artificial Narrowing The subject matter of the tender cannot be supplied by recognized cloud computing services available in the central repository (established under Article 22). Furthermore, "no adequate or reasonable alternative or comparable cloud computing service exists."

    • Critical Constraint: The proposal explicitly states that this absence must not be the result of an "artificial narrowing down of the parameters of the public procurement procedure." If the technical specifications were written so narrowly that they exclude recognized providers, the derogation is invalid.

  2. Ground (b): Previous Failure The contracting authority has launched a "similar procurement process within the previous year but did not receive any suitable tenders or suitable participants."

    • Time Limit: The previous attempt must have occurred within the last 12 months.
    • Outcome: The failure must be due to a lack of suitable tenders or participants, not a cancellation by the authority.

  3. Ground (c): Disproportionate Cost "Applying the requirements of this Regulation would require the contracting authority to procure services at disproportionate cost."

    • Threshold: This is not merely about higher prices; the cost must be disproportionate relative to the benefits or the project's scope.

The Documentation Protocol

Since Article 30 does not prescribe a specific template, the "duly justified" requirement implies a rigorous evidentiary burden. A compliant documentation file must include:

  • Explicit Ground Selection: The record must clearly state which ground (a, b, or c) is being invoked. If multiple grounds apply, each must be independently substantiated.
  • Central Repository Verification (Mandatory for Ground a): For market unavailability, you must provide evidence of a search in the central repository (Article 22). This includes:
    • The date and time of the search.
    • The specific search criteria used (e.g., assurance level, service type, technical features).
    • The negative result confirming no recognized service matches the requirements.
  • Proof of Non-Artificial Narrowing: You must demonstrate that the procurement parameters were set broadly enough to allow recognized services to compete. This may involve a market consultation record or a technical justification showing why specific features are essential and cannot be met by recognized providers without compromising the service's core function.
  • Cost-Benefit Analysis (For Ground c): A comparative analysis showing that the cost of a recognized service is disproportionate. This should include a breakdown of the recognized service's cost versus the project's total budget or the value of the service, explaining why the difference is unreasonable.
  • Historical Procurement Records (For Ground b): Copies of the previous tender notice, the evaluation report showing the lack of suitable tenders, and the date of the launch (confirming it was within the previous year).

What this means for you

For procurement officers and legal teams, the CADA proposal fundamentally shifts the burden of proof. You are no longer just buying a service; you are actively managing sovereignty compliance.

  • Pre-Procurement Repository Check: Before drafting any tender, you must consult the central repository under Article 22. If a recognized service exists that meets your needs, you generally cannot use a derogation. Skipping this step invalidates any claim of "market unavailability."
  • Specification Design: Avoid overly specific technical requirements that might inadvertently exclude recognized services. If you need a specific feature, verify if recognized providers can deliver it. If they cannot, document this gap carefully to prove the narrowing was not "artificial."
  • Audit-Ready Files: Maintain a dedicated file for every derogation. This file should include the justification report, repository search logs, cost comparisons, and previous tender results. National competent authorities (designated under Article 25) will have the power to investigate suspected infringements, and this documentation is your primary defense.
  • Exceptional Nature: Treat derogations as rare exceptions. Routine use of derogations may indicate a failure to plan for sovereign supply chains or an attempt to artificially narrow parameters, which could lead to enforcement actions under Article 26.

Common misconceptions

"I can use a derogation if the recognized service is too expensive." Incorrect. Ground (c) requires the cost to be disproportionate, not just high. You must demonstrate that the cost outweighs the benefits or is unreasonable relative to the project's scope. Mere budget constraints or a preference for a cheaper, non-recognized vendor are not sufficient justification.

"I can use a derogation if I prefer a non-recognized vendor." Incorrect. Preference for a specific vendor is not a ground for derogation. You must show that no recognized service can meet the technical requirements (ground a) or that previous attempts failed (ground b).

"I don't need to check the central repository if I know no one is listed." Incorrect. Article 30(4)(a) explicitly references the central repository. You must conduct a formal check and document the result. Assuming no services are available without checking is not "duly justified."

"Derogations apply to all cloud services." Incorrect. The derogation applies only to the requirement to procure services with a specific Union assurance level. It does not exempt you from other CADA obligations, such as conducting risk assessments (Article 29) or adhering to transparency requirements.

"Ground (a) allows me to bypass the repository if I can't find a match." Incorrect. The ground applies only if the service is not available in the repository and no reasonable alternative exists. If a recognized service exists but you simply didn't look, or if you narrowed your specs to exclude it, the derogation fails.

Related

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