AI e protezione dei dati, gli scenari di rischio da valutare nella DPIA: una guida

LAlla luce dell’aumento esponenziale di soluzioni e applicazioni che utilizzano tecnologie di intelligenza artificiale, non si possono può ignorare le necessarie tutele per le persone; oltre all’AI Act, approvato in via definitiva il 21 maggio 2024 anche dal Consiglio UE, dopo l’approvazione del Parlamento UE, e le diverse iniziative legislative a livello nazionale degli Stati Membri (in Italia, il Governo ha già approvato un disegno di legge specifico), le esigenze applicative e sostanziali diventano sempre più urgenti per i soggetti pubblici e privati.

Le valutazioni di impatto per la protezione dati personali (DPIA), espressamente previste dal GDPR ma anche dall’AI Act quando ci siano condizioni di rischio elevato, non possono essere considerate mero “esercizio di stile” ma, piuttosto, dovrebbero sia illustrare il processo intero di valutazione e l’accountability attuata per l’impiego delle tecnologie di intelligenza artificiale, sia rappresentare l’efficacia, non solo sulla carta, delle misure di mitigazione attuate, per realizzare condizioni di trasparenza e affidabilità dell’AI che trasmettano il più alto grado di fiducia possibile nelle persone.

L’AI Act e la necessità di un risk assessment sui diritti fondamentali

Dei rischi correlati al sempre crescente impiego delle soluzioni di intelligenza artificiale se ne parla già da tempo, davvero tanto si è scritto, e di conseguenza si sta formando ormai discreta letteratura a riguardo.

Rispetto alle tantissime opportunità offerte, sono ormai ben individuati a livello generale, ma anche con approfondimenti più specifici, i potenziali impatti per gli individui, per le comunità, per la società, per l’ecosistema globale, nonché per l’intero pianeta.

Non a caso l’AI ACT dell’Unione Europea vieta espressamente l’utilizzo dell’intelligenza artificiale per alcuni scenari di rischio definiti “ a livello inaccettabile”.

Per gli scenari a rischio elevato, l’AI Act prevede la necessità di un risk assessment sui diritti fondamentali, il cosiddetto FRIA – Fundamental rights impact assessment; che si affianca, nel caso siano implicati trattamenti di dati personali, alla Valutazione di impatto per la protezione dati prevista dall’Art. 35 del GDPR.

Se l’approccio risk based è una costante di ogni nuovo strumento legislativo, ed è al centro di numerose discussioni e pubblicazioni, saper mettere a terra alcune pratiche è fondamentale, perché la portata dello sforzo altruistico delle valutazioni di impatto non è sempre ben compresa.

Può essere dunque utile cercare di inquadrare l’applicazione specifica di alcuni passaggi importanti, che prevedono oneri non da poco nel complicato contesto dell’impiego delle tecnologie di intelligenza artificiale.

La DPIA: un processo per fasi

La valutazione di impatto privacy, ormai famosa con l’acronimo di DPIA, è un adempimento espressamente previsto dall’Art. 35 del GDPR; è un obbligo formale, necessario quando le attività di trattamento dati personali inerenti una certa iniziativa siano particolarmente “invasive”, con rischi elevati per i diritti e le libertà delle persone fisiche, soprattutto quando si prevede l’uso di nuove tecnologie.

Sebbene l’output della DPIA sia nel concreto una relazione documentata, va sempre ricordata l’importanza del processo. La DPIA è infatti un insieme di attività interdisciplinari che possono durare settimane, mesi, perché l’obiettivo reale, vale la pena ricordarlo, è capire se l’iniziativa si può realizzare, in quanto i rischi per le persone sono mitigati a livelli accettabili, oppure no.

Troppo spesso questa relazione di valutazione di impatto viene considerata un documento da redigere prima di andare “live” con il progetto, ovvero, se non si fa in tempo, anche successivamente; come tutti gli adempimenti, è bene che ci siano le necessarie evidenze.

Tale approccio è da ritenersi non corretto, perché la DPIA è invece uno fra i più potenti strumenti di privacy by design, e dovrebbe raccontare l’intero ragionamento svolto per tutelare le persone, dalla concezione dell’idea, alla progettazione, allo sviluppo fino alla realizzazione dell’iniziativa.

La 2 figure di seguito sintetizzano il ciclo del processo:

Fig. 1 e 2 – Esempi di processo DPIA , rielaborati e creati dall’Autore

Anche rendicontare lo sviluppo delle attività è a questo punto essenziale, per cui nella sezione iniziale della relazione, che diventa dunque un documento dinamico, avere una tabella come questa riportata sotto, può aiutare la conduzione.

Fig. 3 – Esempio di tabella per rendicontare le diverse fasi della DPIA – tabella creata dall’Autore

Allo stesso modo, inserire Matrici RACI (R = Responsible, A = Accountable, C = Consulted, I = Informed.), meglio ancora se affiancate da grafici di flusso, è essenziale.

Di seguito un esempio semplice:

Fig. 4 – Esempio di tabella per la matrice RACI – creata dall’autore

Gestire dunque la DPIA come processo e progetto ampio e collaborativo, soprattutto in situazioni complesse come quelle correlate all’uso dell’IA, è importantissimo.

Alcuni key points che ci permettiamo di suggerire sono:

• Il Process Owner dell’iniziativa ha un ruolo fondamentale; i consulenti e gli specialisti sono fondamentali per fornire consulenze, indicazioni e linee guida sulla conduzione, ma senza il commitment costante dei rappresentanti del Titolare, gli esiti possono risultare con ogni probabilità poco approfonditi, inefficaci, inesatti, e spesso contestabili; serve una chiara progettazione del processo, il coinvolgimento di tutti gli stakeholders, e un’intensa collaborazione.
• La DPIA è onere del Titolare. Esistono ovviamente Valutazioni di impatto, o Relazioni di valutazione rischi e misure adottate, fornite dai Fornitori, Responsabili o subresponsabili, ma non possono essere date per “adempimento fatto”; la DPIA del titolare dovrà semmai recepire ogni strumento messo a disposizione dai fornitori, incluse le “DPIA da Responsabili del trattamento” per soluzioni applicative, nella propria DPIA.
• Il Data Protection Officer, se presente e designato, NON è il soggetto che realizza la DPIA; tuttavia, il processo sarà tanto più efficace quanto il DPO è coinvolto e consultato nelle diverse fasi; partecipare attivamente, fornire indicazioni e vigilare sulla collaborazione di tutti gli stakeholders nelle diverse fasi è comunque costruttivo; ridursi invece ad una sola “lettura finale” per esprimere il parere è antidiluviano, formale e spesso non produttivo, in particolare quando il DPO non ha aggiornato le proprie competenze nella materia oggetto di esame.

In conclusione, conviene iniziare a considerare la Valutazione di impatto, se ancora non fosse chiara la portata, come processo con diverse fasi e attività. Come vedremo a breve, tale processo, quando riguarda soluzioni collegate all’impiego o allo sviluppo di tecnologie IA, è spesso più complesso di quello che si pensi, anche in termini di effort per i diversi attori coinvolti, e ciò va tenuto in considerazione.

Aspetti essenziali nelle Valutazioni di impatto per la protezione dati

In 6 anni di piena applicazione del GDPR, la Valutazione di impatto privacy è stata ampiamente descritta, i termini di contenuti, modalità, modelli e strumenti. Ricordiamo che quando è necessaria una certa profondità, la relazione finale della DPIA (di cui spesso è auspicabile realizzare una sintesi pubblicabile e ben leggibile) – consta quasi sempre di un numero congruo di Allegati, alcuni dei quali anche squisitamente tecnici, richiamati nel ragionamento generale che una buona DPIA deve poter raccontare.

Senza scendere in alcun dettaglio, in questa sede si desidera attenzionare soltanto alcuni aspetti essenziali che rilevano particolarmente nel contesto di iniziative correlate all’AI

Liceità, necessità e proporzionalità

Va posta particolare attenzione i questi passaggi iniziali, che non possono, e non devono, peccare di superficialità. Qui si possono infatti decidere le sorti dell’iniziativa; è possibile che si debba rinunciare, ad esempio, a specifici trattamenti.

Se la mappatura dell’attività di trattamento (che andrebbe documentata nel Registro ex Art. 30 GDPR prima di iniziare il processo di DPIA) non è stata accurata, è proprio in questo passaggio che arriva il momento per riflessioni e indagini ben più specifiche. Che non riguardano solo il GDPR e le normative di contesto, beninteso; conviene sempre includere ragionamenti su ogni provvedimento di Autorità di Controllo, sia del nostro Garante che di Autorità di altri Stati, perché rappresentare la consapevolezza delle posizioni già espresse da parte delle Autorità e delle Corti è indice di accountability. Inoltre, se fra le basi giuridiche delle attività in esame ci dovesse essere il legittimo interesse, allora è bene includere nella DPIA (anche come allegato) la relativa LIA (Legitimate interest assessment), con i test di bilanciamento effettuati.

Descrizione funzionale del flusso dei trattamenti di dati

Per questo passaggio, sono di particolare importanza documentazioni chiare, anche stratificate per intelligibilità e comprensione, dello stack tecnologico, del ruolo dei diversi attori, etc. Anche qui dunque, niente superficialità – e serve un lavoro di comunicazione particolarmente importante. Ad esempio, se la DPIA riguarda una soluzione applicativa che impiega, mediante API, una soluzione AI, va descritta ogni attività di trattamento in relazione agli steps del Life Cycle dell’AI impiegata, ponendo particolare attenzione, ad esempio, ad evitare che ulteriori dati personali alimentino il Training della stessa. Allo stesso modo, le fasi di Test, Evaluation, Validation e Verification devono rassicurare circa la migliore affidabilità e robustezza dell’AI impiegata, sia nelle elaborazioni di input che negli output.

Comprendere le peculiarità delle valutazioni dei rischi per i diritti e le libertà delle persone fisiche

Quando si valutano i rischi, non va mai dimenticato l’obiettivo.

Non a caso la definizione più universale di rischio è la seguente: effetto dell’incertezza sugli obiettivi.

Facciamo un esempio, forse banale ma che può chiarire le possibili difficoltà di interpretazione; per una guardia forestale, il rischio di incendio è uno dei principali scenari da attenzionare, rispetto al suo obiettivo di vigilanza delle tutele per il bosco o foresta che tiene sotto controllo. Poniamo il caso che vicino al bosco ci sia un terreno gestito da un contadino, il cui principale obiettivo è salvaguardare il raccolto; in questo caso, l’incendio è solo una delle possibili fonti di rischio che possono inficiare il suo obiettivo principale. Lo scenario di rischio da individuare per il contadino, in questo caso, è la perdita del raccolto, che può avvenire a causa di incendi, grandine, siccità, etc. – mentre l’incendio , che è un rischio per il guardaparco, è nella prospettiva del contadino un possibile evento minaccioso, che può rappresentare l’origine del rischio di perdita del raccolto.

Comprendere dunque la differenza fra scenario di rischio, origine del rischio, minacce o eventi pericolosi, vulnerabilità, è essenziale per gli steps analitici.

A tal proposito, nella DPIA è fondamentale l’impiego chiaro di criteri e metriche coerenti con la dimensione altruistica della valutazione dei rischi per i diritti e le libertà degli interessati.

Nella disciplina della data protection, « Per “rischio” si intende uno scenario descrittivo di un evento e delle relative conseguenze, che sono stimate in termini di gravità e probabilità per i diritti e le libertà »

(Linee guida del Gruppo di lavoro Articolo 29 WP248rev.1).

Comprendere tali sfumature non è sempre semplice, per i legislatori, e nemmeno per gli esperti del settore o per le Agenzie e gli organismi di standardizzazione, tant’è che i tentativi di creare tassonomie ufficiali hanno risultati spesso eterogenei.

Ad esempio, il neo formato Organismo Comunitario EU AI Office, nell’evento del 5 giugno 2024, ha ribadito che secondo l’AI Act ‘risk’ means the combination of the probability of an occurrence of harm and the severity of that harm; e ammette che tale definizione è in contrasto con altre definizioni. (e in effetti, a parere dello scrivente, mal si concilia con i rischi che derivano da trattamenti di dati personali).

(per maggiori dettagli, è comunque interessante riguardare il convegno o leggere le slides, materiale disponibile al link https://ai-watch.ec.europa.eu/news/eu-ai-office-webinar-risk-management-ai-act-and-related-standards-2024-06-05_en ).

Ad ogni modo, non è forse tanto fondamentale soffermarsi sui tecnicismi, quanto invece è opportuno rilevare che nonostante tutto, il GDPR attenziona i rischi per le persone che possono derivare da trattamenti di dati personali. Il focus va dunque posto sulla persona e sui trattamenti, e una chiave di lettura per salvaguardare i diritti e le libertà (tutte/i, non solo il diritto alla protezione dati, che è il veicolo specifico per la salvaguardia degli altri diritti e libertà) è il rispetto dei principi di protezione dati, posti dal GDPR come presidi fondamentali.

Il dato personale, dobbiamo sempre ricordarci, ha una duplice dimensione: non solo quella di dato come asset informativo da proteggere per tutelare la persona a cui è riferito direttamente o indirettamente, ma anche quella di dato come elemento/attributo dell’individuo su cui basare il rispetto per la persona.

Possiamo chiamarla “safety” del dato personale rispetto la “security”, o come vogliamo; nella sostanza, si tratta di considerare, e ciò vale ancora di più per l’uso di AI, la dimensione “etica” di come usiamo i dati personali.

Ecco perché in ogni valutazione dei rischi per la protezione dati che si rispetti, oltre agli scenari di rischio “di sicurezza”, come:

• perdita o indisponibilità di dati
• distruzione non autorizzata di dati
• modifiche indesiderate o non autorizzate ai dati
• divulgazione non autorizzata di dati personali
• accesso illegittimo o non autorizzato ai dati

vanno analizzati scenari di rischio “etici”, ossia rischi come:

• eccessiva raccolta o uso di dati personali
• collegamenti o raffronti inappropriati o non autorizzati di dati personali
• poca trasparenza-chiarezza, non considerazione dei diritti
• riuso per finalità diverse dei dati personali senza la consapevolezza e/o il consenso degli interessati
• difettosità di elaborazione o processo
• conservazione immotivatamente prolungata dei dati personali
• inesattezza o dequalificazione – mancato aggiornamento dei dati personali
• re-identificazione dei soggetti interessati
• sorveglianza ingiustificata o illegittima

Ovviamente tutti gli scenari di rischio elencati a titolo di esempio (a prescindere dalla dizione utilizzata, che può piacere o meno, e che può essere ovviamente personalizzata), sono correlati al mancato rispetto dei principi di protezione dati enunciati nel Regolamento UE 2016/679.

Come se non bastasse, va ricordato che secondo il GDPR “La probabilità e la gravità del rischio per i diritti e le libertà dell’interessato dovrebbero essere determinate con riguardo alla natura, all’ambito di applicazione, al contesto e alle finalità del trattamento. Il rischio dovrebbe essere considerato in base a una valutazione oggettiva mediante cui si stabilisce se i trattamenti di dati comportano un rischio o un rischio elevato.” (cifr. Considerando 76 GDPR).

A complicare la valutazione qualitativa dei rischi, dunque, oltre alla verosimiglianza/probabilità che qualcosa si verifichi e alla gravità di impatto delle possibili conseguenze (in termini di impatto fisico, materiale o immateriale), abbiamo dunque ulteriori parametri da considerare.

I lettori più attenti si saranno chiesti, ad esempio, se la natura del trattamento incida più sulla verosimiglianza di eventi avversi o sulla gravità di impatto; e l’ambito di applicazione? Il contesto?

Si suggerisce una lettura combinata dei considerando da 75 a 94 del GDPR, delle Linee guida del Gruppo di lavoro Articolo 29 WP248rev.1 e delle Linee guida EDPB 4/2019 – come minimo, per comprendere le peculiarità delle valutazioni di rischio privacy. Ci sono poi tante pubblicazioni della ns Autorità Garante, del Cnil Francese, dell’AEPD e di altri Garanti Europei.

La complessità degli scenari di rischio per l’AI

Quando si analizza uno scenario di rischio, ci si deve generalmente porre nella condizione di poter rispondere a domande come queste:

Che cosa può accadere? Perché può accadere? Quali sono le conseguenze? Qual è la probabilità che l’evento si verifichi? Quali fattori possono mitigare le conseguenze del rischio? Quali fattori possono ridurne la probabilità? Il livello di rischio è accettabile? Il livello di rischio richiede un ulteriore mitigazione?

Non bisogna MAI partire dai controlli/misure; essi hanno altro scopo, possono essere utilizzati per assessment di maturità di un modello o sistema rispetto certi requisiti, come nelle Gap Analysis, oppure possono essere utilizzati per rappresentare la mitigazione adottata, come vedremo in seguito.

Piuttosto, si possono descrivere le vulnerabilità delle persone nello scenario di rischio di riferimento, rispetto ai potenziali eventi dannosi o minacce.

Oltre all’impostazione dei valori di probabilità e gravità di impatto, è sempre corretto descrivere, in modo verboso, il perché si attribuisce un certo valore. Ciò aiuta a rendere più oggettiva possibile la valutazione, e ad evitare che un lettore/osservatore/verificatore si debba chiedere “perché è stato indicato questo valore qui?”.

Nello schema che segue, c’è un classico esempio di introduzione di motivazioni/giustificazioni (indicato nell’ultima colonna) rispetto ai valori di verosimiglianza/probabilità assegnati a gruppi di eventi dannosi.

Fig. 5 – Esempio di “assegnazione probabilità” con giustificazione dei valori attribuiti – tabella creata dall’Autore.

Ovviamente ci sono altri gruppi di eventi dannosi da considerare nella valutazione di impatto, e fra questi, in una DPIA per soluzioni basate sull’AI, si dovrà necessariamente coniare degli insiemi di “minacce” la cui tassonomia non è affatto semplice; a tal fine, possono risultare utili standard come le norme ISO/IEC 42001:2023 e la ISO/IEC 23894:2023 (Annex B), o anche l’AI RISK MANAGEMENT FRAMEWORK del NIST.

Se ci si attesta al momento, su una generale mancanza di governo delle tecniche, ad esempio, il livello di verosimiglianza è quantomeno probabile, perché non ci sono studi di settore, pubblicazioni o dati statistici sufficienti e ritenere raro o anche solo possibile il potenziale di danno delle tecnologie AI.

Anche per la gravità delle conseguenze, nel determinare i potenziali impatti per le persone (fisico, materiale, immateriale), si stabilisce tipicamente un livello di gravità, ad esempio basso, medio, alto, critico, fornendo le opportune motivazioni.

Ma come si fa per gli scenari di rischio AI?

Ad esempio, fra gli scenari di rischio specifici, si possono individuare:

• opacità degli algoritmi e dei sistemi
• esclusività della decisione algoritmica
• influenza o manipolazione informativa degli interessati
• disequità o discriminazione algoritmica
• allucinazione algoritmica
• output illeciti
• deepfake
• raccomandazioni pericolose o violente – disallineamento etico rispetto ai valori umani
• distorsione cognitiva
• eccessiva dipendenza dalle tecnologie ai
• contaminazione dati e prestazioni dei sistemi AI – poisoning

La lista non ovviamente esaustiva, ma ricordiamo che stiamo ragionando sugli scenari di rischio che derivano da trattamenti di dati personali, non su tutti i rischi relativi all’impiego dell’AI – della quale si teme ad esempio il job displacement o altri scenari di perdita dell’autonomia e supervisione umana non correlati a trattamenti di dati personali.

Per la determinazione del livello di gravità di impatto, immaginare tutta la “catena delle conseguenze” non è certo banale; di conseguenza i rischi inerenti, intrinsechi, potenziali, quelli che non considerano ancora le misure di mitigazione attuate, avranno con ogni probabilità livelli piuttosto alti se non critici. Se l’obiettivo dell’analisi del rischio è quello di avere rappresentati i diversi livelli di rischio, è necessario trovare una forma leggibile e comprensibile; le immagini riportate sotto sono possibili esempi di heating map realizzabili con strumenti o fogli di calcolo che possono essere sviluppati per elaborare la stima dei diversi livelli di rischio.

Fig. 7-8-9 Esempi di “Heating map” dei livelli di rischio per alcuni scenari “di sicurezza”, “etici”, “specifici per l’AI”; elaborati dall’Autore.

Il fatto che nelle heating maps i livelli di rischio intrinseci siano così elevati non è un caso, derivano da dati di un processo di valutazione in corso in cui la mitigazione sarà tutt’altro che semplice.

Le misure e i controlli per la mitigazione

Le situazioni di rischio elevato prevedono l’attuazione di misure organizzative e tecniche per ridurre il livello di rischio, che devono essere rappresentate con metriche per stabilirne l’efficacia.

Va premesso che stabilire i criteri di efficacia è uno degli aspetti più complicati della mitigazione; esistono diversi modi, che dipendono dalle diverse metodologie utilizzate, ma è il razionale ciò che conta.

L’unica regola abbastanza condivisibile è la seguente:

l’efficacia di una misura di mitigazione su uno scenario di rischio è direttamente proporzionale al grado di applicazione della misura e all’azione specifica su tale scenario

Cosa significa nel concreto? Vediamo un esempio.

Una possibile metrica per il grado di applicazione di un controllo, che indica l’adozione di misure, contromisure o salvaguardia di specifiche condizioni, può essere questo riportato nell’immagine sottostante.

Fig. 10 Esempio di metrica per i gradi di applicazione dei controlli – tabella elaborata dall’Autore.

Ai diversi livelli, possiamo attribuire valori numerici, dei punteggi; prendiamo in esame alcuni controlli che recepiscono “famiglie” di misure; supponiamo che, a fronte di preventive checklist specifiche basate su misure standard, ovvero basate su controlli di specifici framework, si decida di valutarne l’efficacia in una logica di insieme, come in questo esempio:

Fig. 11 Esempio di set di misure estratto da un elenco – con grado di applicazione e giustificazione/motivazione per il valore attribuito – tabella elaborata dall’Autore.

Non si approfondisce in questa sede la scelta dei controlli di mitigazione: questi possono essere codificati anche ex novo in maniera specifica per i rischi privacy, magari considerando preventive liste di controlli universalmente riconosciuti in quanto presenti in standard ben noti; il punto è che tali controlli possono avere azioni importanti o quanto meno significative su alcuni scenari di rischio, mentre possono avere un peso nullo o irrilevante per altri scenari.

Ad esempio, la crittografia non ha alcuna azione sul rischio di poca trasparenza, o sul rischio di esclusività della decisione algoritmica, mentre ha sicuramente un peso importante sugli scenari relativi alla sicurezza, come sul rischio di accesso illegittimo o non autorizzato ai dati – oppure sul rischio di contaminazione dati e/o prestazioni del sistema AI, il cosiddetto “poisonising”.

Allo stesso modo, una misura organizzativa, magari ben applicata e verificata, ad esempio la mappatura delle attività di trattamento nel Registro ex Art. 30 GDPR, ha azione nulla sugli scenari di sicurezza (avere un buon registro non protegge certo da attacchi cyber o da errori utente, o da altri eventi distruttivi) ma invece, con diversi gradi di azione, da moderato a significativo o importante, può mitigare i rischi di natura più etica, in quanto l’aver analizzato e stabilito le specifiche finalità, basi giuridiche e ambiti mitiga un utilizzo improprio dei dati.

Quindi è la combinazione di queste due grandezze, il punteggio relativo al grado di applicazione, e il coefficiente di azione sui diversi scenari (che vanno ahimè impostati e motivati) che può poi dare il valore di efficacia alla singola misura; nulla vieta di stabilire altri pesi, o caratteristiche (ad esempio, misure preventive o protettive, o miste, che agiscono sulla probabilità dei rischi o sulle gravità di impatto).

Ogni livello di rischio dei diversi scenari può essere abbassato dall’efficacia, con metodi di calcolo anche semplici (che rispettino il principio che il rischio non può essere mai azzerato).

Il lavoro di impostazione di criteri e metriche, dei pesi, dei gradi di applicazione e dell’azione delle misure sui rischi può essere anche particolarmente oneroso, ma se la metodologia è coerente e riutilizzabile, e ci sono spiegazioni che facilitano quanto meno l’intersoggettività (l’oggettività assoluta è un miraggio), costruire modelli di rappresentazione efficaci , e criteri di accettabilità del rischio residuo, nelle fasi finali della DPIA, non è difficile.

L’importante, ovviamente, è che quanto riportato su uno strumento, e sulla relazione della Valutazione di impatto, siano analisi oneste e veritiere, che non siano “distanti” dalla realtà applicativa.

Con l’AI, purtroppo, gestire tali contesti, costruire modelli e metriche per l’azione sugli scenari di rischio, non è banale, nonostante ci sono standard e framework che azzardano indicazioni per farlo. La reale efficacia di tante valutazioni si vedrà soltanto con il tempo.

Conclusioni

Come abbiamo cercato di spiegare, mettere a terra metodologie, criteri e metriche per valutazioni di impatto per la protezione dati davvero efficaci in termini di rappresentazione dello sforzo altruistico richiesto non è certo banale; la complessità dei nuovi scenari di rischio, in continua evoluzione, introdotti dall’impiego delle tecnologie di intelligenza artificiale, rende il compito ancora più difficile, e potenzialmente ancora non attendibile. Serve studio, consapevolezza e umiltà per affrontare le nuove sfide che ci attendono.