Woraus ein InterMIND-Meeting besteht

Nahezu jedes Produkt wird aus demselben Standard-Stack aufgebaut — den großen proprietären SaaS-Defaults, nach denen alle greifen. Sie sind der Weg des geringsten Widerstands. An jeder Schicht, in der Ihre Meeting-Daten tatsächlich liegen, haben wir einen anderen gewählt: unseren eigenen Code oder Open-Source, die wir selbst hosten konnten.

Dies ist die Ergänzung zu Wo ein InterMIND-Meeting tatsächlich läuft, die die Geografie kartiert hat — wo jeder Dienst ausgeführt wird und welche Daten ihn durchlaufen. Dieser Beitrag beantwortet, was ein Sicherheitsteam als Nächstes fragt: Woraus ist dieses Ding aufgebaut — und können wir es lesen, auditieren und ersetzen?

Nicht wo es läuft — woraus es besteht, Schicht für Schicht.

Die Defaults — und was sie kosten

Jedes Produkt ist ein Stack aus Entscheidungen. Bei den meisten Produkten werden die meisten dieser Entscheidungen standardmäßig getroffen: Google Analytics, Firebase, die Google Translate API, Auth0, React. Sie sind der Weg des geringsten Widerstands, und für die meisten Teams ist das eine vertretbare Entscheidung. Der Trade-off ist, dass jede davon einen Teil Ihres Stacks hinter einen Anbieter stellt, den Sie nicht lesen, nicht auditieren und nicht ohne einen Rewrite verlassen können.

An jeder Schicht, in der Ihre Meeting-Daten tatsächlich liegen, haben wir uns anders entschieden: unser eigener Code oder Open-Source-Software, die wir selbst hosten konnten. Wo eine Schicht den Inhalt Ihres Meetings nicht berührt, bleiben wir pragmatisch und sagen das auch. Hier ist das gesamte Bild.

Das Rückgrat: Die Engine ist unser Code, nicht die eines Drittanbieters

Beginnen wir mit der Schicht, die am meisten zählt, weil der Großteil Ihres Meetings durch sie fließt. Echtzeit-Transport und Sprach-/Chat-Übersetzung laufen beide auf mind-sdk + der Mind API — unserer eigenen Engine, auf OVH France. Der Standardweg, ein übersetztes Meeting aufzubauen, besteht darin, eine Echtzeit-SaaS (LiveKit) an eine Übersetzungs-API (DeepL, Google) anzubinden; wir betreiben keine von beiden im Live-Pfad. Kein Drittanbieter-Übersetzungsmodell ist im Spiel. (Wir nutzen DeepL — aber nur für Dokumente, die in den Chat eingebracht werden, nicht im Live-Sprach-/Chat-Pfad; siehe die Laufzeitumgebungs-Karte. Die Pipeline-Mechanik haben wir in Innerhalb der vier Übersetzungs-Pipelines behandelt.)

Hier der Teil, der nicht in der Laufzeitumgebungs-Karte steht: Das SDK, auf dem Ihr Meeting läuft, ist Open Source unter der BSD-3-Clause-Lizenz — der mind-sdk-Client ist öffentlich unter gitlab.com/mindlabs/api/sdk, Copyright MindMeeting OÜ, unserer estnischen IP-Einheit. Er spricht mit der Mind API unter api.mind.com, die wir selbst auf OVH France betreiben.

Das ist keine "anschauen, aber nicht anfassen"-Source-Available-Regelung. BSD 3-Clause ist eine permissive, von der OSI genehmigte Lizenz. Ihr Sicherheitsteam kann das SDK klonen, exakt nachvollziehen, wie Ihre Audio- und Textdaten erfasst, framet und gestreamt werden, und diese Integration gegen Ihre eigenen Anforderungen auditieren. Die serverseitige Engine, mit der es spricht, gehört uns — keine Blackbox eines Drittanbieters — und eine vollständig selbst hostbare Engine für einen Mandanten, der sie benötigt, steht auf unserer Roadmap, ist aber heute noch nicht Bestandteil unseres Angebots. Wir werden diesen Beitrag in dem Moment aktualisieren, in dem sie ausgeliefert wird.

Schicht für Schicht: Der Default vs. das, was wir betreiben

Zwei Linien ziehen sich durch diese Tabelle. Open-Source dort, wo das Werkzeug Ihre Daten verarbeitet — damit es auditierbar und grundsätzlich selbst hostbar ist. Offene Standards (Postgres, die S3-API, OIDC) dort, wo wir auf Infrastruktur angewiesen sind — damit nichts an die Preisgestaltung oder Compliance-Position eines einzelnen Anbieters gebunden ist. Postgres kann zu jedem Postgres-Host umziehen; Storage kann zu jedem S3-Store umziehen; Auth föderiert zum Identity Provider, den Sie bereits betreiben. Die letzte Zeile steht auf einer dritten Achse: Das CRM, das Kundendatensätze hält, ist in der EU ansässig (Pipedrive, estnisch) statt auf einer US-Vertriebsplattform — nicht Open-Source, aber auch nicht unter US-Jurisdiktion.

Ein paar davon verdienen einen Satz mehr. PostHog ist Open-Source und selbst hostbar; wir betreiben es auf PostHogs EU-Cloud und proxien es als First-Party über unseren eigenen Origin, sodass die Events nicht still von Ad-Blockern verworfen werden und nicht eine Drittanbieter-Analytics-Domain durchlaufen. Authentifizierung geht nie an eine Drittanbieter-Auth-SaaS, die zwischen Ihnen und Ihren Sessions stünde — wir betreiben den OIDC-Flow selbst und föderieren zu Ihrer bestehenden Google- oder Microsoft-Identity. Und die Schriften auf jeder Seite werden von unserer eigenen Domain ausgeliefert; der einzige Ort, an dem Google Fonts in unserer Codebasis auftaucht, ist ein Offline-Brand-Asset-Skript, nie die Applikation, die Ihre Nutzer laden.

Wo wir pragmatisch sind — offen gesagt

Wir tun nicht so, als sei der gesamte Stack handgestrickt oder non-US. Das ist er nicht, und ein Beitrag, der das behaupten würde, würde durch unsere eigene Laufzeitumgebungs-Karte widerlegt.

Die Infrastruktur — Hosting und SSR (Vercel), die Compute des Meeting-Servers (Fly.io), Zahlungen (Stripe), transaktionale E-Mails (Resend) — läuft auf SaaS mit Sitz in den USA. Stripe und Resend kümmern sich um Billing und Einladungen und sehen niemals Meeting-Inhalte. Vercel und Fly sind gemietete Compute: Unser eigener Code läuft darauf, und der Meeting-Server auf Fly behandelt tatsächlich die Live-Session und das Transkript, das unser Digest liest — aber das ist unser Code auf ihren Maschinen, kein Drittanbieter-Produkt, das Ihr Meeting ingestiert. All das wird zur Laufzeit in der EU ausgeführt (das Thema von der Laufzeitumgebungs-Karte).

Das ist ein bewusster, begrenzter Trade-off: die Data Plane selbst besitzen und als Open-Source halten; für die Control Plane die beste verfügbare SaaS nutzen. Es beim Namen zu nennen ist der Punkt — "Souveränität" bedeutet wenig, wenn die Ausnahmen nicht neben den Erfolgen auf dem Tisch liegen.

Die Post-Meeting-AI-Schritte und der Plan

Kein proprietäres, in den USA ansässiges Modell berührt aus dem Meeting abgeleitete Inhalte. Die Sprachmodell-Schritte, die nach dem Call laufen — der AI Digest (Themen, Entscheidungen, Action Items), die Post-Meeting-Zusammenfassung und der AI-Notiz-Editor — liegen alle auf EU-Prozessoren. Der Digest und die generativen Aktionen des Editors laufen auf EU-gehostetem Mistral mit Zero-Data-Retention (erreicht über Vercels AI Gateway, auf den Mistral-Anbieter gepinnt). Die Zusammenfassung und die Translate-Aktion des Editors laufen auf unserer eigenen EU-Engine auf OVH — derselben, die hinter Live-Sprache und -Chat steht. Echtzeit-Sprache, -Chat, -Notizen und -Dokumente sind von vornherein nie in die Nähe eines General-Purpose-LLM gekommen.

Das einzige US-Modell, das noch im Spiel ist, bewertet unseren öffentlichen Übersetzungs-Benchmark — es scoringt maschinelle Übersetzungen feststehender FLORES-200-Referenzsätze, niemals das Meeting irgendjemandes.

Bei den EU-Mistral-Schritten gehen wir noch weiter: ein eigenkontrolliertes Opt-out, um den Digest vollständig abzuschalten, und ein selbst gehostetes, Open-Weights-Zusammenfassungsmodell auf OVH (Kimi-Klasse), um das externe Mistral zu ersetzen. Der Punkt der Open-Weights-Route ist nicht, wessen Labor die Weights trainiert hat — sondern dass Open Weights auf Infrastruktur laufen können, die wir kontrollieren, was sie auf derselben offenen-und-selbst-hostbaren Achse hält wie der Rest der Data Plane. Beides steht auf der Roadmap, ist noch nicht ausgeliefert; wir werden diesen Beitrag aktualisieren, sobald sie landen.

Warum dies über uns hinaus relevant ist

Das ist keine Technikerei um ihrer selbst willen. Der Grund, einen Stack so aufzubauen, zeigt sich auf Ihrer Seite des Vertrags:

1. Auditierbar. Das SDK, auf dem Ihr Meeting läuft, ist Open-Source-Code, den Ihr Sicherheitsteam lesen kann, und die Engine dahinter gehört uns — keine Blackbox eines Drittanbieters.
2. Portabel. Offene Standards an jeder Datenschicht — Postgres, S3, OIDC — bedeuten keinen proprietären Lock-in. Was sich bewegen lässt, ist nicht an einen einzelnen Anbieter gebunden.
3. Selbst hostbar. Die offenen-Standard-Datenschichten — Postgres, S3, OIDC — laufen bereits auf Infrastruktur, die Sie kontrollieren; eine vollständig selbst hostbare Übersetzungs-Engine steht auf der Roadmap für den Mandanten, der sie benötigt.

Das ist der Stand am 2026-06-07. Wir werden ihn aktualisieren, wenn sich der Stack ändert — ein Vendor-Swap, eine Schicht neu aufgebaut, das Digest-Modell ersetzt. Die aktuelle Konfiguration ist nachprüfbar in unserer offenen vercel.json, unserer nuxt.config.ts und dem oben verlinkten BSD-3-Clause-mind-sdk-Repository.

Wenn eine Schicht hier falsch aussieht oder Ihr Security-Review eine Antwort braucht, die diese Karte nicht gibt, schreiben Sie uns. Wir korrigieren lieber ein fehlendes Detail, als dass Sie es in einem Code-Audit finden.

Quellen: das mind-sdk-Repository (BSD-3-Clause), FLORES-200; Stack-Fakten verifiziert gegen die eingesetzte Konfiguration (vercel.json, nuxt.config.ts) und den ausgelieferten Code, geprüft August 2026.