Valutazione d’impatto sull’IA: quale regime si applica davvero

In sintesi

• Una valutazione d’impatto sull’IA misura ciò che un sistema produce sulle persone, non ciò che costa all’organizzazione. È questo orientamento a determinare quali regole si applicano.
• Sei strumenti distinti portano lo stesso nome. Solo alcuni vincolano giuridicamente, e quale si applichi dipende dal ruolo, dal settore e dalla giurisdizione.
• La valutazione d’impatto sui diritti fondamentali dell’articolo 27 del regolamento sull’IA grava soltanto su tre categorie ristrette di deployer, non su ogni organizzazione che usa l’IA.
• La norma ISO/IEC 42005 è il metodo di riferimento quando nessuna legge obbliga. Si tratta di linee guida, rispetto alle quali nessuno può certificare.
• Il calendario è cambiato. L’articolo 27 si applica dal 2 dicembre 2027, e il Colorado ha cancellato il proprio obbligo di valutazione nel maggio 2026.

Che cos’è davvero una valutazione d’impatto sull’IA

Una valutazione d’impatto sull’IA è una disamina strutturata degli effetti che un sistema di intelligenza artificiale produce sulle persone che tocca: gli individui sottoposti alle sue decisioni, i gruppi che classifica e il pubblico che ne subisce le conseguenze. Lo sguardo è rivolto verso l’esterno. Questa sola caratteristica la distingue dalla maggior parte delle analisi che un’organizzazione già conduce.

Un’analisi dei rischi si chiede quanto il sistema possa costare all’impresa: esposizione regolatoria, fermi operativi, danno reputazionale, malfunzionamento del modello. Una valutazione d’impatto sull’IA si chiede quanto possa costare a terzi: un richiedente di credito respinto, un viaggiatore segnalato per errore, una candidatura scartata prima che un selezionatore apra il fascicolo. I due esercizi si sovrappongono, perché il danno alle persone finisce per diventare danno all’organizzazione, ma non sono intercambiabili. Un’azienda può tenere un registro completo del rischio senza possedere alcun elemento probatorio sull’equità di trattamento dei propri sistemi, come ricordiamo parlando di governance dell’IA.

La seconda proprietà distintiva di una valutazione d’impatto sull’IA riguarda il momento in cui si colloca. È una tappa decisionale, non una relazione redatta dopo l’avvio in produzione. La sua ragion d’essere è orientare la decisione di adozione finché resta aperta. Le analisi prodotte a gara conclusa e contratto firmato documentano scelte già compiute anziché informarle, ed è questo il modo di fallire che i professionisti segnalano più spesso.

Il settore pubblico ha formalizzato la valutazione d’impatto sull’IA prima di quello privato. Lo strumento di valutazione del governo australiano è un fascicolo compilabile che accompagna l’amministrazione attraverso finalità, benefici attesi e una stima del rischio inerente su otto categorie, prima ancora di applicare qualsiasi soglia. È una struttura che vale la pena riprendere anche dove nessuna politica la imponga.

La terza proprietà è che il prodotto finale è una registrazione. Qualunque sia il riferimento adottato, ciò che resta è un documento scritto che nomina il sistema, i gruppi coinvolti, i danni considerati, le misure di mitigazione adottate e la persona che ha accettato la posizione residua. È esattamente questo documento che un’autorità, un revisore o un ricorrente chiederanno di vedere.

Sei regimi, un solo nome

L’espressione copre almeno sei strumenti distinti, che differiscono per destinatari, presupposto, prodotto richiesto ed esistenza o meno di una sanzione.

Strumento	Chi è obbligato	Presupposto	Prodotto	Sanzionabile
Art. 27 regolamento sull’IA (VIDF)	Solo tre categorie di deployer	Prima del primo uso di un sistema ad alto rischio dell’allegato III	Valutazione scritta, notifica all’autorità di vigilanza del mercato, sintesi pubblica	Sì, dal 2 dic. 2027
ISO/IEC 42005:2025	Chi la adotta	Volontario, continuo lungo il ciclo di vita	Valutazione documentata dentro un sistema di gestione dell’IA	No, sole linee guida
Art. 35 GDPR (DPIA)	Ogni titolare del trattamento	Trattamento che presenti un rischio elevato per diritti e libertà	Documentazione DPIA, consultazione preventiva se il rischio residuo resta elevato	Sì, dal 2018
Canada, direttiva sul processo decisionale automatizzato	Istituzioni federali	Prima della messa in produzione	Algorithmic Impact Assessment, pubblicato	Sì, come atto di indirizzo
Colorado SB 24-205, come modificato	Deployer in Colorado	In vigore dal 1 gen. 2027	Solo obblighi informativi, l’obbligo di valutazione è stato abrogato	In parte
Local Law 144 di New York	Datori di lavoro con strumenti automatizzati di selezione	Ogni anno, prima dell’uso	Audit indipendente sui bias, sintesi pubblicata	Sì, da luglio 2023

Due osservazioni contano più della tabella stessa.

In primo luogo, gli unici strumenti che comportano sanzioni per un’impresa privata in Europa sono il regolamento sull’IA e il GDPR, e intervengono su piani diversi. In secondo luogo, la maggioranza delle organizzazioni che si interessano al tema non rientra affatto nell’articolo 27 e sarebbe servita meglio dalla norma ISO/IEC 42005 come metodo che da un testo giuridico che non le nomina. Chiarire presto questo punto evita una mole notevole di lavoro inutile. La mappa di quale norma raggiunga quale organizzazione è ricostruita nelle nostre analisi sulla conformità dell’IA e sulla legge del Colorado.

Chi deve davvero fare la valutazione d’impatto sui diritti fondamentali

È qui che la documentazione pubblicata risulta meno precisa. L’articolo 27 non si applica a ogni deployer di un sistema ad alto rischio, e non riguarda affatto i fornitori.

Tre categorie di deployer sono tenute a condurre una valutazione d’impatto sui diritti fondamentali, come ricostruiscono l’European Center for Not-for-Profit Law e l’Istituto danese per i diritti umani nella loro guida operativa dedicata all’obbligo:

1. Le autorità pubbliche che impiegano sistemi ad alto rischio negli ambiti dell’allegato III: biometria, istruzione e formazione professionale, occupazione, accesso a servizi pubblici e privati essenziali, attività di contrasto, migrazione e controllo delle frontiere, amministrazione della giustizia e processi democratici.
2. I soggetti privati che erogano servizi pubblici essenziali.
3. Le imprese assicurative e bancarie che usano l’IA per la tariffazione delle polizze vita e malattia o per valutare il merito creditizio delle persone fisiche.

La terza categoria merita attenzione particolare nel mercato italiano: coinvolge direttamente gli operatori vigilati da IVASS e Banca d’Italia nel momento in cui un modello interviene nella tariffazione salute e vita o nell’erogazione del credito al consumo.

Ogni altro deployer di un sistema ad alto rischio resta soggetto agli obblighi dell’articolo 26, tra cui la sorveglianza umana e la segnalazione degli incidenti gravi, ma non alla VIDF.

I fornitori sono interamente fuori dall’articolo 27. Il loro obbligo corrispondente è il sistema di gestione dei rischi dell’articolo 9, che copre l’intero ciclo di vita del sistema immesso sul mercato. Questa ripartizione genera confusione perché entrambi i processi esaminano il danno, ma ricadono su soggetti diversi e producono registrazioni diverse.

Conseguenza pratica: chi vende un sistema ad alto rischio ad amministrazioni pubbliche europee si vedrà chiedere il materiale che alimenta le VIDF dei propri clienti, pur non dovendone alcuna. Le clausole contrattuali su qualità dei dati, documentazione per la spiegabilità e notifica delle modifiche che incidono sull’accuratezza sono il meccanismo abituale.

Che cosa impone di produrre l’articolo 27

La disposizione elenca i contenuti. Una valutazione d’impatto sui diritti fondamentali deve descrivere i processi del deployer in cui il sistema ad alto rischio sarà usato conformemente alla finalità prevista; il periodo e la frequenza d’uso previsti; le categorie di persone fisiche e di gruppi presumibilmente interessati; i rischi specifici di danno per tali categorie, tenendo conto delle informazioni fornite dal fornitore; l’attuazione delle misure di sorveglianza umana secondo le istruzioni per l’uso; e le misure da adottare qualora quei rischi si concretizzino, comprese le disposizioni di governance interna e i meccanismi di reclamo.

Due obblighi accompagnano il documento. Il deployer notifica gli esiti all’autorità di vigilanza del mercato, salvo un’esenzione circoscritta. I deployer pubblici pubblicano una sintesi nella banca dati europea dei sistemi ad alto rischio, mentre le sintesi provenienti dalle autorità di contrasto e migratorie confluiscono in una sezione riservata visibile alle sole autorità di vigilanza.

L’obbligo di pubblicazione è la parte più sottovalutata. Una sintesi destinata al pubblico deve spiegare, in un linguaggio comprensibile a chi non è del mestiere, come il sistema viene usato, quali decisioni si prendono a partire dai suoi output, che cosa ha accertato la valutazione, quali mitigazioni sono state scelte, perché l’adozione è stata ritenuta accettabile e come una persona interessata possa reclamare. Una documentazione redatta con sola logica difensiva regge di rado questa traduzione. Costruire la registrazione bene la prima volta costa nettamente meno.

VIDF e DPIA: dove passa il confine

Le organizzazioni soggette all’articolo 27 lo sono quasi sempre anche all’articolo 35 del GDPR, per cui la domanda pratica è se condurre un processo o due.

La guida di ECNL e Istituto danese li tratta come esercizi distinti ma complementari, ed è la scelta più prudente. Una valutazione d’impatto sulla protezione dei dati riguarda i rischi che nascono dal trattamento di dati personali. Una valutazione d’impatto sui diritti fondamentali riguarda gli effetti sull’intero catalogo dei diritti della Carta, compresi danni privi di qualsiasi nesso con un trattamento. La perdita di posti di lavoro conseguente all’introduzione di un sistema ne è l’esempio più netto: nessuna questione di dati personali si pone, e la DPIA non offre alcuna voce in cui registrarla. Lo stesso vale per la perdita di competenze fra professionisti che si affidano agli output automatizzati, e per gli effetti sull’accesso all’istruzione e alle cure che operano a livello di gruppo anziché di persona identificata.

Nella pratica la maggior parte dei team condivide gli input e tiene distinti gli output. Descrizione del sistema, mappa dei dati ed elenco delle parti interessate servono a entrambi. Analisi dei diritti, metodo di graduazione della gravità e verbale delle consultazioni appartengono alla VIDF. Fondere del tutto i due esercizi produce un documento dominato dal lessico della protezione dei dati, in cui i danni non attinenti ai dati scompaiono silenziosamente.

ISO 42005: il metodo quando nessuna legge vi obbliga

La norma ISO/IEC 42005:2025, pubblicata nell’aprile 2025, mette a disposizione un metodo strutturato per la valutazione d’impatto sull’IA. Tratta la delimitazione dell’analisi, la considerazione del comportamento tecnico, dei dati, del flusso d’uso, dei gruppi interessati, degli usi impropri prevedibili, della responsabilità, dei controlli e del monitoraggio, oltre alla rivalutazione lungo il ciclo di vita.

Due elementi vengono presentati regolarmente in modo scorretto. Si tratta di linee guida e non di una norma di requisiti: non esiste alcuna certificazione ISO/IEC 42005 e ogni affermazione contraria è errata. Inoltre la norma è concepita per operare dentro un sistema di gestione dell’IA e non accanto a esso, quindi in complemento alla ISO/IEC 42001 e non in concorrenza con essa. Chi già gestisce un simile sistema conduce la valutazione d’impatto sull’IA come uno dei propri processi documentati e non come esercizio isolato.

Per la grande maggioranza delle organizzazioni è lo strumento giusto. Fornisce un metodo difendibile, si aggancia ai contenuti richiesti dal regolamento sull’IA se in seguito si dovesse rientrare nel suo ambito, e produce la traccia probatoria che clienti e assicuratori chiedono sempre più spesso, nella stessa logica del framework NIST per la gestione del rischio. È una decisione che potete prendere ora, senza attendere che un’autorità vi nomini.

Come condurre una valutazione d’impatto sull’IA

Il metodo che segue riprende la struttura in cinque fasi della guida di ECNL e Istituto danese, pensata per l’articolo 27 ma trasferibile senza forzature a un percorso volontario.

Costituire il gruppo e delimitare il perimetro

Esistono tre modelli. Un gruppo interno interfunzionale preserva la responsabilità e sviluppa competenza propria, ma resta superficiale dove l’esperienza manca. Una valutazione esternalizzata acquista indipendenza e competenza, al prezzo di diluire la responsabilità e di non cogliere le realtà istituzionali. Il modello ibrido, un gruppo interno affiancato da un comitato di esperti esterni, funziona meglio sulle adozioni di grande portata, a costo di uno sforzo di coordinamento.

La delimitazione richiede un’analisi di contesto su tre assi: il contesto di adozione, ossia finalità, durata, decisioni assunte a partire dagli output e persone coinvolte; le caratteristiche del sistema, ossia comportamento tecnico, trattamento di dati personali e quanto è noto su qualità e accuratezza dei dati; e l’assetto di governance, ossia la ripartizione delle responsabilità con il fornitore, il processo di monitoraggio e le misure di sorveglianza umana e trasparenza.

Valutare gravità e probabilità

Costruite da tre a cinque scenari concreti che descrivano come il sistema potrebbe danneggiare le persone, incluso uno scenario peggiore, e individuate ogni diritto che ciascuno mette in gioco. I diritti sono interdipendenti: un sistema affetto da bias nell’istruzione tocca simultaneamente non discriminazione, diritto all’istruzione, diritti dell’infanzia e riservatezza.

La gravità si apprezza poi su quattro parametri: l’intensità dell’ingerenza nel diritto, l’ampiezza dell’impatto e il numero di persone raggiunte, la serietà del danno materiale, psicologico o fisico, e la sua irreversibilità. La probabilità dipende da come il fornitore adempie ai propri obblighi, dalla qualità dei dati, dal grado di sorveglianza umana effettiva, dallo spazio per modifiche successive e dal potenziale di interferenze malevole.

Attenzione particolare va alle persone in condizione di vulnerabilità, che subiscono lo stesso impatto in misura più severa e dispongono di meno vie di rimedio. Il regolamento sull’IA cita esso stesso le persone in povertà estrema, le minoranze etniche e religiose, i minori e le persone con disabilità.

Scegliere le mitigazioni e decidere

Le misure di mitigazione si dividono in tre famiglie. Le misure organizzative coprono sorveglianza umana, gestione dei reclami, trasparenza pubblica e competenza del personale. Le misure tecniche coprono registrazione dei log, sicurezza e qualità dei dati in ingresso. Le misure contrattuali vincolano il fornitore sulla rappresentatività dei dati, sulla fornitura della documentazione necessaria alle richieste di spiegabilità e sulla notifica delle modifiche che incidono sull’accuratezza.

La decisione di adozione dipende poi da quali diritti siano in gioco. Pochi diritti sono assoluti, fra cui il divieto di tortura e la libertà di pensiero, e nessuna ingerenza vi è ammissibile a qualunque livello di gravità o probabilità. Gli altri sono condizionati: un’ingerenza può essere legittima se prevista dalla legge, se persegue un obiettivo legittimo e se resta necessaria e proporzionata. Il gruppo che conduce la valutazione d’impatto sull’IA non è un giudice e non deve raggiungere la precisione di una sentenza, ma percorrere questo test gli mostra i criteri con cui la condotta dell’organizzazione verrebbe poi giudicata.

Monitorare e aggiornare

Con l’adozione la valutazione d’impatto sull’IA non si chiude. Monitorate se le mitigazioni funzionano davvero, attraverso il volume dei reclami e la loro definizione, la qualità osservata della sorveglianza umana e i riscontri degli utenti. Aggiornate l’analisi quando l’uso cambia, quando emergono effetti non previsti, quando una misura rende meno del previsto o quando il quadro giuridico si sposta.

Il calendario reale nel 2026

Tutto ciò che è stato scritto sul tema prima di metà 2026 riporta ormai date superate.

In Europa il regolamento omnibus digitale sull’IA, regolamento (UE) 2026/1744, è stato approvato dal Parlamento europeo il 16 giugno 2026 e dal Consiglio il 29 giugno 2026, pubblicato in Gazzetta ufficiale il 24 luglio 2026 ed entrato in vigore il 27 luglio 2026. Rinvia gli obblighi sui sistemi ad alto rischio autonomi dell’allegato III, e con essi la VIDF dell’articolo 27, dal 2 agosto 2026 al 2 dicembre 2027. I sistemi ad alto rischio incorporati dell’allegato I slittano al 2 agosto 2028. Le pratiche vietate dell’articolo 5 non sono toccate e si applicano dal 2 febbraio 2025.

L’articolo 27, paragrafo 5, incarica l’Ufficio per l’IA di elaborare un questionario modello per agevolare l’adempimento. A metà 2026 non era stato pubblicato e non è prevista alcuna scadenza. La sua assenza non sospende l’obbligo: le organizzazioni interessate hanno interesse a costruire il metodo adesso invece di attendere un formulario.

Negli Stati Uniti il movimento è andato in direzione opposta. La legge SB 189 del Colorado, firmata il 14 maggio 2026, rinvia il Colorado AI Act al 1 gennaio 2027 ed elimina il dovere di diligenza contro la discriminazione algoritmica, il programma di gestione del rischio del deployer e l’obbligo di valutazione d’impatto, lasciando un impianto centrato su informativa e trasparenza con diritti limitati di accesso, rettifica e riesame umano. Qualsiasi documentazione che descriva ancora un obbligo di valutazione in Colorado descrive una disposizione abrogata.

Per un deployer europeo il saldo netto è di circa diciotto mesi in più, e un argomento solido per dedicarli al metodo anziché alla scadenza.

Domande frequenti

La valutazione d’impatto sull’IA è obbligatoria per legge?

A volte. Ai sensi del regolamento sull’IA riguarda solo tre categorie di deployer: autorità pubbliche con sistemi ad alto rischio dell’allegato III, soggetti privati che erogano servizi pubblici essenziali, e assicuratori e banche che usano l’IA per la tariffazione vita e malattia o per il merito creditizio. Ai sensi del GDPR una DPIA è dovuta ogni volta che il trattamento presenti probabilmente un rischio elevato per diritti e libertà, il che copre molto di più. La norma ISO/IEC 42005 resta volontaria. La maggior parte delle imprese private non deve alcuna valutazione di legge e la adotta come buona pratica.

Che differenza c’è con un’analisi dei rischi?

La direzione dello sguardo. Un’analisi dei rischi protegge l’organizzazione dal sistema e misura esposizione, costo e malfunzionamento. Una valutazione d’impatto sull’IA protegge le persone dal sistema e misura gli effetti su diritti, opportunità e trattamento. Il regolamento sull’IA usa entrambe: l’articolo 9 assegna ai fornitori un sistema di gestione dei rischi, l’articolo 27 assegna a determinati deployer una valutazione d’impatto sui diritti fondamentali.

La VIDF coincide con la DPIA?

No. Una DPIA ai sensi dell’articolo 35 del GDPR affronta i rischi derivanti dal trattamento di dati personali. Una VIDF affronta gli effetti su tutti i diritti della Carta, compresi danni privi di dimensione di trattamento come la perdita di posti di lavoro. Le organizzazioni soggette a entrambi condividono di norma gli input e conservano due fascicoli distinti.

Ci si può certificare ISO 42005?

No. La ISO/IEC 42005:2025 è un documento di linee guida e non una norma di requisiti, quindi non esiste nulla da sottoporre ad audit ai fini della certificazione. La norma certificabile di questa famiglia è la ISO/IEC 42001 sul sistema di gestione dell’IA, e un processo di valutazione d’impatto vi si può dimostrare come elemento di prova.

Entro quando bisogna essere pronti?

Per i deployer che rientrano nell’articolo 27, prima del primo uso del sistema, con obbligo applicabile dal 2 dicembre 2027 dopo il rinvio dell’omnibus digitale. Per una DPIA, prima dell’avvio del trattamento. Per gli audit sui bias della Local Law 144 di New York, entro i dodici mesi precedenti l’uso. Per un percorso volontario ISO/IEC 42005, prima della decisione di adozione e poi in modo ricorrente lungo il ciclo di vita.

Chi deve condurre l’esercizio?

Un gruppo interfunzionale e non i soli responsabili del modello. La guida raccomanda di unire competenza sui diritti fondamentali a ingegneria, ufficio legale, protezione dei dati, acquisti e operazioni, e di consultare le persone che il sistema interesserà o i loro rappresentanti legittimi. Dove la competenza sui diritti manchi internamente, va acquisita oppure il gruppo interno va affiancato da un comitato consultivo esterno, anziché rinunciare a quella prospettiva.

Conclusione

La domanda utile non è come condurre una valutazione d’impatto sull’IA in astratto, ma quale vi spetti e quale traccia lasci dietro di sé. Per la maggior parte delle organizzazioni la risposta onesta nel 2026 è che nessun testo le nomina ancora, che la norma ISO/IEC 42005 è il metodo da adottare, e che il rinvio di diciotto mesi dell’articolo 27 è l’occasione per costruire bene la registrazione anziché un motivo per attendere.

Ciò che separa una valutazione difendibile da una semplicemente archiviata è la traccia che la sostiene: gli scenari esaminati, il ragionamento sulla gravità, le mitigazioni assegnate a responsabili nominati e il monitoraggio che ne dimostra la tenuta. AI Sigil conserva questa traccia come registrazione viva, agganciata a ogni sistema e a ogni riferimento normativo che gestite, così che l’analisi diventi un sottoprodotto della vostra governance e non un documento da ricostruire sotto scadenza.