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 AI steps, which run on the AI gateway your organization selects, in an EU region of our own tenant. The vendors behind that gateway are US companies operating EU regions; we say so plainly below, and we say which model sits outside the meeting entirely.

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 on our media server. The audio arrives over WebRTC at our own engine — the Mind API on OVH, France — and is recognized there, word by word, on the same server that carries the call; no third-party speech service is in the loop. Voice notes in chat are the one exception: their speech-to-text runs on Azure AI Speech, the speech service of the default AI gateway (vendor table below). The pipeline itself is 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, one translation per target language present in the room, EU-resident at every hop.
5. A document dropped into chat (PDF, DOCX, DOC, 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 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). During the call the same kind of step writes a summary of every document dropped into chat and answers Ask AI and Mia. These are the only places a general-purpose model touches meeting-derived content, and all of them go to one place:

• The AI gateway your organization selects. One resolver in the code picks it for every call site; there is no second path. The default is Azure OpenAI in the EU Data Zone; from its settings an organization switches to Vertex AI on the EU multi-region endpoint or Amazon Bedrock in Frankfurt, or points every AI feature at its own OpenAI-compatible endpoint — vLLM in its own data centre, a deployment in its own tenant. Each hosted gateway runs in our own tenant, configured for zero data retention and no training on customer content; the fallback stays on the same gateway — a second EU region, or a second model of the same vendor — never another vendor. The AI features docs list the gateways and regions.
• The summary and the editor's translate action go through the translation tract, not the language model — the same path that translates live chat.
• AI can be switched off for the whole organization: transcription and translation keep working; the digest, document summaries, the writing assistant and Ask AI stop.

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

Where the vendors sit: Microsoft, Google and Amazon are US companies operating EU regions. That is stated plainly on the trust page, not hidden — it is the corporate-domicile question from the top of this post, answered for this hop the same way as for the plumbing. One model sits outside the meeting entirely: our public translation-quality benchmark uses an LLM judge (Gemini, with Claude as fallback, via Vercel's AI Gateway) to score machine translations of FLORES-200 reference sentences. That's a fixed, public dataset — not anyone's meeting.

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.

Sources: runtime regions and model routing verified against the deployed configuration (vercel.json, fly.toml) and the shipped code; Vercel AI Gateway (the digest's provider-pinning path), FLORES-200; checked August 2026.