Waaruit één InterMIND-meeting is opgebouwd

Bijna elk product is gebouwd op dezelfde standaardstack: de grote, propriëtaire SaaS-standaarden waar iedereen naar grijpt. Dat is de weg van de minste weerstand. Op elke laag waar je meetingdata werkelijk leeft, hebben we een andere weg gekozen: onze eigen code, of open source die we zelf kunnen hosten.

Dit is het vervolg op Waar één InterMIND-meeting daadwerkelijk draait, dat de geografie in kaart bracht: waar elke dienst wordt uitgevoerd en welke data erdoorheen gaat. Dit bericht beantwoordt wat een securityteam daarna vraagt: waaruit is dit opgebouwd, en kunnen we het lezen, auditen en vervangen?

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

De standaardkeuzes en wat ze kosten

Elk product is een stapel keuzes. Bij de meeste producten worden de meeste van die keuzes standaard gemaakt: Google Analytics, Firebase, de Google Translate API, Auth0, React. Het is de weg van de minste weerstand, en voor de meeste teams is dat een redelijke keuze. De keerzijde is dat elk onderdeel een stuk van je stack onderbrengt bij een leverancier die je niet kunt lezen, niet kunt auditen en niet kunt verlaten zonder alles te herschrijven.

Op elke laag waar je meetingdata werkelijk leeft, maakten we een andere keuze: onze eigen code, of open-sourcesoftware die we zelf kunnen hosten. Waar een laag de inhoud van je meeting niet raakt, blijven we pragmatisch en zeggen we dat ook. Hier is het hele plaatje.

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

We beginnen bij de laag die het zwaarst weegt, want het grootste deel van je meeting stroomt erdoorheen. Realtime transport en de vertaling van spraak en chat draaien allebei op mind-sdk + de Mind API: onze eigen engine, op OVH in Frankrijk. De gebruikelijke manier om een vertaalde meeting te bouwen is een realtime-SaaS (LiveKit) koppelen aan een vertaal-API (DeepL, Google); wij draaien geen van beide in het live pad. Er zit geen vertaalmodel van een derde partij in de keten. (We gebruiken DeepL wel, maar alleen voor documenten die in de chat worden geplaatst, niet voor het live pad van spraak en chat; zie de runtimekaart. De werking van de pijplijnen behandelden we in Binnenin de vier vertaalpijplijnen.)

Dit is het deel dat niet op de runtimekaart staat: de SDK waarop je meeting draait is open source onder de BSD 3-Clause-licentie. De mind-sdk-client is openbaar op gitlab.com/mindlabs/api/sdk, met copyright van MindMeeting OÜ, onze Estse IP-entiteit. Hij praat met de Mind API op api.mind.com, die we zelf draaien op OVH in Frankrijk.

Dit is geen "kijken mag, aanraken niet"-regeling met alleen zichtbare broncode. BSD 3-Clause is een permissieve, door OSI goedgekeurde licentie. Je securityteam kan de SDK klonen, precies nalezen hoe je audio en tekst worden vastgelegd, in frames verdeeld en gestreamd, en die integratie toetsen aan je eigen eisen. De serverengine waarmee de SDK praat is de onze, geen black box van een derde partij. Een volledig zelf te hosten engine voor een tenant die dat nodig heeft staat op onze roadmap en is nu nog niet beschikbaar. We werken dit bericht bij zodra het zover is.

Laag voor laag: de standaard versus wat wij draaien

Twee lijnen lopen door die tabel. Open source waar de tool jouw data verwerkt, zodat die kan worden geaudit en in principe zelf gehost. Open standaarden (Postgres, de S3-API, OIDC) waar we op infrastructuur leunen, zodat niets vastzit aan de prijzen of het compliancebeleid van één leverancier. Postgres kan naar elke Postgres-host verhuizen, opslag naar elke S3-opslag, en authenticatie federeert met de identiteitsprovider die je al draait. De laatste rij zit op een derde as: het CRM met klantgegevens is in de EU gevestigd (Pipedrive, Ests) in plaats van een Amerikaans salesplatform. Het is geen open source, maar valt ook niet onder Amerikaanse jurisdictie.

Een paar hiervan verdienen een zin extra. PostHog is open source en zelf te hosten; wij draaien het op de EU-cloud van PostHog en proxyen het first-party via onze eigen origin, zodat events niet ongemerkt door adblockers worden weggefilterd en niet via een analysedomein van een derde partij lopen. Authenticatie gaat nooit naar een externe auth-SaaS die tussen jou en je sessies zou zitten: we draaien de OIDC-flow zelf en federeren met je 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 voorkomt is een offline script voor merkmateriaal, nooit de app die je gebruikers laden.

Waar we pragmatisch zijn: hardop gezegd

We doen niet alsof de hele stack zelfgebouwd is of niet-Amerikaans. Dat is hij niet, en een bericht dat anders beweerde zou door onze eigen runtimekaart worden weersproken.

De infrastructuur eromheen — hosting en SSR (Vercel), de rekenkracht van de meetingserver (Fly.io), betalingen (Stripe), transactionele e-mail (Resend) — draait op SaaS van Amerikaanse bedrijven. Stripe en Resend verwerken facturatie en uitnodigingen en zien nooit meetinginhoud. Vercel en Fly zijn gehuurde rekenkracht: onze eigen code draait erop, en de meetingserver op Fly verwerkt wel de live sessie en het transcript dat onze digest leest, maar dat is onze code op hun machines, geen leveranciersproduct dat jouw meeting inneemt. Alles wordt tijdens runtime in de EU uitgevoerd (het onderwerp van de runtimekaart).

Dat is een bewuste, afgebakende afweging: de dataplane in eigen beheer en open source; voor de controleplane de beste beschikbare SaaS. Het benoemen is het punt: "soevereiniteit" betekent weinig als de uitzonderingen niet naast de successen op tafel liggen.

De AI-stappen, en het plan dat werd opgeleverd

De stappen met taalmodellen — de AI-digest (onderwerpen, besluiten, actiepunten), documentsamenvattingen, de generatieve acties van de AI-notitie-editor, Ask AI en Mia — draaien op de AI-gateway die je organisatie kiest: standaard Azure OpenAI in de EU Data Zone, naar keuze Vertex AI op het EU-multiregio-endpoint of Amazon Bedrock in Frankfurt, telkens in onze eigen tenant met zero data retention en zonder training op klantinhoud. Of je gebruikt je eigen OpenAI-compatibele endpoint, waarmee het model blijft draaien op infrastructuur die je zelf beheert. De samenvatting na de meeting en de vertaal-actie van de editor lopen via het vertaaltraject, niet via het taalmodel. Realtime spraak, chat, notities en documenten kwamen sowieso nooit in de buurt van een algemeen inzetbaar LLM.

Dat is de eerlijke vorm van deze laag: de modellen zijn propriëtair en hun leveranciers zijn Amerikaanse bedrijven die EU-regio's exploiteren. Het is dezelfde afweging als bij de infrastructuur hierboven, en we vermelden hem erbij in plaats van hem te verbergen. In plaats van een zelf gehost model van onszelf hebben we de keuze opgeleverd: een organisatie kan AI volledig uitschakelen (transcriptie en vertaling blijven werken) en kan elke AI-functie naar een eigen endpoint laten wijzen — vLLM in het eigen datacenter, een deployment in de eigen tenant — waarmee deze laag op dezelfde open-en-zelf-hostbare as komt als de rest van de dataplane. Onze openbare vertaalbenchmark wordt beoordeeld door een LLM-jury (Gemini, met Claude als fallback) op vaste referentiezinnen uit FLORES-200, nooit op iemands meeting.

Waarom dit ook buiten ons van belang is

Dit is geen engineering om de engineering. De reden om een stack zo te bouwen is terug te zien aan jouw kant van het contract:

1. Auditeerbaar. De SDK waarop je meeting draait is open-sourcecode die je securityteam kan lezen, en de engine erachter is onze eigen engine, geen black box van een derde partij.
2. Overdraagbaar. Open standaarden op elke datalaag — Postgres, S3, OIDC — betekenen geen propriëtaire lock-in. Wat kan worden verplaatst, zit niet vast aan één leverancier.
3. Zelf te hosten. De datalagen op open standaarden — Postgres, S3, OIDC — draaien al op infrastructuur die je zelf beheert; een volledig zelf gehoste vertaalengine staat op de roadmap voor de tenant die dat nodig heeft.

Dit is het beeld op 2026-06-07. We werken het bij wanneer de stack verandert: een leverancierswissel, een herbouwde laag, een vervangen digestmodel. De huidige configuratie is verifieerbaar in onze open vercel.json, onze nuxt.config.ts en de BSD-3-Clause-repository van mind-sdk waarnaar hierboven wordt gelinkt.

Als een laag hier niet klopt, of je securityreview een antwoord nodig heeft dat deze kaart niet geeft, schrijf ons dan. We corrigeren liever een ontbrekend detail dan dat jij het ontdekt in een code-audit.

Bronnen: de mind-sdk-repository (BSD-3-Clause), FLORES-200; stackfeiten gecontroleerd aan de hand van de uitgerolde configuratie (vercel.json, nuxt.config.ts) en de opgeleverde code, gecontroleerd in augustus 2026.