Nel dicembre 2024 il Garante Privacy ha inflitto a OpenAI una multa da 15 milioni di euro — la prima sanzione GDPR mai emessa contro un sistema di intelligenza artificiale generativa in Europa. Il provvedimento è stato poi annullato dal Tribunale di Roma il 18 marzo 2026, ma il procedimento rimane un indicatore chiaro della postura del Garante verso i provider AI: l'assenza di base giuridica, la mancata informativa agli interessati e l'inadeguata verifica dell'età sono le contestazioni che definiscono il perimetro di rischio per qualsiasi azienda che processa dati di utenti italiani tramite LLM. Nel frattempo, le scadenze operative dell'AI Act si sono già materializzate:

Divieti AI inaccettabile
Art. 5 AI Act: social scoring, manipolazione, biometrica RT in spazi pubblici — vietati
Vigente
Obblighi GPAI
Modelli general-purpose: trasparenza, sintesi dati addestramento, reporting energetico
Vigente
Sistemi ad alto rischio
Conformità completa (Allegato III): recruiting, credito, HR, healthcare, triage
In scadenza

Il punto non è che stia arrivando qualcosa: è già arrivato. Le aziende italiane che usano LLM in produzione sono oggi soggette a obblighi concreti in base al GDPR e all'AI Act, e la maggior parte non ha ancora eseguito un DPA formale con il provider LLM, né una DPIA, né una classificazione del rischio del proprio sistema AI. Questa guida è per i CTO che devono trasformare questi requisiti normativi in decisioni architetturali e checklist operative.

Il quadro normativo: tre livelli da conoscere

Nel 2026 le aziende italiane che sviluppano o usano sistemi AI operano all'interno di tre livelli normativi sovrapposti. Conoscere quale livello governa quale obbligazione — e con quale scadenza — è il prerequisito per qualsiasi piano di compliance.

  1. GDPR — Regolamento (UE) 2016/679
    Si applica a qualsiasi trattamento di dati personali di persone fisiche nell'UE. Per i sistemi LLM: disciplina il contratto con il provider (Art. 28), la DPIA (Art. 35), le decisioni automatizzate (Art. 22) e le notifiche di violazione (Art. 33). Sanzioni fino a 20 milioni di euro o 4% del fatturato globale.
    Obbligatorio ora
  2. EU AI Act — Regolamento (UE) 2024/1689
    Il primo quadro normativo dedicato all'AI. Classifica i sistemi AI per livello di rischio. Le prime scadenze operative sono già passate (Feb 2025: divieti; Ago 2025: GPAI). La scadenza critica per l'enterprise è il 2 agosto 2026: conformità completa per i sistemi ad alto rischio (Allegato III). Sanzioni fino a 35 milioni di euro o 7% del fatturato globale per i provider.
    Parzialmente vigente
  3. Legge 132/2025 — Prima legge AI nazionale italiana
    Prima legge nazionale sull'AI tra i Paesi UE. Obbliga le imprese a strutture di governance AI interne con ruoli e responsabilità definiti, procedure di valutazione e testing degli algoritmi e sistemi di monitoraggio continuo. Autorità di vigilanza: AgID (agenzia per l'innovazione) e ACN (Agenzia Nazionale per la Cybersicurezza).
    Obbligatorio ora
  4. AI Act — Sistemi ad Alto Rischio (Art. 26)
    I deployer (chi usa, non solo chi sviluppa) di sistemi AI ad alto rischio devono: assegnare supervisione umana qualificata, conservare i log automatici per almeno 6 mesi, notificare incidenti al provider e all'autorità di sorveglianza, informare le persone interessate dalle decisioni automatizzate. Elenco esatto: Allegato III del Regolamento 2024/1689.
    Scadenza: ago 2026

La classificazione del rischio AI: dove si colloca il vostro sistema

L'AI Act adotta un approccio basato sul rischio. Prima di qualsiasi scelta architetturale, il CTO deve classificare il proprio sistema. Le quattro categorie hanno implicazioni operative completamente diverse.

R1
Rischio inaccettabile — vietati dal 2 febbraio 2025
Sistemi di social scoring, AI manipolativi che sfruttano vulnerabilità di persone o gruppi, identificazione biometrica remota in tempo reale negli spazi pubblici (con eccezioni limitate). Non si discute: sono vietati. Se il vostro sistema rientra in questa categoria, va dismesso.
R2
Alto rischio — conformità completa entro il 2 agosto 2026
Allegato III include: sistemi biometrici, infrastrutture critiche, recruiting e screening CV, valutazione del credito, pricing assicurativo vita e salute, triage clinico, monitoraggio dei lavoratori, gestione delle prestazioni, sistemi scolastici e di formazione professionale. Se un LLM supporta anche parzialmente una di queste funzioni — come agente di screening, classificatore di rischio, o sistema di supporto a decisioni su persone fisiche — il sistema è ad alto rischio e richiede DPIA, supervisione umana documentata e registrazione nel database europeo AI.
R3
Rischio limitato — obblighi di trasparenza (Art. 52)
Chatbot, assistenti virtuali e sistemi che interagiscono direttamente con persone fisiche devono rivelare chiaramente di essere un sistema AI, all'inizio di ogni interazione (Art. 52 AI Act). I sistemi che generano contenuti sintetici (testi, immagini, audio, video) devono marcare i contenuti come generati dall'AI. La notifica deve essere "chiara e distinguibile" — non è sufficiente un disclaimer nascosto nei termini d'uso.
R4
Rischio minimo — nessun obbligo AI Act specifico
Filtri antispam, AI nei videogiochi, motori di raccomandazione a basso impatto. Il GDPR si applica comunque se il sistema tratta dati personali. La classificazione a rischio minimo non è un'esenzione permanente: se le funzionalità del sistema evolvono verso usi ad alto rischio, la classificazione va aggiornata.
Il caso dei modelli GPAI

I grandi modelli linguistici come Claude Opus 4.7, Gemini 3.1 e i modelli GPT-5 sono classificati come GPAI (General-Purpose AI). L'AI Act distingue tra GPAI ordinari — soggetti a obblighi di trasparenza dal 2 agosto 2025 — e GPAI con rischio sistemico, identificati dalla soglia di addestramento superiore a 1025 FLOPs. I modelli con rischio sistemico hanno obblighi aggiuntivi: red-teaming obbligatorio, segnalazione di incidenti all'EU AI Office entro due settimane, misure di cybersecurity e reporting sul consumo energetico. Se la vostra azienda usa questi modelli via API, l'obbligo normativo primario è del provider — ma voi, come deployer, avete obblighi di due diligence sul provider scelto.

Art. 28 GDPR: il contratto con il provider LLM che quasi nessuno ha firmato

Ogni chiamata API a un provider LLM esterno — OpenAI, Anthropic, Google, Azure — che trasmette dati personali di persone fisiche è un trattamento dati per conto del titolare. Il GDPR Art. 28 impone che questo trattamento sia disciplinato da un contratto scritto formale (Data Processing Agreement, DPA), distinto dai termini di servizio. Accettare i ToS di un provider non equivale a eseguire un DPA: molte aziende italiane sono oggi in violazione di questo requisito senza saperlo.

Il DPA deve includere obbligatoriamente (Art. 28, co. 3):

Sanzione per assenza di DPA: fino a 10 milioni di euro o 2% del fatturato globale (Art. 83, co. 4 GDPR).

Data residency: quale provider è GDPR-compatibile per i dati personali italiani

Per i dati personali di cittadini UE il trasferimento verso paesi terzi è disciplinato dagli Artt. 44-49 GDPR. Le Standard Contractual Clauses (SCC) sono lo strumento più comune per coprire il trasferimento verso USA, ma richiedono una Transfer Impact Assessment (TIA) documentata. La residenza dei dati in EU elimina il problema alla radice.

Provider Residenza EU Meccanismo Trasferimento US Note operative
Azure OpenAI
(DataZone EUR)		 ✓ Garantita Deployment "Data Zone Standard (EUR)" — inferenza e dati rimangono in Svezia Central o Germany West Central; non condivisi con OpenAI Nessuno — dati restano in UE Opzione più solida per dati personali EU. DPA incluso. Non richiede SCC né TIA. Preferibile per settori regolamentati (finanza, sanità).
AWS Bedrock
(Claude Opus 4.7)		 ✓ Disponibile Endpoint EU: eu-central-1 (Frankfurt), eu-west-1 (Irlanda), eu-west-3 (Parigi). Premium ~10% rispetto agli endpoint globali Nessuno se si usano endpoint EU Soluzione valida per chi preferisce l'ecosistema AWS. DPA AWS incluso. Verificare che il codice utilizzi gli endpoint EU e non quello globale di default.
Anthropic
API Diretta		 ✗ Non disponibile Infrastruttura USA. Il parametro inference_geo supporta "us" e "global" — quest'ultimo non garantisce hosting europeo SCC + TIA obbligatorie Non idoneo per dati personali EU senza SCC documentate e TIA. Per usare Claude con residenza EU: AWS Bedrock (eu-central-1) o Google Vertex AI (regioni EU disponibili).
Google Vertex AI
(Gemini 3.1)		 Parziale Gemini 3.1 non è disponibile nelle regioni EU di Vertex AI a maggio 2026. Versioni precedenti disponibili in europe-west4 (Olanda). SCC necessarie per Gemini 3.1 Verificare disponibilità regionale prima di progettare architetture con Gemini 3.1 per dati personali EU: cloud.google.com/vertex-ai/generative-ai/docs/learn/locations

Art. 35 GDPR: quando la DPIA è obbligatoria per i sistemi AI

La Valutazione d'Impatto sulla Protezione dei Dati (DPIA) deve essere completata prima dell'avvio del trattamento — non dopo il go-live. Questo è un errore operativo frequente: la DPIA viene redatta ex post come formalità, invece di influenzare le decisioni di progettazione.

Per i sistemi AI, la DPIA è obbligatoria automaticamente se si verifica almeno una delle seguenti condizioni:

La CNIL (autorità francese, con linee guida riconosciute anche in Italia) considera la DPIA necessaria per tutti i sistemi ad alto rischio ai sensi dell'AI Act che trattano dati personali. Questa presunzione è di fatto vincolante per qualsiasi sistema enterprise italiano che processa dati di dipendenti, clienti o utenti attraverso modelli LLM con capacità decisionale o di profilazione.

Elementi obbligatori della DPIA per sistemi LLM

Una DPIA per un sistema basato su LLM deve includere:

  1. Descrizione del sistema: architettura, flussi di dati, componenti di addestramento e inferenza, fonti dati, periodi di conservazione
  2. Base giuridica del trattamento: consenso, esecuzione contrattuale, obbligo legale, o legittimo interesse documentato con bilanciamento
  3. Valutazione della necessità: perché il trattamento di dati personali è necessario per la funzione LLM — e perché non è possibile usare dati anonimizzati o sintetici
  4. Analisi dei rischi: probabilità e gravità per diritti e libertà degli interessati, inclusi rischi di memorizzazione involontaria nel modello, output discriminatori, esposizione di dati tramite prompt injection
  5. Misure di mitigazione: pseudonimizzazione, controlli di accesso, retention/deletion policy, meccanismi di supervisione umana, audit e monitoraggio
  6. Consultazione del DPO (dove nominato)
  7. Programma di revisione: frequenza e trigger per aggiornamento della DPIA (es. cambio del modello LLM, espansione del perimetro dati)

Art. 22 GDPR: quando l'output dell'LLM costituisce una "decisione"

L'Art. 22 GDPR vieta decisioni "basate unicamente sul trattamento automatizzato" che producono "effetti giuridici o che incidono in modo analogo significativamente" sulla persona fisica — salvo eccezioni specifiche (consenso esplicito, contratto, obbligo di legge). Il termine "unicamente" è interpretato restrittivamente dall'EDPB (Linee guida 06/2020 sul processo decisionale automatizzato): la supervisione umana deve essere sostanziale, non una firma formale su un output già definitivo.

Per i sistemi LLM enterprise, i casi più frequenti di applicazione dell'Art. 22 sono:

La soluzione non è eliminare l'LLM: è documentare un processo di supervisione umana reale, tracciare le revisioni, e garantire che la persona interessata possa contestare la decisione e ottenere una spiegazione comprensibile della logica usata.

Specifiche italiane: Garante, Legge 132/2025 e lavoro dipendente

La multa OpenAI e il segnale per il mercato italiano

Il provvedimento del Garante contro OpenAI (dicembre 2024, poi annullato dal Tribunale di Roma a marzo 2026) ha comunque delineato le contestazioni che qualsiasi azienda che tratta dati di utenti italiani tramite LLM deve affrontare. Il Garante aveva qualificato le entità OpenAI come titolari del trattamento — applicando i criteri GDPR standard su chi determina le finalità e i mezzi del trattamento — e aveva contestato: assenza di base giuridica per l'uso dei dati italiani nell'addestramento, mancata informativa agli interessati, assenza di meccanismi di verifica dell'età. Indipendentemente dall'esito del ricorso, questi tre profili rappresentano i punti di vulnerabilità più comuni per le aziende italiane che addestrino o personalizzino LLM su dati di utenti propri.

Monitoraggio dei dipendenti via AI: le regole italiane

L'uso di sistemi AI per monitorare le attività dei lavoratori è soggetto all'Art. 4 dello Statuto dei Lavoratori (L. 300/1970) oltre che al GDPR. In Italia, il monitoraggio tecnologico dei dipendenti richiede obbligatoriamente:

Legge 132/2025: governance AI obbligatoria

La Legge 132/2025 — in vigore dal 10 ottobre 2025 — impone alle imprese che usano AI strutture di governance con ruoli e responsabilità definiti, procedure documentate di valutazione e testing degli algoritmi, e sistemi di monitoraggio continuo. Le autorità di vigilanza — AgID per l'innovazione e ACN per la sicurezza informatica — hanno poteri di ispezione e sanzione. Questa legge è la prima a imporre obblighi di governance AI nazionale agli utilizzatori enterprise, non solo ai provider.

Checklist operativa per il CTO

Da completare ora (adempimenti già in vigore)
  • Eseguire un DPA formale con ogni provider LLM che processa dati personali — non i soli ToS
  • Classificare ogni sistema AI in produzione secondo i quattro livelli di rischio dell'AI Act
  • Completare la DPIA per tutti i sistemi che rientrano nelle categorie obbligatorie (Art. 35 GDPR)
  • Verificare che le chiamate API verso provider non-EU siano coperte da SCC e che sia stata redatta una Transfer Impact Assessment
  • Per dati personali EU con requisiti di residenza: instradare verso Azure OpenAI DataZone EUR o AWS Bedrock eu-central-1
  • Aggiungere notifica AI all'inizio di ogni interazione utente con chatbot o assistenti LLM (Art. 52 AI Act)
  • Documentare la base giuridica del trattamento per ogni flusso LLM che processa dati personali
  • Nominare un responsabile interno (ruolo CTO/CISO) per la governance AI secondo Legge 132/2025
  • Verificare la policy di conservazione dei metadati email: il termine "congruo" è 21 giorni (Provvedimento Garante n. 364/2024); eventuali estensioni richiedono documentazione accountability per esigenze di sicurezza IT
  • Verificare che i sistemi AI di monitoraggio dipendenti abbiano accordo sindacale o autorizzazione INL
Da completare entro il 2 agosto 2026 (sistemi ad alto rischio)
  • Registrare i sistemi ad alto rischio nel database europeo AI (EU AI Office)
  • Assegnare supervisori umani qualificati con competenza, formazione e autorità documentate
  • Implementare conservazione automatica dei log per almeno 6 mesi (Art. 26 AI Act)
  • Predisporre procedure di notifica degli incidenti al provider e all'autorità di sorveglianza
  • Informare le persone fisiche soggette a decisioni di sistemi AI ad alto rischio
  • Dotarsi di un sistema di quality management documentato per i sistemi ad alto rischio

Cinque principi architetturali per la compliance by design

01
Separare i flussi dati per livello di sensibilità
Classificare i dati in ingresso prima che raggiungano il provider LLM. I dati che contengono informazioni personali identificabili devono essere instradati verso provider con residenza EU (Azure DataZone EUR, Bedrock eu-central-1). I dati non personali o già pseudonimizzati possono usare endpoint globali. Un gateway LLM centralizzato (es. LiteLLM) rende questo routing operativamente gestibile senza modificare il codice applicativo.
02
Progettare l'anonimizzazione come primo stadio della pipeline
Il principio di minimizzazione (Art. 5 GDPR) si applica anche all'inferenza LLM: se il sistema non ha bisogno del codice fiscale o del nome completo per funzionare, non devono essere passati nel prompt. Implementare un layer di PII detection e pseudonimizzazione prima della chiamata API — ricostruendo il testo originale nel post-processing se necessario. Questo riduce sia l'esposizione normativa sia il rischio di memorizzazione involontaria nel modello.
03
Loggare le decisioni AI con traccia di supervisione umana
Per i sistemi che supportano decisioni su persone fisiche, ogni output LLM che entra in un processo decisionale deve essere loggato con: timestamp, versione del modello e del prompt, output originale, identità del supervisore umano che lo ha validato, eventuale override della decisione. Questo log è l'evidenza che la supervisione umana è "sostanziale" e non formale — richiesta sia dall'Art. 22 GDPR sia dall'Art. 26 AI Act.
04
Versioning del modello LLM come elemento del sistema di qualità
Cambiare il modello LLM sottostante — anche solo per una versione patch — può alterare gli output in modo non deterministico. Per i sistemi ad alto rischio (Allegato III AI Act), i cambiamenti di modello devono essere documentati, testati e approvati prima del deploy in produzione. Il version ID del modello deve essere presente in tutti i log di inferenza per consentire la ricostruzione della decisione in caso di contestazione.
05
Piano di risposta agli incidenti specifico per violazioni LLM
Il GDPR Art. 33 impone la notifica al Garante entro 72 ore dal momento in cui il titolare "viene a conoscenza" della violazione. Per i sistemi LLM, le violazioni più probabili sono: trasmissione non autorizzata di dati personali nel prompt, esposizione di dati nel context window a utenti non autorizzati, output contenente informazioni personali di terzi. Predisporre template di notifica pronti e identificare il punto di contatto con il Garante prima che l'incidente avvenga — non dopo.
Riferimenti
  1. Parlamento Europeo e Consiglio UE. (2024). Regolamento (UE) 2024/1689 sull'Intelligenza Artificiale (AI Act). EUR-Lex
  2. European Data Protection Board. (2024). Opinion 28/2024 on Certain Data Protection Aspects Related to the Processing of Personal Data in the Context of AI Models. Dicembre 2024. edpb.europa.eu
  3. Garante per la Protezione dei Dati Personali. (2024). Provvedimento sanzionatorio nei confronti di OpenAI — 15 milioni di euro. Provvedimento del 26 dicembre 2024. garanteprivacy.it — doc. 10085432. Nota: annullato dal Tribunale di Roma il 18 marzo 2026.
  4. Parlamento Italiano. (2025). Legge 20 settembre 2025, n. 132 — Disposizioni in materia di intelligenza artificiale. In vigore dal 10 ottobre 2025. Prima legge AI nazionale in UE (Squire Patton Boggs; Cleary Gottlieb, 2025).
  5. GDPR — Regolamento (UE) 2016/679. Articolo 22 — Processo decisionale automatizzato relativo alle persone fisiche. gdpr-info.eu
  6. WP29 / EDPB. (2018). Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679 (WP251rev.01). Adottate il 6 febbraio 2018, approvate dall'EDPB il 25 maggio 2018. Fonte primaria per l'interpretazione di Art. 22 GDPR e il requisito di supervisione umana sostanziale. edpb.europa.eu
  7. GDPR — Regolamento (UE) 2016/679. Articolo 28 — Responsabile del trattamento. gdpr-info.eu
  8. GDPR — Regolamento (UE) 2016/679. Articolo 35 — Valutazione d'impatto sulla protezione dei dati. gdpr-info.eu
  9. AI Act — Regolamento (UE) 2024/1689. Articolo 26 — Obblighi dei deployer di sistemi AI ad alto rischio. artificialintelligenceact.eu
  10. AI Act — Regolamento (UE) 2024/1689. Allegato III — Sistemi AI ad alto rischio. Elenco completo delle categorie, inclusi sistemi di valutazione del credito, pricing assicurativo vita e salute (Allegato III, punto 5(b)). artificialintelligenceact.eu
  11. Microsoft. (2026). Azure OpenAI Service Data Zone Standard — Residenza dei dati in EU. learn.microsoft.com
  12. Statuto dei Lavoratori — Legge 20 maggio 1970, n. 300. Articolo 4 — Impianti audiovisivi e altri strumenti di controllo.
  13. Garante per la Protezione dei Dati Personali. (2024). Documento di indirizzo — Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati. Provvedimento n. 364, 6 giugno 2024. Aggiornamento del Provvedimento n. 642/2023: termine "congruo" di conservazione metadati email elevato a 21 giorni. garanteprivacy.it — doc. 10026277
  14. EDPB. (2022). Guidelines 9/2022 on Personal Data Breach Notification. edpb.europa.eu
M
Michele Mader
Technical Leader · AI Systems & Data Engineering

Guido la direzione tecnica di prodotti dati basati su AI per clienti enterprise — definendo architetture, scegliendo lo stack tecnologico e gestendo la delivery dal roadmap alla produzione.

Connettiti su LinkedIn