Videoconferenze e GDPR: quale piattaforma scegliere alla luce del CLOUD Act e della crittografia end-to-end

Il problema: videoconferenze e dati personali

Le videoconferenze sono ormai uno strumento quotidiano per professionisti, istituzioni, studi legali, strutture sanitarie e scuole. Tuttavia, la scelta della piattaforma non è una decisione puramente tecnica: è una scelta che incide direttamente sugli obblighi derivanti dal GDPR, sulla sicurezza dei dati sensibili e sulla sovranità digitale dell’organizzazione.

Una videoconferenza genera, come minimo, i seguenti trattamenti di dati personali: audio e video dei partecipanti, nomi e indirizzi email, metadati (orario, durata, indirizzi IP, tipo di dispositivo), chat testuali, contenuti condivisi tramite screen sharing, eventuali registrazioni.

La domanda chiave è: chi ha accesso a questi dati, dove vengono trattati, e con quali garanzie giuridiche e tecniche?

In un precedente contributo abbiamo analizzato la questione dei metadati nel contesto della messaggistica istantanea. Le stesse considerazioni si applicano, a maggior ragione, alle piattaforme di videoconferenza, dove il volume e la sensibilità dei dati trattati sono significativamente superiori.

Il quadro normativo di riferimento

GDPR: i principi rilevanti

L’Art. 48, in particolare, è il riferimento normativo più diretto per la questione della compelled disclosure da parte di autorità di paesi terzi: stabilisce che le decisioni giurisdizionali o amministrative di un paese terzo che richiedano a un titolare o a un responsabile di trasferire o comunicare dati personali possono essere riconosciute o rese esecutive solo se basate su un accordo internazionale. Questo articolo fonda, nel corpo stesso del GDPR, la problematicità delle richieste di produzione di dati formulate da autorità statunitensi ai sensi del CLOUD Act in assenza di un accordo bilaterale UE-USA specifico.

Il CLOUD Act e il rischio di accesso extraterritoriale

Il Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) chiarisce che i provider di servizi soggetti alla giurisdizione statunitense devono produrre i dati in loro possesso oggetto di valido processo legale statunitense, anche se tali dati sono conservati al di fuori degli Stati Uniti. La disposizione chiave è il 18 U.S.C. § 2713, che impone ai provider di preservare, effettuare il backup e comunicare i contenuti delle comunicazioni e gli altri dati dei clienti “regardless of whether such communication, record, or other information is located within or outside of the United States.”

Esempio pratico: un’organizzazione europea utilizza Zoom per una riunione riservata. Le autorità statunitensi, nell’ambito di un’indagine, richiedono a Zoom di produrre i dati della riunione. Nonostante i server siano in Europa, Zoom è tenuto a conformarsi alla richiesta. Questo scenario è noto come compelled disclosure e rappresenta un rischio strutturale per le organizzazioni europee.

Non si tratta di un accesso automatico o inevitabile, ma di un fattore strutturale di rischio giuridico e organizzativo che il titolare del trattamento europeo è tenuto a valutare ai sensi del Capo V del GDPR — e, in particolare, alla luce dell’Art. 48.

Il Data Privacy Framework: stato attuale

La sentenza della Corte di Giustizia dell’Unione europea nella causa C-311/18 (Schrems II) ha invalidato il Privacy Shield e ha imposto ai titolari del trattamento di valutare, caso per caso, se le garanzie del paese terzo di destinazione siano adeguate. Nel luglio 2023 la Commissione europea ha adottato una nuova decisione di adeguatezza sulla base del EU-US Data Privacy Framework (DPF).

Il DPF è tuttora in vigore. La Commissione ha pubblicato il rapporto sul primo riesame periodico il 9 ottobre 2024 (COM(2024) 451 final). L’EDPB ha pubblicato il proprio rapporto sul primo riesame il 4 novembre 2024, esaminando sia gli aspetti commerciali sia l’accesso da parte delle autorità pubbliche statunitensi. Il Tribunale dell’Unione europea, con sentenza del 3 settembre 2025 nella causa T-553/23 (Latombe c. Commissione), ha respinto l’azione di annullamento del framework. Tuttavia, il 31 ottobre 2025 è stato depositato un appello dinanzi alla Corte di Giustizia (Causa C-703/25 P): la stabilità giuridica del DPF è dunque migliorata rispetto al periodo immediatamente successivo all’adozione, ma non è definitiva.

Il DPF, in ogni caso, non elimina la portata del CLOUD Act, che opera su un piano giuridico distinto dalla base di adeguatezza per i trasferimenti. A mio avviso, il rischio di compelled disclosure derivante dal CLOUD Act rappresenta un fattore strutturale di rischio giuridico e organizzativo per qualsiasi organizzazione europea che tratti dati sensibili — riunioni riservate, consulenze legali, sedute di organi collegiali, colloqui clinici — attraverso piattaforme soggette alla giurisdizione statunitense, indipendentemente dalla sussistenza del DPF.

La crittografia end-to-end come misura tecnica

L’Art. 32 del GDPR cita esplicitamente la cifratura tra le misure tecniche appropriate. La crittografia end-to-end (E2EE) — in cui i dati sono cifrati sul dispositivo del mittente e decifrabili solo dal destinatario, senza che il provider del servizio possa accedervi — rappresenta la forma più forte di protezione tecnica dei dati in transito.

L’efficacia della cifratura come misura supplementare ai sensi della Raccomandazione EDPB 01/2020 dipende da un elemento cruciale: chi controlla le chiavi. Se il provider può accedere alle chiavi di decifratura — o se le chiavi sono accessibili a un’autorità di un paese terzo che raggiunge il provider — la cifratura in transito non costituisce, da sola, una misura supplementare efficace contro il rischio di compelled disclosure.

Non tutte le piattaforme offrono E2EE per impostazione predefinita. Non tutte quelle che la offrono la estendono alle chiamate di gruppo senza trade-off funzionali significativi. Questa distinzione è giuridicamente rilevante ai sensi dell’Art. 25 GDPR (privacy by default).

Il problema della E2EE nelle chiamate di gruppo e il protocollo MLS

La cifratura end-to-end per le chiamate 1:1 è un problema tecnicamente risolto da tempo. La sfida è diversa per le chiamate di gruppo: in un modello tradizionale (come OpenPGP, usato da Proton Mail), ogni messaggio deve essere cifrato separatamente per ciascun destinatario con la sua chiave pubblica. Il costo computazionale e di banda cresce linearmente con il numero di partecipanti, rendendo questo approccio impraticabile per una videoconferenza con decine di persone.

Il protocollo Messaging Layer Security (MLS), divenuto standard IETF nel 2023 (RFC 9420), risolve questo problema. MLS organizza i partecipanti in una struttura ad albero binario che consente di gestire le chiavi crittografiche in modo efficiente anche per gruppi numerosi. Quando un partecipante entra o esce dalla riunione, le chiavi vengono ruotate: chi entra non può accedere ai contenuti precedenti, chi esce non può accedere ai contenuti successivi. Il risultato è una E2EE di gruppo che scala senza richiedere al provider l’accesso ai contenuti.

Questo è il motivo per cui MLS è rilevante nella tabella comparativa: è il protocollo che rende tecnicamente possibile offrire E2EE come impostazione predefinita per le chiamate di gruppo, senza i trade-off funzionali che caratterizzano le implementazioni E2EE di Zoom e Teams.

Analisi comparativa delle piattaforme

Zoom, Microsoft Teams, Google Meet

Queste tre piattaforme sono soggette alla giurisdizione statunitense e, pertanto, al CLOUD Act. Anche quando offrono data center in Europa, il soggetto giuridico titolare del servizio è statunitense, con le conseguenze sopra descritte in termini di rischio di compelled disclosure e di applicazione dell’Art. 48 GDPR.

Sul piano della crittografia, il quadro al 2026 è più articolato rispetto a qualche anno fa, ma la distinzione chiave resta tra cifratura generalizzata e opzioni limitate a scenari specifici.

Zoom ha introdotto E2EE per le chiamate di gruppo come opzione attivabile, ma il suo utilizzo comporta la disabilitazione di numerose funzionalità che richiedono accesso lato server, incluse le funzionalità AI Companion. Le riunioni E2EE sono inoltre limitate a client/endpoint compatibili.

Microsoft Teams supporta oggi E2EE anche per le riunioni di gruppo (fino a 200 partecipanti), ma si tratta di una modalità controllata da policy amministrative, limitata a specifici endpoint (non supportata su web, VDI, dispositivi CVI), e potenzialmente legata alla licenza Teams Premium per gli organizzatori. Restano escluse funzionalità che richiedono l’accesso ai contenuti lato servizio: trascrizione, live captions, PowerPoint Live, Copilot. In Teams, la E2EE è dunque una modalità configurabile dall’amministratore, non una postura di sicurezza predefinita.

Google Meet presenta un quadro che richiede una distinzione precisa tra due modalità diverse:

• Per gli account personali, le chiamate possono utilizzare una additional encryption end-to-end, attivabile tramite un toggle che disabilita funzionalità cloud (messaggi, reazioni, sondaggi, Q&A, add-on, segnalazione abusi). Per gli account Business ed Education, questo toggle non è disponibile: le chiamate sono sempre cloud-encrypted.
• Per gli account Google Workspace, è disponibile la client-side encryption (CSE), in cui i flussi media sono cifrati nel browser dei partecipanti con chiavi rese disponibili solo ai partecipanti e non leggibili dai server Google. La CSE richiede che l’amministratore colleghi Workspace a un identity provider esterno e a un servizio di gestione delle chiavi.

Né l’additional encryption né la CSE costituiscono una E2EE generalizzata e attiva per impostazione predefinita in ogni tipologia di riunione.

Il trade-off tra E2EE e funzionalità operative è significativo e documentato dagli stessi produttori:

In sintesi, tutte e tre le piattaforme offrono oggi opzioni di cifratura avanzata, ma nessuna di esse applica E2EE come modalità predefinita e priva di limitazioni. In un contesto in cui la protezione deve essere il default — non l’eccezione attivabile dall’utente consapevole — questa distinzione resta giuridicamente significativa ai sensi dell’Art. 25 GDPR (privacy by default).

Utilizzo dei dati per l’addestramento di modelli AI. Zoom dichiara espressamente di non utilizzare audio, video, chat, screen sharing e altri customer content per addestrare i propri modelli AI o quelli di terzi, pur descrivendo circostanze limitate in cui l’accesso ai contenuti può avvenire (autorizzazione, sicurezza, supporto). Google Workspace dichiara di non utilizzare i dati del cliente per addestrare modelli generativi senza previo permesso o istruzione del cliente. La criticità residua non riguarda tanto l’addestramento AI in senso stretto, ma l’accesso tecnico ai contenuti da parte del provider e la giurisdizione applicabile a tale accesso: le privacy policy restano soggette a modifiche unilaterali.

Implicazione per il titolare: un’organizzazione europea che utilizza queste piattaforme per riunioni riservate deve valutare, ai sensi dell’Art. 35 GDPR, se il trattamento presenta un rischio elevato per i diritti e le libertà degli interessati. Nella mia lettura, per trattamenti che coinvolgono dati particolari (Art. 9), dati di minori, o comunicazioni coperte da segreto professionale, la risposta è affermativa.

Jitsi Meet

Jitsi Meet è una piattaforma open source per videoconferenze, distribuita sotto licenza Apache 2.0.

Giurisdizione: dipende dalla modalità di utilizzo. L’istanza pubblica (meet.jit.si) è gestita da 8x8, Inc., società statunitense. Dal 24 agosto 2023, la creazione di riunioni sull’istanza pubblica richiede l’autenticazione tramite account Google, GitHub o Facebook. Chi utilizza l’istanza pubblica è soggetto alle stesse considerazioni giurisdizionali valide per le piattaforme statunitensi. Tuttavia, Jitsi può essere installato su un proprio server (self-hosting), il che consente di mantenere il pieno controllo sui dati e sulla giurisdizione applicabile.

Crittografia: Jitsi utilizza DTLS-SRTP per la cifratura dei flussi audio e video. La documentazione ufficiale di Jitsi distingue tre scenari:

• Chiamate 1:1 in modalità P2P: la cifratura DTLS-SRTP è end-to-end tra i partecipanti, anche in caso di transito attraverso server TURN.
• Chiamate multiparty via Jitsi Videobridge (SFU), modalità predefinita: i pacchetti sono cifrati sulla rete con DTLS-SRTP, ma il livello esterno di cifratura viene rimosso durante il transito attraverso il videobridge. Jitsi precisa che i pacchetti non sono memorizzati in modo persistente ma esistono solo in memoria durante l’instradamento.
• Chiamate multiparty con E2EE opzionale: Jitsi supporta un livello aggiuntivo di cifratura end-to-end tramite insertable streams, disponibile sui browser basati su Chromium e sul client Electron. Quando questa modalità è attiva, il videobridge non può rimuovere il livello di cifratura aggiuntivo. Questa funzionalità è tuttavia dipendente dal client e comporta limitazioni funzionali.

Punto di forza: il self-hosting. Un’organizzazione che gestisce il proprio server Jitsi mantiene il pieno controllo sui dati, elimina l’esposizione al CLOUD Act, e può configurare il servizio in conformità con il principio di privacy by design.

Punto critico infrastrutturale: il self-hosting riduce la dipendenza da provider SaaS statunitensi, ma la scelta dell’infrastruttura su cui il server è ospitato resta rilevante. Se Jitsi viene installato su un’infrastruttura cloud controllata da un provider soggetto alla giurisdizione di un paese terzo (ad esempio AWS, Azure o GCP), il rischio di accesso extraterritoriale può ripresentarsi a livello infrastrutturale. Questo è coerente con l’approccio dell’EDPB, che include nella valutazione dei trasferimenti anche l’accesso remoto, il cloud storage e i pattern di sub-processing.

Proton Meet

Proton Meet, lanciato il 31 marzo 2026, è il servizio di videoconferenza di Proton AG, società svizzera con sede a Ginevra.

Giurisdizione: Svizzera. Proton non è soggetta al CLOUD Act. La Svizzera dispone di una decisione di adeguatezza ai sensi dell’Art. 45 GDPR per i trasferimenti di dati personali dall’UE.

Architettura e crittografia: Proton Meet utilizza il protocollo Messaging Layer Security (MLS), standard IETF, per la cifratura end-to-end di audio, video, screen share e chat. La cifratura avviene lato client: Proton dichiara di non poter accedere al contenuto delle riunioni, nemmeno in caso di compromissione dei propri server. La password della riunione è generata localmente sul dispositivo dell’host e non viene mai trasmessa ai server Proton: i server ricevono solo un verificatore crittografico (protocollo SRP). I nomi dei partecipanti sono cifrati end-to-end; indirizzi email e indirizzi IP non sono condivisi tra i partecipanti. L’infrastruttura è costituita da una rete distribuita di data center, con giurisdizione svizzera sul soggetto titolare del servizio — ferma restando la distinzione tra giurisdizione del provider e localizzazione tecnica dell’infrastruttura. Le applicazioni sono open source, il che consente una verifica indipendente delle dichiarazioni di sicurezza. Per approfondimenti tecnici si rinvia al modello di sicurezza e alla pagina sulla sicurezza del servizio.

Limiti da considerare: Proton Meet non è self-hostabile. L’organizzazione si affida all’infrastruttura di Proton. La E2EE riduce il rischio di confidenzialità (il provider non può leggere i contenuti), ma non elimina il rischio di disponibilità: Proton stessa osserva che una compromissione dei server SFU potrebbe consentire il blocco o la censura dell’inoltro dei dati, senza però rivelare il contenuto delle riunioni. Il servizio è appena lanciato: la maturità operativa andrà verificata nel tempo. Nella versione gratuita, le riunioni sono limitate a 50 partecipanti per un massimo di un’ora; il piano professionale parte da 7,99 €/utente/mese.

Integrazione nell’ecosistema: Proton Meet si integra con Proton Calendar, Proton Mail e l’intero ecosistema Proton Workspace (Mail, Calendar, Drive, Docs, Sheets, VPN, Pass), offrendo una suite completa con crittografia end-to-end.

Tabella comparativa: criteri giuridici

Impatti sulla regolamentazione europea dell’innovazione digitale

La scelta della piattaforma di videoconferenza non è soltanto una questione di compliance: si inserisce nel più ampio dibattito sulla sovranità digitale europea.

Nel quadro delle iniziative europee in corso su semplificazione digitale, cloud e infrastrutture AI — dal Digital Omnibus Package, il cui iter legislativo prosegue tra Parlamento e Consiglio, al Cloud and AI Development Act (CADA), che la Commissione prevede di proporre nel 2026, fino al piano per le AI Gigafactories — l’Unione europea sta investendo risorse significative nella costruzione di un ecosistema digitale che riduca la dipendenza da provider extraeuropei.

Il tema non è nuovo. In un contributo del 2020 abbiamo analizzato il concetto di sovranità digitale nella sua duplice dimensione — statale e individuale — argomentando che la sovranità digitale non è prerogativa esclusiva degli Stati, ma si esprime anche nella capacità di soggetti pubblici e privati di esercitare un controllo effettivo sul dominio digitale, in un quadro compatibile con il principio di accountability e con il valore della persona. Quella analisi resta attuale: la scelta degli strumenti di comunicazione da parte di un’organizzazione è essa stessa un atto di sovranità digitale.

In questo contesto più ampio, la scelta di piattaforme di comunicazione soggette alla giurisdizione di paesi terzi — e in particolare al CLOUD Act — merita una riflessione che va oltre la singola valutazione di conformità. A mio avviso, la disponibilità di alternative europee o svizzere con architetture privacy-first — come Jitsi (open source, self-hostabile) o Proton Meet (giurisdizione svizzera, E2EE nativa) — rende oggi più difficile giustificare, sul piano della accountability del titolare, l’adozione di piattaforme che non offrano garanzie equivalenti, almeno per i trattamenti più sensibili.

Impatti sull’utilizzo dell’intelligenza artificiale

Le principali piattaforme di videoconferenza stanno integrando funzionalità basate sull’intelligenza artificiale: trascrizione automatica, riassunti delle riunioni, traduzione in tempo reale, riduzione del rumore, riconoscimento dei partecipanti.

Queste funzionalità, per la loro stessa natura, richiedono che il provider abbia accesso ai contenuti audio e video della chiamata lato server. Ne consegue un trade-off strutturale: le funzionalità AI lato server che richiedono accesso al contenuto della riunione sono tecnicamente incompatibili con la crittografia end-to-end. Dove la E2EE è attiva, il provider non può elaborare i contenuti e le funzionalità AI risultano necessariamente disabilitate. Questo non è un’inferenza teorica: è documentato dagli stessi produttori, che elencano esplicitamente le funzionalità disabilitate quando la E2EE è attiva (inclusi AI Companion su Zoom, Copilot su Teams, e le funzionalità cloud-dependent su Google Meet).

Per il titolare del trattamento, questo trade-off genera una scelta esplicita: funzionalità AI o protezione crittografica dei contenuti. Una scelta che deve essere documentata, motivata e — per i trattamenti a rischio elevato — sottoposta a DPIA.

Vi è poi una dimensione regolamentare ulteriore. Il Regolamento (UE) 2024/1689 (AI Act) incide su alcune funzionalità AI integrate nelle piattaforme di videoconferenza. In particolare:

• L’Art. 5, par. 1, lett. f) vieta i sistemi AI utilizzati per inferire le emozioni delle persone in contesto lavorativo e nelle istituzioni scolastiche, salvo per finalità mediche o di sicurezza. Una funzionalità di analisi delle emozioni dei partecipanti integrata in una piattaforma di videoconferenza utilizzata in ambito scolastico o lavorativo ricadrebbe sotto questa previsione.
• L’Allegato III classifica come ad alto rischio determinati sistemi AI, inclusi quelli utilizzati per il riconoscimento biometrico e per la valutazione, l’ammissione o il monitoraggio in contesto educativo e lavorativo.

Il principio guida, nella mia lettura, è questo: l’integrazione di funzionalità AI nelle piattaforme di videoconferenza non è di per sé problematica, ma lo diventa quando avviene in modo opaco, senza adeguata informazione agli interessati, e senza una valutazione d’impatto che consideri congiuntamente i profili GDPR e AI Act. Per un’analisi specifica delle categorie di rischio nel contesto educativo, si rinvia al nostro recente contributo IA a scuola: 10 categorie di strumenti AI e come si classificano sotto l’AI Act; sui ruoli soggettivi nell’AI Act si veda anche il nostro contributo su arXiv.

Il caso più frequente: quando la piattaforma la sceglie l’altro

L’analisi fin qui condotta presuppone che il titolare del trattamento possa scegliere la piattaforma. Nella pratica professionale, tuttavia, il caso più frequente è diverso: si riceve un link Teams da un cliente, un link Zoom da un tribunale, un link Meet da una pubblica amministrazione. Rifiutare non è un’opzione. La questione allora non è quale piattaforma scegliere, ma come governare il rischio quando la piattaforma la sceglie qualcun altro.

Quando organizzi tu

Chi organizza la riunione determina il livello di protezione. Questo è un atto diretto di accountability. Per le riunioni ordinarie, la scelta della piattaforma può seguire le consuetudini organizzative. Per le riunioni sensibili — coperte da segreto professionale, che coinvolgono dati particolari o dati di minori, o che riguardano decisioni di organi collegiali — la responsabilità di proporre una piattaforma con garanzie adeguate ricade su chi convoca. Non delegare questa scelta per inerzia: è una decisione che il GDPR chiede di motivare.

Quando sei invitato

Non puoi rifiutare, ma puoi ridurre l’esposizione dei dati con misure operative concrete.

Separare il canale dalla sostanza. Questo è il principio guida. La videoconferenza serve per la discussione; i contenuti sensibili — documenti, dati, allegati — devono viaggiare su canali che controlli. In pratica: non condividere documenti riservati tramite screen share o chat della piattaforma durante la riunione. Inviali prima o dopo tramite canale cifrato (email crittografata, PEC, o canale dedicato concordato con l’interlocutore).

Ridurre la superficie di esposizione. Alcune misure operative possono limitare la quantità di dati personali trattati dalla piattaforma:

• Preferire l’accesso da browser rispetto all’app nativa, come misura di riduzione dell’esposizione (meno telemetria, meno dati persistenti sul dispositivo — non una garanzia in sé, ma un fattore di contenimento).
• Chiedere che la riunione non venga registrata né trascritta automaticamente, o quantomeno essere informati se tali funzionalità sono attive.
• Mantenere la videocamera disattivata quando non strettamente necessario, riducendo il volume di dati biometrici trattati.
• Eventualmente, utilizzare una VPN per ridurre l’esposizione dell’indirizzo IP.

A livello organizzativo

La misura più efficace non è tecnica ma organizzativa: adottare una policy interna che classifichi le riunioni per livello di sensibilità. Riunioni operative ordinarie: qualsiasi piattaforma accettata dall’organizzazione. Riunioni sensibili (segreto professionale, dati particolari, minori, organi collegiali): solo piattaforme con E2EE nativa o infrastruttura self-hosted. Quando l’uso di una piattaforma non conforme ai criteri più protettivi è inevitabile, documentare la valutazione del rischio e le misure di mitigazione adottate.

Questo approccio non indebolisce la tesi dell’articolo: la rafforza. La accountability del titolare si esprime non solo nella scelta della piattaforma, ma anche nella capacità di governare il rischio quando la scelta non è sua.

Checklist operativa: cosa fare prima di scegliere una piattaforma

1. Valutare la sensibilità dei dati trattati — Coinvolgono dati particolari (Art. 9 GDPR) o riguardano minori? Sono coperti da segreto professionale?
2. Verificare la giurisdizione del provider — È soggetto al CLOUD Act o ad altre leggi extraterritoriali? Esiste una decisione di adeguatezza per il paese terzo? Qual è la giurisdizione dell’infrastruttura di hosting?
3. Controllare la crittografia offerta — La piattaforma offre E2EE per impostazione predefinita? La E2EE è disponibile per le chiamate di gruppo? Chi controlla le chiavi di cifratura?
4. Valutare il self-hosting — L’organizzazione ha le competenze tecniche per gestire un proprio server? Il self-hosting è realizzato su infrastruttura non soggetta a giurisdizioni extraterritoriali?
5. Documentare la valutazione del rischio — Effettuare una DPIA se il trattamento presenta un rischio elevato. Adottare le misure supplementari raccomandate dall’EDPB.
6. Considerare l’uso di funzionalità AI — Sono necessarie funzionalità come trascrizione o live captions? Queste funzionalità sono compatibili con la E2EE? Ricadono sotto le previsioni dell’AI Act?

La mia posizione

Utilizzo personalmente l’ecosistema Proton da diversi anni. Non ho alcun rapporto commerciale o di partnership con nessuno dei soggetti analizzati in questo articolo. La mia valutazione si basa esclusivamente sull’analisi giuridica e sulla conoscenza diretta delle piattaforme esaminate.

La scelta della piattaforma dipende dal contesto.

Per chi ha le competenze tecniche per gestire un proprio server, Jitsi self-hosted — su infrastruttura non soggetta a giurisdizioni extraterritoriali — offre il massimo livello di controllo: giurisdizione scelta dal titolare, nessuna dipendenza da terzi, codice completamente verificabile, e possibilità di attivare la E2EE opzionale per le chiamate di gruppo.

Per chi cerca una soluzione con E2EE nativa senza la complessità del self-hosting, Proton Meet è, a oggi, l’opzione più strutturata. L’architettura zero-knowledge, la giurisdizione svizzera, l’open source dei client e l’integrazione nell’ecosistema Proton Workspace ne fanno una proposta solida, sebbene la sua maturità operativa sia ancora da verificare nel tempo.

Per chi continua a utilizzare Zoom, Teams o Google Meet — e in molti contesti organizzativi ciò è inevitabile per ragioni pratiche — è essenziale: attivare le opzioni E2EE o CSE ove disponibili, documentare la valutazione del rischio, effettuare una DPIA ove necessario, e adottare le misure supplementari raccomandate dall’EDPB nella Raccomandazione 01/2020 sui trasferimenti di dati.

Conclusioni

In un contesto in cui la protezione dei dati e la sovranità digitale sono priorità strategiche per l’Europa, la scelta di una piattaforma di videoconferenza non può essere lasciata al caso. Le alternative esistono: sta al titolare del trattamento valutare con attenzione i rischi e adottare soluzioni che garantiscano non solo la compliance formale, ma anche la reale tutela dei diritti degli interessati.

La crittografia end-to-end non è un lusso tecnico. È una misura di sicurezza prevista dall’Art. 32 del GDPR. In un contesto geopolitico in cui le leggi extraterritoriali di paesi terzi possono imporre la produzione forzata di dati, la E2EE — intesa come impostazione predefinita, non come opzione attivabile in scenari limitati — diventa non solo una scelta tecnica ma una garanzia giuridica.

Fonti

Fonti normative e giurisprudenziali

• Regolamento (UE) 2016/679 (GDPR): EUR-Lex
• Regolamento (UE) 2024/1689 (AI Act): EUR-Lex
• CLOUD Act (2018) — 18 U.S.C. § 2713: U.S. Code
• CLOUD Act — Testo legislativo: Congress.gov
• CGUE, Causa C-311/18 (Schrems II): Curia
• Tribunale UE, Causa T-553/23, Latombe c. Commissione, sentenza del 3 settembre 2025
• CGUE, Causa C-703/25 P, Latombe c. Commissione — appello pendente (depositato 31 ottobre 2025)

Fonti istituzionali UE

• EU-US Data Privacy Framework: Commissione europea
• Commissione europea, Rapporto sul primo riesame del DPF, 9 ottobre 2024 — COM(2024) 451 final
• EDPB, Rapporto sul primo riesame del DPF, 4 novembre 2024
• EDPB, Raccomandazione 01/2020 sulle misure supplementari per i trasferimenti: EDPB
• Decisioni di adeguatezza della Commissione europea: Commissione europea

Fonti tecniche — piattaforme

• Messaging Layer Security (MLS), RFC 9420: IETF
• Zoom — E2EE meetings: Zoom Support
• Zoom — Privacy Statement: Zoom
• Microsoft Teams — End-to-end encrypted meetings: Microsoft Learn
• Google Meet — Call & meeting encryption: Google Meet Help
• Google Meet — Client-side encryption (CSE): Google Meet Help
• Jitsi Meet — Security/encryption: Jitsi
• Jitsi Meet — Repository GitHub: GitHub
• Proton Meet — Pagina ufficiale: Proton
• Proton Meet — Modello di sicurezza: Proton Blog
• Proton Meet — Pagina sulla sicurezza: Proton
• Proton Meet — Annuncio di lancio e Proton Workspace: Proton Blog

Contributi accademici

• N. Fabiano, “Subject Roles in the EU AI Act”: arXiv
• N. Fabiano, “Digital Sovereignty Between ‘Accountability’ and the Value of Personal Data”, ASTESJ, Vol. 5(3), pp. 270-274, 2020: ASTESJ