In breve
Quando in azienda si comincia a usare ChatGPT, Copilot, Claude o altri servizi di IA generativa, il primo problema non è la qualità del modello, è capire dove finiscono i dati che gli passi. Buona parte di questi servizi sui piani “consumer” (ChatGPT Plus, Copilot personale) usa di default i tuoi input per addestrare il modello, e i dati transitano su server fuori dall’Unione Europea senza garanzie contrattuali specifiche. Per le aziende che trattano dati di clienti questo è un problema GDPR concreto: senza un Data Processing Agreement firmato col fornitore, il trattamento è privo di base contrattuale conforme all’art. 28 GDPR. Esistono piani “business/enterprise” che risolvono buona parte del problema (DPA disponibile, niente training su input, residency EU), ma vanno scelti con cura.
Capita sempre più spesso di entrare in un ufficio e vedere qualcuno che usa ChatGPT con il proprio abbonamento personale per analizzare un’e-mail cliente, leggere un PDF di contratto, riassumere un report. La cosa funziona meravigliosamente bene, tanto che si fa fatica a tornare indietro. Ma c’è un problema che a quel “qualcuno” raramente viene spiegato: i dati che mette dentro ChatGPT escono dall’azienda, finiscono su server di una società americana, e di default vengono usati per addestrare il modello.
In questo articolo proviamo a raccontare in modo asciutto, da amministratori di sistema, dove i dati finiscono davvero quando si usano i servizi IA generativa più diffusi, e quando questo è un problema GDPR e quando non lo è. Non è consulenza legale (per quella servono avvocati): è un riassunto del lavoro di verifica che abbiamo fatto noi per i nostri clienti, condiviso a beneficio di chi affronta gli stessi temi.
Perché parliamo di “GDPR” e cosa dice davvero
Il GDPR (Regolamento UE 2016/679) è la cornice normativa che disciplina il trattamento dei dati personali in Europa. Quando un’azienda decide di usare un servizio cloud per elaborare dati personali (di dipendenti, clienti, fornitori, contatti), il GDPR all’art. 28 stabilisce un punto fondamentale: il rapporto fra l’azienda (titolare del trattamento) e il fornitore cloud (responsabile del trattamento) deve essere disciplinato da un contratto, in pratica un Data Processing Agreement (DPA) che descrive cosa il fornitore può e non può fare con quei dati.
In pratica:
- Senza DPA firmato, il fornitore IA che riceve dati personali agisce senza titolo legale rispetto al titolare. L’azienda è in posizione non conforme all’art. 28.
- Con DPA firmato, il fornitore si assume obblighi specifici: usare i dati solo per le finalità autorizzate, applicare misure di sicurezza adeguate, notificare i breach, restituire/cancellare i dati a fine contratto, accettare le clausole contrattuali standard (SCCs) per i trasferimenti extra-UE.
A questo si aggiunge un secondo tema: dove vengono ospitati i dati. Trasferire dati personali fuori dall’Unione Europea richiede una base giuridica adeguata (decisione di adeguatezza, SCCs, normative di sicurezza). Gli Stati Uniti hanno una decisione di adeguatezza chiamata Data Privacy Framework (DPF), in vigore dal luglio 2023, ma con alcuni equilibri tuttora in evoluzione su due fronti: la legge USA sulla sorveglianza estera (Section 702 FISA), che è in regime di estensione temporanea in attesa di rinnovo strutturale, e un ricorso pendente davanti alla Corte di Giustizia UE.
Il GDPR è un argomento ampio, ma per usarlo come “filtro pratico” su un fornitore IA prima di firmare bastano tre domande:
- DPA disponibile e firmabile sul piano che useremo effettivamente?
- Training del modello su input/output: di default sì o no?
- Data residency: dove vengono ospitati i dati? Hanno regioni EU disponibili?
Il resto (audit log, SSO, certificazioni SOC 2/ISO) è importante ma viene dopo.
Caso 1: ChatGPT (OpenAI)
Piano consumer (Free, Plus, Pro): il DPA col titolare aziendale non è disponibile. Il training su input è attivo di default (esiste un opt-out nelle impostazioni utente, ma il default è l’opposto). Anche con opt-out, OpenAI dichiara una retention di 30 giorni dei dati per “abuse monitoring”, che il sistema “Zero Data Retention” elimina solo nei piani business.
Tradotto: un dipendente che usa ChatGPT Plus per analizzare dati di un cliente mette quei dati in un sistema sul quale l’azienda non ha firmato il contratto previsto dall’art. 28 GDPR. È un trattamento privo di base contrattuale conforme, con conseguenti rischi sanzionatori per il titolare aziendale.
Piano Team: il DPA è disponibile, il training su input è disattivato di default, ma la residency dei dati è prevalentemente USA con possibilità EU limitate.
Piano Enterprise: DPA + certificazioni di sicurezza importanti (SOC 2 Type 2, ISO 27001, ISO 27017/27018/27701, ISO 42001 specifica per i sistemi di gestione IA). Residency EU disponibile come opzione contrattuale: tra le regioni supportate ci sono USA, Europa, UK, Canada, Australia. Per i clienti che firmano da territorio EEA il contratto è con OpenAI Ireland Limited, mentre per i dati UK il data importer SCC è OpenAI OpCo LLC con UK Addendum.
Conclusione operativa: se in azienda ci sono dipendenti che usano ChatGPT consumer per dati di clienti, bisogna passare a Team o Enterprise (con DPA firmato) o passare ad alternative. Continuare con il consumer è una scelta che a un audit non regge.
Caso 2: Microsoft 365 Copilot
Microsoft 365 Copilot è generalmente più semplice da giustificare dal punto di vista GDPR: il DPA di M365 si estende a Copilot, prompts e response non sono usati per addestrare il modello base, l’engine sotto è Azure OpenAI (non OpenAI public services), e Microsoft dichiara espressamente che M365 Copilot è un servizio sotto EU Data Boundary per i clienti europei.
Ma c’è un punto importante da sapere: Anthropic è subprocessor di Microsoft 365 Copilot, e i suoi modelli (Claude) possono essere selezionati come engine alternativo in alcuni componenti di Copilot: Researcher, Copilot Studio, Power Platform, Agent Mode in Excel, agenti Word/Excel/PowerPoint.
Microsoft dichiara espressamente che i modelli Anthropic sono fuori dall’EU Data Boundary: usandoli, una parte dei dati può uscire dal perimetro europeo.
La buona notizia: per i clienti EU/EFTA/UK il toggle “Anthropic come subprocessor” è impostato a OFF di default. Va attivato esplicitamente da un amministratore del tenant; quella attivazione dovrebbe essere preceduta da una valutazione interna (in alcuni scenari potrebbe servire una DPIA, Data Protection Impact Assessment, ex art. 35 GDPR).
Conclusione operativa: Copilot M365 in tenant EU, con il toggle Anthropic OFF, è una scelta GDPR-compliant relativamente lineare. Ma se il toggle è stato attivato (magari da uno IT senza piena coscienza dell’impatto), alcuni dati possono uscire dal perimetro UE, e va verificato.
Caso 3: Anthropic Claude
Anthropic ha un DPA disponibile (effective 24 febbraio 2025) e dichiara espressamente che non addestra i suoi modelli su contenuti di clienti commerciali. Sul fronte residency, però, l’API diretta Anthropic è prevalentemente ospitata negli Stati Uniti: i parametri disponibili per la regione di inferenza sono "us" e "global", e per i dati a riposo l’unica opzione è "us". Anthropic risulta self-certified al Data Privacy Framework, quindi il trasferimento UE-USA è coperto da decisione di adeguatezza (con le SCCs nel DPA come backup giuridico).
Per ottenere residency EU, le strade sono due:
- Claude via AWS Bedrock con region EU (Ireland, Stockholm): copertura disponibile su Claude Opus 4.7 e versioni precedenti.
- Claude via Google Vertex AI con endpoint EU: copertura disponibile su Claude 4.5, 4.6 e Opus 4.7 (l’endpoint EU di Vertex mantiene i dati dentro l’EU Data Boundary, con routing automatico tra le region europee di Google).
Una terza strada (Microsoft Foundry su Claude con EU residency) è dichiarata “coming 2026” da Microsoft: non è ancora disponibile.
Conclusione operativa: per uso enterprise con residency EU sul modello più recente (Opus 4.7), le strade valide sono Bedrock EU (Ireland o Stockholm) o Vertex AI con endpoint EU, in entrambi i casi con DPA firmato sia con Anthropic sia con il cloud provider scelto. L’API Anthropic diretta funziona per use case con dati meno sensibili o dove il DPF è ritenuto base sufficiente, tenendo presente che alcuni equilibri legali del DPF sono in evoluzione (vedi sezione precedente sulla legge USA sulla sorveglianza e sul ricorso davanti alla Corte di Giustizia UE).
Caso 4: n8n e gli orchestratori di workflow
n8n non è un modello IA: è uno strumento di orchestrazione di workflow, sempre più usato per costruire automazioni che chiamano vari servizi IA. n8n.cloud è ospitato in Germania (Hetzner) + Microsoft Azure, ha un DPA disponibile, e tratta i dati che transitano per i nodi come responsabile del trattamento.
Il problema però non è dove gira n8n: è dove finiscono i dati nei nodi LLM dentro il workflow. Se in un workflow n8n.cloud c’è un nodo che chiama ChatGPT API o Claude API, i dati vengono mandati a quel provider. Il DPA di n8n non copre il trasferimento successivo verso il modello IA: va firmato un DPA separato con il provider IA chiamato.
La combinazione che riduce drasticamente il problema GDPR è: n8n self-hosted (su un server controllato dal cliente) + modello IA locale (per esempio Ollama con un LLM open-source). In questa architettura il modello IA non vede mai dati che escono dal perimetro aziendale. È esattamente l’architettura che abbiamo costruito noi; ne abbiamo parlato in altri articoli qui sul lab.
Va però segnalato un caveat importante di sicurezza: n8n (sia cloud sia self-hosted) contiene le credenziali per accedere a tutti i servizi esterni che i workflow richiamano (Microsoft 365, gestionali, database, API di provider IA, account e-mail, ecc.). n8n diventa quindi un punto di concentrazione delle credenziali aziendali: la sicurezza dell’istanza n8n è critica e va trattata come si tratterebbe un password manager aziendale: accessi controllati, audit, rotazione credenziali, backup cifrati, niente esposizione dell’interfaccia a internet senza VPN o reverse proxy con autenticazione forte.
Da questa concentrazione discende una conseguenza GDPR concreta: un eventuale data breach dell’istanza n8n non esporrebbe solo i dati che transitano nei workflow attivi, ma potenzialmente tutte le credenziali memorizzate e, di conseguenza, tutti i sistemi a cui n8n è connesso. n8n è quindi uno scenario di rischio elevato che deve emergere esplicitamente nell’analisi del rischio prevista dall’art. 32 GDPR (misure tecniche e organizzative adeguate al rischio); e quando i sistemi connessi trattano volumi rilevanti di dati personali o categorie particolari (art. 9), spesso si entra nella soglia che richiede una DPIA (Data Protection Impact Assessment) ex art. 35 GDPR. Vale la pena chiarire subito che la DPIA non è un onere specifico del self-hosted: scatta sul rischio del trattamento (volumi + IA + combinazione di fonti) e si applica anche se gli stessi workflow girano su un orchestratore SaaS (Power Automate, Zapier, n8n.cloud, Make). Quello che cambia è il contenuto della valutazione: in self-hosted pesa il rischio architetturale interno, in SaaS pesa il rischio contrattuale e di trasferimento extra-UE.
Inoltre, dal punto di vista GDPR, il pattern “n8n self-hosted + LLM locale” chiude il problema solo per il passaggio LLM. Se un workflow chiama Microsoft 365 per inviare un’e-mail, quella stessa e-mail e i suoi dati escono comunque: non più verso un LLM esterno, ma verso Microsoft. Vanno comunque firmati i DPA con tutti i fornitori esterni che i workflow chiamano. Self-hosting di n8n non li sostituisce, riduce solo la superficie di trasferimento ai provider IA.
Tre regole pratiche per il decisore aziendale
Per chi in azienda deve decidere “quale servizio IA usare” senza essere giurista, tre regole che useremmo noi:
- Vietato l’uso aziendale di piani consumer (ChatGPT Plus/Pro, Copilot personale) per dati di terzi. Se serve, comprare i piani business/enterprise con DPA firmato.
- Verificare ogni 6 mesi i subprocessor del fornitore: i fornitori IA cambiano relazioni con altri vendor con frequenza. Quello che era “tutto in EU” oggi può essere “alcune componenti fuori EU” domani. Anthropic come subprocessor di Microsoft 365 Copilot è un esempio concreto e recente.
- Per requisiti EU stretti, considerare seriamente l’on-prem con LLM locale: non è la risposta a tutto (i modelli locali sono meno potenti dei migliori cloud), ma per molti casi d’uso aziendali è adeguato e chiude il tema GDPR alla fonte.
Perché lo raccontiamo
Non è un manuale, e non sostituisce un consulente legale per le decisioni complesse. Lo raccontiamo perché diversi nostri clienti ci stanno chiedendo come stiamo affrontando questi temi internamente, e perché alcune cose stanno cambiando in modo non banale e non sempre seguite dalla stampa specializzata. Le risposte che diamo a voce le abbiamo messe in altri articoli qui sul lab:
- Il nostro server IA in casa, senza pretese: hardware, stack, limiti reali del setup interno che abbiamo costruito.
- Documenti PDF che si inseriscono da soli nel gestionale: come usiamo l’IA per estrarre dati strutturati senza che escano dall’azienda.
- Da cassetta postale a workflow: come automatizziamo la classificazione e-mail con un LLM in casa.
Esperienza accumulata, soluzioni che funzionano per i nostri volumi, posizione GDPR pensata da amministratori di sistema. Se queste informazioni ti risulteranno utili, avremo fatto bingo.
Domande frequenti
Posso usare ChatGPT in azienda per leggere documenti dei clienti?
Solo nei piani Team/Enterprise con DPA firmato. Sui piani consumer (Free, Plus, Pro) il DPA non è disponibile: usarli per dati di terzi non è conforme all’art. 28 GDPR.
Microsoft 365 Copilot rispetta il GDPR per i tenant EU?
Generalmente sì: Copilot è un servizio sotto EU Data Boundary, prompts e response non sono usati per training del foundation model, il DPA di M365 si estende a Copilot. Va però considerato che Anthropic è subprocessor di Copilot e i suoi modelli sono fuori dall’EU Data Boundary. Per clienti EU il toggle Anthropic è OFF di default: va verificato che non sia stato attivato da un amministratore.
Claude rispetta il GDPR?
Sì nei piani Team/Enterprise, con DPA firmato (effective 24 febbraio 2025) e niente training su input commerciali. Per residency EU le strade valide sono Claude via AWS Bedrock (region Ireland o Stockholm) o Google Vertex AI con endpoint EU. L’API diretta Anthropic ospita i dati negli USA ed è coperta dal Data Privacy Framework UE-USA.
n8n.cloud è una scelta sicura per workflow IA in EU?
n8n.cloud è ospitato in Germania (Hetzner) + Azure, ha un DPA disponibile: per la parte n8n stessa è OK. Ma se il workflow chiama OpenAI o Anthropic API, i dati escono comunque: va firmato un DPA separato col provider IA chiamato. La combinazione che chiude il GDPR alla fonte è n8n self-hosted + LLM locale.
Cosa devo fare se in azienda qualcuno sta usando ChatGPT Plus su dati clienti?
Sospendere l’uso il prima possibile, valutare il passaggio al piano Team/Enterprise (con DPA) o ad alternative. Documentare la valutazione: in caso di audit del Garante è importante poter dimostrare che il problema è stato individuato e gestito.
Devo fare una DPIA per i workflow IA?
Dipende dal trattamento, non dall’architettura. Se i workflow combinano fonti dati, usano IA generativa e operano su volumi rilevanti (cioè quasi sempre, per un’azienda che li adotta su scala), la DPIA ex art. 35 GDPR è probabilmente dovuta, sia che l’orchestratore giri in casa (n8n self-hosted) sia che giri in cloud (Power Automate, Zapier, n8n.cloud, Make). Quello che cambia è il contenuto della DPIA: in self-hosted pesa il rischio architetturale interno (concentrazione credenziali, hardening, gestione patch); in SaaS pesa il rischio contrattuale e di trasferimento (sub-processor, residency, cambi unilaterali del vendor).
