L’AI espone i dati mentre li usa: come proteggerli anche durante il calcolo

Sanità, finanza, giustizia e Pubblica Amministrazione lavorano ogni giorno con informazioni di enorme valore per tutta la società, essendo dati importanti e delicati. In questi settori l’introduzione dell’Intelligenza Artificiale nei processi elaborativi introduce una tensione concreta fra nuove opportunità di efficienza e i nuovi rischi e minacce di sicurezza che esse introducono.

Perché l’IA espone i dati sensibili durante l’elaborazione

I grandi modelli linguistici (gli LLM, cioè le macchine capaci di capire e scrivere testi come fa ChatGPT) e i sistemi di calcolo automatico di dati richiedono e lavorano al meglio con grandi di informazione, di massima qualità, in termini di precisione e ricchezza di dettagli. Queste informazioni servono sia per la fase di training del modello che anche quando il modello integra informazioni esterne tramite il sistema RAG (Retrieval-Augmented Generation, ovvero il metodo con cui l’IA consulta un archivio esterno prima di rispondere).

Questi dati sono però soggetti a vincoli normativi e di legge, evolutesi negli ultimi anni. Il GDPR disciplina la protezione dei dati personali. L’EU AI Act (Regolamento UE 2024/1689) [1] introduce obblighi specifici sulla gestione e sul controllo dei dati nei sistemi di IA. Accesso, uso, trasferimento e verifica dei patrimoni informativi sensibili devono quindi seguire regole precise, essere documentate e verificabili da enti di verifica esterni accreditati.

Storicamente la sicurezza informatica protegge il dato soprattutto in due momenti:

Protezione dei dati a riposo e in transito

• I dati a riposo (Data at Rest): vengono cifrati (cioè trasformati in un codice segreto illeggibile senza una chiave) quando restano su dischi, database e archivi. Tra gli algoritmi più diffusi per la crittografia simmetrica c’è AES-256: le linee guida NIST SP 800-111 [2] definiscono il riferimento tecnico per questo scenario.
• I dati mentre viaggiano sulla rete (Data in Transit): vengono protetti durante il trasferimento da un computer all’altro. Il protocollo TLS 1.3 (RFC 8446) [3] che usiamo ogni giorno per navigare sul web copre questa fase con un livello di maturità ormai consolidato.

Il rischio del Data in Use

Una nuova criticità emerge quando il dato viene elaborato dai modelli IA. Per essere elaborata in modo automatico l’informazione deve essere prima decifrata. Poi passa “in chiaro” nella RAM o nei registri di CPU e GPU delle architetture hardware. Questa è la fase del Data in Use, cioè il momento in cui il dato viene usato. Nello stesso tempo è anche il punto più esposto ad un uso abusivo.

Infatti, durante l’elaborazione, il dato resta leggibile nella memoria dell’infrastruttura. Una qualunque vulnerabilità software o hardware, o un attacco ad un amministratore, che dovesse presentarsi rende possibile compromettere la confidenzialità del dato. Lo stesso scenario di si presenterebbe a fronte di un malware che riesca ad infiltrarsi sull’hypervisor (il programma che gestisce le macchine virtuali su un server), sulla macchina virtuale o un container, per un’operazione di memory dumping (la copia forzata del contenuto della memoria) o per un attacco su canale collaterale.

Questi rischi sono sempre stati presenti nelle moderne architetture dei calcolatori. Ma i sistemi AI introducono nuovi scenari di rischio, ampliando la superfice di attacco. Con tecniche come i Model Inversion Attacks [4] (attacchi di “inversione del modello”, in cui l’attaccante fa molte domande all’IA per indovinare a ritroso quali dati sono stati usati per addestrarla) e i Membership Inference Attacks [5] (attacchi per capire se un dato specifico, come la cartella clinica di un paziente, fa parte dell’archivio dell’IA), un attaccante può ricostruire porzioni dei dataset di training o dedurre informazioni sensibili dal comportamento del modello, violando la riservatezza del dato elaborato.

Confidential Computing per proteggere i dati in uso

Per ridurre questa esposizione è quindi necessario introdurre un nuovo paradigma di computazione che offra maggiori garanzie di sicurezza. Uno dei più promettenti è il Confidential Computing (il “calcolo riservato”, ossia una tecnologia che unisce ingegneria dei sistemi e crittografia applicata). Il principio, richiamato anche dal Confidential Computing Consortium (CCC) della Linux Foundation, è semplice: il dato va protetto anche mentre viene elaborato, non solo quando è archiviato o trasferito. Per farlo, i calcoli vengono eseguiti dentro ambienti isolati dall’hardware, i Trusted Execution Environment (TEE) [6] (veri e propri “ambienti di esecuzione protetti” scritti direttamente nel silicio del chip).

In questo modello la logica Zero Trust (cioè “fiducia zero”: il principio secondo cui nessun software è sicuro a prescindere, oggi molto richiamata in diversi ambiti) scende fino al processore. L’ambiente software che ospita la macchina dove elabora il modello AI non viene più trattato come affidabile per definizione. Invece questo nuovo approccio tende a isolare dal perimetro di fiducia il Sistema Operativo, l’hypervisor, gli amministratori dell’infrastruttura quando si tratta di avere la possibilità di leggere i dati in chiaro durante l’elaborazione.

Un TEE può essere un’enclave applicativa o una Confidential VM (una macchina virtuale riservata, cioè un computer interamente simulato e blindato). In entrambi i casi riserva una parte della memoria fisica che protegge con cifratura hardware. La differenza rispetto a un’architettura tradizionale è evidente: il contenuto di quella memoria non è leggibile dal sistema operativo host, dall’hypervisor né da un utente con privilegi di amministrator sul server cloud o infrastruttura elaborativa di riferimento.

In questo modo prima di inviare dati riservati a un’enclave occorre verificarne l’integrità. A questo serve l’attestazione remota (Remote Attestation), definita nello standard IETF RATS – RFC 9334 [10]. L’hardware genera una prova crittografica firmata. Una terza parte può così verificare l’autenticità del processore e del codice caricato. Le chiavi di decifratura vengono rilasciate da un sistema KMS (Key Management Service, il programma che custodisce le chiavi segrete) solo dopo questa verifica. Da quel momento, il trattamento avviene esclusivamente dentro l’ambiente protetto.

Privacy-Preserving AI e crittografia per i dati sensibili

I TEE proteggono l’ambiente di calcolo. La Privacy-Preserving AI (l’IA che rispetta la riservatezza), invece, lavora sul dato. L’obiettivo è usare dataset sensibili senza esporre il contenuto originale. Per farlo questa tecnica integra crittografia, statistica e modelli distribuiti.

Non tutte le tecniche crittografiche che sono state sviluppate dalla ricerca scientifica negli anni possono risolvere completamente il problema in oggetto. Infatti, mentre alcune proteggono il calcolo, altre limitano la ricostruzione dei dati. Oppure, ancora altre. evitano lo spostamento degli archivi da una forma in chiaro ad una crittografata e viceversa. In molti casi funzionano meglio se usate insieme, in base al tipo di dato e al rischio da gestire.

Tecniche crittografiche e modelli distribuiti

• Crittografia Omomorfica Completa (FHE): Con la Fully Homomorphic Encryption, descritta nella forma completa da Craig Gentry nel 2009 [11], i calcoli vengono eseguiti direttamente su dati cifrati. Il dato non torna mai in chiaro durante l’elaborazione. In uno scenario di IA, il client invia al server un’informazione già cifrata. Il server applica il modello sui ciphertext (i testi in codice cifrato) e restituisce un risultato ancora cifrato. Solo il client, che possiede la chiave privata, legge l’output finale. Per anni l’FHE è rimasta troppo pesante per molti usi reali. Schemi come CKKS e TFHE, insieme a librerie open source come OpenFHE [12], stanno però rendendo l’inferenza (cioè l’uso del modello per fare previsioni o dare risposte) cifrata più praticabile, soprattutto in sanità e nei servizi finanziari.
• Federated Learning e Differential Privacy: Quando i dati restano distribuiti tra ospedali, filiali bancarie o enti pubblici, a titolo esemplificativo, accentrare le varie basi dati diventa rischioso. A volte è anche vietato da norme di privacy. Il Federated Learning (l’apprendimento federato), introdotto da McMahan e colleghi in Google [13], sposta il modello verso i dati. Ogni nodo addestra una copia locale e invia al server centrale solo gli aggiornamenti matematici, cioè i gradienti (le correzioni numeriche per migliorare il modello). Poiché anche i gradienti possono rivelare informazioni, il Federated Learning viene affiancato alla Differential Privacy (la privacy differenziale), sviluppata da Cynthia Dwork [14], che aggiunge rumore statistico prima dell’aggregazione. Così il contributo del singolo individuo resta non identificabile, mentre il modello conserva utilità statistica.
• Secure Multi-Party Computation (SMPC): La Secure Multi-Party Computation (il calcolo condiviso sicuro) nasce dal Secret Sharing (la suddivisione matematica di un segreto), a partire dagli studi di Adi Shamir [15]. Più organizzazioni possono calcolare insieme una funzione comune senza rivelare le proprie informazioni. I dati sensibili vengono divisi in porzioni protette da tecniche crittografiche specifiche; da sole non significano nulla. Il calcolo realizzato dall’algoritmo scelto opportunatamente combina queste porzioni tra i nodi, mentre l’informazione originaria resta fuori dalla possibilità di accesso intellegibile dei singoli partecipanti,

Dati sensibili, GDPR e EU AI Act: il quadro normativo

Confidential Computing e Privacy-Preserving AI si collocano dentro un quadro normativo europeo sempre più preciso e puntuale. Le indicazioni dell’European Data Protection Board (EDPB) [16] (il Comitato Europeo per la Protezione dei Dati) vanno nella stessa direzione: proteggere i dati sensibili lungo tutto il trattamento, non solo in alcuni passaggi.

Come adottare Confidential Computing nelle organizzazioni

Per portare questi principi in produzione serve un percorso ordinato. I dirigenti responsabili della tecnologia (CTO) e della sicurezza (CISO) devono partire da una valutazione puntuale dei carichi di lavoro atteso, scegliere l’infrastruttura adatta e misurare l’impatto sulle prestazioni.

Classificazione dei carichi di lavoro e threat model

1. Classificazione dei carichi di lavoro e definizione del threat model: il primo passo è analizzare il threat model (la mappa dei rischi e degli attacchi potenziali) e separare bene training e inference. L’inferenza su modelli sensibili può già usare TEE su GPU in scenari vicini alla produzione [9]. Quando invece l’addestramento coinvolge più enti, l’approccio più solido resta il Federated Learning, rafforzato da meccanismi di Differential Privacy [13, 14].

2. Selezione dell’infrastruttura hardware: la scelta parte dalle istanze Confidential disponibili nei cloud provider o nell’infrastruttura locale. Va verificato il supporto alle architetture richieste, in particolare AMD SEV-SNP e Intel TDX [7, 8] (le tecnologie hardware di AMD e Intel per cifrare la memoria nei microchip).

3. Integrazione dell’attestazione remota: nelle pipeline di CI/CD (Continuous Integration e Continuous Deployment, le catene automatiche di aggiornamento del software), ogni rilascio di un modello AI deve includere la verifica automatica del certificato di attestazione secondo il modello IETF RATS [10]. Il Key Management Service (KMS) rilascia le chiavi solo dopo questa verifica.

4. Valutazione del trade-off prestazionale: il Confidential Computing richiede di valutare il trade-off fra il bilanciamento tra sicurezza e le prestazioni attese. Sulle architetture moderne l’overhead di queste tecniche crittografiche resta generalmente contenuto, tra il 2% e l’8% [6]. Tecniche più pesanti, come la FHE, richiedono invece test specifici sulla latenza (i tempi di risposta) e sugli effetti nei processi aziendali [12].

Un modello Zero Trust per l’IA sui dati sensibili

L’evoluzione dell’Intelligenza Artificiale impone di ripensare la sicurezza alla base dei sistemi con cui i modelli vengono progettati, addestrati e messi in produzione. Quando i dataset diventano più sensibili e i modelli più complessi, non basta più affidarsi a clausole contrattuali, controlli perimetrali o misure di sicurezza concentrate solo sull’infrastruttura esterna. La protezione deve accompagnare il dato lungo tutto il suo ciclo di vita, soprattutto nel momento in cui viene elaborato.

L’integrazione tra Confidential Computing e Privacy-Preserving AI offre una possibile risposta concreta a questa esigenza: da un lato protegge l’ambiente di esecuzione, dall’altro riduce l’esposizione del dato attraverso garanzie crittografiche e statistiche. Ne deriva un modello di sicurezza più adatto all’uso dei dati critici nei sistemi di IA, capace di conciliare innovazione, conformità normativa, sovranità digitale e tutela effettiva della privacy.

Bibliografia e fonti di riferimento

17. US Congress (2018). Clarifying Lawful Overseas Use of Data Act (CLOUD Act). H.R. 4943, 115th Congress.

1. Unione Europea (2024). Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, che stabilisce regole armonizzate sull’intelligenza artificiale (EU AI Act). Gazzetta Ufficiale dell’Unione Europea.

2. National Institute of Standards and Technology (NIST) (2007). Guide to Storage Encryption Technologies for End User Devices. NIST Special Publication 800-111.

3. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446.

4. Fredrikson, M., Jha, S., & Ristenpart, T. (2015). Model Inversion Attacks that Exploit Confidence Information and Basic Countermeasures. Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS ’15), pp. 1322–1333.

5. Shokri, R., Stronati, M., Song, C., & Shmatikov, V. (2017). Membership Inference Attacks Against Machine Learning Models. IEEE Symposium on Security and Privacy (SP), pp. 3–18.

6. Confidential Computing Consortium (CCC) (2021). Confidential Computing: Hardware-Based Trusted Execution for Applications and Data. White Paper, The Linux Foundation.

7. Intel Corporation (2023). Intel Trust Domain Extensions (Intel TDX) Architecture Specification. Intel Technical Documentation.

8. Advanced Micro Devices (AMD) (2020). SEV-SNP: Strengthening VM Isolation with Integrity Protection and More. AMD White Paper.

9. NVIDIA Corporation (2023). NVIDIA Confidential Computing Architecture on Hopper GPUs. NVIDIA Technical White Paper.

10. Birkholz, H., Thaler, D., Tschofenig, H., & Nedos, P. (2023). Remote Attestation Procedures (RATS) Architecture. IETF RFC 9334.

11. Gentry, C. (2009). Fully Homomorphic Encryption Using Ideal Lattices. Proceedings of the 41st Annual ACM Symposium on Theory of Computing (STOC ’09), pp. 169–178.

12. Badawi, A. A., et al. (OpenFHE Consortium) (2022). OpenFHE: Open-Source Fully Homomorphic Encryption Library. WAHC ’22: Proceedings of the 10th Workshop on Encrypted Computing & Applied Homomorphic Cryptography, pp. 55–63.

13. McMahan, B., Moore, E., Ramage, D., Hampson, S., & y Arcas, B. A. (2017). Communication-Efficient Learning of Deep Networks from Decentralized Data. Artificial Intelligence and Statistics (AISTATS), PMLR 54, pp. 1273–1282.

14. Dwork, C. (2006). Differential Privacy. Proceedings of the 33rd International Colloquium on Automata, Languages and Programming (ICALP ’06), Springer, pp. 1–12.

15. Shamir, A. (1979). How to Share a Secret. Communications of the ACM, 22(11), pp. 612–613.

16. European Data Protection Board (EDPB) (2020). Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data. EDPB Guidelines.