Wo ein InterMIND-Meeting tatsächlich läuft

Jedes ernsthafte Beschaffungsgespräch im Unternehmensumfeld führt irgendwann zur selben Frage: „Wohin gehen diese Daten?" Der Datenschutzbeauftragte will eine Liste der Unterauftragsverarbeiter. Der CIO will wissen, welche Anbieter in den USA ansässig sind. Die Rechtsabteilung will ein Diagramm mit Pfeilen.

Wir möchten Ihnen lieber das vollständige Bild geben, als es Stück für Stück per E-Mail nachzureichen. Hier also der Datenpfad eines Meetings — jeder externe Dienst, den es berührt, wo er ausgeführt wird und welche Daten durch ihn fließen. Verifiziert anhand der tatsächlichen Deployment-Konfiguration am 28.05.2026.

Jeder Pfad, der Meeting-Inhalte berührt, läuft zur Laufzeit in der EU — einschließlich der Nach-Meeting-KI-Schritte, die wir früher als die einzige Lücke gekennzeichnet hatten und die wir seitdem auf EU-Auftragsverarbeiter verlagert haben. Wir sagen klar, wo das eine verbleibende US-Modell sitzt — und warum es Ihr Meeting nie zu sehen bekommt.

Dieser Beitrag zeigt, wo Ihr Meeting läuft. Der Begleitartikel Woraus ein InterMIND-Meeting gebaut ist zeigt, woraus es gebaut ist — welche Schichten unser eigener Code sind, welche Open Source sind und wo wir pragmatisch auf proprietäre SaaS-Komponenten setzen.

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

In Souveränitätsdebatten werden zwei Dinge vermischt, die nicht dasselbe sind:

1. Laufzeit / Datenpfad. Wo die Bytes Ihres Meetings während der Anfrage physisch verarbeitet werden. Darum geht es bei Datenresidenz-Vorschriften und den meisten Auftragsverarbeitungsverträgen.
2. Konzernsitz des Anbieters. Wo der SaaS-Anbieter rechtlich firmiert. Darum geht es in CLOUD-Act-Diskussionen — die theoretische Reichweite einer US-Anordnung gegenüber der Muttergesellschaft des Anbieters, unabhängig davon, wo der Workload läuft.

Fast jede „Ist das EU?"-Frage zielt eigentlich auf eines dieser beiden Themen, nur unpräzise formuliert. Wir beantworten beide für jeden Anbieter unten getrennt.

Der Datenpfad eines Meetings

Verfolgen Sie einen Anruf vom Beitritt bis zur Follow-up-E-Mail:

1. Der Browser öffnet die Meeting-Seite. SSR läuft auf Vercel, fest gebunden an fra1 (Frankfurt). Alle Request-/Response-Daten — Session-Cookies, API-Payloads, serverseitig gerendertes 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 Sprechers. Lokal. Verlässt das Gerät nicht, bis das resultierende Transkript zur Übersetzung gesendet wird. (Warum, haben wir in Inside the four translation pipelines erläutert.)
4. Sprach- und Chat-Übersetzung laufen auf unserer eigenen Engine bei OVH France. Das ist mind-sdk + die Mind API — unser Code, unsere Hosts, in Frankreich. Kein Drittanbietermodell ist beteiligt. Sub-Sekunden-Budget, WebSocket-Pool pro Sprache, EU-resident an jedem Hop.
5. Ein in den Chat eingebrachtes Dokument (PDF, DOCX, PPTX, XLSX) geht serverseitig vom Paris-WS-Server an DeepL in Köln. Deutsches Unternehmen, deutsche Verarbeitung. Sprach- und Chat-Übersetzung 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 Speicher auf Fly. Edge-repliziert; das Bucket lässt sich für Mandanten, die es enger fixiert brauchen, auf Multi-Region-EU konfigurieren.
8. Fehler- und Performance-Traces gehen an Sentrys EU-Instanz (de.sentry.io). Die US-Organisation wurde im Mai stillgelegt.
9. Produktanalysen gehen an PostHog EU (eu.i.posthog.com).
10. Transaktionale E-Mails (Magic Links, Einladungen, Belege) gehen über Resend aus eu-west-1 (Irland) hinaus.

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, nicht der eines Dritten. Das Client-SDK, auf dem sie läuft, ist Open Source (BSD-3-Clause) und heute schon auditierbar; das Self-Hosting der Engine selbst steht für einen Kunden, der es braucht, auf der Roadmap.

Die Anbieterübersicht

Die beiden volumenstärksten Datenflüsse — Sprach-/Chat-Übersetzung über unsere eigene Engine bei OVH und Dokumentenübersetzung über DeepL — kommen zufällig auch von den beiden Anbietern, deren Muttergesellschaft in der EU sitzt. Damit ist der Großteil der Meeting-Inhalte abgedeckt. Die vollständige Liste der Unterauftragsverarbeiter mit Angaben zum Konzernsitz wird wie üblich Bestandteil des Auftragsverarbeitungsvertrags; die Tabelle oben ist die Laufzeitsicht — und darum geht es bei den meisten Datenresidenz-Klauseln.

Die Nach-Meeting-KI-Schritte, klar benannt

Nach Ende des Gesprächs führen wir einige Sprachmodell-Schritte auf dem Gesagten aus: das KI-Digest (Themen, Entscheidungen, Aktionspunkte, offene Fragen), die Nach-Meeting-Zusammenfassung und den KI-Notizeditor (eine Notiz übersetzen oder korrigieren / erweitern / vereinfachen). Das sind die einzigen Stellen, an denen ein Allzweckmodell Meeting-bezogene Inhalte berührt — und sie alle laufen jetzt auf EU-Auftragsverarbeitern:

• Das Digest läuft auf EU-gehostetem Mistral (mistral-large-3, mistral-medium-3.5 als Fallback), erreicht über Vercels AI Gateway, fest auf den Mistral-Provider gebunden mit Zero Data Retention — die Anfrage schlägt fehl, statt auf einen Nicht-ZDR- oder US-Host zurückzufallen.
• Die Zusammenfassung und die Übersetzen-Aktion des Editors laufen über unsere eigene EU-Engine bei OVH — dieselbe, die auch Live-Sprache und Chat übersetzt — sodass die Zusammenfassung die Datenebene, in der das Meeting bereits stattfand, nie verlässt.
• Die generativen Aktionen des Editors (Korrigieren, Erweitern, Kürzen, Vereinfachen, Zusammenfassen) lassen sich nicht auf einer Übersetzungs-Engine ausführen, daher nutzen sie denselben EU-Mistral- + Zero-Data-Retention-Pfad wie das Digest.

Echtzeit-Sprache, Echtzeit-Chat, Notizen und Dokumentenübersetzung laufen nie über einen dieser Pfade — sie waren von Anfang an EU-resident.

Die einzige Stelle, an der ein in den USA ansässiges Modell noch im Spiel ist, berührt keine Meeting-Daten: Unser öffentlicher Übersetzungsqualitäts-Benchmark nutzt ein Frontier-Modell als automatisierten Richter, der maschinelle Übersetzungen von FLORES-200-Referenzsätzen bewertet. Das ist ein fester, öffentlicher Datensatz — niemandes Meeting.

Bei den EU-Mistral-Schritten gehen wir noch weiter: ein geplantes vom Eigentümer steuerbares Opt-out, um das Digest komplett zu deaktivieren, und ein selbst gehostetes Open-Weights-Modell (Kimi-Klasse) auf OVH, das den externen Mistral für Zusammenfassungsaufgaben ersetzt, die keinen Frontier-Reasoner benötigen. Beides steht auf der Roadmap, ist aber noch nicht ausgeliefert; wir aktualisieren diesen Beitrag, sobald sie verfügbar sind.

Was das für Ihren Auftragsverarbeitungsvertrag bedeutet

Für die meisten EU-Käufer — deutscher Mittelstand, regulierte Branchen mit Standard-DSGVO-AVVs — beantwortet das obige Bild die Datenresidenz-Frage direkt: Jeder Laufzeit-Hop, den Ihr Meeting nimmt, liegt in der EU. Der Konzernsitz der Anbieter wird wie üblich in der Liste der Unterauftragsverarbeiter offengelegt; nichts Überraschendes dabei. Die Residenzübersicht ist ein Baustein; für die übrigen datenschutzrechtlichen Pflichten — Löschung, Aufbewahrung, Portabilität, Einwilligung — haben wir die Codebasis einem vollständigen Audit unterzogen und jeden Punkt am Code geschlossen.

Für französische souveraineté numérique und Beschaffung auf SecNumCloud-Niveau ist der Konzernsitz des Anbieters selbst Teil des Kriteriums, nicht nur der Laufzeitstandort. Das ist eine andere Diskussion — eine alternative Deployment-Topologie, die jede Komponente bei Anbietern unter europäischer Jurisdiktion hält. Wir betreiben das nicht standardmäßig; wir richten es für einen Mandanten ein, der es braucht und bei dem der Vertrag den Aufwand rechtfertigt.

Für US-Inlands- und die meisten APAC-Käufer gilt meist das Umgekehrte — sie wollen niedrige Latenz aus ihrer Region, was ein anderes Problem ist. Heute betreiben wir Single-Region in fra1. Wenn Ihr Traffic einen US-Edge rechtfertigt, planen wir das mit Ihnen.

Worauf uns dieser Beitrag festlegt

Dies ist der Stand am 28.05.2026. Wir aktualisieren ihn, wenn sich der Stack ändert — Anbieterwechsel, Regionsmigration, ein neuer externer Dienst. Die aktuelle Konfiguration ist nachprüfbar in unserer offenen vercel.json, der mind-sdk + Mind API Engine bei OVH France und im jeweils eigenen Dashboard jedes Anbieters.

Falls etwas hier falsch aussieht oder Ihr Datenschutzbeauftragter eine Antwort braucht, die diese Übersicht nicht gibt, schreiben Sie uns. Wir korrigieren lieber ein fehlendes Detail, als dass Sie es bei einer Vertragsprüfung entdecken.