Woraus ein InterMIND-Meeting besteht

Fast jedes Produkt wird aus demselben Standard-Stack gebaut — den großen proprietären SaaS-Standards, die jeder verwendet. Sie sind der Weg des geringsten Widerstands. Auf jeder Ebene, auf der Ihre Meeting-Daten tatsächlich liegen, haben wir einen anderen gewählt: unseren eigenen Code oder Open-Source, das wir selbst hosten konnten.

Dies ist der Begleitartikel zu Wo ein InterMIND-Meeting tatsächlich läuft, in dem die Geografie kartiert wurde — wo jeder Service ausgeführt wird und welche Daten ihn durchlaufen. Dieser Beitrag beantwortet, was ein Sicherheitsteam als Nächstes fragt: Woraus ist das gebaut — und können wir es lesen, auditieren und ersetzen?

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

Die Standards und ihr Preis

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 vernünftige Entscheidung. Der Kompromiss ist, dass jede Entscheidung einen Teil Ihres Stacks hinter einem Anbieter platziert, den Sie nicht lesen, nicht auditieren und nicht ohne eine Umschreibung verlassen können.

Wir haben auf jeder Ebene, auf der Ihre Meeting-Daten tatsächlich liegen, eine andere Entscheidung getroffen: unser eigener Code oder Open-Source-Software, die wir selbst hosten konnten. Wo eine Ebene den Inhalt Ihres Meetings nicht berührt, bleiben wir pragmatisch und sagen das auch. Hier ist das vollständige Bild.

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

Beginnen wir mit der Ebene, die am wichtigsten ist, da der Großteil Ihres Meetings darüber abläuft. 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 zu erstellen, besteht darin, eine Echtzeit-SaaS (LiveKit) an eine Übersetzungs-API (DeepL, Google) anzubinden; wir betreiben keine der beiden im Live-Pfad. Kein Übersetzungsmodell eines Drittanbieters ist in die Schleife eingebunden. (Wir nutzen DeepL — aber nur für Dokumente, die in den Chat eingestellt werden, nicht für den Live-Sprach-/Chat-Pfad; siehe die Laufzeit-Karte. Die Pipeline-Mechanik haben wir in Innerhalb der vier Übersetzungs-Pipelines behandelt.)

Hier ist der Teil, der nicht in der Laufzeit-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 kommuniziert mit der Mind API unter api.mind.com, die wir selbst auf OVH France betreiben.

Das ist keine „Ansehen, aber nicht anfassen“-Source-Available-Vereinbarung. BSD 3-Clause ist eine freizügige, von der OSI genehmigte Lizenz. Ihr Sicherheitsteam kann das SDK klonen, genau nachlesen, wie Ihre Audio- und Textdaten erfasst, verpackt und gestreamt werden, und diese Integration anhand Ihrer eigenen Anforderungen auditieren. Die serverseitige Engine, mit der es spricht, ist unsere — keine Blackbox eines Drittanbieters — und eine vollständig selbst hostbare Engine für einen Mandanten, der dies benötigt, steht auf unserer Roadmap, ist aber heute nicht etwas, das wir anbieten. Wir werden diesen Beitrag aktualisieren, sobald es ausgeliefert wird.

Schicht für Schicht: Der Standard vs. was wir betreiben

Zwei Fäden ziehen sich durch diese Tabelle. Open-Source, wo das Tool Ihre Daten verarbeitet — damit es auditierbar und im Prinzip selbst hostbar ist. Offene Standards (Postgres, die S3-API, OIDC), wo wir von Infrastruktur abhängen — damit nichts an die Preisgestaltung oder Compliance-Haltung eines einzelnen Anbieters gebunden ist. Postgres kann zu jedem Postgres-Host wechseln; Speicher kann zu jedem S3-Speicher wechseln; Auth föderiert zu dem Identity Provider, den Sie bereits betreiben. Die letzte Zeile steht auf einer dritten Achse: Das CRM, das Kundendaten hält, ist EU-ansässig (Pipedrive, estnisch) statt einer US-Sales-Plattform — nicht Open-Source, aber auch nicht der US-Gerichtsbarkeit unterworfen.

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

Wo wir pragmatisch sind — offen gesagt

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

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

Das ist ein bewusster, begrenzter Kompromiss: Die Datenebene besitzen wir und ist Open-Source; für die Kontrollebene nutzen wir die beste verfügbare SaaS. Es zu benennen ist der Punkt — „Souveränität“ bedeutet wenig, wenn die Ausnahmen nicht neben den Erfolgen auf dem Tisch liegen.

Die KI-Schritte und der Plan, der ausgeliefert wurde

Die Sprachmodell-Schritte — der AI-Digest (Themen, Entscheidungen, Action Items), Dokument-Summarys, die generativen Aktionen des AI-Note-Editors, Ask AI und Mia — laufen auf dem AI-Gateway, das Ihre Organisation auswählt: standardmäßig Azure OpenAI in der EU Data Zone, wahlweise Vertex AI auf dem EU-Multi-Region-Endpoint oder Amazon Bedrock in Frankfurt, jeweils in unserem eigenen Mandanten mit null Datenaufbewahrung und keinem Training mit Kundeninhalten — oder Ihr eigener OpenAI-kompatibler Endpoint, der das Modell auf Infrastruktur hält, die Sie kontrollieren. Die Post-Meeting-Zusammenfassung und die Übersetzungs-Aktion des Editors laufen über den Übersetzungs-Tract, nicht über das Sprachmodell. Echtzeit-Sprache, Chat, Notizen und Dokumente kamen von vornherein nie in die Nähe eines allgemeinen LLM.

Das ist die ehrliche Form dieser Ebene: Die Modelle sind proprietär, und ihre Anbieter sind US-Unternehmen, die EU-Regionen betreiben — derselbe Kompromiss wie bei der Infrastruktur oben, daneben benannt statt versteckt. Was statt eines selbst gehosteten Modells von uns ausgeliefert wurde, ist die Wahl: Eine Organisation kann KI vollständig deaktivieren (Transkription und Übersetzung funktionieren weiterhin), und sie kann jede KI-Funktion auf ihren eigenen Endpoint richten — vLLM im eigenen Data Centre, ein Deployment im eigenen Mandanten — was diese Ebene auf dieselbe offene-und-selbst-hostbare Achse wie der Rest der Datenebene stellt. Unser öffentlicher Übersetzungs-Benchmark wird von einem LLM-Judge (Gemini, mit Claude als Fallback) anhand fester FLORES-200-Referenzsätze bewertet — niemals an einem Meeting irgendjemandes.

Warum dies über uns hinaus wichtig ist

Das ist kein Selbstzweck-Engineering. Der Grund, einen Stack so zu bauen, 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 ist unsere eigene — keine Blackbox eines Drittanbieters.
2. Portierbar. Offene Standards auf jeder Datenschicht — Postgres, S3, OIDC — bedeuten keinen proprietären Lock-in. Was verschoben werden kann, 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.

Dies ist der Stand am 2026-06-07. Wir werden es aktualisieren, wenn sich der Stack ändert — ein Anbieterwechsel, eine neu aufgebaute Ebene, das ausgetauschte Digest-Modell. Die aktuelle Konfiguration ist in unserer offenen vercel.json, unserer nuxt.config.ts und dem oben verlinkten BSD-3-Clause-mind-sdk-Repository nachprüfbar.

Wenn eine Ebene hier falsch aussieht oder Ihr Security-Review eine Antwort benötigt, die diese Karte nicht liefert, 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 anhand der eingesetzten Konfiguration (vercel.json, nuxt.config.ts) und des ausgelieferten Codes, geprüft im August 2026.