Data Residency Requirements for Meeting Intelligence Tools

An organization that selects a meeting intelligence tool because its marketing page says "EU-hosted" has solved one problem out of at least four. Data residency, in the way most procurement teams use the term, refers only to where data sits at rest, and a meeting recording or transcript travels through several distinct processing stages before it ever becomes a stored file a buyer can point to on a map.

The confusion starts with vocabulary. An organization or vendor chooses where data is stored under data residency. Data localization, by contrast, is a legal mandate imposed by statute, requiring that certain data remain inside a specific jurisdiction. Data sovereignty is broader still, and arguably the more consequential idea of the three: it holds that data is subject to the laws of whatever jurisdiction processes it, including which government can compel access to it regardless of where the data happens to be stored. These three concepts get treated as synonyms in sales conversations, but a buyer who conflates them will sign a contract that satisfies residency while leaving sovereignty exposure untouched.

This confusion is visible in how AI notetakers were actually built. Many of them join calls as a bot and send all captured audio to US servers by default, because the products were designed for the US market first, with data protection added later as a compliance patch rather than built into the architecture from the start. That history matters for any buyer outside the US, because it means the default configuration of a widely used tool may not match the jurisdictional assumptions a European compliance team needs to make.

Sophisticated buyers have already updated the question they ask. European technical-sovereignty guidance has shifted the framing away from "where is data stored" toward a more granular inquiry: where is data processed, who can access it at each point, and which legal regime governs that access. Storage residency alone no longer satisfies a rigorous procurement review under that framing. The question the rest of this piece answers is what full pipeline compliance actually requires, stage by stage, from the moment audio is captured to the moment a language model produces a summary.

The four-stage pipeline and data residency

A meeting intelligence tool is not a single-step service. A tool's claim of "EU residency" may describe only one of these four stages, leaving the other three undocumented.

Audio capture and preprocessing comes first, and where it happens decides whether raw audio can leave a user's device or local network before transcription begins. A local or on-device capture architecture does not, because the recording never has to leave the machine it was captured on before the next stage begins. This distinction matters because raw audio is itself regulated personal data, independent of any transcript derived from it. Residency rules can attach to conversation recordings and, in some regions, to voice biometrics, so the audio file already carries legal weight when it sits on a server before transcription has even started.

Speech-to-text transcription is the second stage, and it can happen on-device, on the vendor's own servers in a declared region, or through a third-party speech-recognition provider sitting in a jurisdiction the vendor doesn't fully control. Where a vendor instead relies on a third-party automatic speech recognition provider, such as a major cloud company's speech API, that provider becomes a sub-processor in its own right, and its location and contractual agreements belong in the compliance picture as much as the primary vendor's do.

Speaker diarization is the third stage, and its relevance here is narrow but important: it is a separate processing event that can cross a jurisdictional border on its own. It does not necessarily attach a named identity to that label, because that needs the separate step of speaker identification, but the label-to-segment link still counts as personal data about a specific natural person under GDPR. This stage can run on the same infrastructure as transcription, or it can be handled by an entirely separate model hosted somewhere else.

LLM summarization and action item extraction form the fourth stage, and it's the one procurement reviews most often fail to examine. The prompt sent to the language model, any retrieved knowledge used to construct that prompt, and the customer context folded into it all constitute regulated processing under GDPR, and the location where that inference runs counts as a processing location in its own right. A vendor can store transcripts in an EU region and still send those transcripts to a US-hosted model for summarization. The storage is compliant; the processing is a separate question entirely, and one that a vendor's residency claim does not automatically answer.

A fifth surface sits alongside these four stages rather than inside them: training and fine-tuning. If a vendor improves its models using customer conversations, that training data carries its own residency and consent implications, and these differ from the processing that produces the summary a user actually sees. Binding no-training agreements with every AI sub-processor in the chain, not just the primary vendor, are a distinct compliance requirement rather than a courtesy feature a vendor might offer as an upsell.

What GDPR requires from each stage of the pipeline

GDPR does not stop regulating data once it reaches storage. It imposes obligations at every stage of the pipeline described above, and several of those obligations are routinely underdocumented by meeting tool vendors, including requirements around lawful basis, sub-processor transparency, cross-border transfer mechanisms, and special category data.

Meeting recordings and transcripts are personal data as a matter of course. Names, voices, job titles, and opinions expressed during a call all qualify, and where a call touches on health concerns or political views, that content becomes special category data under Article 9, carrying stricter handling requirements than ordinary personal data. Any transfer of this data outside the EU needs its own legal basis, typically an adequacy decision or a safeguard mechanism such as Standard Contractual Clauses, and that basis has to be established independently of whatever basis justified the original recording.

Lawful basis, in fact, has to be documented separately for each data type the pipeline produces. Raw audio, a verbatim transcript, and a structured AI-generated summary are three distinct forms of derivative personal data, and each one has its own retention period and access implications. A recording captured under legitimate interest does not automatically extend to cover indefinite retention of the summary derived from it, and it does not automatically cover that summary's use in downstream AI workflows the organization adds later. Documentation needs to specify the basis, the purpose, and the retention period for each of these forms separately, not as a single blanket justification covering the whole pipeline.

Employee consent, in particular, is not the safe harbor many compliance teams assume it to be. Consent is generally not a defensible lawful basis for recording employee meetings under GDPR, because the power imbalance between employer and employee means the employee cannot refuse freely, and European data protection authorities have reached this position in enforcement decisions. Criminal law adds a sharper edge to this in several jurisdictions. Spain's Article 197 Código Penal criminalizes non-participant recording but, unlike the German statute, permits participant recording, making it only a partial analogue to the German rule.

Sub-processor transparency is its own legal requirement, separate from lawful basis. The sub-processor list a vendor publishes has to be current and publicly available, and it has to cover every third party touching the data, including the LLM providers handling summarization. Each of those sub-processors needs a valid transfer mechanism in place if it processes data outside the EEA, and that mechanism has to hold up on its own rather than borrowing legitimacy from the primary vendor's paperwork.

Cross-border transfer mechanisms themselves are unstable ground. A vendor certified under the EU-US Data Privacy Framework has covered transfers of stored data, but that certification does not automatically extend to LLM inference performed on US infrastructure, because that inference is a separate processing event needing its own transfer basis.

The EU AI Act layers a new disclosure obligation on top of all of this. Article 50 transparency obligations for chatbots became enforceable on August 2, 2026, so providers now have to tell users they are dealing with an AI system. If a meeting tool surfaces AI-generated outputs to participants, the organization using it now has to meet this disclosure duty alongside, not instead of, its existing residency and processing obligations.

The sub-processor chain is where most compliance gaps hide

The sub-processor chain connecting audio capture to LLM output is where most meeting tool compliance programs actually break down, because vendors tend to disclose their own data location in detail while leaving the processing locations of everyone downstream of them undocumented or buried in a footnote. Since each stage of the pipeline described earlier can run through a different sub-processor, a buyer evaluating "the vendor's" data location is often evaluating only the strongest link in a chain whose weakest link remains invisible.

The practical gap looks like this in most contracts: a vendor declares EU storage and signs an Article 28 data processing agreement, and the buyer treats that as the end of the inquiry. But the speech-to-text provider that vendor relies on, the diarization service it uses, and the LLM inference endpoint handling summarization may all be operated by separate companies, in separate jurisdictions, each running its own sub-sub-processor chain that the primary vendor's contract never fully accounts for.

A compliant sub-processor disclosure, measured against what GDPR actually asks for, needs to include a current, named list of every third party that touches meeting data, not a vague assurance that the vendor "uses reputable cloud providers." It needs the processing location, down to country and region, for each of those sub-processors. It needs the specific transfer mechanism in place for any sub-processor operating outside the EEA. It needs advance-notice provisions so customers have the chance to object before a new sub-processor gets added to the chain. And it needs binding no-training commitments obtained from each sub-processor individually, not just from the primary vendor signing the master contract.

The gap between Microsoft Teams and Copilot illustrates the problem at enterprise scale, without any suggestion of wrongdoing on Microsoft's part: the company keeps Copilot data inside the M365 tenant within its EU Data Boundary, but models provided by Anthropic as a subprocessor within that same environment are currently excluded from the EU Data Boundary.

Hedy offers a useful reference point for what full disclosure looks like in practice: its EU accounts have Cloud AI processing handled in Sweden by Inceptron, as of September 2026, a named and located sub-processor for the LLM inference stage specifically.

Logs and audit trails deserve the same scrutiny as the primary data path, because they are regulated data in their own right. A system that logs prompts, transcripts, or customer context for debugging or analytics purposes is processing personal data through that log, and a sub-processor that handles only logs rather than primary meeting content is still a sub-processor under GDPR, with the same disclosure obligations as any other.

Architecture choices and the compliance baseline

Architecture is a compliance lever: the decision between a bot-based joining model, a local desktop recorder, and an on-device transcription model determines how many cross-border transfer problems a team has to solve before the tool is even deployed.

In a bot-based architecture, a visible bot joins the call as a participant, captures audio server-side, and sends it onward to the vendor's processing infrastructure, so every stage of the pipeline happens inside the vendor's cloud by default. The bot's visible presence in the participant list functions as a practical consent signal, since everyone on the call can see it join, but it is not legally sufficient on its own: no jurisdiction treats bot presence as informed agreement, and explicit disclosure is required regardless of which recording method a vendor uses.

A local desktop recorder architecture changes that calculus at the first stage. A desktop app captures the call's audio locally, so raw audio never has to traverse the vendor's infrastructure before transcription begins, and this reduces exposure at the capture stage considerably. Where a vendor offers both a bot-based option and this kind of bot-free desktop recording, as Circleback does, a team gets to choose its own trade-off between the visibility a bot provides and the reduced data transfer that local capture offers, based on its own compliance requirements rather than a single architecture imposed by the vendor.

If transcription is also performed on-device, the audio never leaves the device at the second stage either, and only the processed transcript, or in some configurations only the summary, gets sent to the cloud. Because two of the four pipeline stages never touch the vendor's servers in raw form, that gives a structurally smaller transfer surface than a bot-based architecture produces. LLM summarization, though, still typically needs a cloud call unless the model itself runs locally, and that remains uncommon given the computational demands of current language models. That's the stage where the gap between a vendor's residency claim and its actual processing footprint tends to open up: a vendor can truthfully advertise EU data residency for stored transcripts while still routing inference requests to a US-hosted model, a distinction most procurement reviews miss. Vendors that expose APIs and webhooks for custom integrations, a capability Circleback provides, give teams a way to build their own processing pipelines and route inference through infrastructure they've vetted themselves, rather than accepting the vendor's default processing path as the only option available to them.