Woraus ein InterMIND-Meeting gebaut ist

Fast jedes Produkt wird aus demselben Standard-Stack gebaut: den großen proprietären SaaS-Defaults, zu denen alle greifen. Das ist der reibungslose Weg. In 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 könnten.

Dieser Beitrag ergänzt Wo ein InterMIND-Meeting tatsächlich läuft. Dort ging es um die Geografie: wo jeder Dienst ausgeführt wird und welche Daten ihn durchlaufen. Hier beantworten wir, was ein Security-Team als Nächstes fragt: Woraus besteht das Ganze – und können wir es lesen, auditieren und ersetzen?

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

Die Standardwahl – und was sie kostet

Jedes Produkt ist ein Stapel von Entscheidungen. Bei den meisten Produkten fallen die meisten dieser Entscheidungen per Default: Google Analytics, Firebase, die Google Translate API, Auth0, React. Das ist der reibungslose Weg, und für die meisten Teams ist das eine vernünftige Wahl. Der Preis dafür: Jede dieser Entscheidungen stellt einen Teil Ihres Stacks hinter einen Anbieter, den Sie nicht lesen, nicht auditieren und ohne Neuentwicklung nicht verlassen können.

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

Das Rückgrat: Die Engine ist unser Code, nicht der eines Dritten

Beginnen wir mit der wichtigsten Schicht, denn durch sie fließt der größte Teil Ihres Meetings. Echtzeit-Transport und die Übersetzung von Sprache und Chat laufen beide über mind-sdk + die Mind API – unsere eigene Engine, bei OVH France. Üblicherweise baut man ein übersetztes Meeting, indem man ein Echtzeit-SaaS (LiveKit) mit einer Übersetzungs-API (DeepL, Google) verbindet; wir betreiben im Live-Pfad keines von beiden. Kein Übersetzungsmodell eines Dritten ist beteiligt. (DeepL setzen wir durchaus ein, aber nur für Dokumente, die in den Chat gelegt werden, nicht im Live-Pfad für Sprache und Chat; siehe die Runtime-Map. Die Mechanik der Pipelines haben wir in Einblick in die vier Übersetzungspipelines beschrieben.)

Was in der Runtime-Map nicht 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 verfügbar, Copyright MindMeeting OÜ, unsere estnische IP-Gesellschaft. Er spricht mit der Mind API unter api.mind.com, die wir selbst bei OVH France betreiben.

Das ist keine „Ansehen erlaubt, Anfassen verboten“-Konstruktion im Sinne von Source-available. BSD 3-Clause ist eine permissive, von der OSI anerkannte Lizenz. Ihr Security-Team kann das SDK klonen, genau nachlesen, wie Ihr Audio und Ihr Text erfasst, gerahmt und gestreamt werden, und diese Integration gegen Ihre eigenen Anforderungen auditieren. Die serverseitige Engine, mit der es spricht, gehört uns – sie ist keine Blackbox eines Dritten. Eine vollständig selbst hostbare Engine für Mandanten, die sie brauchen, steht auf unserer Roadmap, ist heute aber nicht Teil unseres Angebots. Wir aktualisieren diesen Beitrag, sobald sie verfügbar ist.

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

Zwei Linien ziehen sich durch diese Tabelle. Open Source, wo das Tool Ihre Daten verarbeitet – damit es sich auditieren und im Prinzip selbst hosten lässt. Offene Standards (Postgres, die S3-API, OIDC), wo wir von Infrastruktur abhängen – damit nichts an die Preise oder die Compliance-Haltung eines einzelnen Anbieters gebunden ist. Postgres lässt sich auf jeden Postgres-Host verlagern, der Speicher in jeden S3-Speicher, und die Authentifizierung föderiert mit dem Identity-Provider, den Sie ohnehin betreiben. Die letzte Zeile liegt auf einer dritten Achse: Das CRM mit den Kundendaten hat seinen Sitz in der EU (Pipedrive, estnisch) statt in einer US-Vertriebsplattform – nicht Open Source, aber auch nicht unter US-Jurisdiktion.

Einige davon verdienen einen Satz mehr. PostHog ist Open Source und selbst hostbar; wir betreiben es in der EU-Cloud von PostHog und proxyen es als First-Party über unseren eigenen Origin, sodass die Events nicht stillschweigend von Ad-Blockern verworfen werden und keine Analyse-Domain eines Dritten durchlaufen. Die Authentifizierung geht nie an ein Auth-SaaS eines Dritten, das sich zwischen Sie und Ihre Sessions schieben würde – wir betreiben den OIDC-Flow selbst und föderieren mit Ihrer bestehenden Google- oder Microsoft-Identität. Und die Schriftarten auf jeder Seite kommen von unserer eigenen Domain; Google Fonts taucht in unserer Codebasis nur in einem Offline-Skript für Marken-Assets auf, nie in der App, die Ihre Nutzer laden.

Wo wir pragmatisch sind – offen gesagt

Wir tun nicht so, als wäre der gesamte Stack in Handarbeit gebaut oder frei von US-Anbietern. Das ist er nicht, und ein Beitrag, der etwas anderes behauptete, würde von unserer eigenen Runtime-Map widerlegt.

Der Unterbau – Hosting und SSR (Vercel), die Rechenleistung des Meeting-Servers (Fly.io), Zahlungen (Stripe), transaktionale E-Mails (Resend) – läuft auf SaaS mit Sitz in den USA. Stripe und Resend verarbeiten Abrechnung und Einladungen und sehen nie Meeting-Inhalte. Vercel und Fly sind gemietete Rechenleistung: Unser eigener Code läuft darauf, und der Meeting-Server auf Fly verarbeitet zwar die Live-Sitzung und das Transkript, das unser Digest liest – aber das ist unser Code auf deren Maschinen, kein Anbieterprodukt, das Ihr Meeting aufnimmt. Alles wird zur Laufzeit in der EU ausgeführt (das Thema von der Runtime-Map).

Das ist ein bewusster, klar begrenzter Kompromiss: Datenebene selbst betreiben und auf Open Source setzen, für die Steuerungsebene das beste verfügbare SaaS nutzen. Genau das zu benennen ist der Punkt – „Datenhoheit“ bedeutet wenig, wenn die Ausnahmen nicht neben den Stärken auf dem Tisch liegen.

Die KI-Schritte – und das, was tatsächlich ausgeliefert wurde

Die Schritte mit Sprachmodellen – der KI-Digest (Themen, Entscheidungen, Action items), Dokumentzusammenfassungen, die generativen Aktionen des KI-Notiz-Editors, Ask AI und Mia – laufen auf dem AI-Gateway, das Ihre Organisation auswählt: standardmäßig Azure OpenAI in der EU Data Zone, nach Wahl Vertex AI auf dem EU-Multi-Region-Endpunkt oder Amazon Bedrock in Frankfurt, jeweils in unserem eigenen Tenant mit Zero Data Retention und ohne Training auf Kundeninhalten – oder Ihr eigener OpenAI-kompatibler Endpunkt, der das Modell auf einer Infrastruktur hält, die Sie kontrollieren. Die Zusammenfassung nach dem Meeting und die Übersetzen-Aktion des Editors laufen über den Übersetzungspfad, nicht über das Sprachmodell. Echtzeit-Sprache, Chat, Notizen und Dokumente kamen von vornherein nie mit einem Allzweck-LLM in Berührung.

So sieht diese Schicht ehrlich aus: Die Modelle sind proprietär, und ihre Anbieter sind US-Unternehmen, die EU-Regionen betreiben – derselbe Kompromiss wie beim Unterbau oben, hier daneben benannt statt versteckt. Statt eines selbst gehosteten eigenen Modells haben wir die Wahlfreiheit ausgeliefert: Eine Organisation kann KI komplett abschalten (Transkription und Übersetzung funktionieren weiter), und sie kann jede KI-Funktion auf ihren eigenen Endpunkt richten – vLLM im eigenen Rechenzentrum, eine Bereitstellung im eigenen Tenant –, womit diese Schicht auf derselben Achse aus Offenheit und Selbst-Hosting liegt wie der Rest der Datenebene. Unser öffentlicher Übersetzungs-Benchmark wird von einem LLM-Judge (Gemini, mit Claude als Fallback) auf festen FLORES-200-Referenzsätzen bewertet – nie auf dem Meeting von irgendjemandem.

Warum das über uns hinaus zählt

Das ist keine Technik um ihrer selbst willen. 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 Security-Team lesen kann, und die Engine dahinter ist unsere eigene – keine Blackbox eines Dritten.
2. Portabel. Offene Standards in jeder Datenschicht – Postgres, S3, OIDC – bedeuten kein proprietäres Lock-in. Was sich verlagern lässt, hängt nicht an einem einzelnen Anbieter.
3. Selbst hostbar. Die Datenschichten auf offenen Standards – Postgres, S3, OIDC – laufen schon heute auf Infrastruktur, die Sie kontrollieren; eine vollständig selbst gehostete Übersetzungs-Engine steht für Mandanten, die sie brauchen, auf der Roadmap.

Das ist der Stand zum 2026-06-07. Wir aktualisieren ihn, wenn sich der Stack ändert – bei einem Anbieterwechsel, einer neu gebauten Schicht oder einem ersetzten Digest-Modell. Die aktuelle Konfiguration ist nachprüfbar in unserer offenen vercel.json, unserer nuxt.config.ts und im oben verlinkten BSD-3-Clause-Repository mind-sdk.

Wenn eine Schicht hier falsch aussieht oder Ihr Security-Review eine Antwort braucht, 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 abgeglichen mit der ausgelieferten Konfiguration (vercel.json, nuxt.config.ts) und dem produktiven Code, Stand: August 2026.