Vad ett InterMIND-möte är byggt av

Nästan alla produkter byggs av samma standardstack: de stora proprietära SaaS-tjänster som alla väljer av ren vana. Det är den friktionsfria vägen. I varje lager där din mötesdata faktiskt finns har vi valt en annan väg: vår egen kod, eller öppen källkod som vi kan köra själva.

Det här är en följeslagare till Där ett InterMIND-möte faktiskt körs, som kartlade geografin: var varje tjänst körs och vilken data som passerar den. Det här inlägget svarar på nästa fråga som ett säkerhetsteam brukar ställa: vad är det här byggt av, och kan vi läsa det, granska det och byta ut det?

Inte var det körs, utan vad det är gjort av, lager för lager.

Standardvalen och vad de kostar

Varje produkt är en samling val. För de flesta produkter görs de flesta valen av ren vana: Google Analytics, Firebase, Google Translate API, Auth0, React. De är den friktionsfria vägen, och för de flesta team är det ett rimligt beslut. Priset är att var och en lägger en del av din stack bakom en leverantör som du inte kan läsa, inte kan granska och inte kan lämna utan att skriva om.

I varje lager där din mötesdata faktiskt finns har vi gjort ett annat val: vår egen kod, eller öppen källkod som vi kan köra själva. Där ett lager inte rör innehållet i ditt möte är vi pragmatiska, och säger det. Här är hela bilden.

Ryggraden: motorn är vår kod, inte en tredje parts

Vi börjar med det lager som betyder mest, eftersom största delen av ditt möte flödar genom det. Realtidstransport samt översättning av röst och chatt körs båda på mind-sdk + Mind API, vår egen motor, på OVH i Frankrike. Standardsättet att bygga ett översatt möte är att skruva ihop en realtids-SaaS (LiveKit) med ett översättnings-API (DeepL, Google). Vi kör ingen av dem i den live-körda vägen. Ingen tredje parts översättningsmodell ingår i kedjan. (Vi använder DeepL, men bara för dokument som släpps i chatten, inte för röst och chatt i realtid. Se körningskartan. Pipelinernas mekanik går vi igenom i Inuti de fyra översättningspipelinerna.)

Här är det som inte framgår av körningskartan: SDK:n som ditt möte körs på är öppen källkod under BSD 3-Clause-licensen. Klienten mind-sdk är publik på gitlab.com/mindlabs/api/sdk, med upphovsrätt MindMeeting OÜ, vår estniska IP-enhet. Den talar med Mind API på api.mind.com, som vi driver själva på OVH i Frankrike.

Det här är inget "titta men rör inte"-upplägg med tillgänglig källkod. BSD 3-Clause är en tillåtande, OSI-godkänd licens. Ditt säkerhetsteam kan klona SDK:n, läsa exakt hur ljud och text fångas, paketeras och strömmas, och granska den integrationen mot era egna krav. Serversidans motor som den talar med är vår egen, inte en tredje parts svarta låda. En helt självhostbar motor för de kunder som behöver den finns på vår färdplan, men erbjuds inte idag. Vi uppdaterar det här inlägget så fort den levereras.

Lager för lager: standardvalet mot det vi kör

Två trådar går genom tabellen. Öppen källkod där verktyget behandlar din data, så att det kan granskas och i princip självhostas. Öppna standarder (Postgres, S3-API:t, OIDC) där vi är beroende av infrastruktur, så att inget är låst till en enskild leverantörs prissättning eller efterlevnadsläge. Postgres kan flyttas till vilken Postgres-värd som helst, lagringen kan flyttas till vilken S3-lagring som helst, och autentiseringen federeras till den identitetsleverantör som du redan kör. Den sista raden ligger på en tredje axel: CRM:et som håller kundposterna har säte i EU (Pipedrive, estniskt) i stället för att vara en amerikansk försäljningsplattform. Det är inte öppen källkod, men det ligger inte heller under amerikansk jurisdiktion.

Ett par av dessa förtjänar en mening till. PostHog är öppen källkod och kan självhostas. Vi kör det i PostHogs EU-moln och proxar det som förstapart genom vår egen origin, så att händelserna inte tyst fångas upp av annonsblockerare och inte passerar en tredje parts analysdomän. Autentiseringen går aldrig via en extern autentiserings-SaaS som skulle sitta mellan dig och dina sessioner: vi kör OIDC-flödet själva och federerar till din befintliga Google- eller Microsoft-identitet. Typsnitten på varje sida serveras från vår egen domän, och den enda plats där Google Fonts förekommer i vår kodbas är ett offline-skript för varumärkesmaterial, aldrig i appen som dina användare laddar.

Där vi är pragmatiska: sagt rakt ut

Vi låtsas inte att hela stacken är handbyggd eller icke-amerikansk. Det är den inte, och ett inlägg som påstod något annat skulle motsägas av vår egen körningskarta.

Rörledningen, alltså hosting och SSR (Vercel), mötesserverns beräkning (Fly.io), betalningar (Stripe) och transaktionell e-post (Resend), körs på SaaS med amerikanskt säte. Stripe och Resend hanterar fakturering och inbjudningar och ser aldrig mötesinnehåll. Vercel och Fly är hyrd beräkningskraft: vår egen kod körs på dem, och mötesservern på Fly hanterar visserligen den pågående sessionen och transkriptet som vår sammanfattning läser, men det är vår kod på deras maskiner, inte en leverantörsprodukt som tar emot ditt möte. Allt körs i EU vid körning (ämnet för körningskartan).

Det är en medveten, avgränsad kompromiss: äga och använda öppen källkod för dataplanet, och använda den bästa tillgängliga SaaS-tjänsten för kontrollplanet. Att namnge det är hela poängen. "Suveränitet" betyder lite om undantagen inte läggs på bordet bredvid framgångarna.

AI-stegen och planen som levererades

Språkmodellsstegen, alltså AI-sammanfattningen (ämnen, beslut, action items), dokumentsammanfattningar, AI-anteckningsredigerarens generativa åtgärder, Ask AI och Mia, körs på den AI-gateway som din organisation väljer: som standard Azure OpenAI i EU Data Zone, och efter val Vertex AI på EU:s multiregion-endpoint eller Amazon Bedrock i Frankfurt, alla i vår egen tenant med noll datalagring och ingen träning på kundinnehåll. Eller din egen OpenAI-kompatibla endpoint, som håller modellen på infrastruktur som du kontrollerar. Sammanfattningen efter mötet och redigerarens översätt-åtgärd går via översättningsflödet, inte språkmodellen. Röst, chatt, anteckningar och dokument i realtid har aldrig varit i närheten av en generell LLM från första början.

Det är den ärliga bilden av det här lagret: modellerna är proprietära, och deras leverantörer är amerikanska företag som driver EU-regioner. Det är samma kompromiss som med rörledningen ovan, och vi redovisar den bredvid i stället för att dölja den. Det som levererades i stället för en självhostad modell av vårt eget märke är valet: en organisation kan stänga av AI helt (transkribering och översättning fortsätter fungera), och den kan peka varje AI-funktion mot sin egen endpoint, vLLM i det egna datacentret eller en driftsättning i den egna tenanten, vilket placerar det här lagret på samma öppna och självhostbara axel som resten av dataplanet. Vår publika översättningsbenchmark poängsätts av en LLM-domare (Gemini, med Claude som reserv) på fasta referensmeningar från FLORES-200, aldrig någons möte.

Varför det spelar roll bortom oss

Det här är inte ingenjörskonst för sin egen skull. Skälet till att bygga en stack på det här sättet visar sig på din sida av avtalet:

1. Granskningsbar. SDK:n som ditt möte körs på är öppen källkod som ditt säkerhetsteam kan läsa, och motorn bakom den är vår egen, inte en tredje parts svarta låda.
2. Portabel. Öppna standarder i varje datalager, Postgres, S3 och OIDC, innebär ingen proprietär inlåsning. Det som kan flyttas är inte bundet till en enda leverantör.
3. Självhostbar. De öppna standardlagren för data, Postgres, S3 och OIDC, körs redan på infrastruktur som du kontrollerar. En helt självhostad översättningsmotor finns på färdplanen för de kunder som behöver den.

Det här är bilden per 2026-06-07. Vi uppdaterar den när stacken ändras: ett leverantörsbyte, ett lager som byggs om, sammanfattningsmodellen som byts ut. Den aktuella konfigurationen är verifierbar i vår öppna vercel.json, vår nuxt.config.ts och mind-sdk-repot under BSD-3-Clause som länkas ovan.

Om något lager här ser fel ut, eller om er säkerhetsgranskning behöver ett svar som den här kartan inte ger, skriv till oss. Vi rättar hellre en saknad detalj än att du hittar den i en kodgranskning.

Källor: mind-sdk-repot (BSD-3-Clause), FLORES-200. Stackfakta har verifierats mot den driftsatta konfigurationen (vercel.json, nuxt.config.ts) och den levererade koden, kontrollerat i augusti 2026.