Oltre Turing
Un ospedale universitario di Berlino, uno di Milano, uno di Barcellona, uno di Praga condividono un problema clinico comune - la stratificazione precoce del rischio di scompenso cardiaco in pazienti seguiti da wearable - e non possono condividere il dato che permetterebbe di risolverlo. La ragione non è tecnica: è normativa. Il Regolamento UE 2016/679 (GDPR) articolo 9 qualifica il dato sanitario come categoria particolare, il Regolamento UE 2017/745 (MDR) impone un'evidenza clinica specifica al contesto d'uso del dispositivo, il Regolamento UE 2024/1689 (AI Act) - pienamente applicabile ai sistemi ad alto rischio dal 2 agosto 2026 - sovrappone requisiti di data governance verificabili e tracciabili. Trasferire quattro dataset da quattro giurisdizioni verso un data centre centralizzato per addestrare un modello è, oggi, una via ingegneristicamente possibile e giuridicamente in via di chiusura.
La domanda ingegneristica che si pone è precisa. Se il dato non può migrare, deve migrare il modello. Se il modello migra, la rete diventa il luogo del calcolo, e il nodo - l'ospedale, il dispositivo indossabile, il gateway domestico - diventa un'unità computazionale sovrana con obblighi giuridici propri. Il paradigma dell'apprendimento federato (McMahan et al., 2017), articolato per contesti sanitari (Rieke et al., 2020) e maturato nel triennio della validazione clinica multi-istituzionale (Kaissis et al., 2020), risponde a questa domanda. Ma non la risolve. La sposta.
Questo articolo attraversa la rete e il nodo - dall'architettura FedAvg baseline alle sue estensioni per popolazioni non identicamente distribuite, dalla topologia hub-and-spoke agli scenari peer-to-peer, dalla privacy-preservazione stratificata alla nuova geometria delle responsabilità che l'AI Act sovrappone alla catena - e mostra come la maturità di un sistema federato in tele-salute non si misuri nella cifra decimale dell'accuratezza aggregata, ma nella capacità di ciascun nodo di mantenere sovranità computazionale entro una rete che esiste per servire, non per assorbire, l'unità clinica.
§1. Il problema della centralizzazione e la sovranità del dato clinico
Il paradigma classico dell'apprendimento automatico presuppone un dataset centralizzato. I dati, generati in luoghi eterogenei - cartelle cliniche elettroniche, dispositivi indossabili, sistemi di imaging - vengono raccolti in un data lake unico e sottoposti a modellazione. L'assunzione ha reso possibile due decenni di progresso del deep learning medicale (Esteva et al., 2019), ma poggia su una premessa che il quadro giuridico europeo ha progressivamente restretto: l'accessibilità e la poolability del dato sanitario.
L'articolo 9 del GDPR qualifica il dato sanitario come categoria particolare, ammessa al trattamento solo su basi giuridiche rinforzate (consenso esplicito, finalità di sanità pubblica, ricerca clinica autorizzata). L'articolo 62 del MDR impone un'indagine clinica specifica al contesto d'uso, che vincola l'evidenza al setting di deployment. Il Regolamento UE 2022/868 (Data Governance Act) e il Regolamento UE 2023/2854 (Data Act) introducono un'infrastruttura di data intermediation e di data spaces settoriali - European Health Data Space (EHDS) in fase di implementazione - che formalizza un modello di condivisione strutturato ma segmentato per uso primario e secondario del dato. L'AI Act articolo 10, infine, impone che i dataset di addestramento, validazione e test siano rilevanti, sufficientemente rappresentativi, esenti da errori nella misura del possibile, e completi rispetto alla finalità perseguita - un requisito che, in ambito clinico, è insoddisfacibile con dataset monogenici.
La convergenza di questi vincoli produce un problema ingegneristico ben definito. Il modello statistico deve essere addestrato su dati che, per ragioni tanto epistemiche quanto giuridiche, non possono essere aggregati. La letteratura ingegneristica della tele-salute ha esplorato negli ultimi anni piattaforme collaborative distribuite proprio per rispondere a questa geometria vincolata (Fabbrizio et al., 2023; Fucarino, Fabbrizio et al., 2024): il problema non è privo di soluzioni tecniche, ma la soluzione tecnica deve essere pensata come parte integrante dell'architettura, non come strato accessorio di conformità.
La sovranità del dato clinico - che il GDPR fonda sul concetto di titolarità del trattamento e che il Data Governance Act estende alla nozione di data holder - non è un ostacolo che l'ingegneria deve aggirare: è la condizione al contorno che l'ingegneria deve incorporare nel disegno del sistema. L'apprendimento federato nasce esattamente da questa incorporazione.
§2. L'architettura federata: dalla media dei gradienti alla topologia della fiducia
L'algoritmo di riferimento - Federated Averaging o FedAvg (McMahan et al., 2017) - articola il calcolo in cicli sincronizzati di comunicazione. In ciascun ciclo, un server di aggregazione distribuisce lo stato corrente del modello - un vettore di parametri θ_t - a un sottoinsieme S_t di nodi partecipanti. Ciascun nodo k esegue K passi di stochastic gradient descent sul proprio dataset locale D_k, producendo un aggiornamento locale θ_t^k. Il server aggrega gli aggiornamenti mediante media pesata sulla numerosità dei dataset locali: θ_{t+1} = Σ_k (|D_k| / |D|) θ_t^k. Il dato grezzo non lascia mai il nodo. Il traffico di rete si riduce, in ordine di grandezza, ai parametri del modello - decine di megabyte per architetture ragionevoli - invece che ai dataset - potenzialmente terabyte.
La convergenza teorica di FedAvg è garantita sotto ipotesi di dati identicamente e indipendentemente distribuiti (i.i.d.) attraverso i nodi. In sanità, questa ipotesi è quasi sempre violata. La distribuzione dei pazienti in un ospedale universitario tedesco non coincide con la distribuzione in un centro spoke italiano; i protocolli di acquisizione dei segnali variano; l'apparato di imaging cambia. Il fenomeno è noto in letteratura come client drift e produce degradi prestazionali documentati fino al 30-40% rispetto al baseline i.i.d. (Zhao et al., 2018). Le estensioni proposte - FedProx con termine di regolarizzazione prossimale (Li et al., 2020), SCAFFOLD con correzione della varianza (Karimireddy et al., 2020), FedBN con batch normalization locale (Li et al., 2021) - costituiscono, oggi, lo strumentario ingegneristico per operare in regime non-i.i.d. clinico.
La topologia della rete federata è la seconda scelta architetturale fondamentale. Nel modello hub-and-spoke, un server centrale orchestra i cicli di comunicazione: architettura semplice, latenza contenuta, ma singolo punto di fallimento e concentrazione di fiducia sul coordinatore. Nel modello peer-to-peer (Roy et al., 2019), i nodi comunicano direttamente in schemi gossip senza coordinatore centrale: architettura resiliente ma con convergenza più lenta e maggiore complessità di consensus. Nel modello gerarchico, livelli intermedi di aggregazione - un edge server regionale che aggrega ospedali di un'area, un server nazionale che aggrega le regioni - riproducono la geografia amministrativa dell'assistenza sanitaria e, contemporaneamente, la geografia giuridica delle competenze territoriali.
La scelta topologica non è neutrale rispetto alla governance. Un'architettura hub-and-spoke con server collocato in una giurisdizione extra-UE trasforma silenziosamente il trattamento in un trasferimento transfrontaliero regolato dagli articoli 44-49 del GDPR. Un'architettura peer-to-peer distribuita su nodi in Stati membri diversi diluisce la titolarità del trattamento in modi che il diritto europeo non ha ancora completamente cartografato. La topologia della rete, in un sistema federato sanitario, è essa stessa un artefatto normativo.
§3. Il nodo: edge computing, TinyML e il calcolo situato
Il nodo, nell'apprendimento federato sanitario, non è un'astrazione. È un artefatto ingegneristico con caratteristiche fisiche precise: un microcontrollore ARM Cortex-M4/M7 in un cinturino wearable, un system-on-chip ESP32 o nRF52840 in un dispositivo domestico, un gateway Raspberry Pi in una stanza di degenza, un server locale in un ambulatorio. La banda di memoria disponibile spazia dalle centinaia di kilobyte del microcontrollore ai gigabyte del server locale; il budget energetico spazia dai milliwatt del dispositivo indossabile alle decine di watt del gateway. La disciplina che studia il trade-off fra questi vincoli è, oggi, il TinyML (Banbury et al., 2020; Warden & Situnayake, 2019).
La quantizzazione post-training - la conversione dei pesi del modello da rappresentazione floating-point a 32 bit verso rappresentazioni intere a 8 bit (INT8) o inferiori - riduce la memoria del modello di un fattore 4 e la latenza di inferenza di un fattore 2-3 con perdite di accuratezza spesso inferiori all'1% (Jacob et al., 2018). Le tecniche di pruning strutturato eliminano fino al 90% dei parametri non informativi (Han et al., 2016) preservando la prestazione entro margini clinicamente accettabili. La distillazione della conoscenza (Hinton et al., 2015) trasferisce l'informazione da un modello teacher complesso a un modello student compatto adatto all'inferenza on-device.
Il concetto operativo che unifica queste tecniche è quello di continuum edge-cloud. Non tutti gli stadi del calcolo devono avvenire nello stesso luogo. Un wearable può eseguire pre-processing e feature extraction locali, delegando l'inferenza pesante al gateway domestico; il gateway può eseguire inferenza in tempo reale, delegando l'addestramento incrementale al server ospedaliero; il server ospedaliero può eseguire aggiornamento locale, partecipando ai cicli federati con server regionali. Il partitioning del calcolo lungo il continuum non è più una scelta di ottimizzazione - è una specifica architetturale che interseca sovranità del dato, energia disponibile, latenza tollerabile e requisiti di sorveglianza umana ai sensi dell'articolo 14 dell'AI Act.
L'esperienza operativa maturata su piattaforme di tele-esercizio distribuite (Fucarino, Zimatore, Fabbrizio et al., 2024) ha mostrato che l'efficacia clinica di un sistema di monitoraggio remoto cresce non con la potenza computazionale del server centrale ma con l'affidabilità del nodo periferico. Un dispositivo wearable che perde connettività per otto ore in una fascia rurale, e che continua a operare in autonomia registrando localmente e sincronizzando alla prima disponibilità di rete, è un dispositivo più utile - e più conforme - di un sistema centralizzato che si degrada silenziosamente al variare della qualità di rete.
§4. La privacy come stratificazione tecnica e la matematica della fiducia
L'apprendimento federato mantiene i dati grezzi sul nodo, ma non è, in sé, privacy-preservante. Gli aggiornamenti del modello scambiati con il server di aggregazione portano informazione sui dati locali, ricostruibile in forme parziali attraverso attacchi documentati - gradient leakage (Zhu et al., 2019), membership inference (Shokri et al., 2017), model inversion (Fredrikson et al., 2015). La protezione della privacy in un sistema federato è, di conseguenza, una stratificazione tecnica specifica, ciascuno strato con un costo computazionale e una garanzia formale distinti.
La Differential Privacy (Dwork et al., 2006; Abadi et al., 2016) fornisce una garanzia matematica quantitativa. Un meccanismo di addestramento è (ε, δ)-differentially private se la probabilità di ottenere un particolare risultato varia al massimo di un fattore e^ε con probabilità 1-δ, quando un singolo record viene aggiunto o rimosso dal dataset. In pratica, si inietta rumore gaussiano calibrato ai gradienti prima dell'invio: valori tipici in ambito medicale - ε compreso fra 1 e 10, δ pari a 10^-5 - producono degrado di accuratezza del 3-15% in cambio di garanzia formale contro attacchi di ricostruzione (Kaissis et al., 2020).
La Secure Aggregation (Bonawitz et al., 2017) impiega protocolli di calcolo multiparte per far sì che il server osservi solo la somma degli aggiornamenti, mai un singolo aggiornamento del nodo. La costruzione crittografica si basa su secret sharing e maschere pseudo-casuali; il costo comunicativo cresce come O(N) con il numero di partecipanti. La Homomorphic Encryption - schemi CKKS (Cheon et al., 2017) per operazioni approssimate su numeri reali, schemi BFV/BGV per operazioni intere - consente al server di aggregare gli aggiornamenti direttamente sui dati cifrati, senza mai decifrarli. Il costo computazionale è ancora oggi elevato (rallentamento di due-tre ordini di grandezza rispetto al calcolo in chiaro), ma la maturità delle librerie open source - SEAL di Microsoft, HElib di IBM, OpenFHE - la sta portando entro perimetri applicativi crescenti.
Il quarto strato è ambientale: i Trusted Execution Environments - Intel SGX, ARM TrustZone, AMD SEV - creano enclavi hardware in cui il calcolo avviene in aree di memoria isolate anche dal sistema operativo ospite. Attacchi laterali documentati (Chen et al., 2019) hanno mostrato che le enclavi non sono impenetrabili, ma la loro combinazione con Differential Privacy e Secure Aggregation produce architetture di defense-in-depth che rispondono in modo verificabile ai requisiti dell'articolo 15 dell'AI Act sulla cybersecurity dei sistemi ad alto rischio e agli obblighi di sicurezza del Regolamento UE 2022/2555 (NIS2) per gli operatori essenziali del settore sanitario.
La lezione ingegneristica maturata nel triennio delle grandi consortium sanitarie - MELLODDY per il drug discovery pre-competitivo, EXAM per la stratificazione COVID-19 su 20 ospedali (Dayan et al., 2021), le collaborazioni di NVIDIA Clara Federated Learning con reti di centri oncologici - è che nessun singolo strato tecnico è sufficiente. La privacy in un sistema federato sanitario si costruisce come architettura stratificata: Differential Privacy per la garanzia matematica, Secure Aggregation per l'isolamento del server, Trusted Execution per la difesa hardware, e - sopra tutti - governance documentata, audit trail registrato ai sensi dell'articolo 12 dell'AI Act, Data Protection Impact Assessment rinnovato ad ogni evoluzione del modello.
§5. Il resto del nodo: chi risponde nell'architettura distribuita
L'apprendimento federato risolve un problema di ingegneria dei dati e ne apre uno di ingegneria della responsabilità. L'AI Act distingue con precisione i ruoli lungo la catena - provider, deployer, importer, distributor, authorised representative - e attribuisce a ciascuno obblighi specifici (articoli 16-27). Il provider del modello è responsabile della conformità del sistema; il deployer - chi utilizza il sistema nella propria attività professionale, tipicamente l'ospedale - è responsabile del monitoraggio nell'uso, della segnalazione degli incidenti, dell'applicazione delle istruzioni del provider.
In un'architettura federata, la distinzione provider/deployer si complica strutturalmente. Ogni ospedale che partecipa ai cicli di addestramento contribuisce, con i propri gradienti, all'evoluzione del modello: è ancora solo deployer o diventa, in senso sostanziale, co-provider? Il modello aggregato che ritorna al singolo nodo dopo il ciclo di addestramento è ancora lo stesso sistema, o è un sistema modificato che - ai sensi dell'articolo 25 - comporta obblighi documentativi rinnovati? La letteratura giuridica europea sta iniziando a cartografare queste zone (Truby et al., 2022; Malgieri & Comandé, 2017 sul precedente GDPR), ma la geometria delle responsabilità distribuite è ancora un open problem che la prassi degli organismi notificati sta costruendo caso per caso.
La risposta ingegneristica matura, oggi, articola tre strati di documentazione parallela. Il primo - l'accordo di consorzio - formalizza chi partecipa, con quali dati, sotto quali basi giuridiche GDPR, con quale distribuzione delle titolarità del trattamento e delle contitolarità (articolo 26 GDPR). Il secondo - il model card federato (esteso dalla proposta di Mitchell et al., 2019) - documenta l'evoluzione del modello ciclo per ciclo, i partecipanti a ciascun ciclo, le distribuzioni dei dati locali sintetizzate in metriche di eterogeneità (KL divergence, earth mover's distance), le prestazioni pre-e-post aggregazione. Il terzo - l'audit log distribuito, tipicamente realizzato su tecnologia distributed ledger o su archivi immutabili append-only - registra ogni evento di addestramento, ogni aggiornamento del modello, ogni evento di sicurezza in una forma ricostruibile e verificabile.
La sorveglianza umana ai sensi dell'articolo 14 dell'AI Act, in una rete federata, non è una funzione locale. È una funzione della rete. Ciascun deployer mantiene la sorveglianza sul proprio uso locale del modello; il consorzio mantiene sorveglianza sull'evoluzione aggregata; il provider - quando distinto - mantiene sorveglianza sul modello di riferimento distribuito. La stratificazione degli oversight non è ridondanza: è la specifica funzionale che permette al sistema di identificare a quale livello si sia originato un problema, in tempo utile per intervenire.
La rete matura, in questa lettura, è quella in cui ciascun nodo può dire - con supporto tecnico verificabile - "questo aggiornamento non lo accetto", "questo dato non lo condivido", "in questa condizione mi sospendo". La sovranità del nodo non è ostacolo alla rete: è la condizione della sua fiducia. Una rete federata sanitaria che non prevede protocolli espliciti di opt-out selettivo, di model rejection locale, di graceful exit dal consorzio, non è una rete matura - è un'aggregazione fragile in attesa del primo evento di rottura.
Fra la rete e il nodo si dispiega la geometria della sanità digitale europea. La rete garantisce potenza statistica, ampiezza epidemiologica, robustezza al singolo evento locale; il nodo garantisce sovranità del dato, rispetto della titolarità clinica, prossimità al soggetto. Non c'è opposizione fra i due - c'è, semmai, una tensione produttiva che l'ingegneria del sistema deve tenere aperta. Il nodo che non partecipa alla rete si isola in un ottimo locale povero; la rete che assorbe il nodo si trasforma nel monolite centralizzato che l'apprendimento federato era nato per superare.
La riga di codice più importante, in un sistema federato sanitario, è quella che consente al nodo di dire no. Non alla rete come istituzione - al singolo aggiornamento che il nodo, sulla propria evidenza locale, sulla propria popolazione, sulle proprie soglie di confidenza, riconosce come indebitamente estraneo. Un sistema che ha inscritto quella riga di codice nel proprio protocollo è un sistema che ha compreso qualcosa di preciso: la rete esiste per il nodo, e il nodo esiste per il soggetto. Ogni altra configurazione tradisce l'ordine dei fini.