Art. 22 GDPR e decisioni automatizzate: cosa dicono Garante e Corte UE, e perché è una questione di gestione del rischio

Un fido negato in pochi secondi, una candidatura scartata prima che un essere umano l’abbia letta, l’account di un lavoratore di piattaforma bloccato da un sistema di punteggio, una fornitura di energia rifiutata sulla base di uno score creditizio. Le decisioni automatizzate non sono più un tema da convegno: sono il modo ordinario in cui molte organizzazioni selezionano, valutano, ammettono ed escludono le persone. L’art. 22 del GDPR, scritto nel 2016 quando l’intelligenza artificiale generativa non esisteva, è oggi una delle norme più attuali dell’intero Regolamento: la Corte di giustizia l’ha allargato, il Garante lo applica con costanza crescente e l’AI Act gli è cresciuto intorno. Vale la pena capire davvero come funziona, perché il punto di arrivo è sempre lo stesso: la gestione del rischio, la stessa logica che regge la ISO 31000 e la ISO/IEC 27001.

Cosa dice davvero l’art. 22

La norma è breve e spesso letta male. Il paragrafo 1 stabilisce che l’interessato ha il diritto di non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato, compresa la profilazione, che produca effetti giuridici che lo riguardano o che incida in modo analogo significativamente sulla sua persona. Le linee guida WP251 del Gruppo Articolo 29, fatte proprie dall’EDPB, hanno chiarito il punto decisivo: non si tratta di un diritto che l’interessato deve esercitare, ma di un divieto generale che opera di default. Se la decisione rientra nel perimetro, è vietata a prescindere, salvo che ricorra una delle tre eccezioni del paragrafo 2.

Il perimetro è definito da due condizioni. La prima: la decisione deve essere unicamente automatizzata. Qui la prassi ha smontato il trucco più diffuso, cioè l’intervento umano di facciata: se una persona si limita a ratificare l’esito dell’algoritmo senza competenza, informazioni e potere reale di modificarlo, la decisione resta unicamente automatizzata. L’intervento umano che fa uscire dall’art. 22 deve essere significativo: qualcuno che può guardare i dati, capire la logica e ribaltare il risultato. La seconda condizione: la decisione deve produrre effetti giuridici o incidere in modo analogo e significativo. Rientrano il rifiuto di un credito, l’esclusione automatica da una selezione di personale, il blocco di un account da cui dipende il reddito di una persona, la negazione di un servizio essenziale.

Le tre eccezioni del paragrafo 2 sono la necessità contrattuale (la decisione automatizzata è necessaria per concludere o eseguire un contratto con l’interessato), l’autorizzazione del diritto dell’Unione o dello Stato membro con garanzie adeguate, e il consenso esplicito. Nelle prime due ipotesi e nella terza, il paragrafo 3 impone comunque le garanzie minime che sono il cuore operativo della norma: il diritto di ottenere l’intervento umano del titolare, di esprimere la propria opinione e di contestare la decisione. Il paragrafo 4 chiude il cerchio sui dati particolari: le decisioni automatizzate fondate su dati ex art. 9 sono ammesse solo con consenso esplicito o per motivi di interesse pubblico rilevante, e sempre con misure specifiche di tutela.

Attorno all’art. 22 lavora poi il pacchetto trasparenza: gli artt. 13, par. 2, lett. f) e 14, par. 2, lett. g) impongono di dichiarare nell’informativa l’esistenza di processi decisionali automatizzati e di fornire informazioni significative sulla logica utilizzata, oltre che sull’importanza e sulle conseguenze previste per l’interessato; l’art. 15, par. 1, lett. h) rende queste stesse informazioni esigibili con una richiesta di accesso. È su questo terreno che si è giocata la partita più recente davanti alla Corte di giustizia.

La Corte di giustizia ha allargato il campo

Con la sentenza SCHUFA (causa C-634/21, 7 dicembre 2023) la Corte ha risolto un problema che nella pratica creava un vuoto di tutela: chi calcola lo score non decideva formalmente nulla, e chi decideva (la banca) sosteneva di non fare una decisione unicamente automatizzata perché lo score arrivava da fuori. La Corte ha tagliato il nodo: il calcolo stesso del punteggio di affidabilità creditizia è una decisione ai sensi dell’art. 22 quando il destinatario vi si basa in modo determinante per concedere o negare il credito. La nozione di decisione è ampia e può includere atti preparatori che di fatto segnano l’esito finale. Per chi produce scoring, rating e punteggi destinati a terzi, questo significa entrare in prima persona nel perimetro dell’art. 22, con tutto ciò che ne consegue in termini di base giuridica, informative e garanzie.

La seconda tappa è la sentenza Dun & Bradstreet Austria (causa C-203/22, 27 febbraio 2025), nata da un caso quasi banale: un operatore telefonico nega a una consumatrice un contratto da pochi euro al mese sulla base di una valutazione automatizzata, e la consumatrice chiede di capire come si sia arrivati a quel giudizio. La Corte ha chiarito cosa significano le informazioni significative sulla logica utilizzata: non la consegna dell’algoritmo o della formula matematica, che per la persona media sarebbe incomprensibile, ma una spiegazione concisa, trasparente e intelligibile della procedura e dei principi applicati in concreto, tale da permettere all’interessato di capire quali suoi dati sono stati usati e come hanno pesato sul risultato. E ha aggiunto il punto che interessa ogni azienda: il segreto commerciale non è un veto assoluto. Se il titolare ritiene che la spiegazione esponga segreti industriali, non può semplicemente rifiutare: le informazioni vanno fornite all’autorità di controllo o al giudice, che bilanciano i diritti in gioco e stabiliscono cosa comunicare all’interessato.

Messe in fila, le due sentenze dicono una cosa sola: la spiegabilità delle decisioni automatizzate non è una buona pratica, è un requisito giuridico esigibile. Chi usa sistemi di scoring o di valutazione automatizzata deve essere in grado, oggi, di spiegare in linguaggio comprensibile come il sistema arriva ai suoi esiti. Chi non ci riesce ha un problema che nessuna clausola contrattuale risolve.

La linea del Garante: conoscibilità, non esclusività, non discriminazione

Il Garante italiano su questo terreno non è arrivato dopo la Corte: ci lavorava da prima. La sua linea si può riassumere in tre principi che l’Autorità ha reso espliciti nel tempo, in dialogo con la giurisprudenza amministrativa sulle decisioni algoritmiche della pubblica amministrazione: conoscibilità (la persona ha diritto di sapere che esiste un processo decisionale automatizzato e di capirne la logica), non esclusività (nel processo deve esserci un contributo umano capace di controllare e ribaltare l’esito) e non discriminazione algoritmica (il sistema va verificato e corretto perché non produca effetti distorti su gruppi di persone).

Il filone più noto è quello del lavoro tramite piattaforma. Con l’ordinanza ingiunzione del giugno 2021 contro Foodinho (gruppo Glovo), sanzionata per 2,6 milioni di euro, il Garante ha contestato un sistema di gestione dei rider basato su punteggi e assegnazione automatica degli ordini senza informazioni adeguate, senza garanzie di intervento umano e senza verifiche sull’esattezza e sulla correttezza dei risultati, con conseguente rischio di discriminazione. Poche settimane dopo è arrivata la sanzione da 2,5 milioni a Deliveroo, sullo stesso impianto: l’algoritmo che assegna il lavoro non può essere una scatola nera incontestabile. Nel novembre 2024 il Garante è tornato su Foodinho con una sanzione da 5 milioni di euro: account dei rider bloccati o disattivati da sistemi automatizzati, compreso il riconoscimento facciale, senza che i messaggi di blocco informassero della possibilità di contestare la decisione e di ottenere una verifica umana. Le misure correttive imposte sono una piccola lezione di compliance: riformulare le comunicazioni, garantire la verifica umana delle decisioni algoritmiche, controllare i meccanismi reputazionali che possono discriminare.

Fuori dal lavoro di piattaforma, la linea è la stessa. Nel caso Mevaluate, la piattaforma di rating reputazionale bloccata dal Garante, la Cassazione (ordinanza n. 14381/2021) ha fissato un principio che vale per qualunque sistema basato sul consenso: il consenso non è valido se lo schema di funzionamento dell’algoritmo non è conoscibile dall’interessato. Nel settembre 2023 il Garante ha pubblicato il decalogo per la realizzazione di servizi sanitari nazionali attraverso sistemi di intelligenza artificiale, che ha elevato i tre principi a criteri di progettazione: supervisione umana effettiva, trasparenza sulla logica dei sistemi, valutazione d’impatto preventiva e attenzione specifica ai bias, in un settore dove una decisione algoritmica sbagliata pesa sulla salute delle persone.

L’ultimo tassello è recentissimo e riguarda un settore molto ordinario: la fornitura di energia. Con il provvedimento del 3 luglio 2026 il Garante ha sanzionato Hera Comm per 5,8 milioni di euro per il sistema di verifica dell’affidabilità creditizia applicato a circa un milione di potenziali clienti: informative inadeguate sull’esistenza e sulla logica dello scoring, riscontri incompleti alle richieste di accesso, dati riutilizzati per affinare il sistema di rating oltre le finalità dichiarate. E il richiamo esplicito alle garanzie dell’art. 22, par. 3: chi viene respinto sulla base di uno score ha diritto all’intervento umano e alla contestazione. È la logica SCHUFA applicata in Italia, a un mercato di massa, con i numeri di una utility.

Il risk-based approach: dove GDPR e ISO parlano la stessa lingua

Fin qui la norma e la sua applicazione. Ma per chi guida un’azienda la domanda vera è un’altra: come si governa tutto questo senza trasformarlo in un adempimento burocratico? La risposta sta nell’impianto stesso del GDPR, che è una normativa risk-based da cima a fondo. L’art. 24 calibra le misure di accountability sulla natura, l’ambito, il contesto e le finalità del trattamento, oltre che sui rischi per i diritti e le libertà delle persone. L’art. 25 porta la stessa logica nella progettazione. L’art. 32 chiede misure di sicurezza adeguate al rischio, non misure standard. E l’art. 35 impone la valutazione d’impatto quando il rischio è elevato, indicando esplicitamente, alla lettera a) del paragrafo 3, il caso che ci interessa: la valutazione sistematica e globale di aspetti personali basata su trattamento automatizzato, compresa la profilazione, su cui si fondano decisioni con effetti giuridici o incidenza analoga. Una decisione automatizzata rilevante ex art. 22 porta con sé, quasi per definizione, l’obbligo di DPIA. I considerando 75 e 76 completano il quadro: il rischio va valutato in termini di probabilità e gravità per i diritti e le libertà dell’interessato, con un giudizio oggettivo.

Chi lavora con i sistemi di gestione riconosce immediatamente questo schema. La ISO 31000 definisce il rischio come effetto dell’incertezza sugli obiettivi e struttura il processo in fasi che qualunque DPIA ben fatta ripercorre: definizione del contesto, identificazione dei rischi, analisi, ponderazione, trattamento, monitoraggio e comunicazione. La ISO/IEC 27001 applica lo stesso processo alla sicurezza delle informazioni: i punti 6.1.2 e 6.1.3 chiedono una metodologia di valutazione con criteri di accettazione definiti, l’individuazione dei rischi, l’analisi di probabilità e impatto, un piano di trattamento e la Dichiarazione di applicabilità; i punti 8.2 e 8.3 impongono di ripetere il ciclo a intervalli pianificati e a ogni cambiamento significativo. Il ciclo è lo stesso della DPIA: cambia l’oggetto, non il metodo.

C’è però una differenza concettuale che va tenuta ferma, perché è il punto in cui molte integrazioni tra privacy e sistemi di gestione falliscono. Nella ISO 31000 e nella ISO 27001 il rischio si misura sugli obiettivi dell’organizzazione: continuità operativa, riservatezza degli asset, conformità, reputazione. Nel GDPR il rischio si misura sui diritti e sulle libertà delle persone fisiche: il portatore del rischio non è l’azienda ma l’interessato. La conseguenza pratica è netta: un rischio residuo che l’azienda potrebbe tranquillamente accettare per sé (una percentuale di falsi positivi in un sistema antifrode, per esempio) può essere inaccettabile quando a subirlo è la persona esclusa ingiustamente da un servizio. I criteri di accettazione non sono trasferibili: non si possono accettare i rischi degli altri con la stessa disinvoltura con cui si accettano i propri. È il motivo per cui un ISMS certificato 27001 non assorbe da solo la DPIA, e una DPIA non sostituisce la valutazione dei rischi dell’ISMS.

La buona notizia è che i due mondi si integrano bene, se la differenza è chiara. In pratica funziona così: un registro dei rischi unico con due dimensioni di impatto distinte (impatto sull’organizzazione e impatto sugli interessati), la DPIA agganciata al processo di risk assessment dell’ISMS come approfondimento obbligato quando il trattamento tocca l’art. 35, la ISO/IEC 27701 come estensione privacy del sistema 27001, e per chi usa intelligenza artificiale la ISO/IEC 42001, che porta nel sistema di gestione proprio la valutazione d’impatto sulle persone dei sistemi di AI. In questo impianto l’art. 22 smette di essere una norma esotica e diventa un controllo da presidiare: censimento delle decisioni automatizzate, qualificazione giuridica, DPIA, misure di intervento umano, spiegabilità, test antidiscriminazione, log e riesame periodico.

Cosa cambia con l’AI Act, e cosa potrebbe cambiare con il Digital Omnibus

L’AI Act non sostituisce l’art. 22: gli si affianca. Il Regolamento sull’intelligenza artificiale classifica come ad alto rischio molti dei sistemi che generano decisioni rilevanti ex art. 22, dal credit scoring alla gestione dei lavoratori alla selezione del personale, e impone al loro ciclo di vita un sistema di gestione del rischio, requisiti di trasparenza e la sorveglianza umana effettiva. La logica è complementare: il GDPR protegge la singola decisione sulla singola persona, l’AI Act regola il sistema che la produce. Per le aziende significa che le misure convergono: la sorveglianza umana chiesta dall’AI Act e l’intervento umano chiesto dall’art. 22, par. 3 si progettano insieme, una volta sola.

Sul fronte opposto si muove il pacchetto Digital Omnibus presentato dalla Commissione il 19 novembre 2025, che tra le modifiche proposte al GDPR interviene anche sull’eccezione contrattuale dell’art. 22, chiarendola in senso più permissivo per i titolari. La proposta è all’inizio del percorso legislativo, EDPB ed EDPS hanno già espresso riserve importanti sul pacchetto nel parere congiunto 1/2026, e il testo finale potrà cambiare molto. Il punto operativo è uno solo: oggi non è in vigore nulla di tutto questo. Le decisioni si prendono sul quadro attuale, che è quello descritto sopra, e chi allenta le garanzie oggi scommettendo sull’esito di un negoziato legislativo si assume un rischio regolatorio, non lo gestisce.

In pratica: da dove cominciare

• censire le decisioni automatizzate, comprese quelle comprate da fornitori: scoring, filtri automatici di selezione, sistemi antifrode, blocchi automatici di account e servizi;
• qualificarle: sono unicamente automatizzate? producono effetti giuridici o significativi? se sì, individuare l’eccezione applicabile e documentarla;
• eseguire la DPIA dove il trattamento rientra nell’art. 35, par. 3, lett. a), integrandola nel processo di risk assessment aziendale con la doppia dimensione di impatto;
• aggiornare le informative: esistenza della decisione automatizzata, logica, importanza e conseguenze, come chiedono gli artt. 13 e 14;
• progettare un intervento umano vero: persone con competenza, accesso ai dati e potere effettivo di modificare l’esito, con tracciatura delle revisioni;
• preparare la spiegabilità: essere in grado di raccontare a un interessato, in linguaggio comprensibile, come il sistema arriva al risultato, senza nascondersi dietro il segreto commerciale;
• verificare periodicamente esattezza e non discriminazione degli esiti, e registrare le verifiche: è la prova di accountability che l’Autorità chiede per prima.

Guardata da vicino, la disciplina delle decisioni automatizzate non è una gabbia: è un test di maturità organizzativa. Le aziende che sanno spiegare i propri algoritmi, correggerli e mettere una persona competente al posto giusto del processo sono anche quelle che di quegli algoritmi si fidano di più, perché li conoscono. PL Consulting affianca le organizzazioni nella valutazione d’impatto e nella governance dei trattamenti automatizzati: scopri il servizio dedicato alla DPIA e contattaci per costruire un impianto che tenga insieme GDPR, AI Act e sistemi di gestione.

Nota: ogni sistema decisionale automatizzato richiede una valutazione specifica del contesto, delle basi giuridiche e dei rischi. Questo articolo ha finalità informative generali e non sostituisce una valutazione professionale sul caso concreto. Articolo aggiornato ad agosto 2026.