Da cosa è composta una riunione su InterMIND

Quasi ogni prodotto è costruito sullo stesso stack predefinito — i grandi default SaaS proprietari che tutti scelgono. Sono il percorso senza attrito. A ogni livello in cui i dati della vostra riunione risiedono effettivamente, noi abbiamo preso una strada diversa: codice nostro, o open-source che potevamo self-hostare.

Questo è il documento complementare a Dove si svolge effettivamente una riunione su InterMIND, che mappava la geografia — dove ogni servizio viene eseguito e quali dati lo attraversano. Questo post risponde a ciò che un team di sicurezza si chiede subito dopo: da cosa è composto questo sistema — e possiamo leggerlo, auditarlo e sostituirlo?

Non dove viene eseguito — ma 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 queste 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 ognuna di queste mette una parte del vostro stack dietro a un vendor che non potete leggere, non potete auditare e da cui non potete andarvene senza una riscrittura.

Abbiamo fatto una scelta diversa a ogni livello in cui i dati della vostra riunione risiedono effettivamente: codice nostro, o software open-source che potevamo self-hostare. Dove un livello non tocca il contenuto della vostra riunione, restiamo pragmatici e lo diciamo chiaramente. Ecco il quadro completo.

La spina dorsale: il motore è codice nostro, non di terzi

Partiamo dal livello che conta di più, perché la maggior parte della vostra riunione vi fluisce attraverso. Il trasporto in tempo reale e la traduzione voce/chat girano entrambi su mind-sdk + la Mind API — il nostro motore, su OVH France. Il modo predefinito di costruire una riunione tradotta è agganciare un SaaS in tempo reale (LiveKit) a un'API di traduzione (DeepL, Google); non usiamo nessuno dei due nel percorso live. Nessun modello di traduzione di terzi è nel ciclo. (Usiamo DeepL — ma solo per i documenti inseriti nella chat, non per il percorso live 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 vostra 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à IP estone. Comunica con la Mind API su api.mind.com, che gestiamo noi stessi su OVH France.

Non è un accordo "source-available" del tipo "guarda ma non toccare". La BSD 3-Clause è una licenza permissiva, approvata OSI. Il vostro team di sicurezza può clonare l'SDK, leggere esattamente come audio e testo vengono acquisiti, impacchettati e trasmessi, e auditare quell'integrazione rispetto ai vostri requisiti. Il motore lato server con cui comunica è nostro — non una scatola nera di terzi — e un motore completamente self-hostable per un tenant che ne avesse bisogno è sulla nostra roadmap, non qualcosa che offriamo oggi. Aggiorneremo questo post non appena sarà disponibile.

Livello per livello: il default vs. cosa usiamo noi

Due fili attraversano quella tabella. Open-source dove lo strumento elabora i vostri dati — così può essere auditato e, in linea di principio, self-hostato. Standard aperti (Postgres, l'API S3, OIDC) dove dipendiamo da infrastrutture — così nulla è vincolato al pricing o alla postura di compliance di un singolo vendor. Postgres può essere spostato su qualsiasi host Postgres; lo storage può essere spostato su qualsiasi archivio S3; l'autenticazione si federa con l'identity provider che già usate. L'ultima riga poggia su un terzo asse: il CRM che detiene i record dei clienti ha sede nell'UE (Pipedrive, estone) anziché essere una piattaforma di vendite USA — non è open-source, ma non è sotto giurisdizione USA.

Un paio di questi meritano una frase in più. PostHog è open-source e self-hostable; lo eseguiamo sul cloud EU di PostHog e lo proxyiamo come first-party tramite il nostro origin, così gli eventi non vengono silenziosamente bloccati dagli ad-blocker e non transitano su un dominio di analytics di terzi. L'autenticazione non passa mai attraverso un SaaS di autenticazione di terzi che si interporebbe tra voi e le vostre sessioni — gestiamo noi il flusso OIDC e ci federiamo con il vostro Google o Microsoft esistente. E i font su ogni pagina sono serviti dal nostro dominio; l'unico posto in cui Google Fonts compare nel nostro codebase è uno script offline per le risorse di brand, mai nell'app che caricano i vostri utenti.

Dove siamo pragmatici — detto a chiare lettere

Non fingiamo che l'intero stack sia costruito a mano o non-USA. Non lo è, e un post che affermasse il contrario sarebbe smentito dalla nostra stessa mappa di runtime.

L'idraulica del sistema — hosting e SSR (Vercel), il compute del server della riunione (Fly.io), i pagamenti (Stripe), l'email transazionale (Resend) — gira su SaaS con sede negli USA. Stripe e Resend gestiscono fatturazione e inviti e non vedono mai il contenuto delle riunioni. Vercel e Fly sono compute in affitto: il nostro codice gira su di essi, e il server della riunione su Fly gestisce la sessione live e la trascrizione che il nostro digest legge — ma è il nostro codice sulle loro macchine, non un prodotto di un vendor che ingerisce la vostra riunione. Tutto viene eseguito nell'UE a runtime (l'argomento della mappa di runtime).

Questo è 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 ai successi.

I passaggi AI e il piano che abbiamo rilasciato

I passaggi del modello linguistico — l'AI digest (argomenti, decisioni, action item), i riepiloghi documenti, le azioni generative dell'AI note-editor, Ask AI e Mia — girano sul gateway AI che la vostra organizzazione seleziona: Azure OpenAI nell'EU Data Zone per default, Vertex AI sull'endpoint multi-region UE o Amazon Bedrock a Francoforte a scelta, ciascuno nel nostro tenant con zero data retention e nessun training sui contenuti dei clienti — oppure il vostro endpoint OpenAI-compatible, che mantiene il modello su un'infrastruttura che controllate. Il riepilogo post-riunione e l'azione traduci dell'editor passano attraverso il tract di traduzione, non dal modello linguistico. Voce in tempo reale, chat, note e documenti non sono mai passati da un LLM generico.

Questa è la forma onesta di questo livello: i modelli sono proprietari e i loro vendor sono aziende USA che gestiscono regioni UE — lo stesso compromesso dell'idraulica di cui sopra, dichiarato accanto ad essa anziché nascosto. Quello che abbiamo rilasciato invece di un modello self-hostato nostro è la scelta: un'organizzazione può disattivare l'AI del tutto (trascrizione e traduzione continuano a funzionare), e può puntare ogni funzionalità AI al proprio endpoint — vLLM nel proprio data center, un deployment nel proprio tenant — che mette questo livello sullo stesso asse open-e-self-hostable del resto del data plane. Il nostro benchmark di traduzione pubblico è valutato da un LLM giudice (Gemini, con Claude come fallback) su frasi di riferimento fisse di FLORES-200 — mai sulla riunione di nessuno.

Perché conta al di là di noi

Questa non è ingegneria fine a se stessa. Il motivo per costruire uno stack in questo modo emerge dalla vostra parte del contratto:

1. Auditable. L'SDK su cui gira la vostra riunione è codice open-source che il vostro team di sicurezza può leggere, e il motore dietro di esso è nostro — non una scatola nera di terzi.
2. Portabile. Standard aperti a ogni livello dei dati — Postgres, S3, OIDC — significano nessun lock-in proprietario. Ciò che può essere spostato non è vincolato a un singolo vendor.
3. Self-hostable. I livelli di dati a standard aperto — Postgres, S3, OIDC — girano già su infrastrutture che controllate; un motore di traduzione completamente self-hostable è sulla roadmap per il tenant che ne ha bisogno.

Questo è il quadro al 2026-06-07. Lo aggiorneremo quando lo stack cambia — un vendor sostituito, un livello ricostruito, il modello del digest rimpiazzato. La configurazione attuale è verificabile nel nostro vercel.json aperto, nel nostro nuxt.config.ts, e nella repository mind-sdk con licenza BSD-3-Clause linkata sopra.

Se un livello qui vi sembra sbagliato, o la vostra security review richiede una risposta che questa mappa non fornisce, scriveteci. Preferiamo correggere un dettaglio mancante piuttosto che farvelo trovare in un audit del codice.

Fonti: la repository mind-sdk (BSD-3-Clause), FLORES-200; dati dello stack verificati rispetto alla configurazione deployata (vercel.json, nuxt.config.ts) e al codice rilasciato, verificati ad agosto 2026.