Wo ein InterMIND-Meeting tatsächlich läuft

Jedes ernsthafte Beschaffungsgespräch im Enterprise-Bereich landet irgendwann bei derselben Frage: „Wohin gehen diese Daten?" Der DPO möchte eine Liste der Unterauftragsverarbeiter. Der CIO möchte wissen, welche Anbieter ihren Sitz in den USA haben. Die Rechtsabteilung möchte ein Diagramm mit Pfeilen.

Wir geben Ihnen lieber das vollständige Bild, als es Stück für Stück per E-Mail nachzureichen. Hier ist also der Datenpfad eines Meetings — jeder externe Dienst, den es berührt, wo jeder davon ausgeführt wird und welche Daten ihn durchlaufen. Geprüft anhand der tatsächlichen Deployment-Konfiguration am 28.05.2026.

Es gibt einen Pfad, bei dem der Anbietersitz weiterhin in den USA liegt, und das sagen wir offen. Der Rest ist zur Laufzeit EU.

Was „wo es läuft" tatsächlich bedeutet

Zwei Dinge werden in Souveränitätsdiskussionen vermischt, und sie sind nicht dasselbe:

1. Laufzeit / Datenpfad. Wo die Bytes Ihres Meetings während der Anfrage physisch verarbeitet werden. Darum geht es bei Datenresidenz-Vorgaben und den meisten DPAs tatsächlich.
2. Unternehmenssitz des Anbieters. Wo der SaaS-Anbieter rechtlich eingetragen ist. Darum geht es in CLOUD-Act-Diskussionen — der theoretische Zugriff einer US-Anordnung auf die Muttergesellschaft des Anbieters, unabhängig davon, wo der Workload läuft.

Fast jede „Ist das EU?"-Frage ist in Wahrheit eine dieser beiden, nur ungenau gestellt. Wir beantworten sie für jeden Anbieter unten getrennt.

Der Datenpfad eines Meetings

Verfolgen wir einen Call vom Beitritt bis zur Follow-up-E-Mail:

1. Der Browser öffnet die Meeting-Seite. SSR läuft auf Vercel, gepinnt auf fra1 (Frankfurt). Alle Request-/Response-Daten — Session-Cookies, API-Payloads, server-gerenderte HTML — werden zur Laufzeit in der EU verarbeitet.
2. Der WebSocket verbindet sich mit unserem Meeting-Server in Paris (cdg). Meeting-Orchestrierung, Presence, Signalisierung — alles EU.
3. Spracherkennung läuft im Browser des Sprechenden. Lokal. Verlässt das Gerät nicht, bis das resultierende Transkript zur Übersetzung gesendet wird. (Warum, haben wir in Inside the four translation pipelines behandelt.)
4. Sprach- und Chat-Übersetzung laufen über unsere eigene Engine bei OVH Frankreich. Das ist mind-sdk-web — unser Code, unsere Hosts, in Frankreich. Kein Drittanbieter-Modell ist beteiligt. Sub-Sekunden-Budget, WebSocket-Pool pro Sprache, EU-resident an jedem Hop.
5. Ein in den Chat hochgeladenes Dokument (PDF, DOCX, PPTX, XLSX) geht serverseitig vom Paris-ws-Server an DeepL in Köln. Deutsches Unternehmen, deutsche Verarbeitung. Sprache und Chat berühren DeepL nicht.
6. Anwendungsdaten — Nutzer, Teams, Nachrichten, Meeting-Metadaten — liegen in Neon Postgres auf AWS Frankfurt (eu-central-1). Snapshots in derselben Region.
7. Aufzeichnungen, Anhänge, Exporte werden auf Tigris gespeichert, S3-kompatibler Storage auf Fly. Edge-repliziert; der Bucket lässt sich auf Multi-Region-EU konfigurieren für Tenants, die das enger pinnen müssen.
8. Fehler- und Performance-Traces gehen an die EU-Instanz von Sentry (de.sentry.io). Die US-Organisation wurde im Mai stillgelegt.
9. Produktanalysen gehen an PostHog EU (eu.i.posthog.com).
10. Transaktions-E-Mails (Magic Links, Einladungen, Belege) laufen über Resend aus eu-west-1 (Irland).

Alles oben Genannte ist zur Laufzeit EU. Die Übersetzungs-Engine — der Teil, durch den die meisten Ihrer Daten tatsächlich fließen — ist außerdem unser eigener Code, was bedeutet, dass die Engine selbst auditierbar oder durch einen Kunden, der das braucht, self-hostbar ist.

Die Anbieterübersicht

Die beiden volumenstärksten Datenflüsse — Sprach-/Chat-Übersetzung über unsere eigene Engine bei OVH und Dokumentenübersetzung über DeepL — sind zufällig auch die beiden Anbieter, deren Muttergesellschaft in der EU sitzt. Das deckt den Großteil der Meeting-Inhalte ab. Die vollständige Unterauftragsverarbeiter-Liste mit Angaben zum Unternehmenssitz gehört nach gängiger Praxis in den DPA; die Tabelle oben ist die Laufzeit-Sicht, und um die geht es bei den meisten Datenresidenz-Klauseln.

Die eine aktuelle Lücke, offen benannt

Nach Ende des Calls erzeugen wir ein AI-Digest nach dem Meeting — Themen, Entscheidungen, Action Items, offene Fragen. Das Modell, das den Digest produziert, wird über Vercels AI Gateway (ein EU-Region-Proxy) angesprochen, aber die zugrunde liegenden Modelle sind Google Gemini 2.5 Flash mit Anthropic Claude Sonnet als Fallback — beides Anbieter mit Sitz in den USA.

Echtzeit-Sprache, Echtzeit-Chat und Dokumentenübersetzung laufen nicht über diesen Pfad. Der Digest ist ein separater Schritt nach dem Meeting, der das ohnehin schon erstellte Transkript nimmt und obendrauf eine Zusammenfassung schreibt.

Wir schließen diese Lücke auf zwei Wegen:

1. Vom Workspace-Owner steuerbares Opt-out, in Kürze verfügbar. Ein Workspace-Owner kann die AI-Digest-Pipeline vollständig deaktivieren; in dem Fall wird die Nachmeeting-Zusammenfassung schlicht nicht erzeugt, und das Transkript bleibt, wo es war — in der EU. Für neue Tenants standardmäßig deaktiviert; bestehende Tenants erhalten eine Mitteilung und können die Funktion eingeschaltet lassen, wenn sie möchten.
2. Selbst gehostetes EU-Zusammenfassungsmodell. Wir bringen ein Open-Weights-Modell (Kimi-Klasse) auf OVH für Aufgaben wie Zusammenfassung an den Start, die keinen Frontier-Reasoner brauchen. Sobald das das Digest-Backend ist, entfällt der Trade-off — dieselbe Pipeline funktioniert ohne einen einzigen Anbieter mit US-Sitz.

Wenn der Digest für Ihre Beschaffung der Unterschied zwischen „das passt für uns" und „das passt nicht" ist, sagen Sie uns Bescheid — wir priorisieren entsprechend.

Was das für Ihren DPA bedeutet

Für die meisten EU-Käufer — deutscher Mittelstand, regulierte Branchen mit Standard-GDPR-DPAs — beantwortet das obige Bild die Datenresidenz-Frage direkt: Jeder Laufzeit-Hop Ihres Meetings findet in der EU statt. Der Anbietersitz wird gemäß üblicher Praxis in der Unterauftragsverarbeiter-Liste offengelegt; nichts Überraschendes dabei.

Für französische souveraineté numérique und Beschaffung auf SecNumCloud-Niveau ist der Unternehmenssitz des Anbieters selbst Teil des Kriteriums, nicht nur der Laufzeit-Standort. Das ist eine andere Diskussion — eine alternative Deployment-Topologie, bei der jede Komponente bei Anbietern unter europäischer Jurisdiktion liegt. Wir betreiben das nicht standardmäßig; wir richten es für einen Tenant ein, der es benötigt und bei dem der Vertrag den Aufbau rechtfertigt.

Für US-inländische und die meisten APAC-Käufer ist meist das Gegenteil der Fall — sie möchten geringe Latenz aus ihrer Region, was ein anderes Problem ist. Heute fahren wir Single-Region in fra1. Wenn Ihr Traffic eine US-Edge rechtfertigt, planen wir das mit Ihnen.

Worauf dieser Beitrag uns verpflichtet

Das ist das Bild am 28.05.2026. Wir aktualisieren es, wenn sich der Stack ändert — Anbieterwechsel, Regions-Migration, ein neuer externer Dienst. Die aktuelle Konfiguration ist nachprüfbar in unserer offenen vercel.json, der bei OVH Frankreich laufenden mind-sdk-web-Engine und im jeweiligen Dashboard jedes Anbieters.

Wenn hier etwas falsch aussieht oder Ihr DPO eine Antwort benötigt, die diese Übersicht nicht liefert, schreiben Sie uns. Wir korrigieren lieber ein fehlendes Detail, als dass Sie es in einer Vertragsprüfung entdecken.