Wo ein InterMIND-Meeting tatsächlich läuft

Früher oder später fragt jemand auf Seiten des Hosts – die IT eines Kunden, ein Datenschutzbeauftragter, ein vorsichtiger Partner – immer dasselbe: „Wohin gehen diese Daten?" Verlangt werden eine Liste der Unterauftragsverarbeiter, die Firmensitze der Anbieter und ein Diagramm mit Pfeilen.

Wir möchten, dass Sie das vollständige Bild haben, statt es Stück für Stück per E-Mail nachzuliefern. Hier ist also der Datenpfad eines Meetings: jeder externe Dienst, den es berührt, wo er jeweils ausgeführt wird und welche Daten durch ihn fließen. Geprüft anhand der tatsächlichen Deployment-Konfiguration am 2026-05-28.

Jeder Pfad, der Meeting-Inhalte berührt, liegt zur Laufzeit in der EU. Das gilt auch für die KI-Schritte, die auf dem AI-Gateway laufen, das Ihre Organisation auswählt, in einer EU-Region unseres eigenen Tenants. Die Anbieter hinter diesem Gateway sind US-Unternehmen, die EU-Regionen betreiben. Das sagen wir unten offen. Wir sagen auch, welches Modell vollständig außerhalb des Meetings steht.

Dieser Beitrag zeigt, wo Ihr Meeting läuft. Der Begleitartikel Woraus ein InterMIND-Meeting aufgebaut ist zeigt, woraus es aufgebaut ist: welche Schichten unser eigener Code sind, welche Open Source, und wo wir bei proprietärer SaaS pragmatisch sind.

Was „wo es läuft" eigentlich bedeutet

In Gesprächen über Datenhoheit werden zwei Dinge vermengt, die nicht dasselbe sind:

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

Fast jede Frage der Art „Ist das EU?" ist in Wahrheit eine dieser beiden, nur ungenau gestellt. Wir beantworten sie unten für jeden Anbieter 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, festgelegt auf fra1 (Frankfurt). Alle Request- und 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 in der EU.
3. Die Spracherkennung läuft auf unserem Media-Server. Das Audio erreicht per WebRTC unsere eigene Engine – die Mind API bei OVH in Frankreich – und wird dort Wort für Wort erkannt, auf demselben Server, der den Anruf trägt. Ein Spracherkennungsdienst eines Drittanbieters ist nicht beteiligt. Die einzige Ausnahme sind Sprachnachrichten im Chat: Ihre Speech-to-Text-Verarbeitung läuft auf Azure AI Speech, dem Sprachdienst des Standard-AI-Gateways (Anbietertabelle unten). Die Pipeline selbst beschreibt Die vier Übersetzungs-Pipelines im Detail.
4. Sprach- und Chat-Übersetzung laufen über unsere eigene Engine bei OVH in Frankreich. Das sind mind-sdk + die Mind API – unser Code, unsere Hosts, in Frankreich. Kein Modell eines Drittanbieters ist beteiligt. Es gibt eine Übersetzung pro Zielsprache im Raum, an jeder Station innerhalb der EU verarbeitet.
5. Ein im Chat abgelegtes Dokument (PDF, DOCX, DOC, PPTX, XLSX) geht serverseitig vom Pariser 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 und Exporte werden auf Tigris gespeichert, S3-kompatiblem Speicher auf Fly. Edge-repliziert; der Bucket lässt sich für Tenants, die es enger gefasst 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. Produkt-Analytics gehen an PostHog EU (eu.i.posthog.com).
10. Transaktionale E-Mails (Magic Links, Einladungen, Belege) laufen über Resend aus eu-west-1 (Irland).

All das liegt zur Laufzeit in der EU. Die Übersetzungs-Engine, durch die der größte Teil Ihrer Daten fließt, ist ebenfalls unser eigener Code und nicht der eines Drittanbieters. Das Client-SDK, auf dem sie läuft, ist Open Source (BSD-3-Clause) und schon heute auditierbar. Self-Hosting der Engine selbst steht für Kunden, die es brauchen, auf der Roadmap.

Die Anbieterübersicht

Die beiden datenintensivsten Flüsse – Sprach- und Chat-Übersetzung über unsere eigene Engine bei OVH sowie Dokumentübersetzung über DeepL – laufen zugleich über die beiden Anbieter, deren Muttergesellschaft in der EU sitzt. Damit ist der Großteil der Meeting-Inhalte abgedeckt. Die vollständige Liste der Unterauftragsverarbeiter mit Angaben zum Firmensitz gehört wie üblich in den Auftragsverarbeitungsvertrag (DPA). Die Tabelle oben ist die Laufzeitsicht, um die es in den meisten Klauseln zur Datenresidenz geht.

Die KI-Schritte, offen benannt

Nach dem Ende des Anrufs führen wir einige Sprachmodell-Schritte auf dem Gesagten aus: den KI-Digest (Themen, Entscheidungen, Action items, offene Fragen), die Zusammenfassung nach dem Meeting und den KI-Notizeditor (eine Notiz übersetzen oder korrigieren, erweitern, vereinfachen). Während des Anrufs schreibt ein Schritt derselben Art eine Zusammenfassung jedes im Chat abgelegten Dokuments und beantwortet Ask AI und Mia. Nur an diesen Stellen berührt ein Allzweckmodell aus Meetings abgeleitete Inhalte, und alle gehen an denselben Ort:

• Das AI-Gateway, das Ihre Organisation auswählt. Ein einziger Resolver im Code wählt es für jede Aufrufstelle aus; einen zweiten Pfad gibt es nicht. Standard ist Azure OpenAI in der EU Data Zone. In den Einstellungen wechselt eine Organisation zu Vertex AI auf dem EU-Multi-Region-Endpunkt oder Amazon Bedrock in Frankfurt. Sie kann auch jede KI-Funktion auf einen eigenen OpenAI-kompatiblen Endpunkt zeigen lassen – vLLM im eigenen Rechenzentrum oder eine Bereitstellung im eigenen Tenant. Jedes gehostete Gateway läuft in unserem eigenen Tenant, konfiguriert auf Zero Data Retention und ohne Training mit Kundeninhalten. Der Fallback bleibt auf demselben Gateway – eine zweite EU-Region oder ein zweites Modell desselben Anbieters, nie ein anderer Anbieter. Die Dokumentation der KI-Funktionen listet die Gateways und Regionen auf.
• Die Zusammenfassung und die Übersetzen-Aktion des Editors laufen über den Übersetzungspfad, nicht über das Sprachmodell – denselben Pfad, der den Live-Chat übersetzt.
• KI lässt sich für die gesamte Organisation abschalten: Transkription und Übersetzung funktionieren weiter; der Digest, die Dokumentzusammenfassungen, der Schreibassistent und Ask AI stehen dann still.

Echtzeit-Sprache, Echtzeit-Chat, Notizen und Dokumentübersetzung laufen über keinen dieser Schritte – sie waren von Anfang an innerhalb der EU angesiedelt.

Wo die Anbieter sitzen: Microsoft, Google und Amazon sind US-Unternehmen, die EU-Regionen betreiben. Das steht offen auf der Trust-Seite und wird nicht versteckt. Es ist die Frage nach dem Firmensitz vom Anfang dieses Beitrags, für diese Station genauso beantwortet wie für die übrige Infrastruktur. Ein Modell steht vollständig außerhalb des Meetings: Unser öffentlicher Benchmark der Übersetzungsqualität nutzt einen LLM-Judge (Gemini, mit Claude als Fallback, über Vercels AI Gateway), um maschinelle Übersetzungen von Referenzsätzen aus FLORES-200 zu bewerten. Das ist ein feststehender, öffentlicher Datensatz – kein Meeting von irgendjemandem.

Was das für Ihren DPA bedeutet

Für die meisten EU-Käufer – den deutschen Mittelstand, regulierte Branchen mit gängigen DSGVO-konformen DPAs – beantwortet das Bild oben die Frage nach der Datenresidenz direkt: Jede Station, die Ihr Meeting zur Laufzeit durchläuft, liegt in der EU. Der Firmensitz der Anbieter wird wie üblich in der Liste der Unterauftragsverarbeiter offengelegt; daran ist nichts Überraschendes. Die Residenz-Karte ist nur ein Baustein. Für die übrigen Datenschutzpflichten – Löschung, Aufbewahrung, Portabilität, Einwilligung – haben wir die Codebasis einem vollständigen Audit unterzogen und jeden Punkt am Code abgeschlossen.

Für französische souveraineté numérique und Beschaffung nach SecNumCloud-Maßstab ist der Firmensitz des Anbieters selbst Teil des Kriteriums, nicht nur der Laufzeitstandort. Das ist ein anderes Gespräch: eine alternative Deployment-Topologie, die jede Komponente bei Anbietern unter europäischer Jurisdiktion hält. Wir betreiben sie nicht standardmäßig; wir setzen sie für einen Tenant auf, der sie braucht und bei dem der Vertrag den Aufbau rechtfertigt.

Für US-amerikanische und die meisten APAC-Käufer gilt meist das Umgekehrte: Sie wollen geringe Latenz aus ihrer Region, was ein anderes Problem ist. Heute betreiben wir eine einzelne Region in fra1. Wenn Ihr Traffic einen US-Edge rechtfertigt, planen wir ihn gemeinsam mit Ihnen.

Wozu uns dieser Beitrag verpflichtet

Das ist das Bild zum Stand 2026-05-28. Wir aktualisieren es, wenn sich der Stack ändert – bei einem Anbieterwechsel, einer Regionsmigration oder einem neuen externen Dienst. Die aktuelle Konfiguration ist nachprüfbar in unserer offenen vercel.json, in der mind-sdk + Mind-API-Engine bei OVH Frankreich und im Dashboard jedes einzelnen Anbieters.

Wenn Ihnen hier etwas falsch erscheint oder Ihr Datenschutzbeauftragter eine Antwort braucht, die diese Karte nicht liefert, schreiben Sie uns. Wir korrigieren lieber ein fehlendes Detail, als dass Sie es erst in einer Vertragsprüfung entdecken.

Quellen: Laufzeitregionen und Modell-Routing geprüft anhand der ausgerollten Konfiguration (vercel.json, fly.toml) und des ausgelieferten Codes; Vercel AI Gateway (der Provider-Pinning-Pfad des Digests), FLORES-200; Stand: August 2026.