Miből épül fel egy InterMIND-meeting

Szinte minden termék ugyanabból az alapértelmezett stackből épül fel: a nagy, zárt SaaS-szolgáltatásokból, amelyekhez mindenki nyúl. Ez a súrlódásmentes út. Mi minden olyan rétegnél, ahol a meeting adatai ténylegesen élnek, mást választottunk: saját kódot, vagy olyan nyílt forráskódú megoldást, amelyet magunk is üzemeltethetünk.

Ez a bejegyzés a Hol fut valójában egy InterMIND-meeting című írás párja, amely a földrajzot térképezte fel: hol fut az egyes szolgáltatás, és milyen adat halad át rajta. Ez a bejegyzés arra felel, amit egy biztonsági csapat ezután kérdez: miből épül fel ez a rendszer, és el tudjuk-e olvasni, auditálni és lecserélni?

Nem azt nézzük, hol fut, hanem hogy miből készült, rétegről rétegre.

Az alapértelmezett választások és az áruk

Minden termék döntések sora. A legtöbb terméknél a döntések többségét az alapértelmezés hozza meg: Google Analytics, Firebase, a Google Translate API, Auth0, React. Ez a súrlódásmentes út, és a legtöbb csapatnál ez észszerű döntés. Az ára az, hogy mindegyik a stack egy részét olyan szolgáltató mögé teszi, amelynek a működését nem olvashatja el, nem auditálhatja, és újraírás nélkül nem hagyhatja el.

Mi minden rétegnél másként döntöttünk, ahol a meeting adatai ténylegesen élnek: saját kód, vagy olyan nyílt forráskódú szoftver, amelyet magunk is üzemeltethetünk. Ahol egy réteg nem érinti a meeting tartalmát, ott pragmatikusak maradunk, és ezt ki is mondjuk. Itt a teljes kép.

A gerinc: a motor a mi kódunk, nem harmadik félé

Kezdjük a legfontosabb réteggel, mert a meeting nagy része ezen halad át. A valós idejű átvitel és a hang-/chatfordítás egyaránt a mind-sdk + a Mind API segítségével fut, vagyis a saját motorunkon, az OVH franciaországi infrastruktúráján. Fordított meeting építésének szokásos módja, hogy egy valós idejű SaaS-t (LiveKit) kapcsolnak egy fordító API-hoz (DeepL, Google); mi egyiket sem futtatjuk az élő útvonalon. Harmadik fél fordítómodellje nincs a láncban. (A DeepL-t használjuk, de csak a chatbe dobott dokumentumokhoz, az élő hang-/chatútvonalon nem; lásd a futásidejű térképet. A folyamatok működését az A négy fordítási folyamat belülről című írásban mutattuk be.)

Ez az a rész, amely nincs rajta a futásidejű térképen: az SDK, amelyen a meeting fut, nyílt forráskódú, BSD 3-Clause licenc alatt. A mind-sdk kliens nyilvános a gitlab.com/mindlabs/api/sdk címen, a szerzői jog a MindMeeting OÜ-é, az észt IP-jogi entitásunké. Ez a Mind API-val kommunikál az api.mind.com címen, amelyet mi magunk üzemeltetünk az OVH franciaországi infrastruktúráján.

Ez nem a „nézd meg, de ne nyúlj hozzá” típusú, csak megtekinthető forráskód. A BSD 3-Clause megengedő, az OSI által elfogadott licenc. A biztonsági csapata klónozhatja az SDK-t, elolvashatja, pontosan hogyan rögzítik, keretezik és streamelik a hangot és a szöveget, és a saját követelményei alapján auditálhatja ezt az integrációt. A szerveroldali motor, amellyel az SDK kommunikál, a miénk, nem harmadik fél fekete doboza. Az olyan tenant számára, akinek erre szüksége van, a teljesen saját üzemeltetésű motor szerepel a terveink között, de ma még nem kínáljuk. Ezt a bejegyzést frissítjük, amint elkészül.

Rétegről rétegre: az alapértelmezés és amit mi futtatunk

Két szál húzódik végig a táblázaton. Nyílt forráskód ott, ahol az eszköz az Ön adatait dolgozza fel, hogy auditálható és elvileg saját üzemeltetésben is futtatható legyen. Nyílt szabványok (Postgres, az S3 API, OIDC) ott, ahol infrastruktúrára támaszkodunk, hogy semmi ne záruljon be egyetlen szolgáltató árazásába vagy megfelelőségi helyzetébe. A Postgres bármely Postgres-tárhelyre költözhet, a tárolás bármely S3-tárolóra, a hitelesítés pedig a már üzemeltetett identitásszolgáltatóhoz föderálódik. Az utolsó sor egy harmadik tengelyen áll: az ügyféladatokat tároló CRM uniós székhelyű (Pipedrive, észt), nem amerikai értékesítési platform. Ez nem nyílt forráskód, de nem is amerikai joghatóság alatt áll.

Néhányat érdemes egy mondattal bővebben megemlíteni. A PostHog nyílt forráskódú és saját üzemeltetésben is futtatható; mi a PostHog EU-s felhőjében futtatjuk, és a saját origin-ünkön keresztül, first-party proxyzzuk, így az eseményeket a reklámblokkolók nem dobják el észrevétlenül, és nem haladnak át harmadik fél analitikai domainjén. A hitelesítés soha nem megy harmadik fél hitelesítési SaaS-ához, amely Ön és a munkamenetei közé ékelődne: az OIDC-folyamatot mi magunk futtatjuk, és a meglévő Google- vagy Microsoft-identitásához föderáljuk. Az oldalakon a betűtípusokat a saját domainünkről szolgáljuk ki; a Google Fonts a kódbázisunkban csak egy offline brandelem-szkriptben szerepel, soha abban az alkalmazásban, amelyet a felhasználók betöltenek.

Ahol pragmatikusak vagyunk: kimondva

Nem állítjuk, hogy a teljes stack házilag készült vagy nem amerikai. Nem az, és egy ezt állító bejegyzést a saját futásidejű térképünk cáfolna.

Az infrastrukturális alapok, vagyis a tárhely és az SSR (Vercel), a meetingszerver számítási kapacitása (Fly.io), a fizetések (Stripe) és a tranzakciós e-mailek (Resend), amerikai székhelyű SaaS-on futnak. A Stripe és a Resend a számlázást és a meghívókat kezeli, és soha nem lát meeting-tartalmat. A Vercel és a Fly bérelt számítási kapacitás: a mi kódunk fut rajtuk, és a Flyon futó meetingszerver valóban kezeli az élő munkamenetet és az összefoglalónk által olvasott átiratot. Ez azonban a mi kódunk az ő gépeiken, nem egy szolgáltatói termék, amely az Ön meetingjét fogadja be. Mindez futásidőben az EU-ban hajtódik végre (erről szól a futásidejű térkép).

Ez tudatos, behatárolt kompromisszum: az adatsík saját és nyílt forráskódú, a vezérlősíkhoz a legjobb elérhető SaaS-t használjuk. A megnevezés a lényeg: a „szuverenitás” keveset ér, ha a kivételek nem kerülnek az asztalra az eredmények mellé.

Az AI-lépések és ami ténylegesen elkészült

A nyelvimodell-alapú lépések, vagyis az AI digest (témák, döntések, action items), a dokumentum-összefoglalók, az AI jegyzetszerkesztő generatív műveletei, az Ask AI és a Mia, a szervezete által kiválasztott AI-átjárón futnak: alapértelmezés szerint Azure OpenAI az EU Data Zone-ban, választás szerint Vertex AI az EU multi-régiós végponton vagy Amazon Bedrock Frankfurtban. Mindegyik a saját tenantunkban fut, nulla adatmegőrzéssel és az ügyféltartalmon való tanítás nélkül. Választható még a saját, OpenAI-kompatibilis végpontja, amely a modellt az Ön által felügyelt infrastruktúrán tartja. A meeting utáni összefoglaló és a szerkesztő fordítás művelete a fordítási szakaszon megy át, nem a nyelvi modellen. A valós idejű hang, a chat, a jegyzetek és a dokumentumok eleve soha nem kerültek közel általános célú LLM-hez.

Ez a réteg őszinte képe: a modellek zártak, és a szállítóik amerikai cégek, amelyek uniós régiókat üzemeltetnek. Ez ugyanaz a kompromisszum, mint a fenti infrastrukturális alapoknál, és mi ott említjük, nem elrejtjük. A saját üzemeltetésű, saját modell helyett a választás lehetősége készült el: a szervezet teljesen kikapcsolhatja az AI-t (az átírás és a fordítás tovább működik), és minden AI-funkciót a saját végpontjára irányíthat, például egy saját adatközpontban futó vLLM-re vagy a saját tenantjában lévő telepítésre. Ez ezt a réteget ugyanarra a nyílt és saját üzemeltetésben is futtatható tengelyre teszi, mint az adatsík többi részét. A nyilvános fordítási benchmarkunkat egy LLM-bíró (Gemini, tartalékként Claude) pontozza rögzített FLORES-200 referenciamondatokon, soha nem valakinek a meetingjén.

Miért fontos ez rajtunk túl

Ez nem öncélú mérnöki munka. Az ok, amiért így építünk stacket, az Ön oldalán, a szerződés túloldalán mutatkozik meg:

1. Auditálható. Az SDK, amelyen a meeting fut, nyílt forráskód, amelyet a biztonsági csapata elolvashat, és a mögötte lévő motor a mi saját motorunk, nem harmadik fél fekete doboza.
2. Hordozható. Nyílt szabványok minden adatrétegen (Postgres, S3, OIDC), vagyis nincs zárt szolgáltatóhoz kötöttség. Ami áthelyezhető, az nincs egyetlen szolgáltatóhoz kötve.
3. Saját üzemeltetésben is futtatható. A nyílt szabványú adatrétegek (Postgres, S3, OIDC) már most is az Ön által felügyelt infrastruktúrán futhatnak; a teljesen saját üzemeltetésű fordítómotor szerepel a terveink között annak a tenantnak, amelynek szüksége van rá.

Ez a 2026-06-07-i állapot. Frissítjük, ha a stack változik: szolgáltatócsere, újraépített réteg vagy lecserélt digest-modell esetén. Az aktuális konfiguráció ellenőrizhető a nyílt vercel.json fájlunkban, a nuxt.config.ts-ben és a fent hivatkozott, BSD-3-Clause licencű mind-sdk repóban.

Ha egy réteg itt hibásnak tűnik, vagy a biztonsági felülvizsgálatának olyan válaszra van szüksége, amelyet ez a térkép nem ad meg, írjon nekünk. Szívesebben pótolunk egy hiányzó részletet, mint hogy Ön egy kódauditban találja meg.

Források: a mind-sdk repó (BSD-3-Clause), FLORES-200; a stackre vonatkozó tényeket az üzembe helyezett konfigurációval (vercel.json, nuxt.config.ts) és az éles kóddal vetettük össze, 2026 augusztusában ellenőrizve.