Where one InterMIND meeting actually runs

Every serious enterprise procurement conversation eventually reaches the same question: "Where does this data go?" The DPO wants a sub-processor list. The CIO wants to know which vendors are US-domiciled. Legal wants a diagram with arrows.

We'd rather you have the full picture than ship it piece by piece over email. So here is the data path of one meeting — every external service it touches, where each one executes, and what data flows through it. Verified against the actual deployment configuration on 2026-05-28.

There is one path where vendor-domicile is still US, and we say so plainly. The rest is EU at runtime.

What "where it runs" actually means

Two things get conflated in sovereignty conversations and they are not the same thing:

1. Runtime / data path. Where the bytes of your meeting are physically processed during the request. This is what data-residency regulations and most DPAs are actually about.
2. Vendor corporate domicile. Where the SaaS vendor is legally incorporated. This is what CLOUD-Act discussions are about — the theoretical reach of a US compulsion against the vendor's parent entity, regardless of where the workload runs.

Almost every "is this EU?" question is really one of these two, asked imprecisely. We answer them separately for every vendor below.

The data path of one meeting

Trace one call from join to follow-up email:

1. Browser opens the meeting page. SSR runs on Vercel, pinned to fra1 (Frankfurt). All request/response data — session cookies, API payloads, server-rendered HTML — is processed in EU at runtime.
2. WebSocket connects to our meeting server in Paris (cdg). Meeting orchestration, presence, signalling — all EU.
3. Speech recognition runs in the speaker's browser. Local. Never leaves the device until the resulting transcript is sent for translation. (We covered why in Inside the four translation pipelines.)
4. Voice and chat translation hit our own engine on OVH France. This is mind-sdk-web — our code, our hosts, in France. No third-party model is in the loop. Sub-second budget, per-language WebSocket pool, EU-resident at every hop.
5. A document dropped into chat (PDF, DOCX, PPTX, XLSX) goes server-side from the Paris ws-server to DeepL in Cologne. German company, German processing. Voice and chat do not touch DeepL.
6. Application data — users, teams, messages, meeting metadata — lives in Neon Postgres on AWS Frankfurt (eu-central-1). Snapshots in the same region.
7. Recordings, attachments, exports are stored on Tigris, S3-compatible storage on Fly. Edge-replicated; the bucket is configurable to multi-region EU for tenants who need it pinned tighter.
8. Errors and performance traces go to Sentry's EU instance (de.sentry.io). The US org was retired in May.
9. Product analytics go to PostHog EU (eu.i.posthog.com).
10. Transactional email (magic links, invites, receipts) goes via Resend out of eu-west-1 (Ireland).

Everything above is EU at runtime. The translation engine — the part most of your data actually flows through — is also our own code, which means the engine itself can be audited or self-hosted by a customer who needs it to be.

The vendor map

The two heaviest data flows by volume — voice/chat translation through our own engine on OVH and document translation through DeepL — also happen to be the two vendors whose parent entity is in the EU. That covers the bulk of meeting content. The full sub-processor list with corporate-domicile detail goes into the DPA as standard practice; the table above is the runtime view, which is what most data-residency clauses are about.

The one current gap, named plainly

After the call ends, we generate a post-meeting AI digest — topics, decisions, action items, open questions. The model that produces the digest is reached via Vercel's AI Gateway (an EU-region proxy) but the underlying models are Google Gemini 2.5 Flash with an Anthropic Claude Sonnet fallback — both US-domiciled vendors.

Real-time voice, real-time chat, and document translation do not go through this path. The digest is a separate, post-meeting step that takes the transcript we already produced and writes a summary on top of it.

We're closing this gap two ways:

1. Owner-controlled opt-out, coming shortly. A workspace owner will be able to disable the AI digest pipeline entirely, in which case the post-meeting summary is simply not generated and the transcript stays where it was — in the EU. Default off for new tenants; existing tenants get a notice and can leave it on if they want.
2. Self-hosted EU summarization model. We're standing up an open-weights model (Kimi-class) on OVH for tasks like summarization that don't need a frontier-grade reasoner. Once that's the digest backend, the trade-off goes away — the same pipeline works without any US-domiciled vendor in it.

If the digest is the difference between "this works for us" and "this doesn't" for your procurement, tell us — we'll prioritise accordingly.

What this means for your DPA

For most EU buyers — German Mittelstand, regulated industries running standard GDPR DPAs — the picture above answers the data-residency question directly: every runtime hop your meeting takes is in the EU. Vendor-domicile gets disclosed in the sub-processor list per normal practice; nothing surprising there.

For French souveraineté numérique and SecNumCloud-grade procurement, vendor corporate domicile is itself part of the criterion, not just runtime location. That's a different conversation — an alternative deployment topology that keeps every component under European-jurisdiction vendors. We don't run that by default; we'll spin it up for a tenant that needs it and where the contract justifies the build.

For US-domestic and most APAC buyers, the inverse is usually true — they want low latency from their region, which is a different problem. Today we run single-region in fra1. If your traffic justifies a US edge, we'll plan that with you.

What this post commits us to

This is the picture on 2026-05-28. We'll update it when the stack changes — vendor swap, region migration, a new external service. The current configuration is verifiable in our open vercel.json, the mind-sdk-web engine running at OVH France, and every vendor's own dashboard.

If something here looks wrong, or your DPO needs an answer this map doesn't give, write us. We'd rather correct a missing detail than have you discover it in a contract review.