DPIA e valutazione d'impatto sui diritti fondamentali nell'IA: come decidere quale valutazione serve prima di usare dati sensibili

La domanda iniziale non è se c'è IA, ma cosa accade a ciascuna persona

Un assistente che sintetizza fascicoli, un modello che ordina richieste o uno strumento che stima un rischio possono usare tecniche simili e tuttavia comportare obblighi e danni potenziali molto diversi. La valutazione deve iniziare dal trattamento e dall'effetto effettivi: quali informazioni entrano, quale risultato produce il sistema, chi lo riceve, quale azione determina e quali conseguenze può avere per una persona concreta.

Questa distinzione è particolarmente importante quando sono coinvolti dati sanitari, biometrici, lavorativi, finanziari, assicurativi, di minori o di persone in una situazione di dipendenza. È rilevante anche quando il sistema desume informazioni che nessuno ha fornito espressamente, come una priorità, una propensione, una categoria di rischio o una presunta idoneità. Il fatto che un'inferenza non compaia in un modulo non ne elimina la rilevanza per la protezione dei dati né per i diritti fondamentali.

Lo scopo di una valutazione non è dichiarare che un modello sia etico, sicuro o conforme in astratto. È documentare se un uso circoscritto è necessario e proporzionato, quali danni plausibili può causare, quali evidenze consentiranno di rilevarli, quali controlli li ridurranno e quale responsabile abbia la capacità effettiva di interrompere l'uso. Un modello compilato da un fornitore può apportare informazioni tecniche, ma non può risolvere da solo questioni che dipendono dalla finalità, dalla popolazione interessata, dalle regole operative e dal quadro giuridico di chi impiega il sistema.

Quattro livelli di rischio da tenere distinti

La valutazione d'impatto sulla protezione dei dati, comunemente nota come DPIA, si concentra sui rischi per i diritti e le libertà delle persone derivanti da un trattamento di dati personali. Il Regolamento generale sulla protezione dei dati richiede di svolgerla prima del trattamento quando quest'ultimo può presentare un rischio elevato. Non è un'informativa privacy più estesa: deve descrivere il trattamento, valutare necessità e proporzionalità, analizzare i rischi e stabilire misure per affrontarli.

La valutazione d'impatto sui diritti fondamentali prevista dal regolamento sull'intelligenza artificiale parte da un presupposto diverso. Per determinati deployer di sistemi di IA ad alto rischio, deve essere effettuata prima del primo utilizzo. Analizza come l'uso previsto possa incidere sulle persone o sui gruppi interessati ed è legata al contesto di impiego. Può comprendere rischi di discriminazione, accesso diseguale ai servizi, dignità, tutela dei minori, libertà di espressione, tutela effettiva o altre garanzie, oltre ai rischi collegati ai dati personali.

A questi livelli si aggiungono la sicurezza tecnica e il rischio operativo. La prima comprende, tra le altre materie, robustezza, guasti, cibersicurezza, degrado delle prestazioni e tracciabilità. Il secondo osserva il modo in cui le persone usano il risultato: pressione per raggiungere obiettivi, eccessiva automazione, mancanza di tempo per riesaminare, assenza di canali di correzione o incentivi che trasformano una raccomandazione in una decisione automatica di fatto. Un fascicolo solido collega tutti e quattro i livelli, ma non li confonde né presume che il superamento di un test tecnico elimini i rischi giuridici o sociali.

Albero decisionale prima del deployment

Non esiste una regola affidabile che trasformi ogni uso dell'IA in una DPIA, né un'altra che consenta di escluderla perché è prevista una revisione umana. La decisione richiede di raccogliere i fatti del caso e confrontarli con il RGPD, con gli elenchi dei trattamenti soggetti a DPIA pubblicati dall'autorità di controllo competente e, quando pertinente, con il regolamento sull'intelligenza artificiale.

Per prima cosa, stabilite se vi siano dati personali. Possono trovarsi nei dati di ingresso, nei registri di utilizzo, nei risultati o nelle inferenze. Poi individuate se ricorrano fattori che di solito innalzano il rischio: categorie particolari di dati, profilazione, valutazione sistematica, decisioni con effetti giuridici o effetti analogamente significativi, monitoraggio sistematico, larga scala, persone vulnerabili, combinazione di insiemi di dati, tecnologie innovative o una relazione di potere asimmetrica. Questi fattori non funzionano come un elenco meccanico; servono a motivare una conclusione e a non trascurare rischi prevedibili.

Successivamente, analizzate se il sistema e il suo uso previsto rientrino in una categoria ad alto rischio del regolamento sull'intelligenza artificiale. La classificazione dipende dall'uso effettivo e dalle categorie normative pertinenti, non dal nome del prodotto né da una dichiarazione commerciale. Se lo è, occorre verificare se il deployer rientri nei casi obbligati a svolgere una valutazione d'impatto sui diritti fondamentali prima del primo utilizzo. Quando il flusso tratta anche dati personali con probabile rischio elevato, possono essere necessarie entrambe le valutazioni.

Se, dopo le misure previste, il trattamento continua a comportare un rischio elevato che il titolare del trattamento non può mitigare, il RGPD stabilisce la consultazione preventiva dell'autorità di controllo prima di iniziare il trattamento. La conclusione non deve essere presentata come un semplice rischio accettato internamente se la norma richiede tale consultazione.

Cosa deve contenere una DPIA e perché non equivale a un'informativa privacy

La DPIA deve includere una descrizione sistematica delle operazioni di trattamento e delle loro finalità, compreso il legittimo interesse perseguito quando pertinente. Deve inoltre contenere una valutazione della necessità e della proporzionalità, una stima dei rischi per i diritti e le libertà delle persone e le misure previste per affrontarli. Non è quindi sufficiente elencare categorie di dati, inserire clausole di sicurezza generiche o affermare che esiste un interesse aziendale all'automazione.

In un flusso di IA, la descrizione sistematica dovrebbe comprendere raccolta, preparazione, addestramento quando previsto, inferenza, validazione, intervento umano, comunicazione del risultato, registri ed eliminazione. Deve identificare sia i dati diretti sia le inferenze. Per esempio, un punteggio di frode, una priorità clinica o una previsione di abbandono possono essere dati personali se si riferiscono a una persona identificata o identificabile e sono usati per valutarla.

Un'informativa privacy informa le persone di un trattamento e può essere necessaria per adempiere agli obblighi di trasparenza. Tuttavia, non sostituisce la valutazione interna preventiva di rischi, necessità, proporzionalità e misure. Neppure una valutazione generica elaborata dal fornitore sostituisce l'analisi del titolare del trattamento, perché il fornitore normalmente non conosce con precisione la popolazione servita, i dati locali, le soglie, l'azione decisa dal personale o i rimedi disponibili.

Gli elenchi dei trattamenti che richiedono una DPIA e gli elenchi delle eccezioni possono variare secondo l'autorità di controllo competente. Un'organizzazione che opera in più Stati membri deve documentare quale autorità e quale elenco abbia considerato. Quando vi è un ragionevole dubbio, una valutazione proporzionata e tempestiva può rivelare che il progetto deve cambiare prima che il costo di inversione diventi elevato.

Valutazione d'impatto sui diritti fondamentali: ambito e coordinamento con la DPIA

Il regolamento sull'intelligenza artificiale prevede una valutazione d'impatto sui diritti fondamentali per determinati deployer prima del primo utilizzo di sistemi di IA ad alto rischio. L'obbligo non si attiva per qualunque software che usi IA. Richiede di verificare sia che il sistema rientri nelle categorie ad alto rischio applicabili, sia che il deployer rientri nei casi previsti dalla norma. Tra i contesti che richiedono particolare attenzione figurano determinati usi da parte di organismi pubblici o soggetti che prestano servizi pubblici e alcuni usi ad alto rischio relativi a settori quali credito, assicurazioni o servizi di emergenza, in base alla classificazione e all'ambito normativo applicabili.

La valutazione deve essere contestuale. Lo stesso sistema può presentare rischi diversi se viene usato per supportare una coda di lavoro interna, per filtrare l'accesso a un servizio essenziale o per prioritizzare azioni che incidono su una persona. Deve descrivere i gruppi che potrebbero essere interessati, le possibili conseguenze, le misure di supervisione umana e i meccanismi pertinenti di informazione e reclamo. Deve anche tenere conto dell'esistenza di ostacoli pratici per contestare o correggere un risultato.

Quando il sistema tratta dati personali e la DPIA è obbligatoria, le due valutazioni devono essere coordinate, non duplicate ciecamente. Un inventario comune di dati, finalità, partecipanti, versioni e controlli riduce le incoerenze. Ciononostante, deve essere mantenuta una risposta distinta per ciascun obbligo: la DPIA deve dimostrare l'analisi richiesta dal RGPD, mentre la valutazione dei diritti fondamentali deve rispondere agli elementi del regolamento sull'intelligenza artificiale applicabili al deployment.

Il calendario di applicazione del regolamento sull'intelligenza artificiale contiene regole transitorie ed è stato oggetto di modifiche. Prima di concludere che un obbligo sia già applicabile a un caso concreto, documentate la data di utilizzo previsto, la versione normativa consultata, la categoria del sistema e la disposizione transitoria applicabile. Questa guida non sostituisce tale verifica giuridica specifica.

Inventario minimo e prove che devono accompagnare il fascicolo

Prima di misurare accuratezza o distorsioni, costruite un inventario che consenta di riprodurre l'analisi. Deve fissare la finalità approvata e le finalità escluse; la base e i limiti del trattamento; le origini dei dati; gli attributi forniti, osservati e inferiti; le persone interessate; i destinatari; i periodi di conservazione; il fornitore; il modello e la sua versione; le soglie; e le azioni che il risultato consente o attiva. Se un'organizzazione non riesce a descrivere questi elementi, difficilmente potrà dimostrare necessità, proporzionalità o tracciabilità.

Le prove devono rispondere ai danni plausibili, non soltanto a una metrica aggregata. Se un punteggio determina l'ordine di presa in carico, sono rilevanti i falsi negativi che ritardano i casi urgenti e i falsi positivi che penalizzano ingiustamente altri casi. Se le prestazioni possono differire tra gruppi, la valutazione deve spiegare quali gruppi siano stati analizzati, perché siano rilevanti, quali limiti abbiano i dati di test e cosa si farà se non esistono evidenze sufficienti. In alcuni casi, raccogliere attributi per misurare le disparità crea a sua volta rischi per la protezione dei dati; ciò richiede una giustificazione e salvaguardie specifiche, non un'omissione automatica dell'analisi.

Devono essere testati anche astensione e degrado. Un sistema può essere più sicuro se si astiene quando le informazioni sono incomplete o la sua confidenza non supera una soglia, ma tale astensione deve indirizzare il caso verso un percorso umano effettivo e entro tempi definiti. Simulate gli incidenti: dati errati, cambiamenti della popolazione, indisponibilità di un fornitore, risultati incoerenti, richieste di accesso o rettifica e pressione operativa per saltare i riesami. Registrate quale evidenza consentirebbe di rilevare il problema e chi interverrebbe.

Controlli di riprogettazione, rischio residuo e autorità di fermare il sistema

L'esito di una valutazione non deve ridursi ad approvare o respingere un prodotto. Spesso consente di riprogettare il flusso per ridurre esposizione e danno. Tra le opzioni figurano minimizzare le variabili, non usare categorie particolarmente sensibili quando non necessarie, separare una raccomandazione dalla decisione finale, limitare il sistema a un'attività amministrativa, ridurre la scala iniziale, alzare la soglia di astensione, impedire determinati usi secondari e abilitare un riesame competente prima di effetti sfavorevoli.

Il riesame umano è un controllo solo se dispone di capacità, informazioni, tempo e autorità. Una persona che conferma centinaia di punteggi all'ora o che non conosce i limiti del modello può fornire un'apparenza di controllo senza modificare il rischio. Definite quali risultati richiedono riesame, quali segnali consentono di annullare la raccomandazione, quale formazione riceva il team, quale termine si applichi e come sia registrato il dissenso. Gli annullamenti possono rivelare un problema di dati, di soglia o di progettazione che impone di riaprire la valutazione.

Il rischio residuo deve essere descritto concretamente: quale danno resti possibile, chi possa esserne colpito, con quale probabilità e gravità stimate, quali controlli restino attivi e quali incertezze persistano. L'accettazione non può restare implicita. Deve essere assegnata a una persona o a un organo competente ad assumerla e deve coesistere con un'autorità indipendente per arrestare o ripristinare il sistema quando si attivi una soglia di sicurezza, qualità, discriminazione, non conformità o incidente.

Riaprite la valutazione prima di modifiche sostanziali, non dopo che il danno si è verificato. Sono fattori scatenanti ricorrenti la modifica di modello, fornitore, dati, popolazione, finalità, soglia, integrazione, azione automatica, volume, normativa applicabile o evidenza di prestazioni diseguali. Le revisioni periodiche aiutano, ma non sostituiscono questi fattori basati su cambiamenti concreti.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.