Privacy e GDPR: cosa cambia davvero con l'IA locale

Usare un servizio cloud per l'IA non è un problema solo di convenienza: per chi tratta dati personali o professionali, è una questione di obblighi legali. Il GDPR non vieta di mandare i dati in cloud, ma mette sul tavolo requisiti che ogni trasferimento extra-UE deve soddisfare. L'IA locale cambia l'equazione: niente trasferimento, niente sub-responsabile straniero, niente dipendenza da clausole contrattuali. Ecco cosa dice la normativa, punto per punto.

Il problema dei servizi cloud, in termini GDPR

Quando usi ChatGPT, Claude, Gemini o simili, accadono tre cose che contengono obblighi:

1. Trasferimento a un paese terzo. I tuoi dati lasciano l'area economica europea e vanno su server di paesi senza adeguatezza piena e stabile. Il trasferimento è legittimo solo se passa per una base giuridica: decisione di adeguatezza (art. 45), clausole contrattuali tipo (CCT), regole aziendali vincolanti (BCR) o le deroghe dell'art. 49. Per i servizi USA la base in vigore è la decisione di adeguatezza EU-US Data Privacy Framework, approvata a luglio 2023 dopo la caduta del Privacy Shield nella sentenza Schrems II (C-311/18). Un framework che un tribunale può ribaltare in qualsiasi momento: quando è successo nel 2020, i trasferimenti in corso si sono trovati senza base giuridica dall'oggi al domani.
2. Trattamento dei tuoi dati dal provider. I termini di servizio decidono se le tue prompt vengono conservate, usate per migliorare i modelli o meno. Le impostazioni "off" esistono, ma sono promesse contrattuali, non garanzie tecniche: non hai visibilità né controllo su cosa resta nei log, nei sistemi di sicurezza o nei backup.
3. Sub-responsabilità. Il provider è sub-responsabile (art. 28) e su di lui pesano obblighi che tu dovresti monitorare: misure di sicurezza, notifiche di violazione, cancellazione a fine contratto. In pratica, per la maggior parte delle aziende, quel monitoraggio non esiste.

Cosa dice il GDPR, e cosa cambia con l'IA locale

Gli articoli rilevanti per la scelta cloud vs locale:

Articolo	Obbligo	Cloud	Locale
Art. 5(1)(c) — minimizzazione	Dati adeguati e limitati a quanto necessario	Ogni prompt contiene più dati di quanti il provider possa necessitare: contesto, metadati, log	Il modello vede solo quello che gli passi; il resto resta tuo
Art. 25 — data protection by design	Protezione integrata nella progettazione	La proteggi per contratto, non per architettura	L'architettura stessa non espone i dati a terzi
Art. 28 — sub-responsabili	Contratto e monitoraggio del fornitore	Sub-responsabile extra-UE da sorvegliare	Nessun sub-responsabile: il modello gira in casa
Art. 32 — sicurezza del trattamento	Misure tecniche adeguate (inclusa cifratura)	Dipende dalle misure del provider	Le tue: cifratura, rete, accessi — e l'air-gap se serve
Art. 44 — trasferimenti a paesi terzi	Base giuridica valida per ogni trasferimento extra-UE	Richiede adeguatezza o garanzie, da riesaminare dopo ogni sentenza	Nessun trasferimento: l'articolo non si applica

Il punto non è che il cloud sia illegale — è legale, con i documenti giusti. È che la compliance richiede lavoro continuo: DPIA, registro dei trattamenti aggiornato, monitoraggio del sub-responsabile, riesame alla prossima sentenza sulle trasversali. Con il locale quel lavoro si riduce a gestire un'applicazione in casa, con un perimetro di sicurezza che controlli tu.

I tre benefici, detti con precisione

Niente trasferimento, niente base giuridica da difendere. È il vantaggio tecnico-giuridico più grande: l'art. 44 semplicemente non scatta. Non dipendi più da decisioni di adeguatezza che i tribunali UE hanno già ribaltato due volte.

Niente sub-responsabile. Niente art. 28 da negoziare, niente clausole da aggiornare quando il provider cambia i termini. La catena di responsabilità è corta: tu, la tua macchina, i tuoi dati.

Controllo del ciclo di vita. I dati non finiscono in log, non vanno nei backup del provider, non entrano nel training (se non lo decidi tu). Questo conta soprattutto per i dati che non puoi rivelare: cartelle cliniche, contratti in negoziazione, documenti di clienti.

I casi d'uso dove fa davvero la differenza

Settore	Uso tipico	Cosa si evita
Studi legali	Revisione e sintesi di contratti	Esposizione dei dati dei clienti a un sub-responsabile extra-UE
Sanità	Analisi di cartelle cliniche	Trasferimento di dati di salute (art. 9: categoria speciale)
Finanza	Sintesi di documenti di clienti	Violazione dei doveri di riservabilità verso i clienti
Stampa	Analisi di documenti di inchiesta	Rischio che le fonti vengano esposte a terzi
PA	Assistenti per cittadini	Trasferimento di dati di cittadini a paesi terzi

Nessuno di questi usi è vietato in cloud — ma in ciascuno di essi il rischio di una perdita di confidenzialità, o di un cambio di termini del provider, ha un costo che non si può chiedere al cliente.

E i limiti? Detto con onestà

L'IA locale non è una dichiarazione di conformità: il GDPR continua ad applicarsi al trattamento, che si fa in casa o in cloud. Restano dovuti la base giuridica (art. 6), il registro dei trattamenti (art. 30), l'analisi d'impatto (art. 35) dove serve, le misure di sicurezza (art. 32). Un modello locale che legge cartelle cliniche è ancora un trattamento di dati di salute.

In più, il locale ha due limiti pratici che un DPO dovrebbe sapere: i modelli open-weight non hanno la stessa qualità dei frontier per i compiti complessi, e la responsabilità delle misure di sicurezza resta tua — niente provider da chiamare in causa se c'è una perdita, e questo rende le misure tecniche ancora più importanti.

Come muoversi, in pratica

1. Inventario: quali flussi di dati personali toccherebbe l'IA, e dove finiscono oggi.
2. Classificazione: i dati sono sensibili (art. 9) o professionali? Quelli vanno in locale prima di tutto.
3. Hardware: per i casi d'uso sopra bastano 16–24 GB di VRAM o di RAM unificata, un modello 8B–32B quantizzato, un'interfaccia. La guida Hardware per IA locale dimensiona la macchina per budget; Come eseguire modelli LLM localmente porta dal primo install al modello che risponde.
4. Documenti: aggiorna il registro dei trattamenti, fai la DPIA dove serve, definisci le misure di sicurezza locali (accessi, cifratura a riposo, rete).
5. Valuta: per i compiti che un modello locale non copre bene, resta il cloud — ma solo lì, con i documenti di trasferimento a posto.

In sintesi

L'IA locale non rende il GDPR invisibile: gli obblighi restano. Quello che fa è rimuovere il trasferimento extra-UE e il sub-responsabile straniero, che sono i due punti più fragili della compliance cloud. Per chi tratta dati sensibili o professionali, è il modo più diretto di ridurre il perimetro di rischio a quello che si controlla davvero.

Fonti

• GDPR — art. 5 (principi, inclusa la minimizzazione al 5(1)(c))
• GDPR — art. 32 (sicurezza del trattamento)
• GDPR — art. 44 (principio generale sui trasferimenti a paesi terzi)
• EDPB — Opinion 28/2024 su aspetti di data protection nello sviluppo e deploy di modelli di IA
• Corte di giustizia UE — sentenza Schrems II (C-311/18)

Articolo generato con IA