Hva ett InterMIND-møte er bygget av

Nesten alle produkter er bygget av den samme standardstacken: de store proprietære SaaS-løsningene som alle strekker seg etter. De er den friksjonsfrie veien. I hvert lag der møtedataene dine faktisk ligger, valgte vi noe annet: vår egen kode, eller åpen kildekode vi kunne drifte selv.

Dette er en oppfølger til Where one InterMIND meeting actually runs, som kartla geografien: hvor hver tjeneste kjører, og hvilke data som passerer gjennom den. Dette innlegget svarer på det et sikkerhetsteam spør om neste gang: hva er dette bygget av, og kan vi lese det, revidere det og bytte det ut?

Ikke hvor det kjører, men hva det består av, lag for lag.

Standardvalgene og hva de koster

Ethvert produkt er en stabel av valg. I de fleste produkter er de fleste valgene tatt på autopilot: Google Analytics, Firebase, Google Translate API, Auth0, React. De er den friksjonsfrie veien, og for de fleste team er det et fornuftig valg. Prisen er at hver av dem setter en del av stacken din bak en leverandør du ikke kan lese, ikke kan revidere og ikke kan forlate uten å skrive om.

I hvert lag der møtedataene dine faktisk ligger, gjorde vi et annet valg: vår egen kode, eller åpen kildekode vi kunne drifte selv. Der et lag ikke berører innholdet i møtet ditt, er vi pragmatiske og sier det. Her er hele bildet.

Ryggraden: motoren er vår kode, ikke en tredjeparts

Vi starter med laget som betyr mest, fordi mesteparten av møtet ditt flyter gjennom det. Sanntidstransport og oversettelse av tale og chat kjører begge på mind-sdk + Mind API: vår egen motor, hos OVH i Frankrike. Standardmåten å bygge et oversatt møte på er å skru en sanntids-SaaS (LiveKit) sammen med et oversettelses-API (DeepL, Google). Vi kjører ingen av delene i den levende banen. Ingen tredjeparts oversettelsesmodell er med i løkken. (Vi bruker DeepL, men bare til dokumenter som legges inn i chatten, ikke i den levende tale- og chatbanen. Se kjøretidskartet. Hvordan pipelinene fungerer, gikk vi gjennom i Inside the four translation pipelines.)

Her er delen som ikke står i kjøretidskartet: SDK-en møtet ditt kjører på er åpen kildekode under BSD 3-Clause-lisensen. mind-sdk-klienten er offentlig på gitlab.com/mindlabs/api/sdk, med opphavsrett hos MindMeeting OÜ, vår estiske IP-enhet. Den snakker med Mind API-et på api.mind.com, som vi driver selv hos OVH i Frankrike.

Dette er ikke et «se, men ikke rør»-opplegg med kun tilgjengelig kildekode. BSD 3-Clause er en tillatende, OSI-godkjent lisens. Sikkerhetsteamet ditt kan klone SDK-en, lese nøyaktig hvordan lyden og teksten din fanges opp, rammes inn og strømmes, og revidere integrasjonen mot egne krav. Serversidemotoren den snakker med, er vår egen og ikke en tredjeparts svarte boks. En fullt selvhostbar motor for en tenant som trenger det, står på veikartet vårt, men er ikke noe vi tilbyr i dag. Vi oppdaterer dette innlegget så snart den er klar.

Lag for lag: standardvalget mot det vi kjører

To tråder går gjennom tabellen. Åpen kildekode der verktøyet behandler dataene dine, slik at det kan revideres og i prinsippet driftes selv. Åpne standarder (Postgres, S3-API-et, OIDC) der vi er avhengige av infrastruktur, slik at ingenting er låst til én leverandørs prissetting eller compliance-linje. Postgres kan flyttes til hvilken som helst Postgres-vert, lagringen kan flyttes til hvilken som helst S3-lagring, og autentiseringen føderes til identitetsleverandøren du allerede driver. Den siste raden ligger på en tredje akse: CRM-et som holder kundeposter har EU-domisil (Pipedrive, estisk) i stedet for å være en amerikansk salgsplattform. Det er ikke åpen kildekode, men heller ikke underlagt amerikansk jurisdiksjon.

Noen av disse fortjener en setning til. PostHog er åpen kildekode og kan selvhostes. Vi kjører det på PostHogs EU-sky og proxer det som førsteparts gjennom vår egen origin, slik at hendelsene ikke stille blir blokkert av annonseblokkere og heller ikke passerer et tredjeparts analysedomene. Autentiseringen går aldri til en tredjeparts auth-SaaS som ville sittet mellom deg og øktene dine. Vi kjører OIDC-flyten selv og føderer til din eksisterende Google- eller Microsoft-identitet. Og fontene på hver side serveres fra vårt eget domene. Det eneste stedet Google Fonts forekommer i kodebasen vår, er et frakoblet skript for merkevareressurser, aldri appen brukerne dine laster.

Der vi er pragmatiske, sagt rett ut

Vi later ikke som om hele stacken er håndlaget eller ikke-amerikansk. Det er den ikke, og et innlegg som hevdet noe annet, ville blitt motsagt av vårt eget kjøretidskart.

Infrastrukturen, altså hosting og SSR (Vercel), beregningskraften til møteserveren (Fly.io), betalinger (Stripe) og transaksjonelle e-poster (Resend), kjører på SaaS med amerikansk domisil. Stripe og Resend håndterer fakturering og invitasjoner og ser aldri møteinnhold. Vercel og Fly er innleid beregningskraft: vår egen kode kjører på dem, og møteserveren på Fly håndterer riktignok den levende økten og transkripsjonen som digest-funksjonen vår leser. Men det er vår kode på deres maskiner, ikke et leverandørprodukt som tar inn møtet ditt. Alt kjører i EU under kjøring (temaet for kjøretidskartet).

Det er en bevisst og avgrenset avveining: eie og bruke åpen kildekode i dataplanet, og bruke den beste tilgjengelige SaaS-en i kontrollplanet. Poenget er å si det høyt. «Suverenitet» betyr lite hvis unntakene ikke legges på bordet ved siden av gevinstene.

AI-trinnene, og planen som ble levert

Språkmodelltrinnene, nemlig AI digest (temaer, beslutninger, action items), dokumentsammendrag, de generative handlingene i AI-notatredigereren, Ask AI og Mia, kjører på AI-gatewayen organisasjonen din velger: Azure OpenAI i EU Data Zone som standard, Vertex AI på EUs multiregion-endepunkt eller Amazon Bedrock i Frankfurt etter valg. Hver av dem kjører i vår egen tenant, uten datalagring og uten trening på kundeinnhold. Alternativt kan du bruke ditt eget OpenAI-kompatible endepunkt, som holder modellen på infrastruktur du kontrollerer. Oppsummeringen etter møtet og redigererens oversett-handling går gjennom oversettelsesleddet, ikke språkmodellen. Sanntidstale, chat, notater og dokumenter var aldri i nærheten av en generell LLM til å begynne med.

Det er den ærlige formen på dette laget: modellene er proprietære, og leverandørene er amerikanske selskaper som driver EU-regioner. Det er samme avveining som for infrastrukturen over, og vi sier det rett ved siden av i stedet for å skjule det. Det som ble levert i stedet for en selvhostet modell av vår egen, er valgfriheten: en organisasjon kan slå av AI helt (transkripsjon og oversettelse fortsetter å fungere), og den kan peke hver AI-funksjon mot sitt eget endepunkt, for eksempel vLLM i eget datasenter eller en utrulling i egen tenant. Det plasserer dette laget på samme akse for åpen kildekode og selvhosting som resten av dataplanet. Vår offentlige oversettelsesbenchmark scores av en LLM-dommer (Gemini, med Claude som reserve) på faste referansesetninger fra FLORES-200, aldri på noens møte.

Hvorfor dette betyr noe utover oss selv

Dette er ikke ingeniørkunst for sin egen skyld. Grunnen til å bygge en stack slik, viser seg på din side av kontrakten:

1. Reviderbar. SDK-en møtet ditt kjører på er åpen kildekode som sikkerhetsteamet ditt kan lese, og motoren bak den er vår egen, ikke en tredjeparts svarte boks.
2. Portabel. Åpne standarder i hvert datalag, Postgres, S3 og OIDC, betyr ingen proprietær innlåsing. Det som kan flyttes, er ikke bundet til én enkelt leverandør.
3. Selvhostbar. De åpne datalagene, Postgres, S3 og OIDC, kjører allerede på infrastruktur du kontrollerer. En fullt selvhostet oversettelsesmotor står på veikartet for tenanten som trenger det.

Dette er bildet per 2026-06-07. Vi oppdaterer det når stacken endres: et leverandørbytte, et lag som bygges om, digest-modellen som erstattes. Dagens konfigurasjon kan etterprøves i vår åpne vercel.json, vår nuxt.config.ts og mind-sdk-repoet under BSD-3-Clause som er lenket ovenfor.

Hvis et lag her ser feil ut, eller sikkerhetsgjennomgangen din trenger et svar dette kartet ikke gir, skriv til oss. Vi retter heller opp en manglende detalj enn at du finner den i en kodegjennomgang.

Kilder: mind-sdk-repoet (BSD-3-Clause), FLORES-200. Stackfaktaene er verifisert mot den utrullede konfigurasjonen (vercel.json, nuxt.config.ts) og den leverte koden, kontrollert i august 2026.