Summary As proposed, the Cloud and AI Development Act (CADA) does not redefine core technical terms. Via Article 2, it imports them from the AI Act, the NIS2 Directive and the Cyber Resilience Act (CRA). The result is a layered framework: a single cloud provider can simultaneously face CADA's sovereignty assurance levels, the AI Act's risk-based obligations, NIS2's cybersecurity risk-management duties and the CRA's product-security requirements. Because the definitions are shared, classification under one instrument feeds the others — and misalignment can mean exclusion from public procurement plus separate enforcement under each regime.

Detail

A defining feature of the CADA proposal is its reliance on existing EU law to fix its scope. Rather than create a siloed vocabulary, Article 2 cross-references definitions from three major instruments. This keeps terminology consistent but creates a multi-layered compliance picture for in-house counsel.

The cross-referenced definitions in CADA Article 2

  1. Cloud computing service (NIS2): Article 2(1) defines "cloud computing service" by reference to Article 6, point (30), of Directive (EU) 2022/2555 (NIS2) — a digital service enabling on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources. Anchoring this in NIS2 means entities already classified as cloud providers under NIS2 fall within CADA's sovereignty framework.

  2. AI system (AI Act): Article 2(3) defines "AI system" by reference to Article 3, point (1), of Regulation (EU) 2024/1689 (the AI Act). As the proposal's recitals clarify, only the delivery and making available of a remotely hosted AI system forms part of the cloud computing service; the AI system itself and its underlying model remain governed by the AI Act.

  3. Software, hardware, component and manufacturer (CRA): Article 2(13) to (16) define "software", "hardware", "component" and "manufacturer" by reference to Article 3 of Regulation (EU) 2024/2847 (the CRA) — points (4), (5), (6) and (13) respectively. These definitions feed CADA's Annex II software-supply-chain criteria, including the requirement for a software bill of materials (SBOM).

The layered compliance picture

The cross-referencing creates a "stacked" set of obligations. A European cloud provider offering AI services may need to navigate four interconnected regimes:

  • CADA (sovereignty and procurement): whether the provider meets a Union assurance level (1–4) for public-sector procurement, focusing on localisation, personnel and freedom from third-country control. Member States set penalties under Article 24, which must be effective, proportionate and dissuasive.
  • AI Act (product safety and fundamental rights): governs the AI systems themselves — high-risk obligations and general-purpose AI model rules. Its penalties under Article 99 reach up to EUR 35 million or 7% of total worldwide annual turnover for breaching the Article 5 prohibitions (lower caps apply to other breaches).
  • NIS2 (cybersecurity risk management): requires cloud providers to manage cybersecurity and supply-chain risk and report significant incidents.
  • Cyber Resilience Act (product security): applies to products with digital elements — secure-by-design and lifecycle requirements for the hardware and software in the stack.

Interaction in practice: the audit and procurement nexus

The interplay is sharpest around CADA's Union assurance levels. Article 16 establishes the four-level framework (criteria in Annex II); levels 2–4 require independent third-party audits (Article 20). Annex II's software-supply-chain criteria use CRA-style concepts — an SBOM, dependency lists and source-code audits of security-relevant components. Because CADA borrows the CRA's "software" and "component" definitions, the auditor evaluates these to verify CADA's criteria; a provider unable to produce a compliant SBOM or dependency mapping may fail the audit and lose eligibility for higher-assurance public-sector contracts.

The AI Act's "AI system" definition interacts with procurement too. Article 30 requires public-sector buyers to procure cloud services at the appropriate assurance level. Where a service includes AI capabilities, the AI component must comply with the AI Act while the overall service meets CADA's sovereignty criteria — concurrent, not alternative, obligations.

Timelines and penalties

Counsel must track distinct timelines:

  • CADA: as proposed, Member States must designate national competent authorities, and risk assessments must be carried out, by the date of entry into force plus one year (Articles 25 and 29). Many details are to be filled in by delegated and implementing acts (e.g. Article 45 delegated acts amending Annexes II and III).
  • AI Act: prohibitions apply from 2 February 2025; governance and general-purpose AI rules from 2 August 2025; most high-risk obligations from 2 August 2026.
  • NIS2: in force, with ongoing incident-reporting obligations under national transposition.
  • CRA: its main obligations apply from late 2027.

Penalties are cumulative across regimes: a provider could face AI Act fines for a non-compliant high-risk system while facing CADA penalties (set by Member States under Article 24) for supplying incorrect or misleading information in a sovereignty audit, and separate NIS2 sanctions.

What this means for you

For in-house counsel and compliance officers, the shared definitions mean CADA cannot be treated in isolation.

  1. Map your definitions: Audit how you classify services. If you are a "cloud service" under NIS2, you are within CADA's framework. If you deploy an "AI system" under the AI Act, that component is subject to the AI Act while the service is assessed under CADA when sold to the public sector.
  2. Build CRA-style supply-chain transparency now: CADA's higher assurance levels require SBOMs and dependency mapping aligned with CRA concepts; auditors will expect this granularity.
  3. Procurement readiness: Public-sector tenders will increasingly demand CADA assurance levels; documentation aligned with CRA definitions speeds audits.
  4. Integrate risk management: Align NIS2 cybersecurity risk management with CADA's sovereignty risk assessments — both evaluate third-country control and supply-chain exposure.
  5. Track legislative change: CADA is a proposal; delegated and implementing acts (e.g. under Article 45) will refine how these definitions and levels operate. Watch for Commission guidance.

Common misconceptions

  • "CADA replaces the AI Act for cloud services." No. CADA addresses cloud service delivery and sovereignty; the AI Act addresses the AI system itself. Both apply concurrently.
  • "NIS2 definitions are only for cybersecurity incidents." No. By borrowing NIS2's "cloud computing service" definition, CADA extends its sovereignty framework to entities already within NIS2's cloud scope.
  • "CRA definitions are irrelevant for service providers." No. CADA's assurance-level criteria require CRA-style transparency (SBOMs, dependency mapping), so service providers must adopt CRA-aligned documentation to pass CADA audits.
  • "One team can handle all four regimes alone." Integration helps, but the enforcing authorities differ — AI Act (national authorities and the AI Office), NIS2 (cybersecurity authorities), CRA (market surveillance), CADA (designated national competent authorities) — so coordination is essential.

Official sources

Related

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