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
The Cloud and AI Development Act is built around three areas of intervention, each of which touches video infrastructure in a distinct way.
| 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.
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 resolves into three layers that must be probed separately, because each can fail independently while the others appear to pass.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.