DPIA e FRIA: differenze, obblighi e integrazione
DPIA e FRIA non coincidono. Ecco quando sono richieste, chi deve svolgerle e come coordinarle dopo il Regolamento UE 2026/1744.
Ordine degli Avvocati di Sciacca n. 747 · Avvocato & Sviluppatore · IT Law
DPIA e FRIA sono la stessa valutazione?
No. La DPIA dell'art. 35 GDPR valuta i rischi elevati del trattamento di dati personali; la FRIA dell'art. 27 AI Act valuta l'impatto sui diritti fondamentali di determinati impieghi di sistemi AI ad alto rischio. Possono condividere contenuti e rinvii, ma una non sostituisce automaticamente l'altra. La necessità di ciascuna va verificata separatamente.
Risposta aggiornata al 1° agosto 2026. Il Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026, ha modificato l'AI Act e rinviato l'applicazione delle sezioni dedicate ai sistemi ad alto rischio. Per i sistemi dell'art. 6, par. 2 e dell'Allegato III la nuova data è il 2 dicembre 2027; per quelli dell'art. 6, par. 1 e dell'Allegato I è il 2 agosto 2028. La DPIA GDPR, quando ne ricorrono i presupposti, è invece già obbligatoria.
La domanda corretta non è quindi «devo fare una DPIA oppure una FRIA?», ma: quali trattamenti di dati personali svolge il sistema, come è classificato ai sensi dell'AI Act, chi lo utilizza e in quale contesto? Solo dopo questa verifica è possibile stabilire se occorra una delle due valutazioni o entrambe.
Per una verifica operativa del primo requisito si può usare la guida generale alla DPIA. Per il documento applicativo è disponibile anche la checklist DPIA per sistemi AI.
DPIA e FRIA: confronto essenziale
| Profilo | DPIA | FRIA |
|---|---|---|
| Fonte | Art. 35 GDPR | Art. 27 AI Act |
| Oggetto | Trattamento di dati personali | Uso concreto di alcuni sistemi AI ad alto rischio |
| Presupposto | Probabile rischio elevato per diritti e libertà delle persone | Condizioni soggettive e oggettive indicate dall'art. 27 |
| Soggetto responsabile | Titolare del trattamento | Deployer rientrante nell'ambito dell'art. 27 |
| Focus | Necessità, proporzionalità e rischi del trattamento; misure di gestione | Processi d'uso, persone interessate, rischi per i diritti fondamentali, supervisione e rimedi |
| Momento | Prima del trattamento ad alto rischio | Prima dell'impiego del sistema nel contesto considerato |
| Coordinamento | Può contenere elementi utili alla FRIA | Può richiamare o incorporare parti pertinenti della DPIA |
| Data applicabile | Già applicabile | In via generale, 2 dicembre 2027 per i sistemi dell'Allegato III interessati |
Le due valutazioni possono sovrapporsi su descrizione del sistema, categorie di persone coinvolte, rischi, supervisione umana e misure organizzative. Restano però diversi la base giuridica, il test di attivazione e il perimetro dei diritti considerati.
Quando è necessaria la DPIA per un sistema AI
L'art. 35 GDPR richiede una valutazione d'impatto quando un trattamento, considerate natura, oggetto, contesto e finalità e in particolare l'uso di nuove tecnologie, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche.
L'impiego dell'intelligenza artificiale non rende la DPIA automaticamente obbligatoria. Sono però indici rilevanti, da valutare nel loro insieme:
- valutazione sistematica o profilazione con effetti giuridici o analogamente significativi;
- trattamento su larga scala di categorie particolari di dati o dati relativi a condanne e reati;
- sorveglianza sistematica di aree accessibili al pubblico su larga scala;
- combinazione di dati, uso innovativo, persone vulnerabili o difficoltà nell'esercizio dei diritti;
- decisioni automatizzate che incidono su lavoro, credito, salute, istruzione o accesso a servizi.
La classificazione come «alto rischio» ai sensi dell'AI Act e il rischio elevato ai sensi del GDPR non sono concetti equivalenti. Un sistema può richiedere una DPIA senza essere ad alto rischio secondo l'AI Act; viceversa, un sistema classificato ad alto rischio deve essere esaminato anche sul piano privacy, ma la DPIA dipende dai trattamenti effettivamente svolti e dal relativo rischio.
La DPIA dovrebbe descrivere le operazioni e le finalità del trattamento, valutarne necessità e proporzionalità, analizzare i rischi e indicare le misure previste. Se il rischio residuo resta elevato in assenza di misure idonee, può rendersi necessaria la consultazione preventiva dell'autorità di controllo ai sensi dell'art. 36 GDPR.
Quando è richiesta la FRIA dell'articolo 27 AI Act
La FRIA non è imposta a ogni deployer e neppure per ogni sistema ad alto rischio. L'art. 27 riguarda, prima dell'impiego, sistemi classificati ad alto rischio ai sensi dell'art. 6, par. 2 e dell'Allegato III, con esclusione dell'area delle infrastrutture critiche indicata al punto 2 dell'Allegato III, quando ricorre almeno uno dei seguenti casi:
- il deployer è un organismo di diritto pubblico;
- il deployer è un soggetto privato che presta servizi pubblici;
- il sistema rientra nei punti 5, lettere b) o c), dell'Allegato III, relativi, rispettivamente, alla valutazione dell'affidabilità creditizia o del merito creditizio delle persone fisiche e alla valutazione del rischio o determinazione dei prezzi nelle assicurazioni vita e malattia.
Ne consegue che una società privata che usa un sistema AI per la selezione del personale non è, per questo solo fatto, automaticamente soggetta alla FRIA dell'art. 27. Il sistema può essere ad alto rischio ai sensi dell'Allegato III e può richiedere una DPIA; la FRIA dipende anche dalla qualità del deployer e dagli altri presupposti normativi. Diverso è il caso di un ente pubblico o di un privato che presta un servizio pubblico.
La classificazione richiede comunque un'analisi concreta. Occorre verificare la finalità prevista dal provider, l'uso effettivo del deployer, le esclusioni dell'art. 6 e la specifica voce dell'Allegato III. Etichette commerciali come «assistente», «copilota» o «strumento di supporto» non risolvono la qualificazione.
Cosa deve contenere la FRIA
L'art. 27 richiede almeno una descrizione:
- dei processi del deployer nei quali il sistema sarà usato secondo la finalità prevista;
- del periodo e della frequenza d'uso;
- delle categorie di persone e gruppi che possono essere interessati;
- dei rischi specifici di danno ai diritti fondamentali, considerando le informazioni del provider;
- delle misure di supervisione umana;
- delle misure da adottare se i rischi si concretizzano, inclusi governance interna e meccanismi di reclamo.
Il deployer deve notificare il risultato all'autorità di vigilanza del mercato secondo le modalità previste dall'AI Act, salvo le eccezioni contemplate dalla norma. La valutazione va aggiornata quando cambiano gli elementi rilevanti; per impieghi analoghi può essere utilizzata una valutazione precedente, purché sia ancora pertinente al contesto concreto.
Come coordinare DPIA e FRIA senza perdere informazioni
Il nuovo art. 27, par. 4, come modificato dal Regolamento (UE) 2026/1744, chiarisce la tecnica di coordinamento. Se taluni obblighi della FRIA sono già soddisfatti nella DPIA, il deployer può inserire nella FRIA rinvii alle sezioni pertinenti della DPIA oppure incorporarvi le parti rilevanti.
Non si tratta di una fusione automatica e non basta rinominare la DPIA. Un fascicolo coordinato dovrebbe mantenere una matrice di tracciabilità come questa:
| Informazione | Fonte primaria | Richiamo nell'altro documento | Responsabile | Evidenza | Data di revisione |
|---|---|---|---|---|---|
| Finalità e contesto d'uso | DPIA/FRIA | Sezione e versione esatta | Process owner | Scheda del sistema | Data |
| Categorie interessate | DPIA | Paragrafo FRIA collegato | Privacy lead | Data map | Data |
| Rischi per diritti fondamentali | FRIA | Rischi privacy correlati | Legal/AI governance | Registro rischi | Data |
| Supervisione umana | FRIA | Misura di sicurezza DPIA | Business owner | Procedura e log | Data |
| Informazioni del provider | Fascicolo fornitore | DPIA e FRIA | Procurement/IT | Istruzioni d'uso | Data |
Questa struttura limita tre errori frequenti: copiare informazioni non più aggiornate, perdere allegati tra versioni e dichiarare misure che non trovano riscontro nel sistema reale.
Processo operativo in otto passaggi
1. Identificare sistema, versione e finalità
Registrare modello, componenti, versione, provider, finalità prevista e uso effettivo. Una modifica del modello, dei dati o del processo non comporta sempre una nuova qualificazione, ma deve essere tracciata e valutata.
2. Mappare i dati personali
Descrivere input, output, log, prompt, basi informative RAG, destinatari, trasferimenti, tempi di conservazione e ruoli privacy. Separare dati usati per addestramento, configurazione, inferenza e monitoraggio.
3. Valutare il trigger della DPIA
Applicare l'art. 35 GDPR e i criteri dell'autorità competente. Motivare per iscritto sia la decisione di svolgere la DPIA sia l'eventuale conclusione che non sia necessaria.
4. Classificare il sistema ai sensi dell'AI Act
Verificare articoli 5 e 6, Allegati I e III, finalità prevista ed eventuali esclusioni. Documentare la fonte normativa e i fatti tecnici sui quali si fonda la conclusione.
5. Verificare il perimetro soggettivo della FRIA
Accertare se il deployer è un organismo pubblico, un privato prestatore di servizi pubblici oppure usa uno dei sistemi dei punti 5(b) o 5(c) dell'Allegato III. Non dedurre l'obbligo dalla sola etichetta «alto rischio».
6. Costruire un registro unico delle evidenze
Associare a ogni affermazione un documento verificabile: istruzioni d'uso, data flow, test, log, procedura di supervisione, registro dei reclami, valutazione del fornitore. Indicare proprietario, versione e scadenza.
7. Redigere documenti distinti ma collegati
Mantenere per ciascuna valutazione indice, conclusione e approvazione propri. Usare rinvii stabili a paragrafi e versioni, evitando formule generiche come «si veda la DPIA».
8. Definire trigger di riesame
Prevedere riesame per modifiche della finalità, categorie di persone, dati, modello, soglie decisionali, fornitore, supervisione o contesto normativo. Il semplice trascorrere del tempo non è l'unico indicatore: conta la variazione dei fattori di rischio.
Tre esempi sintetici
Selezione del personale in un'impresa privata
Un sistema destinato a filtrare candidature può rientrare nell'Allegato III. La DPIA è spesso da considerare con particolare attenzione per profilazione, nuove tecnologie ed effetti sulle persone. La FRIA dell'art. 27 non deriva però automaticamente dal solo carattere privato dell'impresa e dalla classificazione ad alto rischio; occorre verificare il perimetro soggettivo.
Credit scoring di persone fisiche
Un sistema destinato a valutare l'affidabilità o il merito creditizio può rientrare nel punto 5(b) dell'Allegato III. Per il deployer, la FRIA può quindi essere richiesta indipendentemente dalla natura pubblica o privata. Se vengono trattati dati personali con rischio elevato, può essere necessaria anche la DPIA.
Sistema AI usato da un ente pubblico
Per un sistema dell'art. 6, par. 2, rientrante nell'Allegato III e non nell'esclusione del punto 2, la qualità pubblica del deployer può attivare la FRIA. La presenza di dati personali richiede una verifica distinta ai sensi del GDPR.
Domande frequenti
La DPIA sostituisce la FRIA?
No. Il nuovo art. 27, par. 4 consente di richiamare o incorporare nella FRIA le parti pertinenti della DPIA. Occorre comunque verificare e coprire tutti gli elementi richiesti dalla FRIA, quando questa è obbligatoria.
Ogni sistema AI ad alto rischio richiede una FRIA?
No. L'art. 27 combina requisiti relativi al tipo di sistema e al soggetto che lo impiega. La FRIA non è un obbligo generale di ogni provider o deployer di sistemi ad alto rischio.
La FRIA è già applicabile il 2 agosto 2026?
Per i sistemi dell'art. 6, par. 2 e dell'Allegato III, il Regolamento (UE) 2026/1744 ha spostato l'applicazione delle pertinenti sezioni del Capo III, incluso l'art. 27, al 2 dicembre 2027. È prudente preparare per tempo governance ed evidenze, senza confondere la preparazione con un obbligo già applicabile. La DPIA GDPR resta invece soggetta alle date e ai presupposti del GDPR.
Un unico documento è sempre la scelta migliore?
Non necessariamente. Un fascicolo coordinato può ridurre duplicazioni, ma deve conservare la tracciabilità dei distinti requisiti. In organizzazioni complesse può essere più chiaro mantenere due valutazioni collegate da una matrice comune.
Fonti normative primarie
- Regolamento (UE) 2024/1689 — AI Act, in particolare artt. 6, 26, 27 e Allegato III.
- Regolamento (UE) 2026/1744 — Digital Omnibus sull'AI, in particolare modifiche agli artt. 27 e 113.
- Regolamento (UE) 2016/679 — GDPR, in particolare artt. 35 e 36.
Valutare un caso concreto
La qualificazione dipende dal sistema, dal ruolo dell'organizzazione e dal contesto d'uso. È possibile richiedere una valutazione preliminare della documentazione disponibile.
Richiedi un confronto
Contenuto informativo aggiornato al 1° agosto 2026. Non sostituisce la valutazione del caso concreto.

Autore
Avvocato iscritto all'Ordine di Sciacca (n. 747), esperto in diritto delle tecnologie e privacy. Prima dell'attività forense ha sviluppato applicazioni web e architetture cloud, competenza che porta nell'analisi tecnico-giuridica di prodotti digitali, SaaS e sistemi AI. Assiste aziende e startup nell'adeguamento a GDPR, AI Act, NIS2 e DORA.
Profilo completo e competenze