Quando un'azienda italiana adotta un sistema AI, il GDPR non è un dettaglio — è una variabile progettuale. Le implicazioni cambiano radicalmente a seconda che il sistema sia installato on-premise o che usi API e infrastrutture cloud. Questo articolo non è consulenza legale, ma un orientamento pratico per chi deve capire le domande giuste da fare al proprio DPO e ai fornitori AI.
Il problema fondamentale: dove vengono elaborati i dati?
Il GDPR non vieta di usare AI. Vieta (o complica significativamente) il trattamento di dati personali in modi che il titolare del trattamento non controlla o non può documentare adeguatamente.
Con un sistema AI cloud, ogni query che contiene dati personali — il nome di un cliente, il contenuto di un contratto, una domanda di un paziente — viene elaborata sui server del provider. Se quel provider è americano (OpenAI, Microsoft Azure, Google Cloud) si aggiunge il problema del trasferimento extra-UE dei dati.
Con un sistema on-premise, i dati non escono mai dalla rete aziendale. Tutta l'elaborazione avviene localmente. Non c'è trasferimento, non c'è provider terzo che elabora i dati.
I nodi GDPR specifici per i sistemi AI
1. Il Data Processing Agreement (DPA)
Ogni provider cloud che elabora dati personali per conto tuo è un "responsabile del trattamento" ai sensi del GDPR e deve firmare un DPA. Molti provider cloud hanno DPA standardizzati — ma standardizzato non significa adeguato al tuo caso specifico.
Con un sistema on-premise, il fornitore installa il software ma non elabora i dati. Il rapporto contrattuale è più simile a quello con un fornitore di software tradizionale — meno oneroso da gestire dal punto di vista compliance.
2. I trasferimenti extra-UE
Dopo la sentenza Schrems II, i trasferimenti di dati personali verso gli USA richiedono garanzie specifiche. Il Data Privacy Framework (DPF) del 2023 ha ripristinato un meccanismo di trasferimento, ma la sua stabilità giuridica è ancora discussa.
Molti provider cloud americani hanno data center europei — ma questo non risolve automaticamente il problema se i dati possono essere accessibili dalla casa madre americana per motivi di supporto tecnico o legali (vedi: CLOUD Act).
Con on-premise il problema non si pone: i dati restano in Italia.
3. I log delle conversazioni
Un chatbot aziendale su documenti registra le conversazioni. Quei log sono dati personali se contengono informazioni identificative (es. "Sono Mario Rossi, ho bisogno di informazioni sul mio contratto"). Devono essere gestiti come tali: retention period definita, accesso limitato, cancellazione su richiesta.
Sia con sistema cloud che on-premise, questo aspetto richiede una policy esplicita. La differenza è che on-premise hai il controllo diretto del database dove i log vengono salvati.
4. Il diritto all'oblio e la cancellazione dai modelli
Questa è una delle domande più complesse: se un cliente chiede di cancellare i suoi dati, si possono davvero cancellare da un modello AI che potrebbe averli memorizzati nel training?
Per i sistemi RAG on-premise (dove il modello non viene riaddestrato sui dati aziendali ma li usa come contesto), la risposta è semplice: si cancellano dal database documentale e il sistema non li userà più nelle risposte. Per i sistemi dove il modello è stato fine-tuned su dati specifici, la questione è più complessa e richiede valutazione caso per caso.
On-premise vs cloud: confronto GDPR in sintesi
Riassumendo in una tabella le implicazioni pratiche per chi deve scegliere l'architettura AI della propria azienda:
| Aspetto GDPR | AI On-Premise | Cloud EU | Cloud USA |
|---|---|---|---|
| DPA obbligatorio | No (o semplificato) | Sì | Sì + clausole CLOUD Act |
| Trasferimento extra-UE | No | No | Sì — richiede garanzie DPF |
| Controllo completo sui log | Sì | Parziale | Parziale |
| Rischio CLOUD Act USA | Nessuno | Basso | Presente |
| Diritto all'oblio (RAG) | Gestibile direttamente | Richiede accordo ad hoc | Richiede accordo ad hoc |
| DPIA semplificata | Sì (perimetro dati chiuso) | Parzialmente | No (perimetro esteso a terzi) |
La DPIA: quando è obbligatoria
Il GDPR richiede una Data Protection Impact Assessment (DPIA) prima di trattamenti che presentano rischi elevati per i diritti degli interessati. L'AI entra quasi sempre in questa categoria quando: elabora dati di categorie particolari (salute, orientamento politico, dati biometrici); prende o supporta decisioni automatizzate con effetti significativi sulle persone; monitora sistematicamente persone su larga scala.
Un chatbot aziendale interno che risponde a domande tecniche dei dipendenti probabilmente non richiede DPIA. Un sistema che analizza le conversazioni dei clienti per valutarne il rischio di insolvenza quasi certamente sì. Il discrimine è il tipo di dati trattati e l'impatto potenziale sulle persone.
AI Act e GDPR: la doppia conformità dal 2026
Il Regolamento UE 2024/1689 (EU AI Act), con gli obblighi per i sistemi ad alto rischio pienamente in vigore da agosto 2026, aggiunge un secondo livello di conformità che le PMI devono considerare insieme al GDPR. Le due normative non sono in conflitto — ma richiedono un coordinamento che parte dalla scelta architetturale.
Come l'AI Act classifica i sistemi AI aziendali
L'AI Act divide i sistemi in quattro livelli di rischio. Per una PMI italiana i più rilevanti sono:
- Rischio minimo — strumenti di produttività, filtri spam, AI generativa per bozze interne: nessun obbligo specifico oltre al buon senso.
- Rischio limitato — chatbot aziendali, assistenti su documenti, sistemi di raccomandazione: obbligo di trasparenza verso l'utente (deve sapere che sta interagendo con un'AI).
- Alto rischio (obblighi sostanziali da agosto 2026) — AI usata in selezione del personale, valutazione del merito creditizio, accesso a prestazioni pubbliche: documentazione tecnica obbligatoria, registro dei log, supervisione umana, valutazione di conformità ante-deployment.
- Rischio inaccettabile (vietati da febbraio 2025) — social scoring statale, manipolazione cognitiva subliminale, riconoscimento biometrico in tempo reale in spazi pubblici.
Un assistente AI interno per documenti aziendali ricade quasi sempre in rischio limitato. Un sistema che contribuisce a decisioni su credito, selezione HR o accesso a servizi rientra invece nell'alto rischio — con implicazioni molto più pesanti, indipendentemente dall'architettura scelta.
Dove le due normative si sovrappongono — e come on-premise semplifica entrambe
La DPIA del GDPR e la valutazione di conformità dell'AI Act per sistemi ad alto rischio condividono la stessa logica: mappare i rischi prima del deployment, documentare le misure di mitigazione, revisionare periodicamente. Farle come due esercizi separati è inefficiente — la pratica emergente è produrre un documento unico che risponda a entrambe.
Il registro obbligatorio dei log richiesto dall'AI Act per i sistemi ad alto rischio deve essere coordinato con le policy di retention del GDPR: i log non possono essere conservati a tempo indeterminato solo per scopi di audit AI se contengono dati personali. Serve una policy di retention che bilanci i due requisiti.
L'architettura on-premise semplifica concretamente entrambe le conformità: l'intero perimetro di trattamento dei dati è interno, il codice è verificabile, i log sono sotto controllo diretto dell'azienda. Ogni audit — che arrivi dal DPO, dal Garante Privacy o dall'autorità di vigilanza AI — trova l'infrastruttura documentabile senza dipendere da SLA e API di un provider esterno.
Checklist pratica per il DPO
Prima di adottare qualsiasi sistema AI aziendale, il DPO dovrebbe verificare:
- □ Dove vengono elaborati i dati? (EU, USA, altro)
- □ Chi è responsabile del trattamento? È necessario un DPA?
- □ Quali dati personali potrebbero passare attraverso il sistema?
- □ I log delle conversazioni vengono salvati? Per quanto? Chi vi accede?
- □ Come si gestisce il diritto di accesso e cancellazione?
- □ È necessaria una DPIA?
- □ Il Registro dei Trattamenti è stato aggiornato con il nuovo trattamento?
- □ Gli interessati sono stati informati (aggiornamento informativa privacy)?
Conclusione
Adottare AI on-premise non risolve magicamente tutti i problemi GDPR — ma elimina la categoria più complessa: il trasferimento di dati a provider terzi su server non controllati. Rimangono le questioni di governance interna (log, retention, diritti degli interessati) che vanno gestite indipendentemente dall'architettura scelta.
Il consiglio pratico: coinvolgere il DPO fin dalla fase di valutazione della soluzione AI, non dopo l'installazione. Le scelte architetturali fatte all'inizio del progetto determinano buona parte della complessità compliance nel lungo termine.
Hai domande su come implementare questo nella tua azienda?
30 minuti di chiamata gratuita con un tecnico. Nessun commerciale, nessun impegno — solo risposte concrete al tuo caso specifico.
Prenota la chiamata gratuita →