Dove si svolge effettivamente una riunione su InterMIND

Ogni conversazione seria sugli appalti aziendali arriva prima o poi alla stessa domanda: "Dove finiscono questi dati?" Il DPO vuole un elenco di sub-responsabili del trattamento. Il CIO vuole sapere quali fornitori hanno sede negli Stati Uniti. L'ufficio legale vuole un diagramma con le frecce.

Preferiamo darti il quadro completo piuttosto che inviartelo pezzo per pezzo via email. Ecco quindi il percorso dei dati di una riunione — ogni servizio esterno che tocca, dove ciascuno viene eseguito e quali dati vi passano. Verificato rispetto all'effettiva configurazione di distribuzione in data 2026-05-28.

Ogni percorso che tocca i contenuti della riunione si svolge nell'UE a runtime — inclusi i passaggi dell'AI, che girano sull'AI gateway selezionato dalla tua organizzazione, in una regione UE del nostro tenant. I fornitori dietro quel gateway sono aziende statunitensi che gestiscono regioni UE; lo diciamo chiaramente di seguito, e specifichiamo quale modello rimane del tutto esterno alla riunione.

Questo articolo mappa dove si svolge la tua riunione. Il suo complementare, Da cosa è composta una riunione su InterMIND, mappa da cosa è composta — quali livelli sono codice nostro, quali sono open source e dove siamo pragmatici riguardo al SaaS proprietario.

Cosa significa davvero "dove viene eseguito"

Nelle conversazioni sulla sovranità vengono spesso confuse due cose che non sono la stessa cosa:

1. Runtime / percorso dei dati. Dove i byte della tua riunione vengono fisicamente elaborati durante la richiesta. Questo è ciò di cui trattano davvero le normative sulla residenza dei dati e la maggior parte dei DPA.
2. Sede legale del fornitore. Dove il fornitore SaaS è legalmente costituito. Questo è l'argomento delle discussioni sul CLOUD Act — la portata teorica di un'ingiunzione statunitense contro l'entità madre del fornitore, indipendentemente da dove viene eseguito il carico di lavoro.

Quasi ogni domanda sul "è nell'UE?" è in realtà una di queste due, posta in modo impreciso. Rispondiamo a ciascuna separatamente per ogni fornitore di seguito.

Il percorso dei dati di una riunione

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

1. Il browser apre la pagina della riunione. L'SSR gira su Vercel, fissato a fra1 (Francoforte). Tutti i dati di richiesta/risposta — cookie di sessione, payload API, HTML renderizzato lato server — vengono elaborati nell'UE a runtime.
2. Il WebSocket si connette al nostro server della riunione a Parigi (cdg). Orchestrazione della riunione, presenza, segnalazione — tutto nell'UE.
3. Il riconoscimento vocale gira sul nostro media server. L'audio arriva tramite WebRTC al nostro motore proprietario — la Mind API su OVH, in Francia — e viene riconosciuto lì, parola per parola, sullo stesso server che trasporta la chiamata; nessun servizio di riconoscimento vocale di terze parti è coinvolto. Le note vocali in chat sono l'unica eccezione: il loro speech-to-text gira su Azure AI Speech, il servizio vocale del gateway AI predefinito (tabella dei fornitori sotto). La pipeline stessa è descritta in Dentro le quattro pipeline di traduzione.
4. La traduzione vocale e chat raggiunge il nostro motore su OVH Francia. Si tratta di mind-sdk + la Mind API — il nostro codice, i nostri host, in Francia. Nessun modello di terze parti è coinvolto. Budget inferiore al secondo, una traduzione per ogni lingua di destinazione presente nella stanza, residente nell'UE a ogni passaggio.
5. Un documento inserito in chat (PDF, DOCX, DOC, PPTX, XLSX) passa lato server dal ws-server di Parigi a DeepL a Colonia. Azienda tedesca, elaborazione tedesca. Voce e chat non toccano DeepL.
6. I dati dell'applicazione — utenti, team, messaggi, metadati delle riunioni — risiedono in Neon Postgres su AWS Francoforte (eu-central-1). Snapshot nella stessa regione.
7. Registrazioni, allegati, export vengono archiviati su Tigris, storage compatibile S3 su Fly. Replicato edge; il bucket è configurabile su multi-regione UE per i tenant che necessitano di un ancoraggio più rigoroso.
8. Errori e tracce delle prestazioni vanno all'istanza UE di Sentry (de.sentry.io). L'organizzazione statunitense è stata disattivata a maggio.
9. Le analytics di prodotto vanno su PostHog UE (eu.i.posthog.com).
10. Le email transazionali (magic link, inviti, ricevute) passano tramite Resend da eu-west-1 (Irlanda).

Tutto quanto sopra si svolge nell'UE a runtime. Il motore di traduzione — la parte attraverso cui passa effettivamente la maggior parte dei tuoi dati — è anch'esso codice nostro, non di terze parti. L'SDK client su cui gira è open source (BSD-3-Clause) e auditabile oggi; l'hosting autonomo del motore stesso è in roadmap per un cliente che ne abbia bisogno.

La mappa dei fornitori

I due flussi di dati più pesanti per volume — la traduzione vocale/chat tramite il nostro motore su OVH e la traduzione dei documenti tramite DeepL — sono anche i due fornitori la cui entità madre si trova nell'UE. Questo copre la maggior parte del contenuto delle riunioni. L'elenco completo dei sub-responsabili del trattamento con i dettagli sulla sede legale va nel DPA come prassi standard; la tabella sopra è la vista a runtime, che è ciò di cui trattano la maggior parte delle clausole sulla residenza dei dati.

I passaggi AI, chiaramente esplicitati

Dopo la fine della chiamata eseguiamo alcuni passaggi con il modello linguistico su ciò che è stato detto: il digest AI (argomenti, decisioni, action items, domande aperte), il riassunto post-riunione e l'editor di note AI (tradurre una nota, o correggerla/estenderla/semplificarla). Durante la chiamata, lo stesso tipo di passaggio scrive un riassunto di ogni documento inserito in chat e risponde ad Ask AI e Mia. Questi sono gli unici punti in cui un modello per uso generico tocca i contenuti derivati dalla riunione, e tutti vanno in un unico posto:

• L'AI gateway selezionato dalla tua organizzazione. Un unico resolver nel codice lo seleziona per ogni punto di chiamata; non c'è una seconda via. Il predefinito è Azure OpenAI nell'EU Data Zone; dalle sue impostazioni un'organizzazione passa a Vertex AI sull'endpoint multi-regione UE o Amazon Bedrock a Francoforte, o indirizza ogni funzionalità AI al proprio endpoint compatibile con OpenAI — vLLM nel proprio data center, un deployment nel proprio tenant. Ogni gateway ospitato gira nel nostro tenant, configurato per zero data retention e nessun training sui contenuti dei clienti; il fallback rimane sullo stesso gateway — una seconda regione UE o un secondo modello dello stesso fornitore — mai un altro fornitore. I documenti sulle funzionalità AI elencano i gateway e le regioni.
• Il riassunto e l'azione traduci dell'editor passano attraverso il canale di traduzione, non il modello linguistico — lo stesso percorso che traduce la chat in diretta.
• L'AI può essere disattivata per l'intera organizzazione: la trascrizione e la 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 attraverso nessuno di questi — sono residenti nell'UE fin dall'inizio.

Dove si trovano i fornitori: Microsoft, Google e Amazon sono aziende statunitensi che gestiscono regioni UE. Questo è dichiarato chiaramente nella pagina sull'affidabilità, non nascosto — è la questione sulla sede legale trattata all'inizio di questo articolo, risolta per questo passaggio allo stesso modo in cui lo è per l'infrastruttura. Un modello rimane del tutto esterno alla riunione: il nostro benchmark pubblico sulla qualità della traduzione utilizza un LLM giudice (Gemini, con Claude come fallback, tramite Vercel AI Gateway) per valutare le traduzioni automatiche delle frasi di riferimento di FLORES-200. È un dataset pubblico e fisso — non la riunione di nessuno.

Cosa significa per il tuo DPA

Per la maggior parte degli acquirenti UE — la Mittelstand tedesca, le industrie regolate che utilizzano i DPA standard del GDPR — il quadro sopra risponde direttamente alla questione della residenza dei dati: ogni passaggio a runtime della tua riunione avviene nell'UE. La sede del fornitore viene divulgata nell'elenco dei sub-responsabili del trattamento secondo la prassi normale; niente di sorprendente lì. La mappa di residenza è un pezzo; per il resto degli obblighi di protezione dei dati — cancellazione, conservazione, portabilità, consenso — abbiamo sottoposto il codebase a un audit completo e chiuso ogni punto rispetto al codice.

Per il souveraineté numérique francese e gli appalti di livello SecNumCloud, la sede legale del fornitore è essa stessa parte del criterio, non solo la posizione a runtime. È una conversazione diversa — una topologia di distribuzione alternativa che mantiene ogni componente presso fornitori sotto giurisdione europea. Non la eseguiamo per impostazione predefinita; la attiveremo per un tenant che ne ha bisogno e dove il contratto giustifica la creazione.

Per gli acquirenti domestici statunitensi e la maggior parte di quelli APAC, è vero solitamente il contrario — vogliono una bassa latenza dalla loro regione, che è un problema diverso. Oggi operiamo su singola regione in fra1. Se il tuo traffico giustifica un edge negli Stati Uniti, lo pianificheremo con te.

A cosa ci impegna questo articolo

Questo è il quadro al 2026-05-28. Lo aggiorneremo quando lo stack cambia — cambio fornitore, migrazione di regione, un nuovo servizio esterno. L'attuale configurazione è verificabile nel nostro vercel.json aperto, nel motore mind-sdk + Mind API in esecuzione su OVH Francia, e in ogni dashboard dei fornitori.

Se qualcosa qui sembra sbagliato, o il tuo DPO ha bisogno di una risposta che questa mappa non fornisce, scrivici. Preferiamo correggere un dettaglio mancante piuttosto che farti scoprire durante una revisione del contratto.

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