Google Research ha annunciato un sistema di apprendimento federato di nuova generazione costruito su Trusted Execution Environments, e il team sta avanzando un'affermazione che sarebbe stata respinta come irraggiungibile qualche anno fa: garanzie di privacy differenziali centrali verificabili esternamente per l'apprendimento federato, per la prima volta. Il sistema, che viene applicato a Gboard, sostituisce un accordo di lunga data "fidati di noi" con attestazione crittografica e registri pubblici che i revisori esterni possono effettivamente ispezionare. Per una copertura continua sull'apprendimento automatico nel rispetto della privacy, segui i nostri ultimi sviluppi dell'intelligenza artificiale.
Il divario di fiducia nell'apprendimento federato
L’apprendimento federato, introdotto da Google nel 2017, avrebbe dovuto risolvere un problema specifico: come addestrare modelli utili sui dati degli utenti senza raccogliere tali dati a livello centrale. Invece di caricare il comportamento di digitazione non elaborata su un server, i dispositivi calcolano gli aggiornamenti del modello localmente e contribuiscono solo con tali aggiornamenti. L'approccio alimenta silenziosamente una notevole quantità di ciò che gli utenti toccano ogni giorno: previsione della parola successiva e Scrittura intelligente in Gboard, suggerimenti di risposta in Messaggi Google e Selezione intelligente del testo in Android.
Ma l’architettura originale aveva al centro una lacuna di fiducia. I dispositivi caricavano i propri dati per l'aggregazione immediata e gli estranei non avevano modo di verificare che i dati non fossero mai stati registrati, conservati o ispezionati lungo il percorso. Gli utenti dovevano credere alla parola di Google per ciò che accadeva sul lato server. Successivamente, Secure Aggregation ha aggiunto la protezione crittografica in modo che i singoli contributi non potessero essere letti isolatamente, ma quella tecnica non era compatibile con gli algoritmi di privacy differenziale centrale all’avanguardia come la fattorizzazione a matrice DP-FTRL, e lasciava ancora intatto un presupposto: ci si doveva fidare di Google per aggiungere correttamente il rumore della privacy differenziale. Un parametro di rumore mal configurato sarebbe invisibile a tutti tranne che all'azienda che commette l'errore.
Come funziona il nuovo sistema
Il nuovo design attacca direttamente il presupposto della fiducia. Sposta il calcolo del gradiente del client sul server, all'interno di un ambiente di esecuzione affidabile, e quindi rende attestabile la logica del server, in modo che l'operatore non debba più essere considerato attendibile. Un TEE è un'enclave di processore isolata dall'hardware il cui codice in esecuzione può essere verificato crittograficamente da estranei; se l'enclave fa qualcosa di diverso da quanto affermato, l'attestazione si rompe.
Secondo l'annuncio di Google, il sistema coordina quattro componenti principali. Innanzitutto, il caricamento dei dati: i dispositivi crittografano gli esempi di formazione localmente e preautorizzano una policy di accesso che elenca esattamente quali calcoli TEE possono elaborare i dati – e tali policy devono apparire in un registro di trasparenza pubblica. In secondo luogo, un sistema di gestione delle chiavi costruito da TEE che eseguono il protocollo di consenso RAFT rilascia chiavi di decrittazione solo ai carichi di lavoro che corrispondono alla policy pubblicata. In terzo luogo, l'esecuzione del carico di lavoro: un TEE root esegue un ciclo di addestramento Python e delega le sottoattività ai TEE lavoratori, con l'orchestrazione gestita da un sistema chiamato Federated Language, derivato dal framework TensorFlow Federated di Google. Solo i pesi dei modelli differenzialmente privati vengono rilasciati dall'enclave. Quarto, ripristino con tolleranza agli errori: ogni ciclo di formazione salva uno stato di ripristino crittografato con KMS in modo che errori root o di lavoro non distruggano la formazione in corso.
Perché le garanzie possono essere effettivamente verificate
La pretesa di verificabilità si basa su una catena di prove pubbliche piuttosto che su attestazioni aziendali. Le politiche di accesso vengono pubblicate su Rekor, il registro di trasparenza pubblica di Sigstore, in modo che i revisori esterni possano tenere traccia di ogni carico di lavoro del server che i dati di un dispositivo potrebbero eventualmente alimentare. Il KMS e i binari di elaborazione dei dati sono riproducibili in modo riproducibile da codice open source, il che significa che chiunque può compilare il codice sorgente pubblicato e verificare che corrisponda ai binari in esecuzione in produzione.
Le politiche stesse descrivono direttamente il programma di formazione Python, che colma la lacuna più comune nelle architetture della privacy: un divario tra ciò che dice una politica sulla privacy e ciò che fa effettivamente il codice. Per proteggere le architetture dei modelli proprietari, i TEE supportano il sideload della logica serializzata in fase di esecuzione, ma con il rigido vincolo che tutta la logica rilevante per la privacy deve rimanere codificata nel programma attestato. Gli operatori del carico di lavoro, compreso il personale dell'infrastruttura di Google, vedono solo le metriche e i pesi dei modelli differenzialmente privati. I dati crittografati possono essere decrittografati solo per un tempo limitato dopo il caricamento, delimitando la finestra in cui è possibile controllare qualsiasi cosa.
Dalle promesse alle prove
L’importanza del progetto non risiede tanto nei singoli componenti quanto nello spostamento di oneri che produce. Le garanzie sulla privacy nell'apprendimento automatico sono state storicamente inquadrate come promesse supportate da documenti politici, audit interni e reputazione dell'operatore. Questo sistema converte quelle promesse in artefatti – rapporti di attestazione, voci di log di trasparenza, build riproducibili – che uno scettico può verificare senza accedere ai componenti interni di Google.
Segna anche una notevole convergenza di due comunità di ricerca che hanno lavorato per lo più in parallelo. Gli ambienti di esecuzione affidabili e la privacy differenziale risolvono diversi problemi: i TEE limitano chi può elaborare i dati, mentre DP limita ciò che qualsiasi calcolo può trapelare. Combinandoli in un unico programma attestabile, con la stessa generazione di rumore DP all’interno dell’enclave verificata, si affronta la debolezza residua di ciascun approccio isolatamente.
Per ora il sistema è in esecuzione nello stack di Google, alimentando carichi di lavoro di formazione del tipo eseguito da Gboard. Se la privacy verificabile diventerà un’aspettativa competitiva in tutto il settore – come è successo a HTTPS dopo che la registrazione della trasparenza è stata standardizzata per i certificati – dipenderà dal fatto che utenti e regolatori inizieranno a porre ad altri fornitori di intelligenza artificiale la domanda a cui questo sistema è progettato per rispondere: dimostrarlo.
---
Stai al passo con l'intelligenza artificialeRicevi le ultime notizie, analisi e scoperte sull'intelligenza artificiale, tutto in un unico posto.
Leggi altre notizie sull'AI →
