Security

Cloud and AI Development Act (CADA): What It Means for Video Platforms

14 min read

June 24, 2026

Video conferencing sits at an awkward intersection for EU organisations: it is one of the most cloud-dependent, data-intensive, and increasingly AI-saturated services they run, and it runs daily. Every session generates real-time media that must be routed somewhere, metadata that must be stored somewhere, and, with growing frequency, AI-processed transcripts and meeting summaries that must be inferred somewhere. That 'somewhere' is now a compliance and procurement question, not merely an engineering choice.

The Cloud and AI Development Act, proposed by the European Commission on 3 June 2026 as part of the broader Tech Sovereignty Package, is designed to answer it. The legislation introduces a new EU-wide cloud and AI sovereignty framework, restructures how public sector bodies procure cloud services, and sets a target of tripling EU data centre capacity within five to seven years. None of that is abstract for a procurement officer choosing a video platform for a hospital, a court service, or a financial regulator.

CADA entered the legislative process on 3 June 2026, with adoption currently targeted around Q4 2027, so its requirements are not yet in force. But organisations making procurement decisions today are locking in operational chains that will be assessed against this framework as it moves from proposal to regulation.

This article makes the legislation concrete for that audience. CADA reshapes the cloud and AI layer beneath your video stack, and understanding what it actually requires is the first step to knowing whether your current platform (or the one you are evaluating) will hold up under the scrutiny it will increasingly face.

Table of contents

What the Cloud and AI Development Act actually is
Why video conferencing is CADA's sharpest test case
Cloud sovereignty for video is not a checkbox: the three layers buyers must probe
What a CADA-ready video platform looks like
A CADA-readiness checklist for choosing a video platform
Conclusion
Frequently asked questions

What the Cloud and AI Development Act actually is

The Cloud and AI Development Act is built around three areas of intervention, each of which touches video infrastructure in a distinct way.

The research, development, and innovation pillar supports the development of next-generation cloud and AI technologies, introduces 'grand challenges' to drive frontier AI research, and funds adoption of cloud and AI in strategic industrial and public sectors through Experience and Acceleration Centres for AI. For video, this matters primarily at the AI feature layer: the push to develop EU-sovereign AI inference capacity creates an alternative to routing media to non-EU model providers.
The capacity pillar addresses the EU's current data centre footprint, which is too limited to support the AI compute workloads its institutions and industries need at scale. The legislation targets at least a tripling of EU data centre capacity within five to seven years, simplifying permitting, improving access to energy, land, and financing, and removing the structural bottlenecks that have constrained EU cloud expansion. Practically, this matters because sovereign video conferencing depends on having adequate EU-located infrastructure to route media, and currently that supply is limited.
The autonomy pillar is the most relevant to procurement decisions today. This section introduces a single EU-wide sovereignty framework for assessing cloud and AI services, defines four distinct assurance levels that public sector bodies must apply when procuring cloud services based on risk assessment, and establishes a common EU-level procurement framework. The four levels are set out below.

Level	Focus	Key requirements
1	Basic location	Data processed and stored on infrastructure physically located within the EU.
2	Independence	Provider demonstrates independence from third-country legal regimes; transparent software supply chain.
3	EU control	Provider is owned and controlled from the EU; additional criteria include personnel citizenship. The Commission may recognise select third-country providers.
4	Full sovereignty	Full transparency and control over the software supply chain; no third-country interference of any kind.

Once adopted, the regulation would require public administrations to assess which systems depend on external cloud services, classify them by assurance level, and procure accordingly, a process the proposal anchors in Articles 29 and 30. Under that framework, the level assigned to any given service follows from the body's own risk assessment, not from a predetermined mapping. A public sector body running a sensitive video platform would typically find that its risk assessment warrants a higher assurance level than basic EU location, but the classification is theirs to make. Level 2, 3, and 4 requirements become mandatory only for activities that a Member State's risk assessment identifies as contributing to the preservation of public order or critical-sector operations.

The regulation's scope is not limited to public bodies alone. CADA also empowers the Commission to adopt delegated acts requiring private companies in NIS2-regulated sectors, including banking, energy, telecommunications, and healthcare, to carry out comparable sovereignty risk assessments. That extension mechanism is directly relevant to the hospitals, financial regulators, and telecoms firms that are the primary audience for this article.

Why video conferencing is CADA's sharpest test case

Most cloud services touch one or two dimensions of the sovereignty framework. Video conferencing touches all of them simultaneously, which is why it provides the clearest test of whether an organisation is genuinely applying the framework or simply complying on the most obvious criterion while ignoring the rest.

A live session routes real-time media through a cloud-hosted Selective Forwarding Unit (SFU). That is a cloud infrastructure question: where is the media being processed, and is that infrastructure governed by an EU-sovereign operational chain? The recording of that same session is stored somewhere as data at rest. That is a separate data storage question, with its own sovereignty implications for retention, access, and key management. And increasingly, the transcript, the meeting summary, and the action-item extraction are processed by an AI model that receives decoded audio or video as its input, which is a third, distinct question: where does inference actually happen, and does media leave the EU to reach it?

Sovereign video conferencing requires a credible answer to all three questions, not just the first one about data centre location. Most procurement conversations stop there: 'Where are your servers?' is the question that gets asked; the AI inference destination rarely does. But the sovereignty framework does not allow that selective attention. Consider a platform that routes media on EU-located servers while sending audio to a non-EU AI provider for transcription: it satisfies Level 1 but would likely raise problems at Level 2, because the provider performing inference on decoded media becomes a sub-processor whose governing jurisdiction is directly material to sovereignty compliance. The proposal does not yet explicitly prohibit AI inference outside the EU at Level 2; that argument is a reading of Level 2's independence requirement, not a named provision. Where the explicit prohibition does appear is at Level 4, which requires no third-country interference of any kind.

This is precisely why video has become the hardest case. The combination of real-time media routing, stored recordings, and AI feature pipelines means that a genuinely sovereign video platform must evidence an EU-governed chain across three distinct data flows, not one. Buyers who audit only the first are leaving the most technically complex vulnerability unexamined.

Cloud sovereignty for video is not a checkbox: the three layers buyers must probe

Cloud sovereignty for video resolves into three layers that must be probed separately, because each can fail independently while the others appear to pass.

The infrastructure layer covers where real-time media is routed during a live session and where recordings are stored at rest. This maps most directly to the Level 1 requirement: data processed and stored on EU-located infrastructure. It is the layer most buyers already check, and it is necessary but not sufficient. A US-headquartered provider can operate EU-located servers; that satisfies Level 1 while leaving Level 2 entirely unaddressed.
The operator layer asks who controls the infrastructure and who can be compelled, by which legal authority, to hand over access or data. US-controlled cloud providers operating EU-located data centres remain subject to US legal frameworks that can compel disclosure from those same providers regardless of where the servers sit physically. Level 2 requires demonstrated independence from third-country legal regimes and transparency over the software supply chain. For video, this means asking not just where the hardware is, but under which legal obligations the entity operating it operates, and whether that entity can be compelled outside EU law. US-headquartered providers have pursued Level 2 and Level 3 qualification via EU-controlled joint ventures and subsidiaries. The April 2026 SEAL sovereign cloud tender awarded a contract at SEAL-2 level to the Proximus consortium, which partners with S3NS, a Thales and Google Cloud joint venture operating under French legal and operational controls. The three other tender winners (Post Telecom with OVHcloud and CleverCloud, STACKIT, and Scaleway) achieved the higher SEAL-3 level because they had no material non-EU supply-chain dependencies. The S3NS result was publicly criticised as 'sovereignty washing' by CISPE, representing 38 European cloud firms, who argued that awarding the contract to a Google-backed structure undermined the framework's purpose; the pure-European vendors who reached SEAL-3 are the ones the framework's architects had in mind. Whether arrangements such as the Proximus/S3NS consortium constitute substantive sovereignty or a pragmatic workaround is a live debate; the test the proposal applies is the operational and legal chain, not the flag on the logo.
The AI and data flow layer is the one most frequently overlooked. AI transcription, meeting summaries, noise cancellation, and speaker analytics each involve decoded media being transmitted to an inference endpoint. The question is direct: is that endpoint located within the EU, operated by an EU-sovereign entity, and free from third-country interference? At Level 4, the answer must be yes without qualification: the level explicitly prohibits any third-country interference of any kind, which includes AI inference pipelines. At Level 2, the picture is less clear: routing audio or video to a non-EU model provider (including one with EU-located servers, if that provider remains subject to non-EU legal access regimes) would likely conflict with the independence requirement, but that conclusion is an interpretation of the text rather than a named rule. The AI pipeline is not a separate product category; it is part of the same data processing chain.

A platform that clears all three layers is a different category of product from one that clears only the first. The highest-sensitivity workloads (judiciary, defence, intelligence) would also need to meet the EU-ownership and control requirements of Level 3 and the full supply-chain transparency of Level 4, so the three-layer checklist below should not be treated as exhaustive for those contexts. The distinction matters now, because organisations making procurement decisions today are locking in operational chains that will be assessed against this framework as it moves from proposal to regulation.

What a CADA-ready video platform looks like

A platform that can answer all three layers credibly needs to have made deliberate architectural decisions from the start, not assembled a compliance narrative after the fact. The choices that matter are not primarily about paperwork; they are about where media flows, who can read it, and whose legal jurisdiction governs the people responsible for it.

To make this concrete: any platform seeking to demonstrate CADA readiness would need to show documented evidence for each layer of the sovereignty chain, covering where media is processed, who operates and controls that infrastructure, and how AI features are handled. Consider what that looks like for a platform designed around these constraints from the beginning.

At Digital Samba, the architectural decisions are documented and public. Infrastructure for the Embedded and Free products is EU-hosted, with sub-processors based in the EU and GDPR-adequate jurisdictions. The SFU forwards encrypted packets without decoding the media content, which confines the server-side data processing surface to packet routing rather than media access. This reflects our documented architecture and is a vendor self-claim consistent with standard SFU design. Processing that works on decoded media, such as transcription and analysis, is handled by a contracted EU-based AI sub-processor rather than routed to a global inference endpoint. The embedded SDK is released under a BSD-2-Clause licence, providing a concrete no-lock-in integration layer that directly aligns with the legislation's promotion of open source solutions as a resilience mechanism.

For buyers, the practical choice this creates is between assembling that chain themselves through self-hosted open source infrastructure, or inheriting it by embedding a platform that has already built it. Self-hosting achieves the same sovereignty goals but requires the buyer to own the entire operational burden: infrastructure provisioning, SFU maintenance, AI sub-processor contractual relationships, compliance evidence generation, and ongoing security patching. The embedded model transfers that complexity to the vendor without transferring sovereignty, provided the vendor can evidence the chain end to end.

One important caveat: for workloads requiring Level 4 assurance (full supply-chain control, no third-country interference of any kind), a vendor-managed embedded service may not be sufficient. Buyers operating at that level would typically need to control the full stack, including running the SFU on their own infrastructure. The embedded model is most directly suited to Level 2 and Level 3 procurement requirements.

A CADA-readiness checklist for choosing a video platform

The three-layer model produces a practical set of questions for any video procurement process. For workloads that a risk assessment places at Level 3 or Level 4, these questions are a starting point; those levels add ownership, control, and supply-chain transparency requirements that go beyond what is listed here.

Infrastructure layer

Where is real-time media routed during a live session, and in which country?
Where are recordings stored at rest, and on whose infrastructure?
Is the underlying infrastructure provider subject to any extra-EU legal access regime?

Operator layer

Who operates the service, and in which jurisdiction are they incorporated?
Which sub-processors handle any part of the media or data chain, and where is each of them based?
Can the vendor provide documentation mapping their service to the CADA sovereignty assurance levels?

AI and data flow layer

Where does AI transcription and inference take place and can audio or video data leave the EU?
Are AI sub-processors named and documented, with EU-based operational chains?
Does the vendor's sub-processor list cover all AI features, or only the core media routing?

Exit and portability

Is there a defined exit and data portability process, or does the 'EU-hosted' framing mask a closed operational dependency?
Is any part of the integration layer open source and available for inspection?

Conclusion

The legislation will not take effect overnight, and its final form will emerge from the trilogue (the interinstitutional negotiation between the Commission, the Parliament, and the Council). But the direction is clear and consistent with every EU digital sovereignty initiative of the past three years: cloud services used for sensitive workloads in the public sector will be assessed against a four-level sovereignty framework, and video conferencing, together with its real-time media, stored recordings, and AI inference, will need to evidence compliance across all three data flow layers, not just the one that is easiest to photograph in a marketing deck.

The platforms already thinking in these terms are ahead of procurement. For buyers who need to make decisions now, the questions in the checklist above translate the regulation's logic into vendor-selection criteria that should serve you well regardless of how the trilogue resolves. One caveat worth noting: the third-party audit required to formally certify Levels 2 through 4 depends on an EU cybersecurity certification scheme (EUCS) that has not yet been finalised, so vendors cannot yet obtain validated certification under the CADA framework. That is a known implementation gap, not a reason to delay procurement conversations, but it is worth understanding before you ask vendors to produce documentation that does not yet exist.

For more on how we approach data security and infrastructure transparency, visit the Digital Samba security page. For a wider treatment of data sovereignty for video, read our earlier article on the subject.

Frequently asked questions

What is the Cloud and AI Development Act (CADA)?

The Cloud and AI Development Act is a legislative proposal published by the European Commission on 3 June 2026 as part of the EU Tech Sovereignty Package. It targets three areas: supporting research and innovation in cloud and AI, tripling EU data centre capacity within five to seven years, and introducing a single EU-wide sovereignty framework for assessing cloud and AI services. That framework defines four assurance levels that public sector bodies must apply when procuring cloud services based on their risk profiles.

How does CADA affect video conferencing platforms in the EU?

The legislation makes video conferencing platforms subject to a formal sovereignty assessment when used by public sector bodies. Video touches every layer the framework cares about: real-time media routing on cloud infrastructure, stored recordings, and AI inference for transcription and summaries. Each of those is assessed separately under the four-level sovereignty model. A platform that satisfies Level 1 (data on EU-located servers) but routes AI inference through a non-EU provider would likely face problems at Level 2 under the independence requirement, though the explicit geographic prohibition on AI inference data leaving the EU is a Level 4 rule, not a Level 2 one.

What is cloud sovereignty for video, and how is it different from EU hosting?

Cloud sovereignty for video means that EU-governed control can be evidenced across the entire data processing chain: where media is routed and stored, who operates and controls the infrastructure, and where AI inference happens. EU hosting is a subset of this, as it satisfies the Level 1 location requirement but says nothing about who controls the infrastructure or whether the operator is subject to extra-EU legal access demands. A platform can be EU-hosted and still fail sovereignty at Level 2 if it is operated by a non-EU-controlled entity.

Does CADA require AI transcription and inference to stay in the EU?

The explicit answer depends on which level you are looking at. At Level 4, the requirement is clear: no third-country interference of any kind, which covers AI inference pipelines. At Level 2, the picture is less settled. The Level 2 independence requirement (demonstrating independence from third-country legal regimes) would likely create a functional barrier for AI providers subject to non-EU access laws, but that conclusion is a reading of the independence requirement rather than a named provision in the proposal. For a public sector body procuring a video platform at Level 2, routing audio to a non-EU AI provider for transcription would almost certainly create problems in a sovereignty assessment, even if the exact legal basis for that conclusion may shift as the trilogue progresses.

How can you tell if a video platform is genuinely EU-sovereign?

The most reliable signal is whether the vendor can answer three questions with documented evidence rather than marketing language: Where exactly is live media processed and who operates that infrastructure? Where does AI inference happen, and who are the named AI sub-processors? Is the operational chain (hosting, operations, and AI processing) entirely within EU-incorporated entities not subject to extra-EU legal access regimes? A vendor who can map their service to the CADA sovereignty levels in a procurement response is demonstrating the kind of operational transparency the framework is designed to incentivise.

What should EU buyers ask a video vendor about cloud and AI?

Buyers should ask for documented answers across three areas: (1) the location and operator of the infrastructure handling live media and recordings; (2) the identity, location, and legal jurisdiction of all AI sub-processors handling transcription, summaries, or any other feature involving decoded media; and (3) whether the vendor can provide a mapping of their service to the CADA sovereignty assurance levels, with supporting evidence. A public repository or a 'GDPR-compliant' label is not a sufficient answer to any of these questions.