Di cosa è composta una riunione InterMIND
Quasi ogni prodotto è costruito a partire dallo stesso stack predefinito — i grandi default del SaaS proprietario a cui tutti ricorrono. Sono il percorso senza attrito. A ogni livello in cui risiedono concretamente i dati della tua riunione, ne abbiamo scelto uno diverso: codice nostro, oppure open-source che potevamo auto-ospitare.
Questo è il complemento a Dove si svolge concretamente una riunione InterMIND, che ha mappato la geografia — dove viene eseguito ciascun servizio e quali dati lo attraversano. Questo post risponde a quello che un team di sicurezza si chiede dopo: di cosa è costruito questo oggetto — e possiamo leggerlo, sottoporlo a audit e sostituirlo?
Non dove viene eseguito — di cosa è fatto, livello per livello.
I default, e il loro costo
Ogni prodotto è uno stack di scelte. Per la maggior parte dei prodotti, la maggior parte di quelle scelte è fatta per default: Google Analytics, Firebase, l'API di Google Translate, Auth0, React. Sono il percorso senza attrito, e per la maggior parte dei team è una scelta ragionevole. Il compromesso è che ciascuno mette una parte del tuo stack dietro un vendor che non puoi leggere, non puoi sottoporre a audit e non puoi abbandonare senza una riscrittura.
A ogni livello in cui risiedono concretamente i dati della tua riunione abbiamo fatto una scelta diversa: codice nostro, oppure software open-source che potevamo auto-ospitare. Dove un livello non tocca il contenuto della tua riunione, restiamo pragmatici e lo diciamo. Ecco il quadro completo.
La spina dorsale: il motore è codice nostro, non di una terza parte
Partiamo dal livello che conta di più, perché la maggior parte della tua riunione lo attraversa. Il trasporto in tempo reale e la traduzione di voce/chat girano entrambi su mind-sdk + la Mind API — il nostro motore, su OVH Francia. Il modo predefinito di costruire una riunione tradotta è agganciare un SaaS in tempo reale (LiveKit) a un'API di traduzione (DeepL, Google); non eseguiamo nessuno dei due nel percorso live. Nessun modello di traduzione di terze parti è nel ciclo. (DeepL lo usiamo — ma solo per i documenti inseriti in chat, non per il percorso live di voce/chat; vedi la mappa di runtime. Abbiamo trattato la meccanica della pipeline in Dentro le quattro pipeline di traduzione.)
Ecco la parte che non è nella mappa di runtime: l'SDK su cui gira la tua riunione è open source con licenza BSD 3-Clause — il client mind-sdk è pubblico su gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, la nostra entità estone per la proprietà intellettuale. Comunica con la Mind API su api.mind.com, che gestiamo noi stessi su OVH Francia.
Non è un accordo "guarda ma non toccare" con codice solo consultabile. La BSD 3-Clause è una licenza permissiva, approvata da OSI. Il tuo team di sicurezza può clonare l'SDK, leggere esattamente come vengono catturati, impacchettati e trasmessi i tuoi audio e testo, e sottoporre a audit quell'integrazione rispetto ai tuoi requisiti. Il motore lato server a cui si rivolge è nostro — non una scatola nera di terze parti — e un motore completamente auto-ospitabile per un tenant che ne avesse bisogno è nella nostra roadmap, non qualcosa che offriamo oggi. Aggiorneremo questo post non appena sarà disponibile.
Livello per livello: il default vs. cosa eseguiamo noi
| Livello | Il default consueto | Cosa eseguiamo noi | Perché conta per te |
|---|---|---|---|
| Motore in tempo reale + traduzione (voce + chat) | LiveKit + un'API di traduzione (DeepL / Google) | mind-sdk (client BSD-3-Clause) + la nostra Mind API, OVH Francia | Il flusso di dati più pesante è il nostro motore, non un modello di terze parti — e il suo client SDK è aperto e auditabile |
| Framework frontend | React (Meta) / Next.js | Vue + Nuxt | OSS governato dalla community — nessuna singola azienda possiede il framework su cui gira la tua UI |
| Analytics di prodotto | Google Analytics | PostHog | Open-source, cloud UE, proxato come first-party tramite il nostro dominio — i dati di utilizzo non finiscono in una piattaforma pubblicitaria di terze parti |
| Font | Google Fonts CDN | Auto-ospitato (@nuxt/fonts) | Nessuna chiamata a font di terze parti dalla pagina che caricano i tuoi utenti — un punto GDPR ricorrente, evitato |
| Autenticazione | Auth0 / Clerk / Firebase Auth | OIDC gestito in casa, federato con il tuo Google / Microsoft | Nessun intermediario di autenticazione trattiene le tue sessioni — porti il tuo identity provider |
| Traduzione di documenti | Google Translate | DeepL (Colonia) | Vendor UE specializzato, elaborazione tedesca |
| Contenuto / docs | Contentful / Sanity (headless CMS) | Nuxt Content (markdown tracciato in git) | Le parole sul nostro sito vivono nel nostro repo, non nel database di un vendor |
| Database applicativo | Firestore / DynamoDB (proprietario) | Postgres (su Neon) | Standard aperto — portabile su qualsiasi host Postgres, nessuna API di query proprietaria da riscrivere |
| Object storage | API blob proprietarie | Tigris (compatibile S3) | Protocollo aperto — registrazioni ed esporti sono portabili su qualsiasi archivio S3 |
| CRM / vendite | Salesforce / HubSpot | Pipedrive (estone) | I record di clienti e deal risiedono in un CRM con sede nell'UE, non in una piattaforma di vendite US |
Due fili attraversano quella tabella. Open-source dove lo strumento processa i tuoi dati — così può essere sottoposto a audit e, in linea di principio, auto-ospitato. Standard aperti (Postgres, l'API S3, OIDC) dove dipendiamo dall'infrastruttura — così nulla è vincolato al prezzo o alla postura di conformità di un solo vendor. Postgres può migrare su qualsiasi host Postgres; lo storage può migrare su qualsiasi archivio S3; l'autenticazione si federa con l'identity provider che già gestisci. L'ultima riga si colloca su un terzo asse: il CRM che trattiene i record dei clienti ha sede nell'UE (Pipedrive, estone) invece di essere una piattaforma di vendite US — non è open-source, ma non è nemmeno sotto giurisdizione US.
Un paio di queste meritano una frase in più. PostHog è open-source e auto-ospitabile; lo eseguiamo sul cloud UE di PostHog e lo proxiamo come first-party tramite la nostra origine, così gli eventi non vengono silenziosamente scartati dagli ad-blocker e non transitano su un dominio di analytics di terze parti. L'autenticazione non passa mai per un SaaS di autenticazione di terze parti che si interpone tra te e le tue sessioni — eseguiamo noi stessi il flusso OIDC e ci federiamo con la tua identità Google o Microsoft esistente. E i font su ogni pagina sono serviti dal nostro dominio; l'unico punto in cui Google Fonts compare nel nostro codebase è uno script offline di brand asset, mai nell'app che caricano i tuoi utenti.
Dove siamo pragmatici — detto a chiare lettere
Non fingiamo che l'intero stack sia scritto a mano o non-US. Non lo è, e un post che sostenesse il contrario sarebbe smentito dalla nostra stessa mappa di runtime.
Il plumbing — hosting e SSR (Vercel), il compute del server delle riunioni (Fly.io), pagamenti (Stripe), email transazionale (Resend) — gira su SaaS con sede negli US. Stripe e Resend gestiscono fatturazione e inviti e non vedono mai il contenuto delle riunioni. Vercel e Fly sono compute in affitto: sopra ci gira codice nostro, e il server delle riunioni su Fly gestisce effettivamente la sessione live e la trascrizione che il nostro digest legge — ma è il nostro codice sulle loro macchine, non un prodotto del vendor che ingerisce la tua riunione. Tutto viene eseguito nell'UE a runtime (l'argomento di la mappa di runtime).
È un compromesso deliberato e delimitato: possedere e rendere open-source il data plane; usare il miglior SaaS disponibile per il control plane. Nominarlo è il punto — "sovranità" significa poco se le eccezioni non sono sul tavolo accanto alle vittorie.
I passi AI post-riunione, e il piano
Nessun modello proprietario con sede negli US tocca contenuti derivati dalla riunione. I passi basati su modello linguistico che girano dopo la chiamata — l'AI digest (argomenti, decisioni, action item), il post-meeting summary, e l'AI note-editor — risiedono tutti su processori UE. L'AI digest e le azioni generative dell'AI note-editor girano su Mistral ospitato nell'UE con zero-data-retention (raggiunto tramite l'AI Gateway di Vercel, fissato sul provider Mistral). Il post-meeting summary e l'azione translate dell'AI note-editor girano sul nostro motore UE su OVH — lo stesso dietro voce e chat in tempo reale. Voce, chat, note e documenti in tempo reale non si sono mai avvicinati a un LLM general-purpose fin dall'inizio.
L'unico modello US ancora nel ciclo giudica il nostro benchmark di traduzione pubblico — assegnando punteggi a traduzioni automatiche di frasi di riferimento fisse di FLORES-200, mai alla riunione di qualcuno.
Stiamo andando oltre anche sui passi EU-Mistral: un opt-out controllato dall'owner per disattivare del tutto il digest, e un modello di summarization auto-ospitato a pesi aperti su OVH (classe Kimi) per sostituire il Mistral esterno. Il punto della via dei pesi aperti non è di quale lab abbia addestrato i pesi — è che i pesi aperti possono girare su infrastruttura che controlliamo, il che la mantiene sullo stesso asse aperto-e-auto-ospitabile del resto del data plane. Entrambi sono in roadmap, non ancora rilasciati; aggiorneremo questo post quando saranno disponibili.
Perché conta al di là di noi
Non è engineering fine a se stesso. Il motivo per costruire uno stack in questo modo si vede dalla tua parte del contratto:
- Auditabile. L'SDK su cui gira la tua riunione è codice open-source che il tuo team di sicurezza può leggere, e il motore dietro di esso è nostro — non una scatola nera di terze parti.
- Portatile. Standard aperti a ogni livello di dati — Postgres, S3, OIDC — significano nessun lock-in proprietario. Ciò che può essere spostato non è vincolato a un solo vendor.
- Auto-ospitabile. I livelli di dati a standard aperto — Postgres, S3, OIDC — girano già su infrastruttura che controlli; un motore di traduzione completamente auto-ospitabile è in roadmap per il tenant che ne ha bisogno.
Questo è il quadro al 2026-06-07. Lo aggiorneremo quando lo stack cambia — un cambio di vendor, un livello ricostruito, il modello del digest sostituito. La configurazione attuale è verificabile nel nostro vercel.json pubblico, nel nostro nuxt.config.ts, e nel repository BSD-3-Clause mind-sdk linkato sopra.
Se un livello qui sembra sbagliato, o la tua security review ha bisogno di una risposta che questa mappa non dà, scrivici. Preferiamo correggere un dettaglio mancante piuttosto che farti trovarlo in un code audit.
Fonti: il repository mind-sdk (BSD-3-Clause), FLORES-200; i fatti di stack verificati rispetto alla configurazione distribuita (vercel.json, nuxt.config.ts) e al codice rilasciato, verificati ad agosto 2026.