La FRIA, Fundamental Rights Impact Assessment, è la valutazione d’impatto sui diritti fondamentali che l’AI Act impone a specifici deployer di sistemi di IA ad alto rischio prima del loro primo utilizzo. È disciplinata dall’art. 27 Reg. UE 2024/1689 e diventerà applicabile a partire dal 2 agosto 2026: per pubbliche amministrazioni, enti privati che erogano servizi pubblici, banche e assicurazioni che impiegano IA per credit scoring o pricing assicurativo, la finestra operativa per arrivare pronti è ormai stretta. Questa guida spiega chi è obbligato, cosa va valutato, come strutturare l’attività, in che rapporto sta con la DPIA del GDPR e quali errori evitare.

1. Cos’è la FRIA e perché l’AI Act la introduce

La FRIA è uno strumento preventivo che obbliga determinati utilizzatori di sistemi di IA ad alto rischio a valutare, prima del primo impiego, l’impatto che quel sistema può produrre sui diritti fondamentali delle persone. Non è una formalità documentale: è un’analisi strutturata che deve identificare rischi specifici, categorie di soggetti coinvolti, misure di mitigazione, meccanismi di reclamo e governance interna.

La sua introduzione nel testo dell’AI Act non era prevista nella proposta originaria della Commissione del 2021. È stata aggiunta nel corso del trilogo tra Commissione, Consiglio e Parlamento, su impulso del Parlamento europeo, che l’ha inserita per la prima volta nell’allora art. 29a del testo. La FRIA è poi confluita nell’attuale art. 27 del Regolamento.

Sul piano sistematico la FRIA si inserisce nell’approccio antropocentrico e trustworthy che caratterizza la strategia digitale dell’Unione. Lo stesso AI Act richiama espressamente gli orientamenti etici per un’IA affidabile elaborati nel 2019 dall’AI High Level Expert Group: intervento e sorveglianza umani, robustezza tecnica e sicurezza, vita privata e governance dei dati, trasparenza, diversità, non discriminazione ed equità, benessere sociale e ambientale, responsabilità (Considerando 27).

1.1 FRIA e art. 9 AI Act: due livelli diversi di gestione del rischio

La FRIA non è una specificazione del sistema generale di gestione dei rischi già imposto dall’AI Act. L’art. 9 del Regolamento richiede a tutti i sistemi di IA ad alto rischio un’attività iterativa continua di identificazione e valutazione dei rischi, lungo l’intero ciclo di vita del sistema, a carico del fornitore.

L’art. 27, invece, opera su un piano distinto. Si applica solo ad alcuni sistemi ad alto rischio, solo ad alcuni deployer, e solo prima del primo utilizzo. È un adempimento preventivo, mirato e settoriale, non un sistema di gestione continua.

2. Chi deve fare la FRIA: i deployer obbligati

L’art. 27 AI Act circoscrive in modo netto i destinatari dell’obbligo. La FRIA è dovuta solo da deployer che rientrano in una di tre categorie:

• organismi di diritto pubblico, ossia enti istituiti per soddisfare esigenze di interesse generale a carattere non industriale o commerciale, dotati di personalità giuridica e finanziati prevalentemente o controllati dallo Stato o da autorità pubbliche;
• enti privati che forniscono servizi pubblici, quali quelli operanti nei settori dell’istruzione, dell’assistenza sanitaria, dei servizi sociali, degli alloggi e dell’amministrazione della giustizia (Considerando 96);
• deployer di sistemi di IA ad alto rischio impiegati per credit scoring o per la valutazione dei rischi e la determinazione dei prezzi in relazione a persone fisiche nel caso di assicurazioni sulla vita e assicurazioni sanitarie (All. III, n. 5, lett. b e c).

Sono esclusi dall’obbligo, salvi i casi appena indicati, i deployer privati che impieghino sistemi ad alto rischio in contesti puramente commerciali. Sono esclusi inoltre i fornitori, gli importatori e i distributori: la FRIA grava esclusivamente sul deployer.

2.1 Perché proprio il deployer

La scelta non è casuale. Il deployer è il soggetto che meglio conosce il contesto concreto di utilizzo del sistema: le persone o i gruppi che ne saranno effettivamente impattati, le procedure interne in cui il sistema si inserisce, le scelte di governance e di sorveglianza umana. Solo il deployer può identificare rischi significativi non prevedibili nella fase di sviluppo, perché legati al modo in cui il sistema verrà calato in un processo operativo specifico.

L’obbligo del deployer completa, non sostituisce, quello del fornitore: chi sviluppa il sistema deve garantire conformità by design, chi lo utilizza deve garantire conformità in uso.

3. Quando si fa la FRIA: tempistiche e aggiornamento

La FRIA ha carattere esclusivamente preventivo. Va eseguita “prima del primo uso del sistema di IA ad alto rischio” (art. 27, par. 2). Non si tratta di un’attività continua: l’obbligo si esaurisce con la valutazione ex ante.

Per usi successivi analoghi al primo, il deployer può basarsi su FRIA precedentemente effettuate, proprie o anche del fornitore. Se durante l’utilizzo del sistema emerge che uno degli elementi della valutazione è cambiato o non è più aggiornato, il deployer deve adottare le misure necessarie per aggiornare le informazioni, senza dover ripetere l’intera valutazione.

L’art. 27 prevede inoltre che il deployer notifichi all’autorità di vigilanza del mercato i risultati della valutazione, salvo i casi di esenzione di cui all’art. 46, par. 1.

3.1 Settori coinvolti dell’Allegato III

I sistemi ad alto rischio che rientrano nel campo della FRIA sono quelli dell’art. 6, par. 2, ossia dell’Allegato III (con esclusione di quelli destinati a operare come componenti di sicurezza nella gestione delle infrastrutture critiche). In sintesi:

• biometria (All. III, 1);
• istruzione e formazione professionale (All. III, 3);
• occupazione, gestione dei lavoratori e accesso al lavoro autonomo (All. III, 4);
• accesso a servizi privati essenziali e a prestazioni e servizi pubblici essenziali (All. III, 5), tra cui assistenza sanitaria, credit scoring (lett. b), valutazione dei rischi e pricing assicurativo vita e salute (lett. c);
• attività di contrasto (All. III, 6);
• migrazione, asilo e gestione del controllo delle frontiere (All. III, 7);
• amministrazione della giustizia e processi democratici (All. III, 8).

Per i sistemi ad alto rischio dell’Allegato III, n. 2 (infrastrutture critiche) la FRIA non è dovuta, ferma restando l’applicabilità dell’art. 9 sul risk management.

4. Cosa contiene una FRIA: la struttura operativa

L’art. 27 non disegna un modello rigido. Indica gli elementi minimi che una FRIA efficace deve contenere, lasciando al deployer ampio margine di adattamento al caso concreto. Sulla base del dato normativo emerge una struttura in cinque blocchi.

4.1 Analisi del sistema di IA

La prima fase è ricostruire in modo realistico e dettagliato il sistema di IA che si intende impiegare. Vanno descritti:

• finalità del sistema e processi del deployer in cui sarà utilizzato (art. 27, lett. a);
• ambiti di utilizzo concreti, in linea con la finalità prevista dal fornitore;
• periodo di tempo entro il quale il sistema sarà utilizzato e frequenza d’uso (art. 27, lett. b).

Il punto di partenza sono le informazioni fornite dal fornitore ex art. 13 AI Act (trasparenza e fornitura di informazioni ai deployer), che devono essere chiare, complete e accessibili al deployer.

4.2 Perimetro soggettivo di applicazione

Identificate finalità e modalità d’uso, il secondo passaggio è individuare chi sarà impattato dall’impiego del sistema:

• categorie di persone fisiche o gruppi verosimilmente interessati (art. 27, lett. c);
• diritti fondamentali che, per quelle categorie, possono essere coinvolti dall’utilizzo del sistema.

Si passa da un’analisi oggettiva (cosa fa il sistema) a un’analisi soggettiva (chi tocca e come). È in questa fase che la conoscenza del contesto operativo del deployer diventa decisiva.

4.3 Mappatura dei rischi

Il cuore della FRIA è la mappatura strutturata dei rischi. Vanno individuati e categorizzati:

• macro-tipologia di rischio (legale, etico, economico, reputazionale);
• rischi specifici di danno per le categorie di persone fisiche o per i gruppi individuati (art. 27, lett. d);
• probabilità di verificazione del rischio;
• impatto stimato sui diritti fondamentali in caso di concretizzazione.

In questa fase il deployer deve tenere conto delle informazioni trasmesse dal fornitore ex art. 13. È inoltre necessaria una descrizione dell’attuazione delle misure di sorveglianza umana secondo le istruzioni per l’uso (art. 27, lett. e). Il Considerando 96 raccomanda, in particolare per i sistemi impiegati nel settore pubblico, di coinvolgere portatori di interessi rilevanti: rappresentanti dei gruppi potenzialmente interessati, esperti indipendenti, organizzazioni della società civile.

4.4 Misure di mitigazione

Identificati i rischi, la FRIA deve definire le misure da adottare qualora tali rischi si concretizzino, comprese le disposizioni di governance interna e i meccanismi di reclamo (art. 27, lett. f). Tipicamente:

• misure tecniche, calibrate sulla tipologia di rischio (revisione degli algoritmi, strumenti per mitigare allucinazioni, interventi sui dataset, controlli di output);
• misure procedurali, con piani di azione specifici per i casi di violazione dei diritti fondamentali, ritagliati sul contesto operativo;
• procedure di governance interna sia per la fase di risk assessment sia per l’eventuale impact management;
• strumenti e meccanismi di reclamo accessibili ai soggetti impattati.

4.5 Monitoraggio, revisione, documentazione

Pur essendo un adempimento ex ante, la FRIA può diventare obsoleta. L’art. 27, par. 2, prevede l’aggiornamento delle informazioni quando elementi della valutazione cambiano o non sono più attuali. Sono quindi necessari:

• un’attività di monitoraggio periodico, anche in relazione all’evoluzione tecnologica del sistema e del contesto;
• una documentazione tracciabile dei processi di valutazione e delle decisioni prese, da conservare come record per le successive evoluzioni;
• trasparenza verso le autorità di regolazione e, ove opportuno, verso i soggetti interessati.

4.6 Il modello AI Office in arrivo

L’art. 27, par. 5, AI Act prevede che l’AI Office metta a disposizione un modello di questionario, anche tramite un applicativo online, per agevolare i deployer nell’adempimento dell’obbligo in modo semplificato. Si tratta di uno strumento analogo, per ratio, a quelli rilasciati dalle autorità di protezione dei dati per la DPIA. Lo Studio raccomanda ai deployer di monitorare con attenzione il rilascio del template e di adattare la propria documentazione interna al formato che sarà ufficialmente adottato.

5. FRIA e DPIA: cosa cambia, cosa coesiste

L’art. 27, par. 4, AI Act prevede espressamente la possibilità di integrazione tra FRIA e DPIA, la valutazione d’impatto sulla protezione dei dati ex art. 35 GDPR (o ex art. 27 Direttiva (UE) 2016/680 in ambito penale). Quando entrambe sono dovute, le due valutazioni coesistono e si integrano reciprocamente.

L’art. 26, par. 9, AI Act stabilisce inoltre che i deployer di sistemi di IA ad alto rischio utilizzano le informazioni fornite dal fornitore ex art. 13 anche per assolvere all’obbligo di DPIA ex GDPR. Il punto di intersezione più frequente sarà la fase di raccolta e trattamento dei dati, terreno presidiato dal GDPR (l’AI Act non regola la fase di raccolta) e centrale per sistemi che richiedono grandi dataset.

Le due valutazioni restano però strumenti distinti, con finalità e disciplina diverse.

5.1 I tratti comuni

• Entrambe sono preventive: vanno fatte prima del primo uso del sistema (FRIA) o prima del trattamento (DPIA).
• Entrambe seguono un risk-based approach.
• Entrambe ammettono aggiornamento o riesame successivo senza necessità di una nuova valutazione integrale.

5.2 Le differenze

• Onere: la FRIA grava sul deployer, la DPIA sul titolare del trattamento (che può coincidere o meno con il deployer).
• Ambito: la FRIA copre una vasta gamma di diritti fondamentali, non solo i dati personali (non discriminazione, libertà di espressione, accesso alla giustizia, equità, e così via); la DPIA è primariamente focalizzata sui rischi del trattamento di dati personali.
• Casi: la FRIA è dovuta solo da determinati deployer e per determinati sistemi ad alto rischio; la DPIA è dovuta in tutti i casi in cui il trattamento può presentare un rischio elevato per i diritti e le libertà delle persone fisiche (art. 35, par. 3, GDPR).
• Notifica: la FRIA deve essere notificata all’autorità di vigilanza del mercato (salvo esenzioni ex art. 46, par. 1); la DPIA non è soggetta a notifica preventiva ma deve essere esibita all’autorità in caso di richiesta.
• Output: la FRIA può portare a modifiche strutturali, procedurali, di compliance e tecniche; la DPIA si concentra di norma su misure tecniche e organizzative per la protezione dei dati.

Per i deployer che impiegano sistemi di riconoscimento biometrico, sistemi di credit scoring o sistemi di pricing assicurativo, la coesistenza tra FRIA e DPIA è la regola, non l’eccezione. La buona prassi è impostare un processo integrato che soddisfi entrambi i regimi senza duplicazioni inutili.

6. Casi pratici applicativi

Tre scenari concreti illustrano l’ambito tipico della FRIA.

6.1 Pubblica amministrazione che adotta un sistema IA per la gestione di prestazioni sociali

Un ente pubblico introduce un sistema di IA per supportare l’istruttoria di pratiche relative a benefici sociali. Il sistema rientra nell’All. III, n. 5 (servizi pubblici essenziali). Il deployer pubblico è obbligato alla FRIA prima del primo utilizzo.

L’analisi deve coprire: scopo e modalità d’uso del sistema, categorie di cittadini interessati (in particolare gruppi vulnerabili), rischi di discriminazione algoritmica, bias nei dataset, impatto sull’accesso a un diritto sociale, misure di sorveglianza umana, meccanismi di reclamo accessibili al cittadino, eventuale coinvolgimento di organizzazioni della società civile.

6.2 Banca o piattaforma fintech che impiega IA per credit scoring

Un istituto di credito o una fintech utilizza un sistema di IA ad alto rischio per la valutazione del merito creditizio di persone fisiche (All. III, n. 5, lett. b). Anche se è un soggetto privato, è obbligato alla FRIA in forza dell’art. 27, par. 1.

L’analisi deve coprire: dataset usati, eventuali profili di disparate impact, rischi per persone economicamente vulnerabili, sorveglianza umana nelle decisioni sfavorevoli, procedure di revisione su richiesta del cliente, interazione con la DPIA ex GDPR e con la disciplina del credito al consumo. Le decisioni automatizzate ricadenti nell’art. 22 GDPR richiedono ulteriori cautele coordinate.

6.3 Compagnia assicurativa che adotta IA per pricing vita o salute

Una compagnia assicurativa impiega un sistema di IA per la determinazione del prezzo di polizze vita o sanitarie (All. III, n. 5, lett. c). L’obbligo di FRIA scatta indipendentemente dalla natura privata del soggetto.

L’analisi deve coprire: variabili di input del modello di pricing, rischio di discriminazione su categorie protette, gestione di dati relativi alla salute (con DPIA integrata), trasparenza verso l’assicurato, meccanismi di contestazione del prezzo, governance interna del modello e del suo aggiornamento.

7. Errori ricorrenti e opportunità

La FRIA è un adempimento nuovo e si presta a errori sistemici nelle prime applicazioni. Tra i più frequenti:

• trattarla come adempimento formale, replicando modelli generici senza una vera analisi del contesto operativo;
• sovrapporla in modo confuso alla DPIA, perdendo i vantaggi di un processo integrato;
• sottovalutare il ruolo del fornitore, omettendo di acquisire e analizzare le informazioni ex art. 13 AI Act;
• escludere stakeholder rilevanti, in particolare per sistemi destinati al settore pubblico, dove il coinvolgimento di rappresentanti dei gruppi impattati e di esperti indipendenti è raccomandato dal Considerando 96;
• non documentare il processo, perdendo la tracciabilità necessaria sia per la notifica all’autorità sia per gli aggiornamenti futuri;
• non aggiornare la FRIA quando il contesto operativo o il sistema cambiano.

Sul versante delle opportunità, una FRIA seria è anche uno strumento di posizionamento reputazionale. Per pubbliche amministrazioni, banche, assicurazioni e fornitori di servizi pubblici, dimostrare di aver impostato sistemi di IA rispettosi dei diritti fondamentali by design e by default è un asset di fiducia verso utenti, clienti, autorità.

Restano aperte due criticità rilevate dalla dottrina e dagli operatori. La prima è l’assenza di linee guida uniformi: la FRIA lascia oggi ampio margine di discrezionalità al deployer, in attesa del modello AI Office. La seconda è il rischio di over-regulation: una FRIA appesantita da formalismi eccessivi può frenare l’innovazione invece di tutelare i diritti. Un equilibrio richiederà tempo e prassi consolidata.

Conclusione in sintesi