Hvad ét InterMIND-møde er bygget af

Næsten alle produkter er bygget af den samme standardstack: de store proprietære SaaS-løsninger, som alle rækker ud efter. De er den friktionsfri vej. I hvert lag, hvor dine mødedata faktisk ligger, har vi valgt en anden: vores egen kode eller open source, vi selv kan hoste.

Dette indlæg er et supplement til Hvor ét InterMIND-møde faktisk kører, som kortlagde geografien: hvor hver tjeneste kører, og hvilke data der passerer igennem den. Her svarer vi på det, et sikkerhedsteam spørger om som det næste: hvad er det her bygget af, og kan vi læse det, auditere det og udskifte det?

Ikke hvor det kører, men hvad det består af, lag for lag.

Standardvalgene og hvad de koster

Ethvert produkt er en stak af valg. I de fleste produkter træffes de fleste af dem som standard: Google Analytics, Firebase, Google Translate API, Auth0, React. De er den friktionsfri vej, og for de fleste teams er det et rimeligt valg. Prisen er, at hvert af dem placerer en del af din stack hos en leverandør, du ikke kan læse, ikke kan auditere og ikke kan forlade uden at skrive om.

Vi har truffet et andet valg i hvert lag, hvor dine mødedata faktisk ligger: vores egen kode eller open source-software, vi selv kan hoste. Hvor et lag ikke berører indholdet af dit møde, er vi pragmatiske og siger det. Her er hele billedet.

Rygraden: motoren er vores egen kode, ikke en tredjeparts

Vi starter med det lag, der betyder mest, fordi størstedelen af dit møde løber igennem det. Både realtidstransport og oversættelse af tale og chat kører på mind-sdk + Mind API, vores egen motor hos OVH i Frankrig. Standardmåden at bygge et oversat møde på er at skrue en realtids-SaaS (LiveKit) sammen med et oversættelses-API (DeepL, Google); vi kører ingen af delene i den levende sti. Ingen tredjeparts oversættelsesmodel er med i løkken. (Vi bruger DeepL, men kun til dokumenter, der lægges i chatten, ikke i den levende tale- og chatsti; se runtime-kortet. Vi gennemgik pipelinernes mekanik i Inde i de fire oversættelsespipelines.)

Her er den del, der ikke står i runtime-kortet: det SDK, dit møde kører på, er open source under BSD 3-Clause-licensen. mind-sdk-klienten er offentlig på gitlab.com/mindlabs/api/sdk, med copyright hos MindMeeting OÜ, vores estiske IP-enhed. Den taler med Mind API på api.mind.com, som vi selv driver hos OVH i Frankrig.

Det er ikke en "kig, men rør ikke"-ordning med tilgængelig kildekode. BSD 3-Clause er en permissiv, OSI-godkendt licens. Dit sikkerhedsteam kan klone SDK'et, læse præcis hvordan din lyd og tekst fanges, indrammes og streames, og auditere integrationen mod jeres egne krav. Servermotoren, den taler med, er vores og ikke en tredjeparts sorte boks. En fuldt selvhostbar motor til en tenant, der har brug for det, står på vores køreplan, men er ikke noget, vi tilbyder i dag. Vi opdaterer dette indlæg i samme øjeblik, den kommer.

Lag for lag: standarden mod det, vi kører

To tråde løber gennem tabellen. Open source der, hvor værktøjet behandler dine data, så det kan auditeres og i princippet selvhostes. Åbne standarder (Postgres, S3-API'et, OIDC) der, hvor vi afhænger af infrastruktur, så intet er låst til én leverandørs priser eller compliance-holdning. Postgres kan flytte til enhver Postgres-host; lagring kan flytte til ethvert S3-lager; autentificering føderer til den identitetsudbyder, du allerede kører. Den sidste række ligger på en tredje akse: CRM'et med kundeposter har EU-domicil (Pipedrive, estisk) frem for at være en amerikansk salgsplatform. Det er ikke open source, men det er heller ikke under amerikansk jurisdiktion.

Et par af dem fortjener en sætning mere. PostHog er open source og kan selvhostes; vi kører det på PostHogs EU-cloud og proxyer det som first-party gennem vores eget origin, så hændelserne ikke stille og roligt bliver blokeret af ad-blockere og ikke passerer et tredjeparts analysedomæne. Autentificering går aldrig til en tredjeparts auth-SaaS, der ville sidde mellem dig og dine sessioner: vi kører selv OIDC-flowet og føderer til din eksisterende Google- eller Microsoft-identitet. Og skrifttyperne på hver side leveres fra vores eget domæne; det eneste sted, Google Fonts optræder i vores kodebase, er et offline-script til brandmateriale, aldrig i den app, dine brugere indlæser.

Hvor vi er pragmatiske: sagt ligeud

Vi lader ikke, som om hele stacken er håndlavet eller ikke-amerikansk. Det er den ikke, og et indlæg, der påstod andet, ville blive modsagt af vores eget runtime-kort.

Rørføringen, nemlig hosting og SSR (Vercel), mødeserverens regnekraft (Fly.io), betalinger (Stripe) og transaktionsmail (Resend), kører på SaaS med amerikansk domicil. Stripe og Resend håndterer fakturering og invitationer og ser aldrig mødeindhold. Vercel og Fly er lejet regnekraft: vores egen kode kører på dem, og mødeserveren på Fly håndterer den levende session og den transskription, vores digest læser. Men det er vores kode på deres maskiner, ikke et leverandørprodukt, der indtager dit møde. Det hele kører i EU under kørsel (emnet for runtime-kortet).

Det er en bevidst, afgrænset afvejning: eje og bruge open source i dataplanet, bruge den bedste tilgængelige SaaS i kontrolplanet. At nævne det åbent er pointen: "suverænitet" betyder lidt, hvis undtagelserne ikke ligger på bordet ved siden af gevinsterne.

AI-trinnene og den plan, der blev leveret

Sprogmodel-trinnene, nemlig AI digest (emner, beslutninger, action items), dokumentresuméer, de generative handlinger i AI-noteeditoren, Ask AI og Mia, kører på den AI-gateway, din organisation vælger: som standard Azure OpenAI i EU Data Zone, eller efter valg Vertex AI på EU's multi-region-endpoint eller Amazon Bedrock i Frankfurt. Hver kører i vores egen tenant med nul dataopbevaring og uden træning på kundeindhold. Eller dit eget OpenAI-kompatible endpoint, som holder modellen på infrastruktur, du selv kontrollerer. Opsummeringen efter mødet og editorens oversæt-handling går gennem oversættelsesleddet, ikke sprogmodellen. Tale, chat, noter og dokumenter i realtid kom aldrig i nærheden af en almindelig LLM til at begynde med.

Det er den ærlige form på dette lag: modellerne er proprietære, og deres leverandører er amerikanske virksomheder, der driver EU-regioner. Det er den samme afvejning som i rørføringen ovenfor, nævnt ved siden af den frem for skjult. Det, der blev leveret i stedet for en selvhostet model af vores egen, er valgfriheden: en organisation kan slå AI helt fra (transskription og oversættelse virker stadig), og den kan pege alle AI-funktioner på sit eget endpoint, med vLLM i sit eget datacenter eller en deployment i sin egen tenant, hvilket placerer dette lag på samme åbne og selvhostbare akse som resten af dataplanet. Vores offentlige oversættelsesbenchmark bedømmes af en LLM-dommer (Gemini, med Claude som fallback) på faste FLORES-200-referencesætninger, aldrig på nogens møde.

Hvorfor det betyder noget ud over os

Det er ikke ingeniørarbejde for sin egen skyld. Grunden til at bygge en stack på denne måde viser sig på din side af kontrakten:

1. Auditerbar. Det SDK, dit møde kører på, er open source-kode, dit sikkerhedsteam kan læse, og motoren bag det er vores egen, ikke en tredjeparts sorte boks.
2. Portabel. Åbne standarder i hvert datalag, Postgres, S3 og OIDC, betyder ingen proprietær lock-in. Det, der kan flyttes, er ikke bundet til én enkelt leverandør.
3. Selvhostbar. De åbne standarder i datalagene, Postgres, S3 og OIDC, kører allerede på infrastruktur, du selv kontrollerer; en fuldt selvhostet oversættelsesmotor står på køreplanen til den tenant, der har brug for den.

Det her er billedet pr. 2026-06-07. Vi opdaterer det, når stacken ændrer sig: et leverandørskifte, et lag bygget om, digest-modellen udskiftet. Den nuværende konfiguration kan efterprøves i vores åbne vercel.json, vores nuxt.config.ts og det BSD-3-Clause-licenserede mind-sdk-repository, der er linket ovenfor.

Hvis et lag her ser forkert ud, eller jeres sikkerhedsgennemgang har brug for et svar, som dette kort ikke giver, så skriv til os. Vi retter hellere en manglende detalje, end at du finder den i et kodeaudit.

Kilder: mind-sdk-repositoryet (BSD-3-Clause), FLORES-200; stackfakta er verificeret mod den udrullede konfiguration (vercel.json, nuxt.config.ts) og den leverede kode, kontrolleret august 2026.