Dove nasce il giudizio

Un dipendente apre l’assistente interno della sua azienda alle 23 e 40 e scrive una domanda che non farebbe a un collega. Riguarda un congedo, e il timore che il proprio responsabile venga a sapere perché lo chiede. Per formularla bene deve dare qualche dettaglio: che da sei mesi dorme quattro ore per notte, che ha smesso di trovare un motivo per alzarsi, che la mattina arriva sempre più tardi.

Quell’assistente gira su un contratto API con Zero Data Retention. Vuol dire che la conversazione non viene conservata dopo l’elaborazione, che nessuna persona del fornitore potrà leggerla, che non finirà in nessun dataset di addestramento. Mezzo secondo dopo la risposta non esiste più niente. Dal punto di vista della conservazione siamo molto vicini alla condizione ideale: il dato è passato e non ha lasciato residui.

Eppure, mentre passava, il sistema ha concluso qualcosa su di lui.

Non dico ancora che cosa, perché è esattamente il punto. La domanda che abbiamo imparato a fare in trent’anni di protezione dei dati è: chi può vedere questa conversazione? La risposta, in questo caso, è nessuno. È una risposta eccellente, ed è insufficiente.

Il 19 agosto, ieri, OpenAI ha annunciato qualcosa che rende questa insufficienza concreta invece che filosofica.

Che cosa è stato annunciato ieri

Il 19 agosto OpenAI ha comunicato due cose distinte, e conviene tenerle separate perché la prima è una conferma commerciale e la seconda è un’idea architetturale.

La prima: Zero Data Retention continuerà a essere offerto ai clienti API idonei anche sui modelli frontier. In ZDR, secondo la definizione dell’azienda, prompt e risposte non vengono conservati dopo l’elaborazione della richiesta, il contenuto dei clienti non è disponibile al personale per revisione e i dati dei clienti enterprise non vengono usati per addestrare i modelli salvo opt-in esplicito. È una promessa rivolta alle imprese, non agli utenti consumer, e la differenza conta: chi scrive a un chatbot pubblico non sta comprando questa garanzia.

La seconda: l’anteprima di Private Safety Processing. Nasce da un problema che è reale e che le aziende frontier non hanno inventato per marketing. Man mano che i modelli prendono in carico lavori più lunghi e più autonomi, i sistemi di sicurezza devono riconoscere rischi che non si vedono in una singola richiesta, ma nella forma di una sequenza. Una domanda isolata è quasi sempre innocua. Trenta domande in due giorni, prese insieme, possono non esserlo. Solo che per guardare una sequenza bisogna conservarla, e conservarla è precisamente ciò che ZDR promette di non fare.

Private Safety Processing prova a separare le due cose. Nelle configurazioni ZDR il contenuto resta sull’infrastruttura controllata dal cliente, oppure risiede su server OpenAI in forma cifrata con chiavi che il cliente detiene e di cui il fornitore non ha copia. L’analisi dei pattern avviene lì dentro. Quando qualcosa scatta, quello che esce dal confine è un segnale ristretto, che indica il tipo e la gravità dell’attività senza esporre i prompt e le risposte sottostanti. L’allarme lo investiga il cliente, sui propri sistemi; può poi decidere di consegnare volontariamente materiale, per contestare una decisione o per collaborare a un’indagine su un abuso.

Il rollout è annunciato per settembre, insieme a un white paper tecnico. Finché quel documento non esce sarebbe scorretto trarre conclusioni forti: non sappiamo dove giri esattamente il classificatore, quale sia la granularità del segnale, che cosa succeda ai falsi positivi. Chi valuta fornitori ha imparato a distinguere tra un’architettura e un comunicato, e questo per ora è a metà strada.

Anche così, la cosa interessante è già leggibile. Il fornitore può sapere: questa sequenza appartiene probabilmente alla categoria X. Senza sapere: ecco le frasi che l’utente ha scritto. Le due conoscenze non sono la stessa cosa, ed è la seconda che la normativa sulla protezione dei dati ha imparato a governare bene.

Vale la pena notare che l’industria si sta dividendo su questo punto. Anthropic conserva per trenta giorni prompt e output dei propri Covered Models, la categoria a cui applica le politiche più stringenti, dichiaratamente per sostenere il proprio lavoro sulla sicurezza, e lo fa su tutte le piattaforme in cui quei modelli sono offerti. Sono due risposte diverse alla stessa tensione, e nessuna delle due è ovvia.

Concediamo tutto all’obiezione

Prima di sostenere che stia succedendo qualcosa di nuovo bisogna evitare una forzatura molto comune, cioè raccontare come scoperta di oggi una cosa che il diritto conosce da un pezzo.

L’inferenza non nasce con i modelli linguistici. La pubblicità comportamentale deduce interessi da vent’anni. Il credit scoring deduce affidabilità economica. Gli algoritmi antifrode deducono probabilità di comportamento illecito. La profilazione è per definizione la produzione di caratteristiche personali a partire da comportamenti diversi da quelle caratteristiche.

Il GDPR è stato scritto abbastanza largo da comprendere tutto questo. L’articolo 4, punto 4, definisce la profilazione come qualsiasi forma di trattamento automatizzato volto a valutare aspetti personali, e le linee guida europee distinguono da anni fra dati forniti dall’interessato, dati osservati e dati derivati o inferiti, cioè prodotti dal titolare analizzando altri dati.

Ma la difesa più forte del diritto vigente non sta nelle definizioni. Sta in tre sentenze della Corte di giustizia, e sono più radicali di come vengono di solito riassunte.

Il 4 luglio 2023, in Meta contro Bundeskartellamt, la Corte ha stabilito che il divieto sui dati sensibili non richiede una dichiarazione esplicita. Se un operatore raccoglie le visite di un utente a siti e applicazioni collegati a categorie particolari di dati e le collega al suo account, sta trattando dati sensibili, indipendentemente dal fatto che quelle informazioni siano state dichiarate. Rivelare, per la Corte, comprende dedurre. È esattamente il principio che serve per il mondo dell’inferenza, ed è stato scritto tre anni fa.

Il 7 dicembre 2023, nel caso SCHUFA, la Corte è andata ancora più a fondo. Il calcolo automatizzato di un tasso di probabilità sulla capacità di una persona di onorare impegni di pagamento futuri costituisce esso stesso un processo decisionale automatizzato ai sensi dell’articolo 22, quando da quel tasso dipende in modo decisivo la stipula, l’esecuzione o la cessazione di un rapporto contrattuale da parte del terzo a cui viene comunicato. Non la delibera della banca: il punteggio. Il diritto europeo ha già riconosciuto che l’inferenza può essere il vero atto decisorio, e che chi la produce non può nascondersi dietro chi la usa.

Il 4 ottobre 2024, in Schrems contro Meta, la Corte ha stabilito che il principio di minimizzazione impedisce di aggregare, analizzare e trattare per finalità pubblicitarie i dati raccolti dentro e fuori la piattaforma senza limiti di tempo e senza distinzione di tipo. E ha aggiunto che l’avere dichiarato pubblicamente il proprio orientamento sessuale in un’occasione non autorizza a trattare altri dati relativi a quell’orientamento.

C’è infine l’opinione 28/2024 dell’EDPB, adottata il 17 dicembre 2024, che contiene un’intuizione simile applicata ai modelli. Perché un modello addestrato su dati personali possa dirsi anonimo, dice il Board, devono essere insignificanti sia la probabilità di estrarne direttamente dati personali, tenendo conto di attacchi come la membership inference e l’inversione del modello, sia la probabilità che le interrogazioni restituiscano dati personali identificabili, anche in modo non intenzionale.

Sarebbe quindi sbagliato scrivere che abbiamo improvvisamente scoperto una categoria ignota al diritto. Il diritto europeo ha gli strumenti concettuali e li ha già usati. Chi sostiene il contrario di solito non ha letto le sentenze.

Il cambiamento è un altro, ed è più scomodo perché non si risolve legiferando.

Che cosa cambia davvero

Cambiano tre cose insieme, e sono la scala, il costo e la temporalità.

La scala. Un sistema di credit scoring inferisce una cosa. Un sistema pubblicitario inferisce qualche decina di attributi da un catalogo definito in anticipo. Un foundation model non ha un catalogo. Una singola conversazione può contemporaneamente suggerire livello di istruzione, stato emotivo, occupazione, capacità economica, area geografica probabile, orientamento politico, condizione medica, situazione familiare e intenzioni future, e non perché qualcuno abbia costruito nove classificatori. La capacità di produrre quelle categorie esiste nello stesso modello che sta rispondendo a una domanda sulle ferie. Non va attivata: va, semmai, impedita.

Il costo. Per anni la protezione dei dati ha potuto contare su un’assunzione implicita e ragionevole: sapere costa. Serviva accumulare osservazioni, costruire un profilo, mantenerlo aggiornato, e ogni passaggio lasciava tracce che si potevano regolare. Con modelli molto capaci quella relazione si indebolisce. Dieci segnali deboli possono produrre un’inferenza forte. Una fotografia rivela più di quello che mostra. Un pattern temporale rivela una routine. Una frase permette di stimare molto più del suo contenuto semantico esplicito.

La temporalità, che è il pezzo davvero nuovo. La profilazione classica produceva un profilo, cioè uno stato: un record da qualche parte che diceva «questa persona appartiene al segmento 47». Quello stato si poteva ispezionare, contestare, cancellare. Un modello generalista può non archiviare mai la proposizione «questa persona appartiene alla categoria X». Può ricostruirla, identica, ogni volta che gliela si chiede.

Questa formulazione merita di essere tenuta, perché è il centro di tutto il ragionamento: la conoscenza smette di essere uno stato persistente e diventa una capacità persistente di produrre uno stato.

Non è una sottigliezza filosofica. Ha conseguenze pratiche immediate su cancellazione, rettifica e conservazione.

Il paradosso della stanza vuota

Immaginiamo una macchina ideale, costruita da qualcuno in perfetta buona fede.

Riceve il diario personale di una persona. Lo elabora. Nessun essere umano può leggerlo. Non viene scritto su disco. Non viene usato per addestrare niente. Subito dopo è cancellato in modo irreversibile, e la cancellazione è verificabile.

Prima di cancellarlo, però, la macchina produce una riga: probabilità 92% che questa persona appartenga alla categoria A. E conserva soltanto quella.

Abbiamo protetto il dato? Tecnicamente sì, e non in modo cosmetico: quasi tutte le metriche di rischio che usiamo oggi darebbero esito positivo. Abbiamo protetto la persona? Dipende interamente da che cosa sia A e da che cosa succeda dopo.

Un sistema può minimizzare in modo eccellente il possesso del dato e massimizzare contemporaneamente la conoscenza che ne estrae. Sono due minimizzazioni diverse, e le abbiamo trattate come se fossero la stessa perché nel mondo dei database lo erano quasi sempre.

Supponiamo che un assicuratore non riceva mai una cartella clinica. Riceve soltanto uno score sanitario, calcolato localmente sul telefono della persona, con un’architettura su cui nessun crittografo troverebbe da ridire. L’assicuratore non possiede dati clinici. Possiede l’unica informazione che gli interessava davvero, e nella forma più comoda possibile.

Ed è qui che l’inferenza diventa, in certi casi, più pericolosa del dato. Una cronologia di acquisti richiede interpretazione, e l’interpretazione costa, si può sbagliare, si può discutere. L’etichetta «probabile difficoltà finanziaria» è già pronta per essere usata da chiunque, senza competenza e senza attrito. Un insieme di messaggi è ambiguo. Uno score di «propensione ad abbandonare il posto di lavoro» trasforma quell’ambiguità in una decisione, e la consegna in una forma che il destinatario non ha nessun incentivo a rimettere in discussione.

Un’inferenza, molto spesso, è un dato già convertito in potere operativo.

Un’inferenza sbagliata non si corregge

C’è un secondo problema, ed è che le inferenze non devono nemmeno essere esatte per produrre effetti.

Quando un database contiene un indirizzo sbagliato, il diritto ha una risposta semplice e funzionante: si corregge l’indirizzo. Il diritto di rettifica presuppone un fatto registrato, individuabile, sostituibile.

Quando un sistema conclude, combinando migliaia di variabili, che una persona ha un’elevata probabilità di insolvenza, che cosa si rettifica? Quale campo? Quale peso? Quale correlazione? Quale rappresentazione latente? Non c’è una casella sbagliata. C’è un giudizio prodotto, e un giudizio prodotto non ha la struttura grammaticale di un errore materiale.

Il diritto europeo se n’è accorto e sta prendendo una strada diversa, che passa dalla contestabilità più che dalla correzione. Il 27 febbraio 2025, nel caso Dun & Bradstreet, la Corte di giustizia ha stabilito che l’articolo 15, paragrafo 1, lettera h del GDPR obbliga il titolare a spiegare, in forma concisa, trasparente e intelligibile, la procedura e i principi effettivamente applicati per ottenere un determinato risultato a partire dai dati personali di quella persona. Non la formula, non il codice sorgente: il procedimento davvero seguito. E ha aggiunto che il segreto commerciale non è un’obiezione assoluta, perché quell’informazione serve a permettere alla persona di ottenere l’intervento umano, esprimere la propria posizione e contestare la decisione.

È una risposta seria, e resta molto più difficile da applicare a un modello generalista che a un sistema di scoring. Un sistema di scoring ha variabili, pesi e una soglia. Si può spiegare, faticosamente, che cosa ha pesato. Un modello che produce una classificazione come effetto collaterale della propria comprensione linguistica non ha una procedura in quel senso, e la tentazione di rispondere con una descrizione generica dell’architettura sarà fortissima.

Aggiungo un elemento che complica ulteriormente. Il diritto alla cancellazione è costruito sull’idea che esista qualcosa da cancellare. Se il sistema non ha mai archiviato la proposizione su di me, ma è in grado di riprodurla su richiesta, non c’è niente da eliminare, e nemmeno niente che sia rimasto. Cancellare uno stato è possibile. Cancellare una capacità, no.

Apple aveva già spostato il confine

Chi ha guardato Private Cloud Compute quando è stato presentato ha visto la stessa frontiera arrivare da un’altra direzione.

Apple ha stabilito cinque requisiti per PCC, e vale la pena leggerli come un documento di ingegneria politica più che di sicurezza. I dati personali devono essere usati esclusivamente per soddisfare la richiesta e non devono essere disponibili a nessuno che non sia l’utente, nemmeno al personale Apple, né conservati, compreso attraverso il logging o il debug. Le garanzie devono poter essere imposte per via tecnica, il che significa che tutti i componenti devono poter essere vincolati e analizzati. Non devono esistere interfacce privilegiate che permettano al personale operativo di aggirare le garanzie. Un attaccante non deve poter colpire una persona specifica senza tentare di compromettere l’intero sistema. E i ricercatori di sicurezza devono poter verificare che le garanzie corrispondano alle promesse pubbliche.

La conseguenza tecnica più eloquente è quella che di solito viene citata di sfuggita: i nodi PCC non includono shell remote né meccanismi di debug interattivo, e il sistema non contiene nemmeno un meccanismo di logging general-purpose. Possono uscire dal nodo soltanto log e metriche predefiniti, strutturati e sottoposti ad audit.

Fermiamoci un attimo su questa frase, perché contiene l’intera novità. Apple non ha promesso di non guardare. Ha rimosso gli strumenti con cui normalmente si guarda, e ha reso l’insieme delle cose che possono uscire dal nodo una lista chiusa, decisa in anticipo e verificabile.

Il confine di fiducia si è spostato. Prima dovevo fidarmi dell’amministratore di sistema che prometteva di non leggere. Adesso mi fido di un’architettura che stabilisce quali computazioni sono ammesse e quali informazioni possono attraversare il perimetro. È una promessa molto più forte di qualunque privacy policy, perché è falsificabile.

OpenAI, con un’architettura diversa e per un problema diverso, sta esplorando la stessa frontiera concettuale: dentro il confine si calcola, fuori dal confine esce una lista chiusa di segnali.

La privacy, in questa forma, smette di essere una promessa e diventa una proprietà del sistema. E se diventa una proprietà del sistema diventa anche verificabile, negoziabile, certificabile. Per chi lavora sulla compliance come architettura è una notizia enorme, e per una volta è una buona notizia.

Con una conseguenza che nessuno ha ancora affrontato bene: la lista di ciò che può uscire dall’enclave è il vero documento di governance di tutta l’architettura, ed è la parte di cui parliamo meno.

Dalla riservatezza alla calcolabilità

La sicurezza informatica ha sempre parlato di confidenzialità: un soggetto non autorizzato non deve poter leggere il dato. È una proprietà chiara, definita su un oggetto.

Con i sistemi che calcolano dentro un confine chiuso serve una proprietà più sottile, definita non sull’oggetto ma sulle operazioni: un soggetto non autorizzato non deve poter ottenere determinate computazioni sul dato.

Possedere una cartella clinica e possedere un oracolo a cui posso fare domande sulla cartella clinica non sono la stessa cosa. Ma i risultati possono somigliarsi molto più di quanto ci convenga ammettere.

Se non posso scaricare la tabella degli stipendi aziendali ma posso interrogare un sistema chiedendo se una certa persona guadagni più di 80.000 euro, poi più di 90.000, poi più di 95.000, dopo qualche domanda ho ricostruito una parte significativa dell’informazione senza avere mai ricevuto un solo record. È il vecchio problema del controllo statistico della divulgazione, quello che ha prodotto la privacy differenziale, e i modelli linguistici lo rendono immensamente più grave: perché l’interrogazione non deve più essere numerica, perché non serve conoscere lo schema del database e perché il numero di domande sensate che si possono porre non è più enumerabile in anticipo.

La proprietà da governare, allora, non è soltanto l’accesso. È la calcolabilità: quali funzioni possono essere calcolate su quei dati, con quale precisione, quante volte, con quali output, per conto di chi.

È una domanda che quasi nessuna checklist di compliance pone oggi, e che qualunque architetto di sistemi riconosce immediatamente come la domanda giusta.

La finalità applicata a ciò che si può sapere

Qui il GDPR torna sorprendentemente contemporaneo, perché il principio che regge meglio l’urto è anche uno dei più antichi: la limitazione della finalità.

I dati si raccolgono per uno scopo. Il problema è che un foundation model è precisamente una macchina capace di riutilizzare lo stesso input per un numero enorme di finalità diverse, e di farlo senza che nessuno lo abbia programmato per quello.

Una conversazione fornita per assistenza clienti può tecnicamente servire a inferire il sentiment. Il sentiment può diventare propensione all’abbandono. La propensione può diventare priorità commerciale. La stessa conversazione può suggerire vulnerabilità economica, e la vulnerabilità economica è il genere di informazione su cui si costruiscono prezzi diversi per persone diverse. Nessuno di questi passaggi richiede una nuova raccolta di dati, e la capacità tecnica esiste anche quando l’organizzazione non ha nessuna intenzione di usarla.

Ne segue che la privacy by design deve spostare il proprio oggetto. Non più soltanto impedire che i dati finiscano nel sistema sbagliato, ma impedire che computazioni non autorizzate vengano eseguite dentro il sistema giusto.

Chiamiamola, con prudenza, minimizzazione delle inferenze. Non è una categoria autonoma del GDPR e non serve inventarla come tale. È un requisito architetturale che discende dalla combinazione di principi già esistenti, e ha il pregio di essere una domanda che si può porre in fase di progettazione: quali inferenze sono strettamente necessarie?

Un assistente per prenotazioni sanitarie ha bisogno della specialità richiesta, della disponibilità e dell’identità necessaria a completare la prenotazione. Dalla conversazione può dedurre lo stato d’ansia della persona, la sua condizione economica, la gravità percepita del problema, la probabilità che disdica. Non dovrebbe farlo, e la differenza pratica è tutta qui: non basta non usare quelle inferenze. Determinati classificatori, output, layer di persistenza e strumenti dovrebbero essere inaccessibili alla funzione applicativa, non semplicemente disattivati da una policy che qualcuno può cambiare in un pomeriggio.

Chi pensa che questa sia una fantasia regolatoria dovrebbe rileggere l’articolo 5 dell’AI Act, applicabile dal 2 febbraio 2025. Vieta i sistemi che inferiscono le emozioni di una persona sul luogo di lavoro e negli istituti di istruzione a partire da dati biometrici, salve ristrette eccezioni mediche e di sicurezza. E vieta la categorizzazione biometrica che deduce razza, opinioni politiche, appartenenza sindacale, convinzioni religiose o filosofiche, vita sessuale o orientamento sessuale.

Sono due divieti che non riguardano la raccolta. Riguardano che cosa è lecito dedurre, e valgono a prescindere da come i dati siano arrivati lì e da quanto a lungo restino. Il legislatore europeo ha già scritto, in un solo articolo, la prima norma che vieta inferenze determinate chiamandole per nome. Alla stessa conclusione la Corte di giustizia era arrivata per via interpretativa; qui è testo. Ha scelto il perimetro più stretto possibile, e ha fatto bene, perché vietare in generale l’inferenza renderebbe inutilizzabile buona parte dell’intelligenza artificiale. Ma il precedente concettuale esiste.

La domanda giusta, allora, non è se un’inferenza sia vietata. È: questa inferenza era necessaria, prevedibile e legittima rispetto alla finalità per cui il dato è stato fornito? È la limitazione della finalità applicata allo spazio delle conoscenze producibili.

Non è essere riconosciuti, è essere classificati

Si potrebbe pensare che il problema si dissolva togliendo l’identità. È un’illusione confortevole e va smontata.

Un sistema può non sapere chi sono e sapere abbastanza per trattarmi diversamente. Un algoritmo pubblicitario non ha bisogno del mio nome se possiede un identificatore pseudonimo agganciato a un profilo sufficientemente preciso. Un agente può non conoscere la mia identità anagrafica e concludere che appartengo a una categoria di rischio, modificando il servizio di conseguenza: risposte più caute, un limite più basso, una richiesta di verifica in più, un prezzo diverso.

L’anonimato risponde alla domanda: sanno chi sono? La privacy inferenziale risponde a un’altra: che cosa possono decidere che io sia?

C’è poi un’ultima asimmetria temporale che rende la retention una metrica insufficiente. Il dato può vivere duecento millisecondi. La conseguenza può durare anni.

La conversazione non viene conservata. Durante l’elaborazione genera uno score. Lo score modifica una decisione. La decisione entra nel CRM, nel sistema di ticketing, nel fascicolo, nella cronologia del rapporto. Il prompt è sparito nel momento previsto dal contratto. La sua conseguenza è diventata storia istituzionale, e nessuno potrà più risalire a come ci è arrivata.

Se disegniamo quella catena, il dato più sensibile dell’intero processo non è il primo elemento. È il secondo.

Safety e privacy tirano in direzioni opposte

Torniamo a OpenAI, perché il conflitto che sta provando a risolvere è genuino e non va addebitato all’azienda come una colpa.

Più i modelli diventano capaci, più chi li costruisce ha bisogno di accorgersi quando qualcuno sta tentando di usarli per fare del male. Per accorgersene deve osservare comportamenti. Ma più osserva, più accumula informazione sulle persone. La sicurezza spinge verso il monitoraggio, la protezione dei dati verso la minimizzazione, ed è una tensione che non si scioglie con le buone intenzioni di nessuna delle due parti.

La risposta interessante non è scegliere fra privacy e safety. È trasformare la scelta in un problema architetturale: eseguire una parte del monitoraggio dentro un confine in cui il fornitore non riceve il contenuto, e far uscire da quel confine soltanto ciò che serve alla funzione di sicurezza. È la stessa logica delle secure enclave, del confidential computing, del private information retrieval e in generale delle privacy-enhancing technologies. Non eliminano il compromesso: ne cambiano la forma, e una forma diversa a volte è tutto quello che serve.

C’è un dettaglio dell’annuncio che merita più attenzione di quanta ne stia ricevendo, ed è chi riceve l’allarme. Nel disegno di OpenAI il segnale ristretto arriva all’azienda, il cliente investiga sui propri sistemi, e semmai decide di condividere materiale. Non è soltanto una scelta di privacy. È una riallocazione della responsabilità: il fornitore tiene la classificazione, il cliente tiene l’enforcement. Chi compra questi servizi farebbe bene ad accorgersene prima della firma, perché significa che una parte del lavoro di sicurezza che pensava di aver comprato resta sua.

Non vedere non significa non decidere

Adesso il contrappeso, senza il quale tutto quello che ho scritto finora diventa un argomento di vendita.

È facilissimo trasformare queste architetture in una nuova generazione di privacy washing, e sarà tentato di farlo anche chi le ha costruite in buona fede, perché la frase è troppo bella per non essere usata: noi non vediamo mai i vostri dati.

Può essere letteralmente vero. E può essere irrilevante rispetto a ciò che sta succedendo alla persona. Se il sistema può classificare, filtrare, rifiutare, limitare, segnalare o modificare un servizio in funzione di quello che ha dedotto, l’azienda continua a esercitare un potere sostanziale su quella persona. Il fatto che nessun essere umano abbia letto la frase non riduce di un grammo l’effetto della categoria che ne è uscita.

La domanda non può quindi fermarsi alla confidenzialità. Deve arrivare a: quali effetti può produrre l’inferenza?

Un sistema privacy-preserving che discrimina resta discriminatorio. Un sistema crittograficamente ineccepibile che deduce erroneamente una condizione sensibile resta un problema, e per chi lo subisce è esattamente lo stesso problema di prima. Una secure enclave protegge il dato dagli amministratori. Non protegge la persona dalla funzione eseguita dentro l’enclave.

È la distinzione che tiene insieme le due metà del problema: la sicurezza del trattamento non coincide con la sua legittimità.

Immaginiamo la macchina perfetta. Nessuno può osservarne gli input, nessuno può alterarne il codice, nessuno può estrarne i dati. E la macchina prende decisioni ingiuste. La sua perfezione crittografica non risolve niente, e anzi rende la contestazione più difficile, perché ogni richiesta di guardare dentro incontrerà una risposta tecnicamente ineccepibile: guardare dentro è precisamente ciò che il sistema è stato progettato per impedire.

La privacy dei prossimi anni dovrà quindi tenere insieme due proprietà che trattiamo separatamente perché tirano in direzioni opposte. Confidenzialità degli input, che richiede opacità. Responsabilità sulle inferenze, che richiede trasparenza. Dobbiamo impedire a soggetti non autorizzati di vedere il dato, e contemporaneamente sapere quali inferenze vengono prodotte, con quale finalità e con quali conseguenze. È una tensione formidabile e non conosco nessuno che l’abbia risolta.

Vale anche per il trasferimento di fiducia che queste architetture comportano, e che va detto con onestà. Prima dovevo fidarmi dell’amministratore. Adesso devo fidarmi dell’hardware, dell’attestazione, del codice, della catena di fornitura, della funzione eseguita, della correttezza dell’output e della policy che stabilisce che cosa può uscire. La fiducia non è sparita. Si è distribuita su una superficie più larga e, questa è la parte buona, su una superficie che si può ispezionare.

Dal diagramma dei dati al diagramma delle inferenze

Da qui viene la parte utile per chi lavora, ed è un cambio di forma prima che di contenuto.

Ho scritto ad aprile che la DPIA è un genere, non un modulo, cioè una forma di scrittura con una struttura riconoscibile e non un formulario da riempire. Se è un genere, allora può evolvere, e per i sistemi AI deve.

Una DPIA per un sistema di intelligenza artificiale non può fermarsi a descrivere categorie di dati, base giuridica, destinatari, tempi di conservazione, subresponsabili e trasferimenti internazionali. Sono tutte cose necessarie e tutte costruite intorno all’idea che il rischio abiti in un archivio.

Deve cominciare a modellare il flusso delle inferenze. Sull’input: chi può leggerlo, dove viene decifrato, quanto sopravvive. Sulle rappresentazioni: se vengono creati embedding, se persistono, se sono collegabili a una persona, il che è tutt’altro che scontato visto che un embedding non è né un dato grezzo né un’inferenza dichiarata. Sull’inferenza: quali classificazioni vengono prodotte, quali sono necessarie alla finalità dichiarata, quali costituiscono dati personali e quali toccano categorie particolari. Sull’azione: se l’inferenza modifica il comportamento del sistema, se produce una decisione, se viene mostrata a una persona. E infine sulla conservazione, ma alla fine e non all’inizio: quale parte della catena sopravvive alla richiesta.

Dal diagramma di flusso dei dati al diagramma di flusso delle inferenze. Non è un esercizio accademico: è l’unico modo per accorgersi che il rischio di un sistema può stare interamente in un elemento che nessun modello di DPIA oggi in circolazione chiede di descrivere.

Ne segue anche un vendor assessment diverso, ed è la parte immediatamente spendibile per chi compra software. La domanda classica, usate i nostri dati per addestrare il modello, resta necessaria e non è più sufficiente.

Vanno aggiunte almeno tre famiglie di domande. Dove viene eseguita l’inferenza e chi può accedere all’input durante l’elaborazione, che è una domanda sull’architettura e non sulle intenzioni. Quali dati vengono registrati, quali rappresentazioni derivate persistono e per quanto, e se sono associabili a un’identità. E infine quali classificazioni automatiche vengono prodotte, quali segnali possono lasciare il confine di elaborazione, se alimentano decisioni o attività di enforcement, e con quale meccanismo una persona può contestare un’inferenza sbagliata.

L’ultima è quella che quasi nessun contratto oggi prevede, ed è quella su cui, se le sentenze degli ultimi tre anni indicano una direzione, si litigherà.

Dire genericamente «non conserviamo i dati» diventa ambiguo se non abbiamo definito che cosa consideriamo un dato. Input grezzo, rappresentazioni derivate, inferenze, classificazioni di sicurezza, telemetria, log leggibili da un umano, output, stato persistente: sono otto cose diverse, possono avere otto destini diversi, e in quasi tutti i contratti che ho letto ne vengono nominate due.

Il secondo territorio

C’è un ultimo posto in cui questa distinzione cambia il quadro, ed è la sovranità digitale.

Parliamo continuamente di sovranità sul dato: dove è conservato, in quale giurisdizione, su quale cloud, gestito da quale società. Sono domande indispensabili e ho passato mesi a scrivere che non bastano, perché la sovranità non abita nel data center.

Facciamo l’esperimento. Tutti i dati di un ospedale europeo restano fisicamente in Europa, dentro un ambiente di confidential computing gestito da un fornitore europeo. Un modello americano viene eseguito lì dentro. Gli input non lasciano mai il territorio, il fornitore del modello non può leggerli, l’attestazione è verificabile e il registro delle computazioni ammesse è pubblico.

Abbiamo raggiunto la sovranità? Sul dato, plausibilmente sì. Sulla logica che trasforma quel dato in una categoria clinica e quella categoria in una priorità di lista d’attesa, non necessariamente.

Perché restano aperte cinque domande che nessuna localizzazione risolve: chi controlla il modello, chi stabilisce le categorie che il modello può produrre, chi può aggiornare la funzione e con quale preavviso, chi verifica che le inferenze siano corrette su una popolazione europea, e chi decide che cosa può uscire dal confine.

Chiamiamola sovranità sulle inferenze, e mettiamola accanto a quella sui dati invece che al suo posto. Negli ultimi anni abbiamo costruito un’intera politica tecnologica europea intorno alla localizzazione, al controllo e alla disponibilità del dato, e non era sbagliato. L’intelligenza artificiale aggiunge un secondo territorio, che è quello della produzione del giudizio.

Un modello riceve fatti e produce interpretazioni. Riceve segnali e produce categorie. Riceve storia e produce previsione. È lì che una parte crescente del potere digitale verrà esercitata, e quel potere può esistere anche quando nessun essere umano ha mai visto il dato originale.

Non conta soltanto dove vive il dato. Conta dove nasce il giudizio.

Quello che non abbiamo mai detto

Qualcuno, arrivato fin qui, potrebbe obiettare che stia costruendo un problema troppo astratto, e che tutto questo sia semplicemente il GDPR esistente applicato con più precisione.

In buona parte avrebbe ragione, e conviene concederlo fino in fondo perché è la posizione più solida di tutte. Non serve un nuovo diritto alla privacy. Non serve un GDPR per le inferenze. Limitazione della finalità, minimizzazione, esattezza, trasparenza, necessità, disciplina della profilazione e delle decisioni automatizzate, privacy by design: gli strumenti ci sono, e le sentenze che ho citato dimostrano che funzionano meglio di quanto pensassimo. Chi invoca una nuova legge di solito sta chiedendo, senza saperlo, di ricominciare da capo una discussione che l’Europa ha già vinto.

La lacuna probabilmente non è normativa. È architetturale.

Continuiamo a progettare compliance e sistemi informativi intorno ai database, mentre il valore informativo si è spostato dentro computazioni che durano duecento millisecondi e non lasciano niente dietro di sé. Continuiamo a chiedere dove stanno i dati a sistemi il cui rischio principale è che cosa sanno dedurre. Il problema non è scrivere una nuova legge. È aggiornare che cosa consideriamo una superficie di trattamento.

Torno al dipendente delle 23 e 40.

Per anni abbiamo pensato alla privacy con la metafora della porta. I nostri dati stanno in una stanza, e la questione è decidere chi ha la chiave. La crittografia ha reso la porta più resistente. La minimizzazione ha provato a mettere nella stanza meno cose. Il GDPR ha stabilito chi potesse entrare, per quanto tempo e per quale motivo. Sono conquiste vere e non vanno svendute per moda.

L’intelligenza artificiale mette nella stanza una macchina. Possiamo chiudere la porta perfettamente e non fare entrare nessuno. Possiamo distruggere tutto ciò che c’era dentro qualche millisecondo dopo, e possiamo dimostrarlo. Ma prima di farlo possiamo chiedere alla macchina che si trova all’interno di dirci che cosa ha capito.

E quello che esce può essere più importante di tutto ciò che avevamo cercato di proteggere.

Questo non rende inutili le conquiste della privacy tradizionale. Le rende insufficienti se le interpretiamo in modo puramente materiale, come se il rischio fosse fatto di file.

La privacy del mondo dei database proteggeva soprattutto ciò che avevamo rivelato. La privacy dell’intelligenza artificiale dovrà proteggere anche ciò che una macchina può dedurre senza che glielo abbiamo mai detto. È un passaggio dal possesso del dato al governo della conoscenza, e cambia chi deve rispondere di che cosa.

Il dipendente ha chiesto come funziona un congedo. Il sistema, nel mezzo secondo in cui la sua frase è esistita, ha stabilito una probabilità su una condizione che lui non aveva dichiarato, e a nessuno è stato chiesto se quella probabilità servisse a qualcosa.

Non l’ha letta nessuno. Non è stata conservata. Non addestrerà niente.

E adesso è la sola cosa che resta di quella conversazione.

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →