Valutazione d’impatto sui diritti fondamentali per l’IA: come stabilire se è necessaria e cosa documentare

Ambito e cautela: una valutazione per decidere prima dell’uso

La valutazione d’impatto sui diritti fondamentali prevista dall’articolo 27 del regolamento sull’intelligenza artificiale, noto come AI Act, è un’analisi preventiva che determinati deployer devono svolgere prima di utilizzare alcuni sistemi di IA ad alto rischio. Il suo scopo pratico è esaminare come l’uso previsto potrebbe incidere su persone o gruppi nel contesto specifico e stabilire quali misure, responsabili e meccanismi di risposta siano necessari prima di autorizzarlo.

Non è una certificazione del sistema, una garanzia che non si verificheranno danni né una valutazione generale di tutte le attività di un’organizzazione. Inoltre, non sostituisce automaticamente una valutazione d’impatto sulla protezione dei dati (DPIA). Questa guida ha un obiettivo più circoscritto: aiutare a stabilire se l’obbligo si applica al caso e organizzare il lavoro necessario per rendere tracciabile la decisione di mettere il sistema in uso.

La normativa applicabile può cambiare e le fonti ufficiali indicate segnalano una modifica del 2026 che incide, tra gli altri aspetti, sul trattamento degli elementi della DPIA e sul questionario che deve elaborare l’Ufficio per l’IA. Prima di applicare questa guida, occorre quindi consultare il testo consolidato vigente, i moduli ufficiali e il calendario applicabile. Questa guida struttura l’analisi, ma non costituisce consulenza legale.

Percorso di applicabilità: chi deve valutare e quale uso verificare

L’obbligo previsto dall’articolo 27 non riguarda indistintamente ogni organizzazione che utilizza l’IA. In generale, occorre verificare se il sistema rientra nella pertinente categoria ad alto rischio e se il soggetto che lo mette in uso appartiene a una delle categorie indicate dalla norma. L’articolo contempla, tra gli altri, gli organismi di diritto pubblico, gli enti privati che forniscono servizi pubblici e i deployer di determinati sistemi ad alto rischio nell’ambito del credito e delle assicurazioni sulla vita o malattia.

La valutazione è legata all’uso effettivo previsto, non soltanto al nome commerciale del prodotto o alla classificazione generale assegnata dal fornitore. Occorre individuare la finalità, le funzioni attivate, il processo organizzativo in cui il sistema è inserito e le persone interessate. Se uno strumento ha più impieghi, è opportuno analizzare separatamente ciascun caso d’uso: l’obbligo e i rischi possono variare da un caso all’altro.

L’articolo 27 esclude da questo specifico obbligo i sistemi ad alto rischio indicati al punto 2 dell’allegato III. L’esclusione non va estesa a qualsiasi sistema che sembri comportare un rischio limitato e, da sola, non risolve gli eventuali altri obblighi previsti dall’AI Act, dalla normativa sulla protezione dei dati o dalle norme settoriali. Se la classificazione dipende da un’eccezione, da una modifica dell’uso o dall’interpretazione della finalità, documenta le ragioni della conclusione e richiedi una verifica legale.

La decisione può essere ricondotta a queste domande: l’organizzazione è un deployer incluso? Il sistema e il caso d’uso rientrano nell’ambito pertinente? Si applica un’eccezione? La valutazione già svolta è ancora valida per questo uso? Se mancano informazioni per rispondere, la conclusione responsabile non è presumere che l’obbligo non si applichi: occorre individuare il dato mancante, assegnarne la responsabilità e specificare quale condizione impedisce di concludere l’approvazione.

Tempistiche, responsabilità e comunicazione all’autorità

La valutazione deve essere completata prima del deployment pertinente, non dopo che si sono già verificati danni o che è iniziata l’operatività ordinaria. In pratica, il punto di controllo dovrebbe precedere l’autorizzazione dell’accesso agli utenti, l’integrazione del sistema in un processo decisionale o la possibilità che i suoi risultati incidano su decisioni riguardanti le persone.

Le responsabilità organizzative devono essere assegnate esplicitamente. Il team che promuove il caso d’uso descrive il processo e le decisioni che il sistema contribuirà a supportare; le funzioni di conformità, privacy, diritti fondamentali, sicurezza e operations esaminano i rispettivi ambiti; un organo con poteri sufficienti decide se l’uso possa essere approvato, debba essere modificato oppure debba essere interrotto. La collaborazione non deve rendere indistinto chi è responsabile di completare e mantenere aggiornata la valutazione.

La norma prevede che, una volta svolta, la valutazione sia comunicata all’autorità di vigilanza del mercato competente. Per stabilire quale autorità sia competente e quali siano il canale e il formato applicabili, occorre verificare la giurisdizione, l’organizzazione istituzionale nazionale e le istruzioni ufficiali vigenti. Non è opportuno inventare un destinatario o una procedura basandosi su un modello interno.

È inoltre necessario stabilire quando aggiornare la valutazione. Un cambiamento della finalità, della popolazione interessata, dei dati in ingresso, della frequenza d’uso, del livello di automazione, delle misure di supervisione o delle condizioni operative può modificare l’analisi. Registra quali cambiamenti impongono di riaprire la decisione, chi li rileva e chi può sospendere l’uso durante la revisione.

Cosa documentare: dalla finalità alle persone interessate

L’articolo 27 definisce un nucleo di informazioni che consente di mettere in relazione il sistema con il contesto in cui sarà usato. La valutazione deve descrivere i processi nei quali il sistema sarà utilizzato, in linea con la finalità prevista; la durata e la frequenza d’uso; le categorie di persone e di gruppi che potrebbero essere interessati; i rischi specifici di danno in quel contesto, tenendo conto delle informazioni pertinenti fornite dal fornitore; l’applicazione delle misure di supervisione umana; e le misure da adottare qualora i rischi si concretizzino, incluse le disposizioni di governance interna e i meccanismi di reclamo.

Perché questi elementi siano utili a prendere una decisione, evita formule vaghe come «potrebbe esserci un bias» o «sarà garantita la supervisione umana». Spiega chi potrebbe subire un pregiudizio, in quale fase del processo, quale conseguenza è plausibile e quali evidenze permetterebbero di rilevarla. Se l’impatto dipende da circostanze ancora ignote — per esempio, le dimensioni di un gruppo interessato o la qualità di determinati dati — annota l’incertezza anziché trasformarla in un’affermazione.

Le informazioni fornite dal fornitore possono aiutare a comprendere le capacità, i limiti e i rischi noti del sistema, ma non sostituiscono l’analisi del deployer. Lo stesso sistema può produrre conseguenze diverse a seconda dei criteri di ammissione, del personale che interpreta i risultati, della possibilità di correggere i dati e dei canali a disposizione di una persona per contestare una decisione. La valutazione deve riflettere queste condizioni specifiche.

La consultazione delle persone interessate, dei loro rappresentanti o di esperti può fornire informazioni assenti dalla documentazione tecnica. Occorre distinguere l’obbligo legale dalle buone pratiche editoriali od organizzative: se la norma non prescrive un metodo specifico di consultazione, registra la consultazione come misura scelta per migliorare l’analisi, non come requisito testuale attribuito all’articolo.

Dai rischi alle decisioni: misure, evidenze e limiti

Un elenco di rischi non è sufficiente. Ogni rischio rilevante deve essere collegato a una misura verificabile, a un responsabile, a una scadenza e a un’evidenza che consenta di controllare se la misura funziona. Se una misura dipende da un’altra unità, da una funzionalità non ancora implementata o da una convalida in sospeso, non descriverla come già operativa. Trattala come una condizione da soddisfare prima del deployment.

Le misure possono includere la limitazione della finalità o delle persone ammesse, la riduzione della frequenza d’uso, il miglioramento della qualità dei dati, la definizione di soglie di revisione, test per individuare differenze rilevanti nei risultati, una revisione umana prima di una decisione sfavorevole, la possibilità di correggere i dati e presentare reclami, oppure l’interruzione del sistema in presenza di segnali di danno. Sono opzioni da motivare nel contesto specifico: non costituiscono un elenco esaustivo né garantiscono, da sole, la conformità.

La supervisione umana deve essere concreta e praticabile. Specifica chi effettua la revisione, quali informazioni riceve, quale formazione gli serve, quanto margine ha per discostarsi dal risultato e come registra la propria decisione. Il fatto che una persona confermi automaticamente gli output, senza tempo, informazioni o autorità per intervenire, non rende effettiva una misura solo perché è menzionata in una procedura.

L’autorizzazione può essere subordinata a condizioni. Per esempio, si può consentire un progetto pilota limitato solo dopo aver completato i test, convalidato il canale di reclamo e assegnato le risorse necessarie alla revisione. La decisione deve specificare i criteri di sospensione o modifica: errori superiori a una soglia definita in precedenza, reclami che segnalino uno schema ricorrente, modifiche non approvate del sistema o impossibilità di svolgere la supervisione promessa. Le soglie specifiche devono derivare dalla valutazione; non vanno inventate come valori universali.

Rapporto con la DPIA: coordinare senza confondere

Una DPIA, o valutazione d’impatto sulla protezione dei dati, si svolge secondo la normativa sulla protezione dei dati quando il trattamento previsto può comportare un rischio elevato per i diritti e le libertà delle persone. Il suo oggetto è il trattamento di dati personali e gli obblighi in materia di protezione dei dati; la valutazione prevista dall’articolo 27 si concentra sugli impatti sui diritti fondamentali derivanti dall’uso del sistema di IA nell’ambito previsto dall’AI Act. I due ambiti possono sovrapporsi, ma finalità e portata non coincidono.

L’articolo 27 disciplina il rapporto con le valutazioni in materia di protezione dei dati. Inoltre, le fonti ufficiali indicate segnalano che una modifica del 2026 incide sul riutilizzo degli elementi della DPIA e sul questionario che deve elaborare l’Ufficio per l’IA. Non si deve quindi applicare automaticamente una formulazione precedente sul fatto che la valutazione debba integrare, riutilizzare o richiamare una DPIA: occorre leggere il testo consolidato vigente e le istruzioni ufficiali per conoscere le condizioni attuali.

Come metodo di lavoro, mantieni una mappa delle corrispondenze. Indica quali analisi della DPIA forniscono informazioni utili sulle persone, sui dati o sui rischi pertinenti alla valutazione dei diritti fondamentali; quali elementi richiedono un’analisi supplementare; e quali questioni non sono coperte da una valutazione svolta per l’altro scopo. I riferimenti incrociati riducono le duplicazioni, ma devono permettere a chi effettua la revisione di trovare le evidenze e capire perché sono pertinenti al punto considerato.

Se nel caso specifico non è richiesta una DPIA, ciò non dimostra che non sia dovuta neppure la valutazione prevista dall’articolo 27. Allo stesso modo, l’esistenza di una DPIA non prova, di per sé, che siano stati considerati anche i rischi che non si limitano al trattamento dei dati. L’organizzazione deve documentare la conclusione applicabile al caso, la normativa vigente utilizzata e le lacune ancora da colmare.

Caso pratico: valutazione delle richieste di credito

Ipotizziamo che un’organizzazione utilizzi un sistema ad alto rischio per supportare la valutazione delle richieste di credito. L’esempio è ipotetico: non afferma che esista un sistema specifico, che una determinata organizzazione sia soggetta all’obbligo o che si siano verificati danni. Prima di applicarlo, l’organizzazione dovrebbe confermare la classificazione, il proprio ruolo, l’uso previsto e le condizioni giuridiche del caso.

Per prima cosa si rappresenta il processo: quali informazioni riceve il sistema, quale risultato produce, chi lo consulta e se tale risultato raccomanda, ordina o determina una decisione. Si descrivono anche la durata e la frequenza d’uso. Un’analisi che si limiti a dire «il modello valuta il credito» non chiarisce se il personale possa discostarsi dalla raccomandazione, se il risultato causi un rifiuto automatico o se sia prevista una seconda revisione.

Successivamente si individuano le persone interessate — per esempio, i richiedenti e le persone i cui dati incidono indirettamente sulla valutazione — e si formulano ipotesi di danno che l’organizzazione deve convalidare. Si potrebbero esaminare la possibilità che decisioni sfavorevoli derivino da dati incompleti, effetti sproporzionati su determinati gruppi, errori difficili da correggere o ostacoli alla comprensione e alla contestazione di una decisione. Non sono conclusioni su un modello reale: richiedono dati, test e analisi del contesto.

Le misure devono rispondere alle ipotesi formulate. L’organizzazione potrebbe verificare la provenienza e la qualità dei dati, testare i risultati e le differenze pertinenti, impedire che un punteggio costituisca l’unico fondamento di decisioni sfavorevoli quando l’analisi indica la necessità di una revisione, formare il personale, registrare le ragioni per cui ci si discosta da una raccomandazione e offrire un meccanismo accessibile per correggere le informazioni o presentare un reclamo. Per ciascun controllo occorre specificare chi lo esegue e quale risultato permetterebbe di considerarlo insufficiente.

Prima di approvare, l’organo responsabile dovrebbe verificare che le misure siano operative e che la supervisione disponga di un’autorità effettiva. Se mancano i risultati dei test, non è operativo alcun canale di reclamo o non è possibile spiegare quali informazioni sostengano una decisione, la scelta prudente può essere rinviare, limitare o non autorizzare il deployment finché la questione non sia risolta. Questa conclusione spetta all’organizzazione e deve basarsi sulle proprie evidenze; l’esempio non sostituisce la sua analisi.

Lista di controllo prima di approvare l’uso

Una lista di controllo è utile se conduce a una decisione e non diventa un semplice esercizio di spunta. Ogni risposta deve essere accompagnata da una fonte, un responsabile e, se necessario, un’azione ancora da svolgere. Tieni distinti i requisiti giuridici individuati nel testo vigente dalle pratiche interne che l’organizzazione aggiunge per rendere più solida l’analisi.

Prima di concludere, verifica che il documento identifichi con precisione il sistema, la sua versione, la finalità, i processi interessati, il periodo e la frequenza d’uso. Controlla che le persone e i gruppi interessati siano descritti in modo sufficientemente specifico, che ciascun rischio sia collegato a un possibile danno nel contesto e che siano stati considerati i limiti del sistema e le informazioni pertinenti fornite dal fornitore.

Conferma anche che la supervisione umana sia concretamente disponibile, che le misure abbiano responsabili e relative evidenze e che i rischi residui siano noti. Verifica i meccanismi per individuare i problemi, ricevere reclami e rispondere agli incidenti. Se sono state consultate persone interessate o esperti, registra cosa ha apportato la consultazione e quali decisioni ha influenzato. Se non sono state consultate, indica se questa assenza limita l’analisi.

Infine, verifica la comunicazione all’autorità competente, i riferimenti alla DPIA quando pertinenti, la data della revisione e le condizioni che impongono di riaprire la valutazione. L’approvazione dovrebbe indicare quale versione della documentazione è stata esaminata, quali condizioni accompagnano l’uso e chi ha il potere di interromperlo.

Cosa verificare prima di usare questa guida

La valutazione deve basarsi sulla versione consolidata dell’AI Act vigente nel momento pertinente, non soltanto su sintesi, bozze o versioni precedenti. Le fonti indicate riportano una modifica legislativa del 2026 e un testo consolidato datato luglio 2026; segnalano inoltre che la Commissione europea ha aggiornato le proprie FAQ nell’agosto 2026. Poiché le norme e le date possono cambiare, verifica che tali versioni siano pertinenti al momento e al caso d’uso oggetto dell’analisi.

Nel testo ufficiale, verifica l’ambito esatto dei deployer obbligati, le categorie di sistemi incluse, l’eccezione, gli elementi richiesti, la comunicazione all’autorità e gli effetti delle modifiche sulla DPIA. Controlla inoltre se siano già stati pubblicati moduli ufficiali definitivi e come debba essere effettuata la notifica nello Stato membro pertinente. Una FAQ può essere utile per orientarsi, ma non prevale sull’atto legislativo.

Il calendario di applicazione merita una verifica distinta: la data pertinente dipende dalle disposizioni vigenti e dalla specifica categoria del sistema. Non dedurre una data generale da una notizia o da una versione precedente del regolamento. Se sussistono dubbi sull’ambito, sull’autorità competente o sull’interazione con altre norme, richiedi una consulenza legale prima di autorizzare l’uso.

Per ampliare l’analisi, collega questa valutazione alle procedure interne dell’organizzazione per la sicurezza e la gestione dei rischi, al processo di confronto tra sistemi e alla valutazione delle alternative prima di selezionare una soluzione. Queste verifiche integrano la decisione, ma non sostituiscono la valutazione legale quando è obbligatoria.

Continua a esplorare

Correzioni e trasparenza

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