Che cos'è il machine learning che preserva la privacy?

Un team decide di eseguire un modello linguistico sui propri server invece di chiamare un'API esterna. La motivazione è la privacy: tenere i dati sensibili in casa e non consegnarli mai a terzi. L'istinto è corretto e il controllo che ne deriva è reale, ma è anche incompleto. Un modello addestrato su dati privati può essere indotto a rivelare se il record di una persona specifica fosse nel suo set di addestramento. Aggiornamenti federati che non trasportano mai dati grezzi possono essere invertiti fino a ricostruire le immagini che li hanno prodotti. Un modello di grandi dimensioni può memorizzare ed emettere porzioni di ciò su cui è stato addestrato. I dati sono rimasti a casa, e il modello ha comunque perso informazioni.

È proprio questo divario, tra sembrare privato ed esserlo in modo dimostrabile, che il machine learning che preserva la privacy affronta. La pipeline di machine learning standard richiede che i dati grezzi siano accessibili all'infrastruttura di addestramento, il che si scontra con la regolamentazione sulla privacy, con i requisiti di sovranità del dato e con partner che i loro dataset non li condividono affatto. Il machine learning che preserva la privacy è la famiglia di tecniche che risolve questo scontro.

La distinzione utile passa tra tecniche che riducono lo spostamento dei dati, tecniche che limitano ciò che gli output possono rivelare e tecniche che mantengono i dati riservati durante il calcolo. L'auto-hosting si affianca a questi controlli, non li sostituisce.

La versione breve

• Il machine learning che preserva la privacy (PPML) è una categoria ombrello, non un singolo metodo. Questo articolo si concentra su quattro approcci principali: apprendimento federato, privacy differenziale, crittografia omomorfica e calcolo multipartitico sicuro. Anche altre architetture che rafforzano la privacy, inclusi i trusted execution environment, possono comparire nei sistemi PPML.
• Da solo, l'apprendimento federato non fornisce alcuna garanzia formale di privacy. Mantiene i dati grezzi alla fonte, ma gli aggiornamenti di gradiente condivisi a volte possono essere invertiti fino a ricostruire record di addestramento. La privacy differenziale è un modo comune per aggiungere un limite formale alla fuga di informazioni.
• La forza della privacy differenziale viene di solito riassunta da epsilon. La garanzia dipende anche da delta, dall'unità protetta e dal metodo di privacy accounting. Una garanzia formale con parametri deboli resta una garanzia sulla carta e teatro nella pratica.
• La crittografia omomorfica è reale ed è lenta. Calcolare su dati cifrati funziona, ma l'overhead oggi lo confina a modelli più semplici, a inferenza tollerante alla latenza e a flussi sperimentali di fine-tuning, non all'addestramento ordinario di modelli grandi né al pretraining completo.
• Ospitare un modello in proprio è localizzazione dei dati, non PPML. Tenere i dati su un'infrastruttura che controlli stabilisce chi può raggiungerli. Non stabilisce cosa il modello stesso possa rivelare.

Nota sul perimetro: questo è un articolo concettuale, non una guida all'implementazione. Non approfondisce il setup delle librerie, la scelta di epsilon, la conformità normativa o il fine-tuning privato degli LLM. Qui l'obiettivo è la mappa. Le indicazioni passo passo spettano a guide di implementazione dedicate.

Come il machine learning che preserva la privacy protegge i dati

Machine learning che preserva la privacy è un termine ombrello per i metodi che riducono, limitano o vincolano formalmente l'esposizione di informazioni durante l'addestramento dei modelli, l'inferenza e l'analisi collaborativa. Questo articolo si concentra su quattro approcci principali: apprendimento federato, privacy differenziale, crittografia omomorfica e calcolo multipartitico sicuro. Proteggono asset diversi sotto modelli di minaccia diversi, quindi non vanno trattati come garanzie intercambiabili.

Il problema è semplice: le pipeline di ML standard presuppongono di solito che il processo di addestramento possa accedere ai record grezzi, mentre la regolamentazione sulla privacy, i requisiti di sovranità del dato e gli accordi con i partner spesso impediscono proprio quell'accesso. Le quattro famiglie rispondono a questo vincolo in modi diversi: portare il calcolo ai dati invece di portare i dati al calcolo (apprendimento federato), aggiungere rumore calibrato perché gli output rivelino meno su una singola persona (privacy differenziale), calcolare su dati che restano cifrati (crittografia omomorfica), oppure lasciare che più parti calcolino insieme un risultato senza esporsi a vicenda gli input grezzi (calcolo multipartitico sicuro).

Il rischio di fondo è enunciato senza giri di parole in la guida di Google sull'IA responsabile: i modelli di machine learning possono ricordare o rivelare aspetti dei dati a cui sono stati esposti, e il lavoro sulla privacy esiste proprio per mettere delle protezioni attorno a questo. Il PPML affronta quel rischio ed è distinto dalla semplice anonimizzazione, per ragioni che la prossima sezione rende concrete.

Perché l'anonimizzazione non basta?

I dati anonimizzati possono comunque essere re-identificati. Togliere nomi e identificatori ovvi da un dataset riduce l'esposizione evidente, ma non garantisce la privacy nel momento in cui quei dati possono essere incrociati con informazioni esterne. È la debolezza ricorrente degli approcci di de-identificazione come la k-anonimità: sotto ipotesi specifiche possono ridurre l'identificabilità, ma non forniscono le garanzie formali disponibili con tecniche come la privacy differenziale o i metodi PPML crittografici.

Questa distinzione pratica conta per chiunque si sia sentito dire "l'abbiamo anonimizzato, quindi siamo a posto". L'anonimizzazione è un'affermazione su un dataset all'interno di un contesto e di un modello di minaccia specifici. Un attacco di linkage non ha bisogno di rompere la cifratura né di aggirare i controlli di accesso. Gli serve solo un altro dataset che si sovrapponga al tuo. Il punto è enunciato direttamente in la guida del NIST sulla de-identificazione, che rileva come i dati de-identificati possano comunque essere re-identificati collegandoli a dataset ausiliari.

La privacy differenziale offre qualcosa che la de-identificazione ordinaria non offre: un limite matematico su quanto i dati di un individuo possano influenzare un risultato pubblicato, sotto un'unità di privacy e un modello di minaccia definiti. La crittografia omomorfica e l'SMPC forniscono tipi diversi di riservatezza crittografica, mentre l'apprendimento federato cambia soprattutto dove i dati vengono elaborati. Queste garanzie sono imparentate, ma non sono la stessa cosa.

Come funziona l'apprendimento federato, e perché da solo non basta?

Nell'apprendimento federato un modello globale viene inviato a dispositivi o server locali, si addestra sui dati che stanno lì e restituisce al centro soltanto gli aggiornamenti dei parametri. I dati grezzi non si spostano mai. È uno schema davvero utile ed è in produzione su larga scala. E non è, di per sé, una garanzia di privacy.

Il meccanismo è dal modello ai dati, non dai dati al modello. Il deployment di Gboard di Google esegue oltre 30 modelli linguistici direttamente sul dispositivo, in più di 7 lingue e in più di 15 paesi, addestrandosi su testo che non lascia mai il telefono. È l'apprendimento federato che funziona come promesso: la tastiera migliora senza che Google raccolga ciò che hai digitato.

Il problema è ciò che viaggia dentro gli aggiornamenti. I gradienti portano informazione sui dati che li hanno prodotti, e quell'informazione può essere recuperata. Zhu, Liu e Han lo hanno dimostrato in Deep Leakage from Gradients (NeurIPS 2019), dimostrando attacchi di inversione del gradiente che recuperano esempi di addestramento privati dagli aggiornamenti di modello condivisi, nei loro esperimenti con ricostruzione delle immagini accurata al pixel e corrispondenza a livello di token per il testo. L'apprendimento federato ha ridotto lo spostamento dei dati. Non ha eliminato il rischio di fuga.

Se l'obiettivo è limitare ciò che la partecipazione può rivelare, la privacy differenziale è un'aggiunta comune. L'aggregazione sicura affronta un rischio diverso, nascondendo i singoli aggiornamenti dei client al server che coordina. Gboard combina apprendimento federato e privacy differenziale formale invece di affidarsi alla sola federazione.

Nota: L'apprendimento federato viene spesso descritto come "privato" perché i dati grezzi restano alla fonte. Quella descrizione è fuorviante. Senza protezioni aggiuntive, gli aggiornamenti federati possono portare segnale sufficiente a ricostruire record di addestramento. Il DP-FL aggiunge una garanzia formale di privacy differenziale invece di affidarsi alla sola federazione. La federazione da sola è una scelta su come si trattano i dati, non una prova di privacy.

Che cos'è la privacy differenziale, e che cosa controlla davvero epsilon?

La privacy differenziale è una definizione matematica che limita quanto un'analisi possa cambiare quando si aggiunge o si toglie un'unità di privacy. Molti meccanismi ottengono quella garanzia aggiungendo casualità calibrata. Epsilon è un parametro visibile, ma una garanzia significativa dipende anche dall'unità di privacy, dalla variante di DP e da eventuali parametri aggiuntivi come delta, oltre che da composizione, accounting e dettagli implementativi.

Epsilon viene descritto come il budget di privacy in il glossario di NVIDIA: valori più bassi significano privacy più forte ma più rumore, valori più alti preservano l'accuratezza al prezzo di garanzie più deboli. Un modo comune di applicare la privacy differenziale durante l'addestramento di deep learning è il DP-SGD, discesa del gradiente stocastica differenzialmente privata: taglia il gradiente di ogni campione a una dimensione limitata, aggiungi rumore gaussiano calibrato, poi aggrega. Il taglio limita quanto un singolo esempio possa influenzare il modello. Il rumore oscura l'influenza che rimane.

Quel budget si consuma. Il meccanismo è descritto in la documentazione di Tumult Analytics sui budget di privacy: ogni query su un dataset protetto spende parte del budget di privacy. Come quelle spese si sommino è teoria standard della privacy differenziale, esposta in The Algorithmic Foundations of Differential Privacy di Dwork e Roth: con la composizione di base, k query ciascuna con parametro epsilon si sommano in una perdita di privacy totale pari a k per epsilon, mentre i teoremi di composizione avanzata danno limiti più stretti. Non hai domande illimitate. Hai un budget, e lo spendi.

Sono quindi le scelte dei parametri a decidere se la garanzia significhi qualcosa nella pratica. Una critica sottoposta a revisione paritaria degli approcci alla privacy nel machine learning sostiene che l'inquadramento matematico può conferire una "patina di oggettività" poi usata per ripulire l'immagine di un progetto. Imposta i parametri di privacy abbastanza deboli e la garanzia può diventare quasi priva di senso, mentre un team può comunque affermare di aver soddisfatto la privacy differenziale. La garanzia è reale. La sua forza pratica è una scelta di progettazione.

Nota: Una garanzia di privacy differenziale è significativa solo quando conosci i parametri di privacy e l'unità che proteggono. Un epsilon molto alto, un delta lasco o un accounting poco chiaro possono far sì che una garanzia tecnicamente valida offra ben poca protezione pratica. Leggere "questo sistema usa la privacy differenziale" non dice quasi nulla di per sé: il significato lo portano i parametri di privacy, su cosa sono stati misurati e come si compongono. I deployment concreti lo rendono tangibile. Google riporta un epsilon pari a 1 a livello utente per il suo sistema Provably Private Insights, ma è la scelta di un deployment per un caso d'uso, non un numero da copiare.

Come fa la crittografia omomorfica a calcolare su dati che non decifra mai?

La crittografia completamente omomorfica (FHE) permette a un server di eseguire calcoli direttamente su dati cifrati e restituire un risultato cifrato che solo il proprietario dei dati può decifrare. Il server fa il lavoro senza mai vedere il testo in chiaro. È uno degli strumenti di privacy più potenti del settore, ma il compromesso si paga in prestazioni.

L'analogia utile è una glove box chiusa con guanti incorporati: un operatore può infilarci le mani e manipolare ciò che c'è dentro senza mai aprire la scatola né estrarne il contenuto. Il proprietario dei dati ha l'unica chiave. Il calcolo avviene sul contenuto sigillato, e solo il proprietario può aprire la scatola per leggere il risultato. È ciò che l'FHE fa matematicamente: operare sul testo cifrato in modo che decifrare l'output dia la stessa risposta che avrebbe dato il calcolo sul testo in chiaro.

Il problema è il costo. Concrete ML, di Zama, converte modelli scikit-learn e PyTorch in equivalenti compatibili con FHE senza costringere l'utente a lavorare direttamente con primitive crittografiche, e la sua versione v1.9 è arrivata il 10 aprile 2025. Ma i benchmark del progetto stesso mostrano l'overhead: una rete di classificazione di immagini CIFAR10 gira sotto FHE a circa 4 minuti per immagine. Va bene per una parte dell'inferenza tollerante alla latenza, per modelli più semplici e per fine-tuning cifrato sperimentale. Non è ancora una strada praticabile verso il pretraining completo di modelli grandi né verso i normali carichi di addestramento. Oggi l'FHE è uno strumento di precisione per un insieme ristretto di lavori, non un livello di privacy generalista.

Che cos'è il calcolo multipartitico sicuro nel machine learning?

Il calcolo multipartitico sicuro (SMPC) permette a più parti di calcolare insieme una funzione sui loro input privati combinati senza che nessuna parte veda i dati grezzi delle altre. L'input di ciascuna parte resta segreto. Diventa noto solo il risultato concordato. L'SMPC può essere costruito con tecniche come la condivisione di segreti, i circuiti garbled, il trasferimento ignaro e loro combinazioni. Nei protocolli di condivisione di segreti i valori privati vengono divisi in quote, così che una singola quota non riveli l'input. I protocolli a circuiti garbled funzionano diversamente: codificano un calcolo perché le parti possano valutarlo senza rivelare i propri input privati.

Il caso d'uso naturale è la collaborazione tra organizzazioni. Diversi ospedali vogliono addestrare un modello sui loro dati clinici combinati, ma nessuno può legalmente condividere le cartelle con gli altri. L'SMPC permette loro di calcolare il modello congiunto come se i dati fossero messi insieme, mentre le cartelle di ciascun ospedale restano sigillate al suo interno. L'overhead dell'SMPC dipende molto dal protocollo, dal modello di sicurezza, dalle condizioni di rete, dal numero di parti e dalla funzione valutata. Molti protocolli sono intensivi in comunicazione, quindi le prestazioni vanno misurate sulla collaborazione specifica invece che classificate genericamente rispetto a privacy differenziale o FHE. Proprio questo schema per il machine learning in sanità è trattato in una rassegna del 2025 su WIREs Computational Statistics.

Un modello di machine learning può far trapelare i suoi dati di addestramento?

Sì. Un modello addestrato può tradire i suoi dati di addestramento in diversi modi distinti: l'inferenza di appartenenza rivela se un record specifico fosse nel set di addestramento, l'inversione del modello e la fuga tramite gradienti possono ricostruire record, e i modelli linguistici di grandi dimensioni possono memorizzare ed emettere alla lettera porzioni dei loro dati di addestramento. Non sono ipotesi. Sono attacchi dimostrati, e sono la ragione per cui esistono le tecniche viste sopra.

Il risultato fondativo è l'inferenza di appartenenza. Shokri e colleghi, in Membership Inference Attacks Against Machine Learning Models (IEEE S&P 2017), hanno mostrato che un attaccante che osserva il comportamento predittivo di un modello può determinare se un dato record facesse parte del suo set di addestramento. Sembra astratto finché il set di addestramento non è "pazienti con una certa diagnosi", perché a quel punto è proprio l'appartenenza il fatto sensibile. L'inversione del modello e gli attacchi di fuga tramite gradienti visti prima estendono la cosa da "questo record c'era?" a "ricostruisci il record".

La frontiera sono i modelli linguistici di grandi dimensioni, ed è lì che i framework PPML più datati si adattano peggio. La ricerca su gli LLM che emettono dati di addestramento documenta che i modelli grandi memorizzano porzioni del proprio corpus di addestramento e possono essere indotti a riprodurlo, con attacchi di estrazione che recuperano dati di addestramento letterali e quasi letterali. Il DP-SGD si può applicare al fine-tuning privato, ma il costo in accuratezza e calcolo alla scala dei modelli grandi è pesante, ed è in parte il motivo per cui il workshop PPML 2026 di Apple ha dedicato un intero filone ai foundation model e alla privacy. Le difese che funzionano pulitamente per un classificatore a regressione logistica non si trasferiscono gratis a un modello con miliardi di parametri.

PPML e IA self-hosted: cosa ti dà l'inferenza locale e cosa no

Ospitare un modello in proprio tiene i tuoi dati su un'infrastruttura che controlli. È una vittoria reale sul piano del controllo degli accessi e della localizzazione dei dati: i dati non viaggiano verso terzi, e sei tu a decidere chi può raggiungere la macchina su cui gira. Non è però machine learning che preserva la privacy. L'inferenza locale non fa nulla, da sola, contro l'inferenza di appartenenza sul modello, e non impedisce a un modello di rivelare ciò che ha memorizzato.

I due risolvono metà diverse del problema, e confonderli è un errore comune in questo ambito. La localizzazione dei dati governa chi può raggiungere i dati: una questione di perimetro, a cui rispondono dove stanno i byte e chi ha le chiavi della stanza. Il PPML governa cosa il modello stesso possa rivelare, una questione di fuga di informazioni a cui rispondono le quattro tecniche viste sopra. Far girare un modello sul proprio server è una risposta forte alla prima domanda e nessuna risposta alla seconda.

Se la domanda che stai valutando è se far girare il modello per conto tuo, il lato costi di quella decisione è un'analisi a sé: vedi Self-hosting di un LLM open-weight vs. un'API: la vera matematica dei costi.

Per chi lavora su piattaforma o infrastruttura, la lettura operativa è questa: "gira sul nostro server" può soddisfare alcuni requisiti di localizzazione dei dati e di controllo degli accessi, ma di per sé non vincola ciò che il modello può rivelare. Se il modello o i suoi output vengono mai condivisi, tra team, con partner o dentro un prodotto, il perimetro che hai costruito attorno all'hardware non esce dalla porta insieme al modello. Le scelte architetturali che spostano davvero la garanzia sono quelle PPML: privacy differenziale sugli output che pubblichi, DP-FL per addestrare su sedi che non puoi centralizzare, calcolo basato su cifratura dove i dati non possono essere esposti nemmeno alla tua infrastruttura. Il deployment Provably Private Insights di Google è istruttivo proprio perché combina più controlli, privacy differenziale, trusted execution environment e analytics federata confidenziale, invece di affidarsi a uno solo. La localizzazione fa parte di un'architettura vera. Non ne è l'intero.

Quando usare quale tecnica PPML?

La logica di scelta segue il vincolo, non la moda. Usa l'apprendimento federato quando i dati non possono essere centralizzati. Usa la privacy differenziale quando ti serve una garanzia formale su ciò che il modello rivela. Usa la crittografia omomorfica quando il calcolo deve avvenire su dati mai decifrati e la latenza lo consente. Usa il calcolo multipartitico sicuro quando più parti devono calcolare insieme senza condividere i propri input.

Le tecniche si compongono anche tra loro. Il DP-FL è l'esempio più chiaro: scegli i controlli in base alle garanzie di cui il sistema ha bisogno, invece di forzare il problema dentro un'unica tecnica.

I compromessi a colpo d'occhio:

Queste caratterizzazioni sono tratte da una rassegna PPML orientata all'IoT del marzo 2026, dai benchmark di Concrete ML di Zama e dalla letteratura sulla re-identificazione.

La tabella è solo un punto di partenza. I sistemi reali combinano spesso più tecniche: un problema di addestramento tra sedi che richiede anche una garanzia formale di privacy è di solito un problema DP-FL, non una scelta tra apprendimento federato e privacy differenziale. Chi vuole strutturare la decisione in modo più rigoroso può lavorare sul framework strutturato di supporto alle decisioni per sviluppatori , pubblicato alla fine del 2024.

Sul fronte degli strumenti, TensorFlow Federated offre un framework open source per l'apprendimento federato e per calcoli su dati decentralizzati. TensorFlow Privacy fornisce utilità per l'addestramento differenzialmente privato, le librerie Differential Privacy di Google coprono statistica e aggregazione differenzialmente private, e Concrete ML fornisce la strada dell'FHE. PySyft oggi si concentra più ampiamente sulla data science remota che preserva la privacy, dove i calcoli girano su dati che restano al proprietario e solo i risultati approvati vengono condivisi. Questi sono i nomi e quello che fanno. Il setup spetta a guide di implementazione dedicate, non a questo testo. La lezione ricorrente è che la matematica può funzionare mentre l'implementazione fallisce lo stesso. La garanzia conta solo se il sistema è progettato attorno al modello di minaccia giusto e i parametri di privacy corrispondono al rischio che si vuole proteggere.

Domande frequenti

Che cosa significa PPML?

Machine learning che preserva la privacy è un termine ombrello per i metodi che riducono, limitano o vincolano formalmente l'esposizione di informazioni durante il machine learning. Gli approcci principali includono apprendimento federato, privacy differenziale, crittografia omomorfica e calcolo multipartitico sicuro, ma proteggono asset diversi e forniscono tipi diversi di garanzia.

L'apprendimento federato basta a proteggere la privacy?

No. L'apprendimento federato mantiene i dati grezzi alla fonte, ma gli aggiornamenti di parametri che condivide possono essere invertiti fino a ricostruire record di addestramento tramite attacchi di inversione del gradiente. Da solo non fornisce alcuna garanzia formale di privacy. La privacy differenziale può aggiungere un limite formale alla fuga di informazioni, dando la combinazione che di solito si chiama DP-FL.

Quale valore di epsilon dovrei usare per la privacy differenziale?

Non esiste un valore universale. Epsilon è uno dei parametri principali nel compromesso tra privacy e accuratezza: valori più bassi in genere significano privacy più forte e più rumore, mentre valori più alti in genere significano privacy più debole e meno rumore. L'impostazione giusta dipende dalla sensibilità dei dati e dal rischio che puoi accettare. Non c'è una soglia universale che renda un valore di epsilon "sicuro". Valuta epsilon insieme all'unità di privacy, alla variante di DP e a eventuali parametri aggiuntivi come delta, al metodo di composizione e al modello di minaccia del sistema.

Qual è la differenza tra PPML e anonimizzazione?

L'anonimizzazione rimuove gli identificatori da un dataset, ma i record anonimizzati possono essere re-identificati collegandoli a dati ausiliari provenienti da altre fonti. Alcune tecniche PPML forniscono garanzie formali che l'anonimizzazione ordinaria non dà. La privacy differenziale può limitare quanto i dati di un individuo influenzino un risultato pubblicato, mentre FHE e SMPC forniscono forme diverse di riservatezza crittografica.

Si possono estrarre dati di addestramento da un modello di machine learning?

Sì. Gli attacchi di inferenza di appartenenza rivelano se un record specifico fosse nel set di addestramento, l'inversione del modello e la fuga tramite gradienti possono ricostruire record, e i modelli linguistici di grandi dimensioni possono memorizzare ed emettere alla lettera dati di addestramento. Sono attacchi dimostrati e documentati nella letteratura di sicurezza, non rischi ipotetici.

Ospitare un modello in proprio garantisce la privacy dei dati?

No. L'auto-hosting tiene i dati su un'infrastruttura che controlli, il che è controllo degli accessi e localizzazione dei dati, una vittoria reale per governare chi può raggiungerli. Non è machine learning che preserva la privacy e non ferma né l'inferenza di appartenenza né le fughe dovute alla memorizzazione. Si sposa bene con le tecniche PPML, ma non le sostituisce.

Quali strumenti open source esistono per il machine learning che preserva la privacy?

Diversi strumenti open source coprono parti diverse del PPML. TensorFlow Federated supporta l'apprendimento federato e i calcoli su dati decentralizzati, TensorFlow Privacy fornisce utilità per l'addestramento differenzialmente privato, e Concrete ML copre il machine learning con FHE. PySyft oggi si concentra sulla data science remota che preserva la privacy, dove i calcoli girano su dati controllati dal proprietario e solo i risultati approvati vengono condivisi.