Dove gira davvero un meeting InterMIND

Prima o poi qualcuno dalla parte dell'host (l'IT di un cliente, un DPO, un partner prudente) pone sempre la stessa domanda: "Dove vanno a finire questi dati?" Vuole un elenco dei sub-responsabili, il domicilio dei fornitori e uno schema con le frecce.

Preferiamo darvi il quadro completo piuttosto che inviarlo a pezzi via email. Ecco quindi il percorso dei dati di un meeting: ogni servizio esterno che tocca, dove viene eseguito e quali dati lo attraversano. Verificato rispetto alla configurazione effettiva del deployment il 2026-05-28.

Ogni percorso che tocca i contenuti del meeting è in UE a runtime, compresi i passaggi AI, che girano sul gateway AI scelto dalla vostra organizzazione, in una regione UE del nostro tenant. I fornitori dietro quel gateway sono società statunitensi che operano regioni UE: lo diciamo apertamente più avanti, insieme a quale modello si trova del tutto fuori dal meeting.

Questo articolo mappa dove gira il vostro meeting. Il suo complemento, Di cosa è fatto un meeting InterMIND, mappa di cosa è fatto: quali livelli sono codice nostro, quali open source e dove siamo pragmatici con il SaaS proprietario.

Cosa significa davvero "dove gira"

Nelle discussioni sulla sovranità si confondono due cose che non sono la stessa cosa:

1. Runtime / percorso dei dati. Dove i byte del vostro meeting vengono elaborati fisicamente durante la richiesta. È il tema delle normative sulla residenza dei dati e della maggior parte dei DPA.
2. Domicilio societario del fornitore. Dove il fornitore SaaS è legalmente costituito. È il tema delle discussioni sul CLOUD Act: la portata teorica di un'ingiunzione statunitense verso la capogruppo del fornitore, indipendentemente da dove giri il carico di lavoro.

Quasi ogni domanda del tipo "è UE?" è in realtà una di queste due, posta in modo impreciso. Qui sotto rispondiamo a entrambe separatamente, fornitore per fornitore.

Il percorso dei dati di un meeting

Seguiamo una chiamata dall'ingresso all'email di follow-up:

1. Il browser apre la pagina del meeting. L'SSR gira su Vercel, fissato su fra1 (Francoforte). Tutti i dati di richiesta/risposta (cookie di sessione, payload API, HTML renderizzato lato server) sono elaborati in UE a runtime.
2. Il WebSocket si collega al nostro server del meeting a Parigi (cdg). Orchestrazione del meeting, presenza, signalling: tutto in UE.
3. Il riconoscimento vocale gira sul nostro media server. L'audio arriva via WebRTC al nostro motore (la Mind API su OVH, Francia) e viene riconosciuto lì, parola per parola, sullo stesso server che regge la chiamata; nessun servizio vocale di terze parti è coinvolto. I messaggi vocali in chat sono l'unica eccezione: la loro trascrizione gira su Azure AI Speech, il servizio vocale del gateway AI predefinito (tabella dei fornitori più sotto). La pipeline è descritta in Dentro le quattro pipeline di traduzione.
4. La traduzione di voce e chat passa dal nostro motore su OVH in Francia. Si tratta di mind-sdk + la Mind API: codice nostro, host nostri, in Francia. Nessun modello di terze parti è coinvolto. Una traduzione per ogni lingua di destinazione presente nella stanza, con residenza UE a ogni passaggio.
5. Un documento caricato in chat (PDF, DOCX, DOC, PPTX, XLSX) va, lato server, dal ws-server di Parigi a DeepL a Colonia. Azienda tedesca, elaborazione in Germania. Voce e chat non toccano DeepL.
6. I dati applicativi (utenti, team, messaggi, metadati dei meeting) risiedono su Neon Postgres su AWS Francoforte (eu-central-1). Gli snapshot sono nella stessa regione.
7. Registrazioni, allegati ed esportazioni sono archiviati su Tigris, storage compatibile S3 su Fly. Replicato sull'edge; il bucket è configurabile su multi-regione UE per i tenant che ne hanno bisogno con un vincolo più stretto.
8. Errori e tracce di performance vanno all'istanza UE di Sentry (de.sentry.io). L'organizzazione statunitense è stata dismessa a maggio.
9. L'analytics di prodotto va a PostHog EU (eu.i.posthog.com).
10. Le email transazionali (magic link, inviti, ricevute) partono tramite Resend da eu-west-1 (Irlanda).

Tutto quanto sopra è in UE a runtime. Il motore di traduzione, la parte da cui passa la maggior parte dei vostri dati, è anch'esso codice nostro, non di terzi. L'SDK client su cui gira è open source (BSD-3-Clause) e auditabile fin da oggi; l'self-hosting del motore stesso è nella roadmap per i clienti che ne hanno bisogno.

La mappa dei fornitori

I due flussi di dati più pesanti per volume, la traduzione di voce/chat attraverso il nostro motore su OVH e la traduzione di documenti attraverso DeepL, sono anche i due fornitori la cui capogruppo ha sede nell'UE. Questo copre la gran parte dei contenuti del meeting. L'elenco completo dei sub-responsabili, con il dettaglio del domicilio societario, entra nel DPA come prassi standard; la tabella qui sopra è la vista a runtime, che è ciò a cui si riferiscono la maggior parte delle clausole sulla residenza dei dati.

I passaggi AI, nominati apertamente

Al termine della chiamata eseguiamo alcuni passaggi con modelli linguistici su ciò che è stato detto: il digest AI (argomenti, decisioni, action items, domande aperte), il riassunto post-meeting e l'editor di note AI (tradurre una nota, oppure correggerla / ampliarla / semplificarla). Durante la chiamata lo stesso tipo di passaggio scrive un riassunto di ogni documento caricato in chat e risponde a Ask AI e Mia. Sono gli unici punti in cui un modello generalista tocca contenuti derivati dal meeting, e tutti vanno in un unico posto:

• Il gateway AI scelto dalla vostra organizzazione. Un unico resolver nel codice lo seleziona per ogni punto di chiamata; non esiste un secondo percorso. Il predefinito è Azure OpenAI nella EU Data Zone; dalle impostazioni un'organizzazione passa a Vertex AI sull'endpoint multi-regione UE o ad Amazon Bedrock a Francoforte, oppure indirizza ogni funzione AI verso un proprio endpoint compatibile con OpenAI: vLLM nel proprio data center, un deployment nel proprio tenant. Ogni gateway ospitato gira nel nostro tenant, configurato con zero conservazione dei dati e nessun addestramento sui contenuti dei clienti; il fallback resta sullo stesso gateway (una seconda regione UE, o un secondo modello dello stesso fornitore), mai un altro fornitore. La documentazione sulle funzioni AI elenca i gateway e le regioni.
• Il riassunto e l'azione traduci dell'editor passano per il percorso di traduzione, non per il modello linguistico: lo stesso percorso che traduce la chat dal vivo.
• L'AI può essere disattivata per l'intera organizzazione: trascrizione e traduzione continuano a funzionare; il digest, i riassunti dei documenti, l'assistente di scrittura e Ask AI si fermano.

La voce in tempo reale, la chat in tempo reale, le note e la traduzione dei documenti non passano mai da nessuno di questi: sono state fin dall'inizio residenti in UE.

Dove si trovano i fornitori: Microsoft, Google e Amazon sono società statunitensi che operano regioni UE. Lo diciamo qui apertamente, senza nasconderlo: è la questione del domicilio societario posta all'inizio di questo articolo, con la stessa risposta data per questo passaggio come per l'infrastruttura di base. Un modello si trova del tutto fuori dal meeting: il nostro benchmark pubblico della qualità di traduzione usa un LLM come giudice (Gemini, con Claude come fallback, tramite l'AI Gateway di Vercel) per valutare le traduzioni automatiche di frasi di riferimento di FLORES-200. È un dataset fisso e pubblico, non il meeting di qualcuno.

Cosa significa per il vostro DPA

Per la maggior parte degli acquirenti UE, come il Mittelstand tedesco o i settori regolamentati con DPA GDPR standard, il quadro qui sopra risponde direttamente alla domanda sulla residenza dei dati: ogni passaggio a runtime del vostro meeting avviene in UE. Il domicilio dei fornitori viene dichiarato nell'elenco dei sub-responsabili secondo la prassi normale; nulla di sorprendente. La mappa della residenza è un tassello; per tutti gli altri obblighi di protezione dei dati (cancellazione, conservazione, portabilità, consenso) abbiamo sottoposto il codice a un audit completo e chiuso ogni punto rispetto al codice.

Per la souveraineté numérique francese e gli appalti di livello SecNumCloud, il domicilio societario del fornitore è esso stesso parte del criterio, non solo l'ubicazione a runtime. È un'altra conversazione: una topologia di deployment alternativa che mantiene ogni componente sotto fornitori di giurisdizione europea. Non la eseguiamo per impostazione predefinita; la attiveremo per un tenant che ne ha bisogno e dove il contratto giustifica la realizzazione.

Per gli acquirenti statunitensi e per la maggior parte di quelli dell'area APAC, di solito vale l'inverso: vogliono bassa latenza dalla loro regione, che è un problema diverso. Oggi operiamo su una singola regione, fra1. Se il vostro traffico giustifica un edge negli Stati Uniti, lo pianificheremo insieme a voi.

A cosa ci impegna questo articolo

Questo è il quadro al 2026-05-28. Lo aggiorneremo quando lo stack cambia: cambio di fornitore, migrazione di regione, un nuovo servizio esterno. La configurazione attuale è verificabile nel nostro vercel.json aperto, nel motore mind-sdk + Mind API in esecuzione presso OVH in Francia e nella dashboard di ciascun fornitore.

Se qualcosa qui vi sembra sbagliato, o il vostro DPO ha bisogno di una risposta che questa mappa non dà, scriveteci. Preferiamo correggere un dettaglio mancante piuttosto che vederlo scoperto durante la revisione di un contratto.

Fonti: regioni a runtime e instradamento dei modelli verificati rispetto alla configurazione in produzione (vercel.json, fly.toml) e al codice rilasciato; Vercel AI Gateway (il percorso di provider-pinning del digest), FLORES-200; verificato ad agosto 2026.