Il giorno in cui il sistema entra in azienda
Immaginiamo il seguente scenario.
Il fornitore ha consegnato il sistema di AI. Il contratto è firmato, il sistema è installato e la presentazione commerciale ha una slide che dice “conforme all’AI Act”.
Ora la palla passa a chi lo userà: un ufficio del personale, un’amministrazione comunale, una banca, un ospedale.
Nel linguaggio del Regolamento, il deployer.
Ed è qui che possono nascere due errori speculari.
Il primo è fidarsi della slide e non chiedere nulla.
Il secondo è pensare che, se il sistema “è conforme”, il deployer non abbia altro da fare.
In mezzo c’è il lavoro vero, che questo articolo prova a descrivere.
Che cosa deve arrivare insieme al sistema
Il deployer non dovrebbe trovarsi davanti a una scatola nera, nemmeno dal punto di vista regolatorio.
Deve sapere quale sistema sta usando, quale sia la sua finalità prevista, quali istruzioni lo accompagnino e come sia stato qualificato ai sensi dell’AI Act.
Per i sistemi ad alto rischio, l’articolo 13 impone che il sistema sia progettato in modo sufficientemente trasparente e accompagnato da istruzioni per l’uso che contengono, tra l’altro:
- la finalità prevista;
- il livello di accuratezza;
- le circostanze note di rischio;
- le misure di sorveglianza umana;
- la durata di vita prevista.
L’articolo 26, dal canto suo, apre gli obblighi del deployer proprio con l’uso conforme a quelle istruzioni (paragrafo 1).
C’è poi la banca dati dell’Unione (articolo 71), dove sono registrati i sistemi ad alto rischio dell’Allegato III e anche quelli che il fornitore ha ritenuto non ad alto rischio ai sensi dell’articolo 6, paragrafo 3.
Per i deployer pubblici la consultazione non è un’opzione: se accertano che il sistema ad alto rischio che intendono usare non è stato registrato, non lo usano (articolo 26, paragrafo 8).
Il deployer, quindi, non inventa da zero la classificazione del sistema acquistato ma acquisisce gli elementi del fornitore, li comprende e verifica che l’uso che intende farne resti nel perimetro previsto.
Verificare non è riclassificare
Comprendere non vuol dire fermarsi all’etichetta.
Occorre andare oltre e capire su quale base è stata raggiunta la conclusione, domandandosi: qual è la finalità prevista? Il sistema ricade nell’Allegato III? Il fornitore ha applicato l’articolo 6, paragrafo 3? Ha escluso la profilazione? Ha registrato il sistema nella banca dati? Quali sono le istruzioni e i limiti?
Il deployer non subentra al fornitore nelle responsabilità che gli competono.
Tuttavia, non può nemmeno considerare la classificazione del sistema come un dato meramente formale o irrilevante, perché, se tale classificazione dovesse rivelarsi errata, l’autorità di vigilanza del mercato potrebbe rimetterla in discussione: con i poteri generali di vigilanza o, se il fornitore ha invocato l’articolo 6, paragrafo 3, con la procedura dell’articolo 80.
In quel caso, l’organizzazione rischierebbe di scoprire di aver utilizzato un sistema ad alto rischio senza aver adottato le garanzie e le misure di conformità che riteneva, erroneamente, di non dover applicare.
Il problema si fa serio quando il deployer decide di usare il sistema per una finalità diversa.
In quel momento deve chiedersi se il nuovo uso resti compatibile con la qualificazione originaria e se scattino le conseguenze dell’articolo 25 dell’AI Act, che trasformano il deployer in fornitore.
Gli obblighi che il deployer non può delegare
Il deployer di un sistema ad alto rischio non è un semplice utilizzatore.
L’articolo 26 gli assegna obblighi propri:
- usare il sistema secondo le istruzioni (paragrafo 1);
- affidare la sorveglianza umana a persone con la competenza, la formazione e l’autorità necessarie (paragrafo 2);
- garantire, nella misura in cui controlla i dati di input, che siano pertinenti e sufficientemente rappresentativi rispetto alla finalità prevista (paragrafo 4);
- monitorare il funzionamento, informare il fornitore e, se del caso, sospendere l’uso e segnalare gli incidenti gravi (paragrafo 5);
- conservare i log generati automaticamente per almeno sei mesi (paragrafo 6).
Tre obblighi meritano una menzione a parte, perché riguardano le persone.
Prima di mettere in servizio o usare un sistema ad alto rischio sul luogo di lavoro, i deployer che sono datori di lavoro informano i rappresentanti dei lavoratori e i lavoratori interessati (paragrafo 7).
I deployer di sistemi dell’Allegato III che adottano decisioni, o assistono nell’adottarle, riguardo a persone fisiche informano queste ultime di essere soggette all’uso del sistema (paragrafo 11).
Ancora, la persona destinataria di una decisione presa dal deployer sulla base dell’output di un sistema dell’Allegato III (esclusi quelli del punto 2), che produca effetti giuridici o incida in modo analogo significativamente su di lei, e che ritenga abbia un impatto negativo sulla sua salute, sulla sua sicurezza o sui suoi diritti fondamentali, ha diritto di ottenere spiegazioni chiare e significative sul ruolo del sistema nella decisione (articolo 86).
È un diritto residuale: non si applica nella misura in cui è già previsto dal diritto dell’Unione (paragrafo 3), e va quindi coordinato con gli articoli 15, paragrafo 1, lettera h), e 22 GDPR, sul cui contenuto la Corte di giustizia si è pronunciata nella sentenza Dun & Bradstreet Austria (C-203/22, 27 febbraio 2025).
Altri obblighi prescindono dall’alto rischio:
- l’alfabetizzazione del personale, che dopo il 27 luglio 2026 richiede di adottare misure a sostegno dello sviluppo delle competenze (articolo 4);
- gli obblighi di trasparenza dell’articolo 50, paragrafi 3 e 4, sui sistemi di riconoscimento delle emozioni, di categorizzazione biometrica e sui deep fake;
- i divieti dell’articolo 5, che si rivolgono anche a chi usa il sistema.
Per il lettore italiano c’è un tassello in più: la legge 23 settembre 2025, n. 132, all’articolo 11, impone al datore di lavoro o al committente di informare il lavoratore dell’utilizzo dell’intelligenza artificiale, nei casi e con le modalità dell’articolo 1 bis del d.lgs. 26 maggio 1997, n. 152.
È un obbligo che si affianca a quello dell’articolo 26, paragrafo 7, e che non aspetta il 2 dicembre 2027.
La seconda valutazione: la FRIA
Prima di usare un sistema ad alto rischio dell’Allegato III (esclusi quelli per le infrastrutture critiche del punto 2), alcuni deployer devono fare qualcosa in più.
I deployer che sono organismi di diritto pubblico o enti privati che forniscono servizi pubblici, e i deployer di sistemi per la valutazione del merito creditizio o per la valutazione dei rischi e la determinazione dei prezzi nelle assicurazioni sulla vita e sanitarie (Allegato III, punto 5, lettere b) e c)), effettuano una valutazione dell’impatto sui diritti fondamentali che l’uso del sistema può produrre (articolo 27).
È la c.d. FRIA (Fundamental Rights Impact Assessment: Valutazione d’Impatto sui Diritti Fondamentali).
La FRIA non è una DPIA con un altro nome.
Descrive i processi del deployer in cui il sistema sarà usato, il periodo e la frequenza dell’uso, le categorie di persone e di gruppi interessati, i rischi specifici di danno per quelle persone, le misure di sorveglianza umana e le misure da adottare se i rischi si concretizzano.
I risultati vanno notificati all’autorità di vigilanza del mercato, compilando il modello di questionario che l’Ufficio per l’IA deve predisporre, anche in forma di strumento automatizzato (paragrafi 3 e 5).
Il Regolamento stesso costruisce il ponte con la protezione dei dati.
Dopo il Regolamento (UE) 2026/1744, se uno qualsiasi degli obblighi dell’articolo 27 è già soddisfatto dalla DPIA effettuata a norma dell’articolo 35 GDPR o dell’articolo 27 della direttiva (UE) 2016/680, il deployer può, nella FRIA, rinviare alle sezioni pertinenti della DPIA o riprenderne le parti rilevanti (paragrafo 4).
È un meccanismo di coordinamento, non di assorbimento: la FRIA resta un adempimento autonomo dell’AI Act, con un proprio oggetto e una propria notifica.
Per un’amministrazione pubblica che adotta un sistema ad alto rischio, quindi, i documenti da tenere distinti sono tre: la scheda di classificazione, la FRIA, la DPIA.
La terza valutazione: la DPIA
Se il sistema tratta dati personali, l’analisi cambia piano.
Il GDPR non richiede di stabilire se il sistema sia “ad alto rischio” ai sensi dell’AI Act.
Chiede al titolare del trattamento di valutare, quando ricorrono i presupposti dell’articolo 35, l’impatto del trattamento previsto sulla protezione dei dati personali.
Nella pratica i due piani si avvicinano più di quanto sembri.
L’articolo 35, paragrafo 3, lettera a) GDPR, rende obbligatoria la DPIA per la valutazione sistematica e globale di aspetti personali basata su un trattamento automatizzato, compresa la profilazione, da cui dipendono decisioni con effetti giuridici o analoghi; e l’elenco del Garante, adottato ai sensi dell’articolo 35, paragrafo 4, comprende i trattamenti valutativi o di scoring su larga scala e quelli effettuati con tecnologie innovative, tra le quali indica espressamente i sistemi di intelligenza artificiale. Nella selezione del personale, poi, gli interessati sono candidati e lavoratori, cioè persone in posizione di squilibrio rispetto al titolare.
Quindi, per il sistema di selezione del personale dei nostri esempi, la DPIA è di regola dovuta, a prescindere dall’AI Act.
La DPIA guarda al trattamento concreto: finalità, categorie di dati, interessati, fonti, flussi, destinatari, conservazione, misure, necessità, proporzionalità e rischi per i diritti e le libertà; e si confronta con l’articolo 22 GDPR.
Dopo la sentenza SCHUFA della Corte di giustizia (C-634/21, 7 dicembre 2023), un punteggio automatizzato sul quale il decisore si basa in modo determinante può costituire esso stesso una decisione automatizzata.
La Corte si è pronunciata su un punteggio prodotto da un terzo, ma il principio è difficilmente eludibile anche per un ranking interno: a mio avviso il “ranking proposto al recruiter” non è al riparo soltanto perché a firmare è una persona, e il titolare dovrà verificare se ricorra una delle eccezioni dell’articolo 22, paragrafo 2, con le garanzie del paragrafo 3.
Le due valutazioni, insomma, non si sovrappongono.
Un sistema può non essere ad alto rischio ai sensi dell’AI Act e il trattamento presentare comunque un rischio elevato ai sensi del GDPR; e un sistema ad alto rischio non consente di saltare la valutazione GDPR né di presumere quali siano i rischi del trattamento concreto.
Un ponte, non una fusione: l’articolo 26, paragrafo 9
L’AI Act riconosce espressamente il collegamento tra i regimi.
L’articolo 26, paragrafo 9, prevede che, “se del caso”, i deployer di sistemi ad alto rischio usino le informazioni fornite dal fornitore a norma dell’articolo 13 per adempiere al loro obbligo di effettuare una valutazione d’impatto sulla protezione dei dati, ai sensi dell’articolo 35 GDPR o dell’articolo 27 della direttiva (UE) 2016/680, recepito in Italia dall’articolo 23 del decreto legislativo 18 maggio 2018, n.51.
Il rinvio alla direttiva di polizia non è un dettaglio: per le autorità di contrasto la DPIA ha una base giuridica diversa, e l’AI Act lo sa.
Il legislatore non dice che la classificazione ad alto rischio sostituisce la DPIA. Dice che le informazioni sul sistema devono alimentarla.
Il fornitore conosce architettura, finalità prevista, prestazioni, limiti, rischi noti e condizioni di funzionamento.
Il titolare conosce il trattamento concreto, il contesto organizzativo, i dati, gli interessati e le conseguenze reali dell’impiego.
La DPIA nasce dall’incontro tra queste due prospettive, ma conserva la propria autonomia giuridica.
Deployer e titolare non sono sinonimi
Un’altra distinzione è necessaria. “Deployer” è un termine dell’AI Act.
“Titolare del trattamento” è un termine del GDPR.
Possono coincidere nella stessa organizzazione, ma non sono la stessa cosa.
Se il deployer usa il sistema per proprie finalità e determina finalità e mezzi del trattamento, è titolare e, quando ricorrono i presupposti, deve fare la DPIA.
Se invece opera come responsabile del trattamento per conto di un titolare, l’obbligo dell’articolo 35 GDPR resta in capo al titolare, e il responsabile deve assisterlo secondo l’articolo 28 GDPR.
La mappa non finisce qui.
Il fornitore che eroga il sistema come servizio tratta spesso i dati del deployer come responsabile e i propri dati di addestramento come titolare.
Un deployer che modifica la finalità del sistema può diventare fornitore ai sensi dell’articolo 25 senza smettere di essere titolare; e il nuovo articolo 4 bis, introdotto dal Regolamento (UE) 2026/1744, che estende a fornitori e deployer di tutti i sistemi la facoltà, già prevista dall’articolo 10, paragrafo 5, di trattare categorie particolari di dati per individuare e correggere le distorsioni, nei limiti della stretta necessità e con garanzie, è un punto di contatto tra i due regimi che la DPIA deve registrare.
Per questo motivo, le mappe dei ruoli AI Act e GDPR vanno costruite separatamente, e poi messe in relazione.
Come strutturerei una DPIA che usa un sistema di AI
Una DPIA ben costruita dovrebbe aprirsi con una sezione dedicata alla qualificazione del sistema ai sensi dell’AI Act, senza farne il cuore della valutazione GDPR.
In quella sezione indicherei fornitore, sistema, finalità prevista, qualificazione AI Act dichiarata, norma applicata, eventuale riferimento all’Allegato III, eventuale uso dell’articolo 6, paragrafo 3, con gli estremi della registrazione nella banca dati, principali istruzioni e limiti, ruolo dell’organizzazione ai sensi dell’AI Act ed eventuale FRIA effettuata o dovuta.
Poi aprirei la vera valutazione GDPR.
Qui analizzerei i rischi per gli interessati derivanti dal trattamento concreto: discriminazione, inaccuratezza, opacità, decisioni automatizzate e loro contestabilità ai sensi dell’articolo 22, eccesso di dati, riutilizzo incompatibile, perdita di controllo, sicurezza, effetti sui diritti, qualità dei dati, bias e ogni altro scenario pertinente.
La classificazione AI Act diventa così un input della DPIA, non il suo risultato; e la FRIA, dove dovuta, può rinviare alle sezioni pertinenti della DPIA senza confondersi con essa.
Conclusioni
L’AI Act qualifica il sistema e disciplina gli obblighi legati al ruolo e all’uso.
Ad alcuni deployer richiede una valutazione d’impatto sui diritti fondamentali dell’uso concreto.
Il GDPR e la direttiva di polizia valutano il trattamento di dati personali e il rischio per i diritti e le libertà delle persone.
Il sistema può essere lo stesso ma i rischi che osserviamo, e i documenti che li governano, sono diversi.
Nel prossimo e ultimo articolo trasformeremo questi principi in uno strumento operativo: una scheda di classificazione AI Act che consenta a fornitori e organizzazioni di documentare il percorso seguito, le fonti usate e le condizioni che impongono un riesame.
