L'articolo 22 del GDPR e le decisioni automatizzate in azienda
L'autorità olandese ha sanzionato Uber per 824,99 milioni di euro per decisioni interamente automatizzate senza intervento umano. Il pattern non riguarda solo le piattaforme: come censire i flussi automatici in azienda e dove va messo il punto di fermata.
Il 21 agosto 2026 l'Autoriteit Persoonsgegevens, l'autorità olandese per la protezione dei dati, ha sanzionato Uber per 824.990.000 euro. È la seconda sanzione più alta mai comminata sotto il GDPR. La contestazione riguarda un sistema che disattivava gli account dei conducenti in modo interamente automatizzato, senza che una persona esaminasse il caso prima del blocco. La condotta contestata copre il periodo 2018-2022. Uber ha presentato ricorso, sostenendo che la maggior parte delle sospensioni sono brevi, che nessuna disattivazione permanente avviene senza revisione umana e che i conducenti possono fare appello.
La difesa di Uber è la parte più utile del caso per chiunque stia valutando la propria esposizione. Esistevano una revisione umana e un canale di appello, e non sono bastati.
Cosa contesta l'autorità
La base giuridica è l'articolo 22 del GDPR, che vieta di sottoporre una persona a una decisione basata unicamente su un trattamento automatizzato quando quella decisione produce effetti giuridici o incide in modo analogo in misura significativa. A questa si aggiungono gli obblighi di informazione e trasparenza degli articoli 12-15, per non aver spiegato adeguatamente il funzionamento del processo decisionale.
Monique Verdier, vicepresidente dell'autorità, ha sintetizzato il principio dicendo che un computer non dovrebbe prendere da solo decisioni con conseguenze rilevanti per una persona, e che quelle decisioni avrebbero dovuto essere esaminate prima da un essere umano.
Le due parole che contano nella frase sono "da solo" e "prima". Non è in discussione se l'algoritmo funzioni bene. Non è in discussione se esista un rimedio successivo. Quello che l'autorità misura è se, nel momento in cui la decisione produce effetto, una persona con potere di fermarla sia stata coinvolta.
Il perimetro reale del problema
Il caso arriva dal ride hailing, e questo porta molte aziende ad archiviarlo come questione di piattaforme e lavoro digitale. È una lettura che costa cara, perché il pattern sanzionato è tra i più diffusi nei sistemi gestionali di aziende del tutto tradizionali.
Alcuni esempi che incontriamo regolarmente nei nostri assessment:
- Sospensione automatica di un fornitore dal portale acquisti al superamento di una soglia di scoring, di ritardo o di non conformità documentale
- Blocco automatico del credito a un cliente al raggiungimento di un parametro di rischio calcolato dal sistema
- Scarto automatico di candidature in fase di screening, con filtri o punteggi applicati prima di qualsiasi lettura umana
- Declassamento automatico di un rivenditore o di un agente da una fascia commerciale a un'altra, con effetti su provvigioni e condizioni
- Revoca automatica di accessi o abilitazioni a un collaboratore in base a metriche di utilizzo o a segnalazioni del sistema
- Rifiuto automatico di rimborsi o pratiche in flussi assicurativi, sanitari, di garanzia
In quasi tutti i casi che abbiamo visto, questi flussi non sono stati progettati come decisioni automatizzate. Sono nati come regole di efficienza dentro un ERP, un CRM o un portale, sono stati configurati anni fa da un fornitore che non c'è più, e nessuno li ha mai censiti come trattamento rilevante ai sensi dell'articolo 22.
L'incastro con l'AI Act
Dal 2 agosto 2026 la Commissione europea, attraverso l'AI Office e insieme alle autorità nazionali, ha avviato l'enforcement dell'AI Act (cosa è davvero vincolante da quella data), e sono diventati applicabili gli obblighi di trasparenza dell'articolo 50, con sanzioni fino a 15 milioni di euro o al 3% del fatturato mondiale annuo.
Diciannove giorni dopo, la prima sanzione europea di peso su una decisione algoritmica che incide sul lavoro non arriva dall'AI Act. Arriva dal GDPR.
Questo dice due cose a chi deve allocare un budget di compliance nei prossimi sei mesi.
La prima è che l'apparato con capacità operativa immediata è quello della protezione dei dati, che dispone di autorità strutturate, otto anni di prassi e una giurisprudenza consolidata. La seconda riguarda la sequenza. L'Allegato III dell'AI Act classifica come ad alto rischio i sistemi usati per l'assunzione, la selezione, la promozione, la cessazione dei rapporti e l'assegnazione dei compiti, ma i relativi obblighi non sono ancora applicabili: il Digital Omnibus li ha spostati al 2 dicembre 2027. Chi legge questo come una tregua sta leggendo male. L'articolo 22 copre già oggi buona parte di quello stesso perimetro, con un'autorità che sanziona e un massimale che il caso Uber ha appena mostrato. Un'azienda che censisce i propri flussi automatici adesso per il GDPR sta costruendo l'inventario che le servirà nel 2027 per l'AI Act, con diciassette mesi di margine invece che sotto scadenza.
Fare due volte lo stesso lavoro, con due gruppi di lavoro diversi e due fornitori diversi, è l'errore di sequenza più costoso che vediamo in questo momento.
Quale framework serve davvero alla tua azienda?
L'AI Rating misura la maturità sulle quattro aree del modello e indica da dove partire, con priorità e sforzo stimato.
Avvia il tuo AI RatingL'inventario delle decisioni automatizzate
Nel 05 Framework questa attività appartiene alla fase ASSESS, prima che qualsiasi use case venga selezionato. La ragione è di ordine pratico: un'azienda che non sa quali decisioni automatiche ha già in produzione non è in grado di valutare il rischio di quelle che sta per aggiungere.
Il censimento parte da cinque domande, applicate a ogni flusso in cui un sistema produce un esito su una persona fisica.
- Quale esito produce il sistema, e su chi. Un dipendente, un collaboratore, un candidato, un cliente persona fisica, un titolare di ditta individuale. Le persone giuridiche non rientrano nell'articolo 22, ma spesso il flusso colpisce entrambe e nessuno ha separato i due casi.
- L'esito ha effetti significativi. Perdita di reddito, esclusione da un'opportunità, interruzione di un rapporto, limitazione di un accesso, peggioramento di condizioni economiche.
- Esiste un punto di fermata a monte. Non un canale di reclamo, non una revisione successiva: una persona con l'autorità e il tempo materiale di bloccare l'esito prima che produca effetto.
- Quella persona ha gli elementi per decidere. Un operatore che vede solo un punteggio e un pulsante di conferma non è un controllo umano, è una firma. L'autorità olandese ha valutato la sostanza del coinvolgimento, non la sua esistenza formale.
- La persona colpita sa che la decisione è automatizzata, e le è stata fornita una spiegazione comprensibile della logica applicata.
Chi risponde no alla terza o alla quarta domanda su un flusso che ha superato le prime due ha trovato un'esposizione, indipendentemente dal fatto che nel flusso ci sia o meno un modello di AI.
Human in the loop come requisito di architettura
L'esito più frequente di questo censimento è la decisione di scrivere una policy. È la risposta sbagliata, e il caso Uber lo mostra bene: una procedura che prevede la revisione umana non protegge se il sistema è comunque in grado di produrre l'esito senza attenderla.
Il presidio va messo nel flusso, non nel documento. In termini concreti significa che il sistema non deve poter chiudere l'operazione finché un'autorizzazione non è stata registrata, che l'autorizzazione deve essere tracciata con identità e timestamp, e che chi autorizza deve vedere il caso e non solo il punteggio.
È una decisione di architettura, e come tale va presa in fase ARCHITECT insieme al resto del disegno, non aggiunta in fase ACTIVATE quando il sistema è già in produzione. Il costo di inserire un punto di autorizzazione in un flusso già rilasciato è, nella nostra esperienza, tra le tre e le sei volte quello di prevederlo nel disegno iniziale.
Da dove partire
Un'azienda strutturata italiana ha in media tra i quindici e i quaranta flussi che meritano la verifica, distribuiti tra ERP, CRM, portali fornitori, sistemi HR e piattaforme di customer service. Il censimento richiede da due a quattro settimane di lavoro e produce tre risultati: la mappa dei flussi, la classificazione del rischio per ciascuno, e la lista dei punti di autorizzazione da inserire in ordine di priorità.
Lo stesso inventario serve poi come base per la classificazione ai sensi dell'Allegato III dell'AI Act quando gli obblighi diventeranno applicabili nel dicembre 2027, senza doverlo rifare da capo.
Fonti