Di cosa è fatto un meeting InterMIND

Quasi ogni prodotto è costruito sullo stesso stack predefinito: i grandi SaaS proprietari a cui tutti si rivolgono. È la strada senza attriti. A ogni livello in cui vivono davvero i dati del vostro meeting, noi ne abbiamo scelta un'altra: codice nostro, oppure open source che potremmo ospitare in autonomia.

Questo articolo è il complemento di Dove gira davvero un meeting InterMIND, che ha mappato la geografia: dove viene eseguito ciascun servizio e quali dati lo attraversano. Qui rispondiamo a ciò che un team di sicurezza chiede subito dopo: da cosa è fatto tutto questo, e possiamo leggerlo, sottoporlo ad audit e sostituirlo?

Non dove gira, ma di cosa è fatto, livello per livello.

Le scelte predefinite e il loro costo

Ogni prodotto è una pila di scelte. Per la maggior parte dei prodotti, la maggior parte di queste scelte viene fatta per impostazione predefinita: Google Analytics, Firebase, l'API di Google Translate, Auth0, React. Sono la strada senza attriti e, per la maggior parte dei team, è una decisione ragionevole. Il compromesso è che ciascuna di queste scelte mette una parte del vostro stack dietro a un fornitore che non potete leggere, non potete sottoporre ad audit e non potete lasciare senza riscrivere tutto.

Noi abbiamo fatto una scelta diversa a ogni livello in cui vivono davvero i dati del vostro meeting: codice nostro, oppure software open source che potremmo ospitare in autonomia. Dove un livello non tocca il contenuto del vostro meeting, restiamo pragmatici e lo diciamo. Ecco il quadro completo.

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

Partiamo dal livello più importante, perché la maggior parte del vostro meeting passa da lì. Il trasporto in tempo reale e la traduzione di voce e chat girano entrambi su mind-sdk + la Mind API: il nostro motore, su OVH Francia. Il modo predefinito di costruire un meeting tradotto è innestare un SaaS in tempo reale (LiveKit) su un'API di traduzione (DeepL, Google); noi non usiamo né l'uno né l'altra nel percorso live. Nessun modello di traduzione di terzi è coinvolto. (Usiamo DeepL, ma solo per i documenti caricati in chat, non per il percorso live di voce e chat; vedi la mappa di runtime. Abbiamo raccontato il funzionamento delle pipeline in Dentro le quattro pipeline di traduzione.)

Ecco la parte che non compare nella mappa di runtime: l'SDK su cui gira il vostro meeting è 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 titolare della proprietà intellettuale. Dialoga con la Mind API su api.mind.com, che gestiamo direttamente su OVH Francia.

Non è un accordo "guarda ma non toccare" di tipo source-available. La BSD 3-Clause è una licenza permissiva, approvata dall'OSI. Il vostro team di sicurezza può clonare l'SDK, leggere esattamente come audio e testo vengono acquisiti, suddivisi in frame e trasmessi in streaming, e verificare tale integrazione rispetto ai vostri requisiti. Il motore lato server con cui dialoga è nostro, non una scatola nera di terzi; un motore completamente self-hostable per i tenant che ne hanno bisogno è nella nostra roadmap, ma non è qualcosa che offriamo oggi. Aggiorneremo questo articolo nel momento in cui sarà disponibile.

Livello per livello: la scelta predefinita e ciò che usiamo noi

Due fili attraversano questa tabella. Open source dove lo strumento elabora i vostri dati, così che possa essere sottoposto ad audit e, in linea di principio, ospitato in autonomia. Standard aperti (Postgres, l'API S3, OIDC) dove dipendiamo da un'infrastruttura, così che nulla sia vincolato ai prezzi o all'assetto di conformità di un singolo fornitore. Postgres può spostarsi su qualsiasi host Postgres; lo storage può spostarsi su qualsiasi store S3; l'autenticazione si federa all'identity provider che già utilizzate. L'ultima riga si colloca su un terzo asse: il CRM che custodisce i record dei clienti ha sede nella UE (Pipedrive, estone) invece di essere una piattaforma di vendita statunitense: non è open source, ma non è nemmeno sotto giurisdizione statunitense.

Un paio di queste voci meritano qualche riga in più. PostHog è open source e self-hostable; noi lo usiamo sul cloud UE di PostHog e lo mettiamo in proxy first-party attraverso la nostra origine, così gli eventi non vengono scartati in silenzio dagli ad-blocker e non transitano da un dominio di analytics di terzi. L'autenticazione non passa mai da un SaaS di autenticazione di terzi che si frapporrebbe tra voi e le vostre sessioni: gestiamo noi il flusso OIDC e ci federiamo con la vostra identità Google o Microsoft esistente. E i font di ogni pagina sono serviti dal nostro dominio; l'unico punto del nostro codice in cui compare Google Fonts è uno script offline per gli asset del brand, mai l'app che caricano i vostri utenti.

Dove siamo pragmatici: detto apertamente

Non facciamo finta che l'intero stack sia sviluppato in casa o non statunitense. Non lo è, e un articolo che sostenesse il contrario sarebbe smentito dalla nostra stessa mappa di runtime.

L'infrastruttura di base (hosting e SSR con Vercel, calcolo del server del meeting con Fly.io, pagamenti con Stripe, email transazionali con Resend) gira su SaaS con sede negli Stati Uniti. Stripe e Resend gestiscono fatturazione e inviti e non vedono mai il contenuto dei meeting. Vercel e Fly sono capacità di calcolo a noleggio: ci gira il nostro codice, e il server del meeting 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 fornitore che acquisisce il vostro meeting. Tutto viene eseguito nella UE a runtime (è l'argomento della mappa di runtime).

È un compromesso deliberato e circoscritto: codice nostro e open source per il data plane; il miglior SaaS disponibile per il control plane. Dirlo è il punto: la "sovranità" significa poco se le eccezioni non vengono messe sul tavolo accanto ai punti di forza.

I passaggi AI e il piano che abbiamo effettivamente realizzato

I passaggi che usano modelli linguistici (l'AI digest con argomenti, decisioni e action items, i riassunti dei documenti, le azioni generative dell'editor di note AI, Ask AI e Mia) girano sul gateway AI scelto dalla vostra organizzazione: Azure OpenAI nella EU Data Zone per impostazione predefinita, Vertex AI sull'endpoint multi-regione UE oppure Amazon Bedrock a Francoforte su scelta, ciascuno nel nostro tenant con zero data retention e senza addestramento sui contenuti dei clienti; oppure il vostro endpoint compatibile con OpenAI, che mantiene il modello su un'infrastruttura che controllate voi. Il riassunto post-meeting e l'azione traduci dell'editor passano dal percorso di traduzione, non dal modello linguistico. Voce in tempo reale, chat, note e documenti non si sono mai avvicinati a un LLM generalista.

Questa è la forma onesta di questo livello: i modelli sono proprietari e i loro fornitori sono aziende statunitensi che operano regioni nella UE, lo stesso compromesso dell'infrastruttura di base qui sopra, dichiarato accanto a quest'ultima invece che nascosto. Al posto di un nostro modello self-hosted, ciò che abbiamo realizzato è la scelta: un'organizzazione può disattivare del tutto l'AI (trascrizione e traduzione continuano a funzionare) e può indirizzare ogni funzione AI al proprio endpoint (vLLM nel proprio data center, un deployment nel proprio tenant), il che colloca questo livello sullo stesso asse open e self-hostable del resto del data plane. Il nostro benchmark di traduzione pubblico è valutato da un giudice LLM (Gemini, con Claude come riserva) su frasi di riferimento fisse di FLORES-200, mai sul meeting di qualcuno.

Perché conta oltre noi

Non è ingegneria fine a sé stessa. Il motivo per costruire uno stack in questo modo si vede dal vostro lato del contratto:

1. Sottoponibile ad audit. L'SDK su cui gira il vostro meeting è codice open source che il vostro team di sicurezza può leggere, e il motore che sta dietro è nostro, non la scatola nera di un terzo.
2. Portabile. Standard aperti a ogni livello dei dati (Postgres, S3, OIDC) significano nessun lock-in proprietario. Ciò che può essere spostato non è legato a un unico fornitore.
3. Self-hostable. I livelli di dati basati su standard aperti (Postgres, S3, OIDC) girano già su un'infrastruttura che controllate voi; un motore di traduzione completamente self-hosted è nella roadmap per il tenant che ne ha bisogno.

Questo è il quadro al 2026-06-07. Lo aggiorneremo quando lo stack cambierà: un fornitore sostituito, un livello ricostruito, il modello del digest rimpiazzato. La configurazione attuale è verificabile nel nostro vercel.json aperto, nel nostro nuxt.config.ts e nel repository mind-sdk BSD-3-Clause linkato sopra.

Se un livello qui descritto vi sembra sbagliato, o se la vostra revisione di sicurezza ha bisogno di una risposta che questa mappa non dà, scriveteci. Preferiamo correggere un dettaglio mancante piuttosto che vederlo scoperto da voi durante un audit del codice.

Fonti: il repository mind-sdk (BSD-3-Clause), FLORES-200; i fatti sullo stack sono stati verificati rispetto alla configurazione distribuita (vercel.json, nuxt.config.ts) e al codice rilasciato, controllati ad agosto 2026.