Art. 27 Reg. (UE) 2024/1689 — Valutazione d’impatto sui diritti fondamentali per i sistemi di IA ad alto rischio

Commento

Inquadramento sistematico: a chi si rivolge e perché

L'articolo 27 del Regolamento (UE) 2024/1689 (AI Act) introduce uno strumento di due diligence specifica a carico di determinate categorie di deployer che utilizzano sistemi di IA ad alto rischio. Si tratta della Fundamental Rights Impact Assessment (FRIA), una valutazione obbligatoria che il deployer deve condurre prima di attivare il sistema.

L'obbligo non si applica indiscriminatamente a tutti i deployer di sistemi ad alto rischio. I soggetti obbligati sono:

• Organismi di diritto pubblico: pubblica amministrazione, enti pubblici economici, autorità indipendenti, aziende sanitarie pubbliche;
• Enti privati che forniscono servizi pubblici: concessionari di servizi di interesse generale, gestori di infrastrutture critiche in regime di concessione;
• Deployer di sistemi ad alto rischio di cui all'allegato III, punto 5, lettere b) e c): rispettivamente sistemi per la valutazione del merito creditizio delle persone fisiche e sistemi per la valutazione del rischio e la determinazione del prezzo in assicurazioni sulla vita e sanitarie.

L'art. 27 non si applica ai sistemi di IA ad alto rischio dell'allegato III, punto 2 (sistemi destinati alla gestione delle infrastrutture critiche), che seguono un regime specifico. Le date di applicazione degli obblighi di alto rischio seguono il calendario dell'art. 113: la gran parte degli obblighi per i sistemi ad alto rischio diventa applicabile dal 2 agosto 2026.

Il contenuto della valutazione: i sei elementi obbligatori

Il paragrafo 1 dell'art. 27 elenca in modo tassativo i sei elementi che la valutazione deve includere:

a) Descrizione dei processi aziendali del deployer: bisogna descrivere in quale processo organizzativo il sistema sarà inserito e come si integra con la finalità prevista dichiarata dal fornitore. Non è sufficiente un'analisi astratta del sistema: la valutazione deve essere contestualizzata all'uso specifico del deployer.

b) Periodo di tempo e frequenza d'uso: con quale cadenza il sistema verrà utilizzato, per quanto tempo e in quale arco temporale complessivo. Questo elemento è rilevante per calibrare l'entità dell'impatto potenziale: un sistema usato continuativamente su vasta scala ha un profilo di rischio diverso rispetto a un utilizzo occasionale.

c) Categorie di persone interessate: quali gruppi di persone fisiche sono verosimilmente esposti alle decisioni o ai risultati del sistema. L'analisi deve essere granulare e considerare la possibilità che alcune categorie — persone vulnerabili, minori, soggetti in condizioni di dipendenza — siano esposte a rischi amplificati.

d) Rischi specifici di danno: i rischi devono essere identificati tenendo conto delle informazioni fornite dal fornitore ai sensi dell'art. 13 (trasparenza e informazioni per i deployer). Questa disposizione crea un nesso diretto tra gli obblighi informativi del fornitore e la capacità del deployer di effettuare una valutazione accurata: se il fornitore non fornisce informazioni complete, il deployer non è in grado di valutare correttamente i rischi.

e) Misure di sorveglianza umana: il deployer deve descrivere come intende attuare le misure di sorveglianza umana indicate nelle istruzioni per l'uso del fornitore. Non è sufficiente affermare che «la sorveglianza umana è garantita»: occorre specificare chi, come e quando interviene nella catena decisionale.

f) Misure di risposta e governance: in caso di concretizzazione dei rischi identificati, quali procedure interne sono previste? Quali meccanismi di reclamo sono disponibili per le persone interessate? Questa disposizione collega la FRIA ai sistemi di governance interna del deployer.

Notifica all'autorità di vigilanza: un obbligo spesso sottovalutato

Il paragrafo 3 dell'art. 27 introduce un obbligo che va ben oltre la redazione di un documento interno: il deployer deve notificare i risultati della valutazione all'autorità di vigilanza del mercato, presentando il modello compilato predisposto dall'Ufficio per l'IA ai sensi del paragrafo 5.

Questo obbligo rende la FRIA uno strumento di accountability pubblica e non un mero esercizio interno di compliance. L'autorità può utilizzare le notifiche per individuare pattern di rischio sistemici, per attivare verifiche specifiche e per orientare le proprie attività di controllo.

Un'esenzione dall'obbligo di notifica è prevista per i deployer che rientrano nel caso di cui all'art. 46, par. 1, relativo alle misure di salvaguardia a livello di Unione. Questa eccezione ha portata limitata e non costituisce una via d'uscita generalizzata dall'obbligo.

Raccordo con la DPIA del GDPR: integrazione, non duplicazione

Uno degli aspetti più importanti sul piano operativo è il raccordo con la valutazione d'impatto sulla protezione dei dati (DPIA) già prevista dall'art. 35 del Regolamento (UE) 2016/679 (GDPR) e dall'art. 27 della Direttiva (UE) 2016/680 (autorità di contrasto).

Il paragrafo 4 dell'art. 27 AI Act stabilisce che, se gli obblighi della FRIA sono già soddisfatti dalla DPIA, la valutazione d'impatto sui diritti fondamentali integra la DPIA. Questo significa che le due valutazioni non sono duplicate ma complementari:

• La DPIA si concentra sui rischi per la protezione dei dati personali;
• La FRIA allarga il perimetro ai diritti fondamentali in senso più ampio: dignità, non discriminazione, accesso alla giustizia, diritti dei lavoratori.

In pratica, i deployer che hanno già effettuato una DPIA per il sistema in questione dovranno verificare se quella valutazione copre già tutti e sei gli elementi richiesti dall'art. 27, par. 1, e, in caso contrario, integrarla con i profili mancanti. Le procedure documentali che già esistono nell'organizzazione possono essere riutilizzate e ampliate, senza necessità di creare un documento del tutto nuovo.

Ciclo di vita della valutazione: primo uso e aggiornamenti

Il paragrafo 2 chiarisce che la FRIA si effettua al primo uso del sistema. Se il deployer ha già effettuato valutazioni precedenti per sistemi analoghi, può fare riferimento a esse, evitando di ricominciare da zero per ogni singola implementazione. Analogamente, può utilizzare valutazioni d'impatto già condotte dal fornitore laddove siano pertinenti al contesto di utilizzo specifico.

Tuttavia, l'obbligo di aggiornamento scatta quando «uno qualsiasi degli elementi elencati al paragrafo 1 sia cambiato o non sia più aggiornato». Situazioni tipiche che impongono un aggiornamento: ampliamento della platea di persone interessate, modifica delle finalità d'uso, aggiornamento significativo del sistema da parte del fornitore, emersione di nuovi rischi non previsti nella valutazione iniziale.

Questa dinamica richiede che il deployer inserisca la FRIA in un processo di gestione ciclica — non un documento da redigere una volta sola — e che la colleghi alle procedure di change management interno.

Implicazioni pratiche per le organizzazioni

Per i deployer interessati, l'art. 27 richiede l'implementazione di un processo strutturato che coinvolge funzioni diverse: il responsabile della protezione dei dati (DPO), l'ufficio legale, le funzioni di compliance, il responsabile del sistema informatico e i referenti operativi dell'unità che utilizzerà il sistema. Il processo deve essere avviato prima della messa in servizio del sistema — non dopo — e deve produrre una documentazione formale da conservare e da trasmettere all'autorità competente.

L'Ufficio per l'IA (istituito a norma dell'art. 64 AI Act) metterà a disposizione un modello di questionario, anche in formato automatizzato, per agevolare l'adempimento. Le organizzazioni farebbero bene ad attendere e adottare tale modello standard, che consentirà anche di uniformare le notifiche alle autorità di vigilanza. Le sanzioni per mancato rispetto degli obblighi del deployer rientrano nel regime dell'art. 99 AI Act.