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.

Every path that touches meeting content is EU at runtime — including the post-meeting AI steps, which we used to flag as the one gap and have since moved onto EU processors. We say plainly where the one remaining US model sits, and why it never sees your meeting.

This post maps where your meeting runs. Its companion, What one InterMIND meeting is built from, maps what it's built from — which layers are our own code, which are open-source, and where we're pragmatic about proprietary SaaS.

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 + the Mind API — 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, not a third party's. The client SDK it runs on is open-source (BSD-3-Clause) and auditable today; self-hosting the engine itself is on the roadmap for a customer who needs it.

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 post-meeting AI steps, named plainly

After the call ends we run a few language-model steps on what was said: the AI digest (topics, decisions, action items, open questions), the post-meeting summary, and the AI note-editor (translate a note, or fix / extend / simplify it). These are the only places a general-purpose model touches meeting-derived content — and all of them now run on EU processors:

• The digest runs on EU-hosted Mistral (mistral-large-3, mistral-medium-3.5 fallback), reached through Vercel's AI Gateway pinned to the Mistral provider with zero-data-retention — the request fails rather than falling back to a non-ZDR or US host.
• The summary and the editor's translate action go through our own EU engine on OVH — the same one that translates live voice and chat — so the summary never leaves the data plane the meeting already lived in.
• The editor's generative actions (fix, extend, reduce, simplify, summarize) can't run on a translation engine, so they use the same EU Mistral + zero-data-retention path as the digest.

Real-time voice, real-time chat, notes, and document translation never go through any of these — they were EU-resident from the start.

The one place a US-domiciled model is still in the loop touches no meeting data: our public translation-quality benchmark uses a frontier model as an automated judge, scoring machine translations of FLORES-200 reference sentences. That's a fixed, public dataset — not anyone's meeting.

We're still going further on the EU-Mistral steps: a planned owner-controlled opt-out to disable the digest entirely, and a self-hosted open-weights model (Kimi-class) on OVH to replace the external Mistral for summarization tasks that don't need a frontier reasoner. Both are on the roadmap, not shipped; we'll update this post when they land.

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. The residency map is one piece; for the rest of the data-protection obligations — erasure, retention, portability, consent — we ran the codebase through a full audit and closed each item against the code.

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 + Mind API 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.