Where does your call data physically sit? EU data residency for conversation intelligence
Data residency for conversation data means knowing where recordings, transcripts, summaries and AI-derived fields are physically stored and processed, and under whose legal jurisdiction each of those places sits. Not the vendor's headquarters. The servers.
Most European Revenue AI projects stall before anyone has picked a use case, and it's rarely a feature gap. Nobody can state in writing where the recorded call data lives, who processes it downstream, and whether anything in that chain trains a model on it. Legal won't sign. The works council won't sign. So the project waits, and the competitor who deployed anyway keeps moving.
This is the map of that chain, link by link, plus the questions that clear the gate. Weflow shows up near the end as a worked example, limits included, and Conversation Intelligence + AI Field Updates is the product doing the work in those examples.
What does EU data residency mean for conversation intelligence?
Residency for call data is not one location. It's a chain, and every link has its own answer.
A recorded sales call becomes at least four separate data assets: the media file, the transcript, the derived summaries and field values, and the prompts and completions passing through a model provider. Each one can sit in a different place, under a different controller, in a different jurisdiction. A vendor who answers "our data center is in Frankfurt" has answered one of four questions.
The concept decomposes into three questions you have to ask separately:
- Where is it stored? The physical region for each asset, named, with the cloud provider behind it.
- Who processes it? Every sub-processor in the chain, including the model providers the vendor doesn't volunteer.
- What trains on it? Whether any of that data reaches a model that learns from it, contractually, across the whole chain.
Residency and ownership are also different questions, and buyers collapse them constantly. Data can sit in an EU region and still be in a vendor's tenant, which means you can report on it only through their interface and you lose it when the subscription ends. In-region and yours are two separate checkboxes.
Why data residency now stalls Revenue AI projects in Europe
Three things converged, and none of them are your reviewer being difficult.
First-generation tools were built US-first. They keep conversation data in their own cloud, and moving it to an EU region isn't a setting you flip during onboarding. Gong charges to relocate a customer's data between regions. That turns residency into a paid project discovered mid-contract, usually at the moment one of your customers asks where the recording of their conversation is stored.
We hear the consequence from teams selling into defence, government and regulated European buyers. A US answer ends the conversation, and the cost of fixing it lands on the buyer, not on the vendor who created it.
The LLM layer added a new link nobody had to think about three years ago. Conversation data now passes through model providers. So "we don't train on your data" is only half an answer. The question is whether that commitment covers the sub-processors, and whether the AI step retains anything at all.
GDPR plus national works-council law raised the bar past certification. "We're SOC 2 and GDPR compliant" doesn't clear a German works council.
When nobody can point at where the conversation physically lives, the safe move is to not move. That's the stall. It's structural, not a failure of nerve.
Where call data sits across a conversation intelligence stack
Here's the map. One recorded call produces several assets, and each one can sit somewhere different under someone different.
| Data asset | Where it can sit | Who typically controls it |
| Video and audio recording | Vendor cloud (US or in-region), or the customer's own cloud storage | Vendor, unless exported |
| Transcript | Vendor cloud, or the customer's own CRM tenant | Vendor, unless written to the CRM |
| Summaries, scores, AI field values | Vendor cloud, or native CRM objects in the customer's org | Vendor, unless written to the CRM |
| Prompts and completions at the AI step | Sub-processed LLM provider, region depends on the vendor's contract | The model provider, governed by the vendor's DPA |
Hold a vendor's architecture against that table. If one cell can't be filled in with a specific answer, you don't have a residency answer yet.
Where the recordings and video files live
The raw recording is the heaviest and most sensitive asset, and it's where vendors diverge most.
Three realistic architectures:
- Vendor cloud, US region. The default for tools built US-first. Fine until a European customer asks, then expensive to change.
- Vendor cloud, in-region. Better, but ask whether it's a setting at provisioning or a migration you'll pay for later.
- Customer's own cloud storage. The media file lands in storage you control, with the CRM record linking out to it.
The reason this link decides jurisdiction is simple: whoever's tenant the file sits in is subject to that tenant's legal regime, and the recording is the asset a works council cares about most, because it carries voices.
Where transcripts, summaries, and AI field updates land
The transcript and its structured outputs are the asset your business actually runs on, and this is the fork that matters more than the data center question.
Two models:
| Vendor-cloud model | Customer-tenant model | |
| Where the transcript lives | Vendor's system, surfaced via their UI and API | Native objects in your own CRM org |
| Who governs access | Vendor's permission model, managed separately | Your existing CRM permissions and role hierarchy |
| Reporting | Vendor dashboards, or an export | Your own reports, alongside everything else |
| What survives the contract ending | Whatever you exported before the last day | The records, because they were always yours |
This is why "the data is in our platform, hosted in the EU" and "the data is in your Salesforce" are different residency answers even when both are technically in Europe. One of them you can point a works council at and say: here is the object, here is who can read it, here is the permission that controls it. The other requires a vendor to explain their access model on your behalf.
A previous Gong user put the ownership half of it plainly on a call with us:
I've used GONG before. I'm a previous GONG user. I know they're weak and also you can never leave them because you don't own any of the data.
The LLM processing step: sub-processors and model training
This is the link that now kills deals, and the one most vendor security pages answer badly.
Every AI feature on a call, the summary, the field extraction, the coaching score, routes conversation content through a model provider. That's a sub-processor, whether or not it's named on the first page of the trust center. So you need three things answered in writing, for the whole chain and not just the vendor's own systems:
- Where the AI step runs and which providers sit in it, named on a list you can read before signing.
- Whether data is retained at that step. Zero Data Retention means the provider doesn't keep the prompt or the completion after processing.
- Whether any of it trains a model, with the commitment explicitly covering sub-processed LLM providers.
The disqualifying pattern is easy to spot once you're listening for it: a vendor answers the training question confidently about their own models, and goes vague the moment you ask about the provider doing the inference. That vagueness is your answer.
Be honest about what a good answer looks like, too. Nobody serving AI features has zero third parties in the chain. What you're testing for is a documented chain governed by contract, not the absence of one.
The residency questions to ask every conversation intelligence vendor
Send these before the demo. Each one has a good answer and a disqualifying answer, and the disqualifying ones are recognizable patterns rather than judgment calls.
| Question | Why it matters | What a good answer looks like |
| Which sub-processors handle our conversation data, and can I see the list before signing? | You can't document a chain you can't see, and the works council will ask for it by name | A public sub-processor list, available now, with advance notice before any change so you can object before it takes effect. "After signature" is a no. |
| Where does the AI processing step physically run, and does Zero Data Retention apply to it? | The LLM layer is a separate residency question from storage, and it's the one vendors skip | Named providers, a stated region, and ZDR covering the AI step, in the DPA rather than on a marketing page |
| Is our data ever used to train a model, including by any sub-processed LLM provider? | A no-training commitment that stops at the vendor's own models covers roughly nothing | A written no, explicitly extended to sub-processed model providers |
| Is EU or UK residency standard configuration, or a paid tier or migration? | Residency discovered as a chargeable relocation mid-contract is the trap this reader is screening for | Region chosen at instance creation, no relocation project, no line item. Ask directly what a region change costs. |
| Are the DPA and EU Standard Contractual Clauses signable up front? | Paper you can't read before a demo is paper you'll be arguing about in week six | Both available on request now, no NDA gate, no "at contract stage" |
| Where do the video files live compared to the transcripts? | They're often two different architectures with two different jurisdictions | A specific answer for each asset, not one answer covering both |
| Does the AI generate any biometric identifiers or voiceprints from call audio? | Biometric data changes which privacy provisions apply and how the works council reads the whole deployment | A direct yes or no. If yes, the documentation burden goes up sharply. |
| Is capture connected at workspace level or per rep? | Not a residency question, but it decides whether your documented process matches reality | Central connection, so coverage doesn't quietly rot when a rep's token expires |
The residency "roadmap" deserves its own warning. A vendor telling you EU hosting is coming next year is telling you their architecture wasn't built for it, and roadmap dates don't clear works councils.
What documentation the works council needs to sign off
In Germany and Austria, a recording tool doesn't fail on features. It fails at the works council, and it fails on paperwork you didn't know to assemble.
The dynamic is worth understanding before you walk in. The council isn't evaluating your business case. They're asking whether employees are being monitored, whether the answer is documented, and whether consent is real rather than buried in a clause someone signed on their first day. A recording tool triggers all three at once.
What to have ready, and where each piece comes from:
- A description of exactly what is captured: which meetings, which platforms, whether email is included, and explicitly what is not captured. From the vendor's product documentation, written in plain language rather than feature names.
- The processing chain, end to end: where recordings are stored, where transcripts land, which sub-processors touch the data at the AI step. From the vendor's sub-processor list and architecture answers.
- Who can access what: the permission model, and ideally the fact that it inherits from a system the council has already approved rather than introducing a new one.
- The consent mechanism, per session: how each recorded meeting notifies participants and how someone declines. A line in an employment contract does not survive this meeting.
- The DPA with EU Standard Contractual Clauses, signed or signable, from the vendor.
- The training and retention commitment in writing, covering sub-processors, because someone will ask what the AI does with the recording.
- The breach notification commitment, with its timeline stated.
One thing that changes the tone of that meeting: separate what reps see from what managers see. Talk ratio, monologue length and meeting hours are exactly what a manager wants and exactly what makes the person being measured go cold. Buyers who've been through a rollout brief the two audiences separately and set permissions to match, and they say so during the evaluation.
How Weflow answers the EU data residency question
Weflow is the Revenue AI Orchestration platform for sales, customer success, and RevOps teams, built for teams running on Salesforce. The residency answer here is architectural rather than a set of claims: the default design keeps the data in-region and in your own tenant, which is why the checklist above comes back clean, including in the two places where the honest answer carries a caveat.
A German vendor hosted in Frankfurt, in-region by configuration
Weflow is a German company hosted in Frankfurt, so the answer to "where is the company" is itself in-region.
The instance side works like this. Weflow spins up your workspace in the region where your Salesforce is hosted, and that can be overridden to keep data in the EU or UK. The underlying infrastructure runs on AWS and Google Cloud with selectable EU, US and APAC regions, with TLS 1.2 or above in transit and AES-256 at rest.
Residency is a configuration decision made at setup, not a relocation project. That's the whole point of matching the region at instance creation.
Stated fairly, this is where Gong works differently: Gong charges to relocate a customer's data between regions. If your buyers won't accept US residency, that difference is a cost line rather than a preference.
Transcripts live in your own Salesforce, not a vendor cloud
Weflow writes conversation data into native Salesforce objects in your own org: a recording object holding the summary and full transcript, plus an indexing object. Summaries land on the Salesforce Event, and AI Field Updates write into the standard and custom fields your team already reports on.
What that changes for a security review:
- Access is governed by permissions the council has already approved. Sign-in is Salesforce OAuth only, using whatever SSO your org enforces. There's no separate Weflow password to phish, and deactivating a user in Salesforce removes their Weflow access immediately.
- The transcript is reportable and queryable alongside everything else in the CRM, because it's a Salesforce record rather than a link into a vendor system.
- It survives the subscription. The analysable asset was always in your tenant, so leaving doesn't mean an export race.
KORE Wireless framed the reason they bought this way rather than as a recording purchase:
We weren't buying conversation intelligence. We were buying a unified data layer that the entire go-to-market motion could run on, and a partner who understood that distinction.
— Scott Jones, SVP of GTM Revenue Intelligence & Enablement, KORE Wireless

Zero Data Retention: no model training across the sub-processor chain
Weflow runs AI processing under Zero Data Retention, and customer data is never used to train models, including any sub-processed LLM providers.
That last clause is the one to quote to legal, because it's the level at which the question actually has to be answered. A commitment covering only the vendor's own models leaves the inference step unaddressed, which is where the conversation content actually goes.
Our CEO Janis Zech makes the point about why the data foundation decides everything downstream:
You can't build AI on top of bad data. We know that. Garbage in, garbage out.
— Janis Zech, CEO of Weflow
The procurement documents available before the demo
The paper this reader screens on, available up front rather than at contract stage:
- A Data Processing Agreement with EU Standard Contractual Clauses.
- A public sub-processor list with advance change notification, so you can object to a new sub-processor before it takes effect rather than discovering it afterwards.
- A 48-hour breach notification commitment.
- SOC 2 Type II, held since 2021, with regular third-party penetration testing.
- GDPR, CCPA and HIPAA compliance, with certificates and controls in the trust center.
- A 99.5% or better uptime SLA with a public status page showing real-time and historical availability.
Bastian Stosic at HolidayCheck, who had used Gong before, described the shortlist criteria in one line:
Weflow ticked all the boxes: GDPR-compliant, tightly integrated with Salesforce, simple to use - and without the heavy price tag of U.S. vendors.
— Bastian Stosic, Head of Media Sales Operations, HolidayCheck
Where Weflow falls short: ISO 27001, FedRAMP, video storage
The caveats a diligent reviewer would find anyway, so you don't have to find them:
- ISO 27001 is in progress, not certified. If your procurement policy mandates it, treat it as underway and plan accordingly rather than taking a verbal.
- Weflow is not FedRAMP certified. US government contractors requiring FedRAMP are not a fit, and we'd rather say that now than in week four.
- The AI step does pass through sub-processed LLM providers. It's governed by Zero Data Retention and the no-training commitment, but it's a processing chain rather than zero third parties. Anyone claiming otherwise while shipping AI features is describing something else.
- Video files are not stored in Salesforce. Salesforce storage is expensive and heavy for media, so recordings are exported through the public API to your own cloud storage and linked from the record. Transcripts and structured outputs stay in Salesforce.
- Weflow works only with Salesforce. No HubSpot, no Dynamics, no Pipedrive. That's a hard product boundary, not a roadmap item.
Walk through the product yourself, no call required.
FAQ: EU data residency and call data compliance
Is EU or UK data residency a paid add-on in Weflow?
No. The instance region is set when your workspace is created, matching the region your Salesforce is hosted in, and it can be overridden to keep data in the EU or UK. It's configuration at setup, not a paid relocation or a premium tier.
Where do meeting video files live compared to transcripts?
Transcripts, summaries and AI field updates land in native Salesforce objects in your own org. Video files are deliberately kept out of the CRM, because Salesforce storage is expensive for media, and are exported through the public API to your own cloud storage with the record linking out to them. Two assets, two locations, both under your control.
What is Weflow's SOC 2 and ISO 27001 status?
Weflow has held SOC 2 Type II since 2021, with regular third-party penetration testing. ISO 27001 is in progress and not yet certified, so a procurement team that mandates ISO 27001 should treat it as underway rather than achieved.
Can we see the sub-processor list and DPA before signing?
Yes. The sub-processor list is public and comes with advance notice of changes, so you can object to a new sub-processor before it takes effect. The Data Processing Agreement with EU Standard Contractual Clauses is available up front, not at contract stage.
Is Weflow FedRAMP certified?
No. Teams that require FedRAMP, typically US government contractors, are not a fit for Weflow today.
Which recording consent model works for European teams?
Three designs work in practice, and the trade-off is always coverage against consent strength:
- Opt-out: the meeting records by default, the guest is notified and can decline. Near-complete coverage, and it asks nothing of sellers. The burden of objecting sits with the participant.
- Opt-in: every participant actively accepts first. Cleaner consent, materially thinner data, and it only holds up for one-to-one and small meetings, because one person forgetting to accept kills the recording.
- Manual: the seller asks in the room. Fine for sensitive accounts, unreliable as a default.
Most teams land on opt-out, because coverage is what decides whether conversation data is a reliable input or an anecdotal one. Weflow supports configurable consent flows, including a Microsoft Teams pre-meeting email with an opt-in or opt-out link and an in-call chat message with a removal option that triggers immediate permanent deletion of the recording data. Decide the model with legal before rollout, not after the first guest objects.






