Waaruit één InterMIND-meeting is opgebouwd

Bijna elk product is opgebouwd uit dezelfde standaardstack — de grote propriëtaire SaaS-standaarden waar iedereen voor kiest. Ze vormen het pad van de minste weerstand. Op elke laag waar uw meeting-gegevens daadwerkelijk leven, hebben wij een andere keuze gemaakt: onze eigen code, of open-source die we zelf konden hosten.

Dit is de begeleidende tekst bij Waar één InterMIND-meeting daadwerkelijk draait, waarin de geografie in kaart werd gebracht — waar elke service wordt uitgevoerd en welke gegevens erdoorheen stromen. Dit bericht beantwoordt wat een beveiligingsteam hierna vraagt: waar is dit ding van gebouwd — en kunnen we het lezen, auditen en vervangen?

Niet waar het draait — waaruit het bestaat, laag voor laag.

De standaardkeuzes, en wat ze kosten

Elk product is een stack keuzes. Voor de meeste producten worden de meeste van die keuzes standaard gemaakt: Google Analytics, Firebase, de Google Translate API, Auth0, React. Ze zijn het pad van de minste weerstand, en voor de meeste teams is dat een redelijke keuze. De afweging is dat elk ervan een deel van uw stack achter een leverancier plaatst die u niet kunt lezen, niet kunt auditen en niet kunt verlaten zonder een herschrijving.

Wij hebben op elke laag waar uw meeting-gegevens daadwerkelijk leven een andere keuze gemaakt: onze eigen code, of open-source software die we zelf konden hosten. Waar een laag de inhoud van uw meeting niet raakt, blijven we pragmatisch en zeggen dat ook. Hier is het volledige plaatje.

De ruggengraat: de engine is onze code, niet die van een derde partij

Begin met de laag die het belangrijkst is, omdat het grootste deel van uw meeting erdoorheen stroomt. Zowel real-time transport als voice/chat-vertaling draaien op mind-sdk + de Mind API — onze eigen engine, op OVH France. De standaardmanier om een vertaalde meeting te bouwen is om een real-time SaaS (LiveKit) vast te koppelen aan een vertaal-API (DeepL, Google); we draaien geen van beide in het live-pad. Er bevindt zich geen vertaalmodel van een derde partij in de loop. (We gebruiken DeepL wel — maar alleen voor documenten die in de chat worden gedeeld, niet voor het live voice/chat-pad; zie de runtime-kaart. We hebben de werking van de pipeline behandeld in Inside the four translation pipelines.)

Hier is het deel dat niet in de runtime-kaart staat: de SDK waarop uw meeting draait is open-source onder de BSD 3-Clause-licentie — de mind-sdk-client is openbaar via gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, onze Estse IP-entiteit. Het communiceert met de Mind API op api.mind.com, die we zelf draaien op OVH France.

Dit is geen "kijken, maar niet aanraken"-broncode-overeenkomst. BSD 3-Clause is een permissieve, door OSI goedgekeurde licentie. Uw beveiligingsteam kan de SDK klonen, precies lezen hoe uw audio en tekst worden vastgelegd, ingekaderd en gestreamd, en die integratie auditen tegen uw eigen vereisten. De server-side engine waarmee het communiceert is van ons — geen black box van een derde partij — en een volledig zelf-hostbare engine voor een tenant die dit nodig heeft, staat op onze roadmap, het is niet iets dat we vandaag aanbieden. We updaten dit bericht zodra het beschikbaar is.

Laag voor laag: de standaard vs. wat wij draaien

Er lopen twee lijnen door die tabel. Open-source waar de tool uw gegevens verwerkt — zodat het auditeerbaar is en in principe zelf te hosten. Open standaarden (Postgres, de S3-API, OIDC) waar we afhankelijk zijn van infrastructuur — zodat niets is vastgeklonken aan de prijzen of compliance-houding van één leverancier. Postgres kan naar elke Postgres-host verhuizen; opslag kan naar elke S3-opslag verhuizen; auth federeren naar de identity provider die u al draait. De laatste rij staat op een derde as: het CRM dat klantrecords vasthoudt, is EU-gevestigd (Pipedrive, Ests) in plaats van een US-salesplatform — niet open-source, maar ook niet onder Amerikaanse jurisdictie.

Een paar hiervan verdienen nog een zin. PostHog is open-source en zelf-hostbaar; we draaien het op de EU-cloud van PostHog en proxyen het first-party via onze eigen origin, zodat de events niet stilletjes worden geblokkeerd door ad-blockers en niet via een analyticsdomeain van een derde partij gaan. Authenticatie gaat nooit naar een auth-SaaS van een derde partij die tussen u en uw sessies zou zitten — we draaien de OIDC-flow zelf en federeren naar uw bestaande Google- of Microsoft-identiteit. En de lettertypen op elke pagina worden geserveerd vanaf ons eigen domein; de enige plek waar Google Fonts in onze codebase opduikt, is in een offline brand-asset-script, nooit in de app die uw gebruikers laden.

Waar we pragmatisch zijn — openlijk gezegd

We doen niet alsof de hele stack met de hand is gebouwd of niet-Amerikaans is. Dat is niet zo, en een bericht dat het tegendeel beweerde, zou worden tegengesproken door onze eigen runtime-kaart.

De leidingen — hosting en SSR (Vercel), de compute van de meeting-server (Fly.io), betalingen (Stripe), transactionele e-mail (Resend) — draaien op in de VS gevestigde SaaS. Stripe en Resend handelen facturering en uitnodigingen af en zien nooit de inhoud van een meeting. Vercel en Fly zijn gehuurde compute: onze eigen code draait erop, en de meeting-server op Fly verwerkt inderdaad de live sessie en het transcript dat onze samenvatting leest — maar dat is onze code op hun machines, niet een vendorproduct dat uw meeting ophaalt. Alles wordt in de EU uitgevoerd in real-time (het onderwerp van de runtime-kaart).

Dat is een bewuste, begrensde afweging: het dataplane in eigen beheer en open-source houden; voor het control plane de best beschikbare SaaS gebruiken. Het benoemen is het punt — "soevereiniteit" betekent weinig als de uitzonderingen niet op tafel liggen naast de successen.

De AI-stappen, en het plan dat is uitgerold

De taalmodelstappen — de AI-samenvatting (onderwerpen, besluiten, actiepunten), documentsamenvattingen, de generatieve acties van de AI-note-editor, Ask AI en Mia — draaien op de AI-gateway die uw organisatie kiest: standaard Azure OpenAI in de EU Data Zone, optioneel Vertex AI op het EU-multi-region endpoint of Amazon Bedrock in Frankfurt, elk in onze eigen tenant met nul gegevensretentie en geen training op klantcontent — of uw eigen OpenAI-compatible endpoint, waardoor het model op infrastructuur blijft die u beheert. De samenvatting na de meeting en de actie vertalen van de editor gaan via de vertaalroute, niet via het taalmodel. Real-time voice, chat, notities en documenten zijn in de eerste plaats nooit in de buurt van een algemeen LLM gekomen.

Dat is de eerlijke vorm van deze laag: de modellen zijn propriëtair, en hun leveranciers zijn Amerikaanse bedrijven die EU-regio's exploiteren — dezelfde afweging als de leidingen hierboven, ernaast vermeld in plaats van verborgen. Wat is uitgerold in plaats van een zelf-gehost model van onszelf is de keuze: een organisatie kan AI volledig uitschakelen (transcriptie en vertaling blijven werken), en het kan elke AI-functie naar zijn eigen endpoint laten wijzen — vLLM in zijn eigen datacentrum, een deployment in zijn eigen tenant — waardoor deze laag op dezelfde open-en-zelf-hostbare as komt te staan als de rest van het dataplane. Onze openbare vertaal-benchmark wordt beoordeeld door een LLM-judge (Gemini, met Claude als fallback) op vaste FLORES-200-referentiezinnen — nooit iemands meeting.

Waarom dit verder reikt dan wijzelf

Dit is geen engineering omwille van engineering. De reden om een stack op deze manier te bouwen, verschijnt aan uw kant van het contract:

1. Auditeerbaar. De SDK waarop uw meeting draait, is open-source code die uw beveiligingsteam kan lezen, en de engine erachter is van ons — geen black box van een derde partij.
2. Overdraagbaar. Open standaarden in elke datalaag — Postgres, S3, OIDC — betekenen geen propriëtaire lock-in. Wat verplaatst kan worden, is niet vastgeklonken aan één leverancier.
3. Zelf-hostbaar. De datalagen met open standaarden — Postgres, S3, OIDC — draaien al op infrastructuur die u beheert; een volledig zelf-hostbare vertaalengine staat op de roadmap voor de tenant die dit nodig heeft.

Dit is het plaatje op 2026-06-07. We werken het bij wanneer de stack verandert — een leveranciersswap, een laag herbouwd, het samenvattingsmodel vervangen. De huidige configuratie is verifieerbaar in onze open vercel.json, onze nuxt.config.ts, en de hierboven gelinkte BSD-3-Clause mind-sdk-repository.

Als een laag hier verkeerd lijkt, of uw beveiligingsbeoordeling een antwoord nodig heeft dat deze kaart niet geeft, schrijf ons. Liever corrigeren we een ontbrekend detail dan dat u het vindt in een code-audit.

Bronnen: de mind-sdk-repository (BSD-3-Clause), FLORES-200; stack-feiten geverifieerd tegen de uitgerolde configuratie (vercel.json, nuxt.config.ts) en de verzonden code, gecontroleerd in augustus 2026.