Summary No, the proposed Cloud and AI Development Act (CADA) does not modify, replace, or add to the transparency duties for AI systems themselves under the EU AI Act (Regulation (EU) 2024/1689). The AI Act's requirements regarding the marking of AI-generated content and informing users of AI interactions remain entirely unchanged. Instead, CADA introduces a distinct, parallel layer of marketplace transparency for cloud computing services. Through a central repository (Article 22) and ongoing reporting obligations (Article 23), CADA requires providers to disclose their Union assurance level (sovereignty status), data residency, and control structures. While the AI Act asks, "Is this output AI-generated?", CADA asks, "Is this cloud infrastructure sovereign and free from third-country control?"

Detail

To navigate the regulatory landscape for AI hosted on cloud infrastructure, it is critical to distinguish between the transparency of the application layer (the AI system) and the transparency of the infrastructure layer (the cloud service). The EU AI Act is a product-safety and fundamental-rights regulation that imposes specific transparency obligations on providers and deployers of AI systems. These duties, particularly under Article 50 of the AI Act, require that natural persons be informed when they are interacting with an AI system and that AI-generated content be marked in a machine-readable format. CADA, as proposed in COM(2026) 502 final, does not alter these rules. The AI Act remains the definitive legal instrument for governing the technical transparency of AI outputs, interactions, and high-risk system documentation.

CADA, by contrast, establishes a "Union cloud computing sovereignty framework" designed to mitigate risks associated with dependence on third-country providers and to safeguard public order. As proposed, CADA introduces transparency mechanisms that operate at the service provider level rather than the AI model level. The core of this regime is the establishment of a central repository and the obligation for cloud computing service providers to maintain the accuracy of their recognised status. This creates a "marketplace transparency" where public buyers can verify the sovereignty credentials of a provider before procurement.

The Central Repository: A Public Marketplace for Sovereignty (Article 22)

Under Article 22 of the proposed CADA, the European Commission is required to establish and maintain a dedicated central repository of cloud computing services that have been recognised as offering specific Union assurance levels (Levels 1 through 4). This repository serves as the primary transparency tool for the cloud market. Its purpose is to facilitate secure and efficient access to information for public sector customers, auditing organisations, and competent authorities, ensuring that procurement decisions are based on verified data.

The mechanism for entry into this repository is strict. The national competent authority of establishment that recognises a cloud computing service under Article 17 is responsible for registering that service in the central repository. Crucially, Article 22(3) mandates that any revocation of an audit report or recognition by a competent authority must be published in this repository and remain available there for five years. This "negative transparency" ensures that a provider's history of non-compliance is visible to the market. The repository itself must be publicly available and regularly updated, ensuring that procurement officers and public bodies can easily verify the sovereignty status of a cloud provider before contracting.

Provider Transparency Obligations: The Duty to Report (Article 23)

Complementing the static repository, Article 23 imposes dynamic, ongoing transparency obligations on cloud computing service providers. Providers must notify their auditing organisation and the national competent authority of establishment as soon as possible upon becoming aware of any information or material change in circumstances that may affect their audit report, their 'positive' audit opinion, or their recognition status.

This creates a continuous loop of transparency. If a provider's infrastructure location changes, if their subcontracting arrangements shift to include third-country entities, or if their legal control structure is altered in a way that impacts their Union assurance level, they must disclose this immediately. The auditing organisation then assesses whether the audit report needs amendment or revocation, and the competent authority assesses whether the recognition needs adjustment. This ensures that the information in the central repository remains current and reliable, preventing a situation where a provider is listed as "sovereign" while their actual operations have drifted into non-compliance.

Different Transparency Objects: AI Output vs. Cloud Assurance

It is critical to note that the "transparency" under CADA Articles 22 and 23 concerns the governance, location, and control of the cloud service, not the functionality or output of the AI systems running on it. The two regimes address fundamentally different questions:

  • AI Act Transparency: Focuses on the end-user experience and the nature of the content. It asks: "Is this text AI-generated?" or "Am I talking to a chatbot?" It requires technical measures like watermarks, clear labels on AI outputs, and disclosure of AI interaction to the user. These duties apply to the AI system regardless of where it is hosted.
  • CADA Transparency: Focuses on the procurement and security experience of the cloud buyer. It asks: "Is this cloud provider subject to third-country control?" or "Does this service meet Union Assurance Level 2?" It requires administrative and legal disclosures regarding data residency, personnel citizenship, cybersecurity certifications, and the absence of extraterritorial third-country laws.

A cloud provider hosting a high-risk AI system must comply with both regimes simultaneously but independently. They must ensure the AI system meets AI Act transparency standards (e.g., providing instructions for use, logging capabilities, and output marking) while also ensuring their own cloud service is correctly registered and reported in the CADA central repository. The AI Act governs the software; CADA governs the platform.

What this means for you

For cloud service providers, data centre operators, and AI providers hosting on cloud infrastructure, this distinction dictates a two-track compliance strategy. You cannot assume that compliance with one framework satisfies the other.

1. Maintain Separate Compliance Workstreams

Your AI Act compliance team should focus on the technical and operational transparency of the AI systems you host or provide. This includes ensuring that AI outputs are marked correctly, that users are informed of AI interaction, and that high-risk systems have the necessary logging and documentation. Your CADA compliance team, however, must focus on the sovereignty and governance of your cloud infrastructure. This involves preparing for independent audits (for Assurance Levels 2-4), maintaining a robust software bill of materials (SBOM), and ensuring your eligibility for recognition in the CADA central repository.

2. Monitor for Material Changes (Article 23)

Under Article 23, you have an active, ongoing duty to monitor your own operations for changes that could affect your assurance level. This goes beyond standard operational monitoring. You must have internal processes to detect and report changes in:

  • Subcontractor arrangements: Especially if they involve new third-country entities or changes in control.
  • Data residency and processing locations: Any shift of data or infrastructure outside the Union.
  • Corporate control structures: New shareholders from third countries or changes in voting rights.
  • Cybersecurity certification status: Changes in your European cybersecurity certificate (e.g., moving from 'substantial' to 'high' or losing certification).

Failure to report these changes promptly could lead to the revocation of your recognition. Under Article 22(3), that revocation will be published in the central repository and remain visible for five years, potentially disqualifying you from public sector contracts and damaging your market reputation.

3. Prepare for Repository Registration

As a provider seeking to serve the EU public sector, you must prepare to submit accurate data to the national competent authority for inclusion in the central repository. Ensure that your internal records regarding data flows, personnel locations, and subcontractor chains are robust and auditable. The repository will be the primary source of truth for public buyers, so inaccuracies could lead to procurement failures or legal challenges. Remember that for Level 1, SMEs benefit from automatic recognition, but for Levels 2-4, independent audits and formal recognition are mandatory before registration.

4. Leverage Transparency for Competitive Advantage

Being listed in the CADA central repository with a high Union assurance level is a significant competitive differentiator. Public sector bodies are required to procure services that meet specific assurance levels based on risk assessments (under Article 30). By maintaining rigorous transparency under Article 23 and ensuring your status is accurately reflected in the repository under Article 22, you position yourself as a trusted, sovereign option for critical public sector workloads. In a market increasingly concerned with third-country interference, this transparency is a key value proposition.

Common misconceptions

Misconception 1: CADA replaces AI Act transparency requirements. Some providers assume that because CADA deals with AI infrastructure, it supersedes the AI Act's rules on AI transparency. This is incorrect. The AI Act's obligations regarding the marking of AI-generated content and the disclosure of AI interaction remain fully in force. CADA does not regulate the AI system itself; it regulates the cloud service hosting it. The two laws operate in parallel.

Misconception 2: "Transparency" means open-source code disclosure. Under CADA, transparency does not require you to open-source your software or reveal your proprietary algorithms. The transparency obligations in Articles 22 and 23 relate to the disclosure of your sovereignty status, audit results, and material changes in your operational or legal structure. This is administrative and governance transparency, not technical code transparency. While CADA encourages open source (Title IV, Chapter V), the transparency regime for assurance levels is about verifying control and location, not revealing source code.

Misconception 3: The central repository is only for public authorities. While the primary users of the CADA central repository are public sector bodies and auditing organisations, Article 22(4) states that the repository shall be publicly available. This means private sector entities, competitors, and researchers can also access this information. Your sovereignty status will be visible to the entire market, making accurate and timely reporting under Article 23 even more critical for your brand reputation.

Misconception 4: One-time registration is sufficient. Providers often view the central repository as a one-time registration exercise. However, Article 23 creates an ongoing obligation. You must continuously monitor your operations and report material changes. If your circumstances change after initial recognition, you must notify the authorities, or your recognition may be revoked, and that revocation will remain in the repository for five years.

Official sources

Related

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