Negli ultimi anni la crittografia omomorfica – spesso indicata anche come homomorphic encryption, fully homomorphic encryption o semplicemente HE/FHE – è passata dall’essere un tema di ricerca di nicchia a una delle tecnologie chiave per abilitare analisi e intelligenza artificiale su dati altamente sensibili, senza mai esporli in chiaro.
Nel seguito utilizzeremo il termine crittografia omomorfica (“CO”) per indicare l’insieme delle tecniche che consentono a un soggetto (tipicamente un cloud provider) di eseguire calcoli su dati cifrati, restituendo un risultato che, una volta decifrato dal titolare dei dati, è equivalente al calcolo che sarebbe stato fatto sui dati in chiaro. Utilizzeremo invece i termini HE/FHE quando è necessario indicare, sempre in ambito CO, i sistemi di fully homomorphic encryption, come infra definiti.
Indice degli argomenti
Evoluzione e scenario attuale della crittografia omomorfica
Tra il 2021 e il 2025 la CO ha visto:
- una maturazione delle librerie e dei tool open source, pensate per sviluppatori non crittografi;
- l’avvio di percorsi di standardizzazione internazionale;
- le prime applicazioni concrete su larga scala in sanità, finanza, marketing, supply chain e cloud; e
- un crescente interesse per l’uso della CO come abilitatore di monetizzazione dei dati, inclusi dati sanitari e altre categorie “ultra-sensibili”, nel rispetto del GDPR.
Dopo una breve introduzione sulla CO esamineremo (1) gli ultimi sviluppi della CO, le innovazioni e le applicazioni più recenti, (2) le applicazioni in ambiti sensibili quali i dati medico-sanitari e politico-etnico-religioso, (3) gli utilizzi nel cloud computing e (4) le potenzialità della CO nel permettere la commercializzazione dei dati (anche sensibili) nel rispetto della normativa privacy. Per “ultimi sviluppi” intendiamo, in particolare, quanto capitato nel quinquennio 2021-2025.
Cosa si intende per crittografia omomorfica oggi
Cos’è (davvero) la crittografia omomorfica? In estrema sintesi, la CO permette di fare calcoli e altre analisi utili senza vedere i dati. Più nel dettaglio, un sistema di CO permette tre operazioni fondamentali:
- il titolare cifra i dati con una chiave pubblica e li invia a un elaboratore esterno (es. cloud);
- il cloud esegue operazioni matematiche direttamente sui cifrati (somma, moltiplicazione, funzioni più complesse), senza poter leggere il dato “in chiaro”; e
- il titolare riceve un risultato ancora cifrato e lo decifra localmente: il valore ottenuto coincide con il risultato del calcolo che sarebbe stato svolto sui dati in chiaro.
La differenza strutturale rispetto alla crittografia tradizionale è che qui non serve mai decrittare lato cloud. Questo riduce drasticamente il rischio di esposizione dovuto a incidenti, insider o compromissione dell’infrastruttura, e rende più semplice l’outsourcing sicuro di elaborazioni complesse su dati sensibili.
Si distingue, in genere, tra:
- schemi parzialmente omomorfici (solo somme o solo prodotti);
- schemi livellati (un numero limitato di operazioni); e
- fully homomorphic encryption – FHE, che consente in principio qualsiasi circuito di calcolo, quindi anche modelli di machine learning complessi[1].
Per anni il problema è stato la performance: tempi di calcolo e risorse richieste erano proibitivi per molti use case reali. Proprio nel periodo 2021-2025 si è visto un netto cambio di passo, grazie a nuove librerie, ottimizzazioni crittografiche e un migliore supporto hardware.
Novità 2021-2025 per la crittografia omomorfica
Nell’ultimo quinquennio sono emerse o maturate diverse librerie pensate per sviluppatori “normali”, cioè non esperti in crittografia, spesso in ottica cloud/AI.
Librerie e toolchain open source
Tra le più conosciute si annoverano:
- Microsoft SEAL, libreria open source molto usata in ambito accademico e industriale, che implementa schemi BFV e CKKS per operazioni su interi e numeri reali[2];
- OpenFHE, nuova libreria open source lanciata nel 2022, erede di progetti come PALISADE e HElib, che punta su efficienza, modularità e sicurezza post-quantum[3]; e
- Concrete e Concrete-ML di Zama, che offrono un compiler per FHE basato su TFHE e strumenti per trasformare automaticamente modelli di machine learning in versioni eseguibili su dati cifrati[4].
Sul fronte toolchain, Google ha annunciato nel 2023 HEIR – Homomorphic Encryption Intermediate Representation, un compilatore open source costruito su MLIR per rendere i programmi FHE portabili tra diversi schemi, librerie e acceleratori hardware[5].
Tali strumenti stanno abbassando significativamente la barriera d’ingresso: oggi un team di sviluppo può integrare la CO in un flusso applicativo senza progettare da zero lo schema cifrario, concentrandosi sugli use case di business e non sulla matematica sottostante.
Standard tecnici internazionali e interoperabilità
Un altro sviluppo cruciale è la standardizzazione. Oltre al lavoro già fatto su homomorphic encryption “classica” (ISO/IEC 18033-6:2019), sono in corso nuovi progetti per la Fully Homomorphic Encryption:
- ISO/IEC 18033-8, parte dedicata agli algoritmi di FHE[6];
- la serie ISO/IEC 28033 in fase di sviluppo, con parti specifiche per varianti BGV/BFV e CGGI (schemi booleani TFHE-like)[7]; e
- il lavoro del consorzio HomomorphicEncryption.org, che organizza incontri periodici (nel 2024 la 7ª riunione a Salt Lake City) per armonizzare parametri di sicurezza, API e best practice[8].
Per imprese e pubbliche amministrazioni (“PA”), questi percorsi sono fondamentali perché:
- facilitano valutazioni di conformità (anche per certificazioni europee dei PETs)[9];
- riducono il rischio di vendor lock-in[10]; e
- consentono di integrare la CO in capitolati e specifiche tecniche con riferimenti normativi chiari.
Performance, rumore e prototipi industriali
Negli ultimi cinque anni la CO è passata da concetto teorico a tecnologia sperimentabile in azienda. Sul piano prestazionale, diversi lavori recenti hanno studiato l’efficienza dei principali schemi e librerie, tra i quali segnaliamo:
- benchmark comparativi tra SEAL, HElib, OpenFHE e Lattigo, con analisi di tempi e risorse per scenari tipici (aggregazioni, inferenza di modelli, ecc.)[11];
- studi empirici sull’uso di SEAL in contesti IoT e cloud[12]; e
- confronti tra diversi schemi (BGV, BFV, CKKS, TFHE, Paillier) per applicazioni sanitarie[13].
Parallelamente, ricerche recenti hanno proposto:
- modelli di multi-key FHE e threshold decryption, che permettono di combinare dati cifrati con chiavi diverse e decriptare il risultato solo con il consenso congiunto di più attori[14]; e
- tecniche per ridurre il rumore accumulato nelle operazioni e migliorare integrità ed efficienza del calcolo crittato, con particolare attenzione all’uso in sanità[15].
Per capire perché le performance stanno migliorando, serve un cenno al concetto di “rumore” nei cifrati. Nel calcolo omomorfico ogni operazione eseguita sul ciphertext (i dati cifrati) introduce una certa quantità di rumore matematico, necessario per garantire la sicurezza dello schema. Il rumore matematico è una piccola componente casuale inserita intenzionalmente nel ciphertext durante la cifratura.
Serve a rendere impossibile, per un attaccante, ricostruire il messaggio originale dai soli dati cifrati, garantendo così la durezza computazionale dello schema (tipicamente basato su problemi di algebra lineare su reticoli, come LWE/RLWE). Questo rumore deriva da scelte casuali effettuate in fase di cifratura e cresce quando si eseguono operazioni omomorfiche. È ineliminabile perché costituisce la base stessa della sicurezza: senza rumore, le relazioni algebriche tra ciphertext e messaggio sarebbero troppo semplici e la cifratura sarebbe facilmente invertibile[16].
Tuttavia, questo rumore cresce man mano che si compongono più operazioni; se supera una soglia critica, il risultato non è più correttamente decifrabile. Per questo gli schemi FHE devono includere tecniche per controllare o “riciclare” il rumore (es. bootstrapping, parametri più ampi, ottimizzazioni aritmetiche). Ridurre il rumore significa poter eseguire più operazioni con meno risorse, ottenere risultati stabili e corretti, migliorare le performance e aumentare la profondità di calcolo disponibile senza dover ricorrere a operazioni costose come il bootstrapping.
Non siamo ancora alla “CO a costo zero”, ma oggi è realistico parlare di:
- analytics batch su dataset cifrati, per tale intendendosi l’esecuzione, in modalità non interattiva e senza vincoli di latenza, di analisi complesse (statistiche, modelli ML leggeri, aggregazioni) direttamente su grandi volumi di dati cifrati;
- modelli ML di dimensioni medie (classificatori, regressioni / logistic regression, random forest poco profonde, reti neurali piccole o “compattate”), ovvero algoritmi classificativi o regressivi che possono essere trasformati in versioni eseguibili su dati cifrati tramite FHE; e
- operazioni in tempi compatibili con molti casi d’uso business, specialmente quando i vincoli di latenza non sono estremi e si possono usare modelli più leggeri, pre-calcolo, caching o pipeline ibride.
Applicazioni della crittografia omomorfica ai dati sanitari
- studi di revisione mostrano come la CO sia ormai una delle tecniche chiave per preservare la privacy nelle analisi di dati clinici, spesso in combinazione con federated learning e differential privacy[17][18];
- lavori specifici esplorano l’uso della FHE per integrare dati clinici distribuiti tra ospedali diversi, mantenendoli cifrati per tutta la pipeline di analisi e AI[19];
- sono stati proposti framework cloud-based che combinano blockchain, FHE e searchable encryption per gestire cartelle cliniche personali (“PHR”) cifrate, con auditabilità delle operazioni[20].
In diversi casi, la CO viene usata per:
- calcolare statistiche aggregate (es. costi medi, tassi di incidenza) su dataset cifrati;
- eseguire inferenza o training parziale di modelli di rischio clinico; e
- consentire a soggetti terzi (es. aziende farmaceutiche, centri di ricerca) di interrogare dataset cifrati senza mai accedere ai dati in chiaro.
Particolarmente rilevante è l’intersezione tra CO e federated learning: uno schema tipico prevede che i parametri dei modelli locali (aggiornati su dati ospedalieri) siano aggregati in forma cifrata, riducendo ulteriormente il rischio di leakage rispetto al solo FL[21].
Dati ultra-sensibili, rischi etici e governance
Molti dataset sanitari includono – direttamente o per inferenza – attributi come religione, etnia, orientamento politico, spesso utilizzati per studi epidemiologici o di equità nell’accesso alle cure. La letteratura recente sottolinea il rischio di attribute disclosure: la rivelazione di attributi come stato di salute, religione o gruppo etnico può portare a discriminazioni o attacchi mirati[22].
In questo contesto la CO consente, ad esempio:
- di allenare modelli che valutano bias e fairness rispetto a gruppi vulnerabili, senza fornire mai al soggetto che effettua l’analisi la visibilità sugli attributi sensibili dei singoli individui[23]; e
- di effettuare studi statistici inter-istituzionali su minoranze religiose o etniche evitando che ciascuna istituzione debba condividere dati in chiaro con una controparte centrale.
Dal punto di vista regolatorio, però, è cruciale ricordare che i dati cifrati restano dati personali finché esiste una chiave che ne consente la decrittazione. La CO non “de-classifica” i dati da sensibili a non personali; li rende tecnicamente più protetti durante l’elaborazione. È quindi un mezzo di sicurezza (art. 32 GDPR[24]) e di data protection by design (art. 25), non un modo per sottrarsi al regime degli articoli 6 e 9.
La CO non elimina:
- il rischio di output privacy (es. risultati troppo granulari che permettono re-identificazione);
- eventuali bias nei modelli, che rimangono anche se i dati sono cifrati; e
- la necessità di governance chiara sugli attori che detengono le chiavi e sulle condizioni di decrittazione.
Per dati politico-etnico-religiosi, occorre quindi progettare non solo lo strato crittografico, ma anche:
- regole di minimizzazione degli attributi,
- politiche di controllo degli accessi agli output,
- meccanismi di audit (anche tramite blockchain) delle operazioni eseguite[25].
Per regole di minimizzazione degli attributi si intende l’applicazione pratica del principio di data minimization: usare, condividere o rendere disponibili solo gli attributi strettamente necessari per svolgere un’analisi o addestrare un modello. Nel contesto di CO, FL o data-sharing sanitari, la minimizzazione riduce il rischio di re-identificazione e semplifica la compliance perché limita la sensibilità dei dati anche prima che vengano cifrati o protetti da PETs.
Crittografia omomorfica nel cloud, nelle clean room e nella supply chain
La CO è nativamente pensata per il modello cloud: i dati sono cifrati dal cliente, inviati a un’infrastruttura gestita da un terzo, elaborati lì, e solo il cliente conserva la chiave privata per leggere i risultati. Studi recenti sul cloud confermano che:
- la CO è una delle principali privacy-enhancing technologies (PETs) per proteggere dati durante l’elaborazione, in particolare in scenari di outsourcing a provider cloud[26];
- gli schemi FHE possono essere integrati in architetture cloud-IoT per analizzare dati provenienti da sensori, dispositivi medici, edge device senza mai decrittarli in piattaforma[27].
Molti cloud provider non offrono ancora FHE “as-a-service” in modo generalizzato, ma diverse tool e librerie HE-ready (SEAL, OpenFHE, Concrete, ecc.) sono usati come building block di soluzioni di confidential AI[28]. Google, ad esempio, descrive pubblicamente l’uso della CO per consentire di eseguire AI su dati cifrati, in modo che neppure un insider del provider possa leggere il contenuto.
Un ambito in forte crescita è quello delle data clean room: ambienti “sigillati” in cui più soggetti possono combinare i propri dati per analisi congiunte (es. misurare l’efficacia pubblicitaria) senza scambiarsi i dati in chiaro.
Nel periodo 2021-2025 diversi studi descrivono clean room che usano CO, federated learning e differential privacy per consentire analytics su milioni di record/ora senza accesso ai dati grezzi[29]. Nel medesimo lasso di tempo sono stati prodotti documentazione tecnica e articoli di settore che citano specificamente la CO tra le tecnologie chiave per mantenere i dati cifrati anche all’interno delle clean room[30].
In pratica, un brand e una piattaforma (es. cloud o walled garden) possono:
- caricare i propri dataset cifrati;
- definire query congiunte (es. audience overlap, attribuzione campagne, segmentazione avanzata); e
- ottenere solo risultati aggregati, evitando qualunque esposizione di identificativi o attributi sensibili.
La CO è sempre più spesso integrata con blockchain e DLT per:
- registrare in modo immutabile chi ha eseguito quali operazioni su dati cifrati; e
- proteggere informazioni di supply chain (es. provenienza di farmaci o componenti critici) con calcoli omomorfici su dati cifrati e ancoraggio delle prove su registro distribuito[31].
In ambito IoT industriale e smart city, la CO viene valutata per:
- analizzare stream di dati sensibili (es. consumi energetici, mobilità) in forma cifrata; e
- combinare dati provenienti da diversi operatori (multi-utility, PA, telco) per modelli predittivi senza centralizzare i dati in chiaro[32].
Commercializzazione dei dati e limiti regolatori
Dal punto di vista regolatorio, la CO non cambia la natura giuridica del dato: lo protegge senza declassarlo. Di conseguenza, è essenziale chiarire alcuni punti:
- i dati cifrati con CO sono dati personali se esiste una chiave che ne consente – anche potenzialmente – la decrittazione (considerando 26 GDPR). La CO è quindi uno strumento di pseudonimizzazione avanzata, non di anonimizzazione;
- la CO rientra tra le misure tecniche di sicurezza (art. 32) e gli strumenti di protezione dei dati by design e by default (art. 25); e
- per dati rientranti nelle categorie particolari (art. 9) – salute, opinioni politiche, credo religioso, dati genetici, ecc. – resta necessario un titolo di liceità specifico (es. consenso esplicito, basi giuridiche sanitarie, interesse pubblico rilevante).
Detto questo, la CO può ridurre il rischio e quindi:
- agevolare valutazioni positive nelle DPIA[33];
- facilitare l’adozione di basi giuridiche come interesse legittimo o contratto, dimostrando che l’impatto sui diritti è mitigato; e
- essere valorizzata nelle certificazioni o nei regimi di code of conduct per i PETs (scenario richiamato da analisi OCSE e altre organizzazioni internazionali)[34].
Modelli di business basati su crittografia omomorfica
Dal 2021 in poi sono emersi diversi modelli di data monetization che sfruttano la CO.
Valutazione del valore del dataset cifrato. Sistemi basati su CO permettono a un potenziale acquirente di testare l’utilità di un dataset cifrato per un certo modello AI, senza mai vedere i dati in chiaro, riducendo asimmetrie informative e rischi legali[35].
Marketplace di dati elaborabili ma non copiabili. Alcune proposte di data marketplace prevedono che il compratore ottenga il diritto di eseguire certe funzioni su dati cifrati (es. lanciare modelli, ottenere solo output aggregati), ma non il dato grezzo – riducendo il rischio di riuso o rivendita non autorizzata[36].
Data clean room e advertising cookieless. Nel marketing digitale, le clean room supportate da CO permettono a brand e publisher di monetizzare i rispettivi first-party data tramite segmentazioni e misurazioni condivise, restando entro i vincoli GDPR e post-cookie[37].
Monetizzazione di dati sanitari e industriali ad alta sensibilità. Analisi su dati sanitari cifrati, o su dati industriali proprietari, possono essere offerte come servizi a pagamento a terzi (industrie farmaceutiche, assicurazioni, fintech, ecc.) mantenendo il controllo sulle chiavi e sugli output.
Linee guida e articoli recenti sul tema della monetizzazione dei dati sottolineano come la CO, insieme a differential privacy e secure multi-party computation, sia uno dei pilastri tecnici per attuare questi modelli in modo conforme[38].
Nonostante le potenzialità, occorre evitare tre equivoci:
- innanzitutto, la CO non sostituisce la base giuridica per il trattamento dei dati. La vendita o licenza d’uso di dati sanitari o politico-religiosi richiede comunque una base valida (consenso esplicito, interesse pubblico, ecc.);
- per quanto riguarda i trasferimenti extra-UE, l’uso di CO non elimina automaticamente il problema del trasferimento verso Paesi terzi. Anche con dati cifrati, molte autorità considerano il trasferimento come tale se il provider extra-UE ha accesso ai cifrati e può influire sul trattamento; e
- sussiste sempre il rischio di re-identificazione tramite output. Se il modello o le query consentono risultati troppo granulari, il rischio di identificare individui resta anche se i dati in input sono cifrati.
Per progettare schemi di monetizzazione leciti, è quindi necessario combinare:
- PETs tecniche (CO, MPC, DP, FL);
- strumenti giuridici (contratti, policy, meccanismi di consenso/opt-out, governance multi-stakeholder); e
- controlli sugli output (limiti sulle query, soglie di aggregazione, revisione umana).
Strategie operative per imprese e pubbliche amministrazioni
Per un’azienda o una PA che intenda intraprendere un percorso di digitalizzazione avanzata e monetizzazione dei dati nel rispetto delle regole europee, la CO non è più solo un tema da convegno accademico. È una tecnologia concreta, ma che richiede competenze integrate:
- critto-matematiche (scelta di schemi, parametri, modelli di minaccia);
- architetturali e DevOps (integrazione in cloud, performance, scalabilità); e
- legali e organizzative (DPIA, basi giuridiche, contratti, accountability).
Nel quinquennio 2021-2025 si è creata una base tecnologica solida: librerie mature, iniziative di standardizzazione, casi d’uso in sanità, finanza, marketing e supply chain, modelli di business per marketplace e data clean room.
Il passo successivo è tradurre queste possibilità in progetti concreti, ideati by design per:
- massimizzare l’utilità dei dati (anche sensibili);
- ridurre l’esposizione tecnica e legale; e
- creare nuove linee di ricavo fondate su fiducia, trasparenza e controllo.
In questo contesto, affidarsi a studi legali e team di legal engineering con forti competenze informatiche e crittografiche non è più un “lusso” ma una condizione necessaria: serve qualcuno che sappia tenere insieme standard tecnici, vincoli regolatori, architetture cloud e obiettivi di business per trasformare la crittografia omomorfica da promessa a infrastruttura operativa.
Riferimenti essenziali
(tutti accessibili da web o banche dati accademiche)
OECD, “Sharing trustworthy AI models with privacy-enhancing technologies”, 2025 (OECD).
Gartner, Hype Cycle for Privacy, 2024, 2024 (trend su Privacy-Enhancing Computation, Gartner) (Gartner).
ENISA, ENISA’s PETs Maturity Assessment Repository, 2019 (overview PETs e valutazione di maturità, ENISA) (ENISA).
World Economic Forum, The Next Generation of Data-Sharing in Financial Services: Using Privacy Enhancing Techniques to Unlock New Value, 2019 (overview PETs e data collaboration, WEF) (WEF).
Google, “Expanding our Fully Homomorphic Encryption offering”, 2023 – annuncio HEIR, toolchain FHE (Google).
Al Badawi et al., “OpenFHE: Open-Source Fully Homomorphic Encryption Library”, 2022; tutorial AAAI 2024 (OpenFHE).
Jorge et al., “Evaluating Homomorphic Encryption Schemes for Privacy in Healthcare”, Cybersecurity, 2025 (Jorge).
Scheibner et al., “Health data privacy through homomorphic encryption and blockchain”, BMC Medical Ethics, 2022 (Scheibner).
Ezeogu, “Homomorphic Encryption in Healthcare Analytics”, 2025; Lou, “Homomorphic Encryption for Healthcare Data Privacy in Industry Use Cases”, ETH, 2024 (Ezeogu).
ISO/IEC JTC 1/SC 27, progetto ISO/IEC 18033-8 – Fully Homomorphic Encryption; serie ISO/IEC 28033 (ISO/IEC).
ITU Journal, “A practical homomorphic encryption approach for GDPR-compliant machine learning full training protocol”, 2025 (ITU Journal).
Note
[1] Per una descrizione generale delle tipologie di crittografia omomorfica e di come la stessa si realizza, si veda, tra i tanti EC/Homomorphic Encryption.
[2] Si veda https://github.com/microsoft/SEAL.
[3] Si veda https://openfhe.org/.
[4] Si veda https://github.com/zama-ai/concrete.
[5] Si veda https://developers.googleblog.com/en/expanding-our-fully-homomorphic-encryption-offering/.
[6] Si veda con esauriente dettaglio https://www.incits.org/news-events/news-coverage/us-to-host-the-information-security-cybersecurity-and-privacy-protection-plenary-and-synchronized-working-group-meetings-of-isoiec-jtc-1sc-27.
[7] Idem https://standardsdevelopment.bsigroup.com/projects/9023-09118.
[8] Si veda https://openfhe.discourse.group/c/announcements/6.
[9] Con “certificazioni europee dei PETs (Privacy-Enhancing Technologies)” si intendono schemi formali e riconosciuti che attestano che un’organizzazione, un prodotto o un servizio ha adottato determinate tecnologie o misure crittografiche (come la crittografia omomorfica, secure multiparty computation, differential privacy, etc.) in conformità a criteri stabiliti in ambito europeo, al fine di rafforzare la fiducia e dimostrare compliance normativa.In particolare:
● il European Union Agency for Cybersecurity (ENISA) indica che i PETs possono essere integrati in certificazioni e standard di sicurezza e privacy europei per rafforzare l’affidabilità delle soluzioni tecnologiche;
● il Europrivacy (European Data Protection Seal) è stato approvato dall’European Data Protection Board come schema di certificazione per la conformità al Regolamento (UE) 2016/679 (“GDPR”), e sebbene non sia specifico per PETs, rappresenta un modello di certificazione che può essere esteso anche alle tecnologie PET; e
● più in generale, la Organisation for Economic Co-operation and Development (OECD) richiama che i PETs devono essere considerati nei quadri regolatori per la protezione dei dati e che standard e certificazioni possono supportarne l’adozione.
In pratica, per una soluzione che impiega la crittografia omomorfica o altre PETs, ottenere una certificazione significa:
● soddisfare criteri tecnici e di governance che dimostrano che le tecnologie sono implementate in modo robusto e sicuro (es. parametri crittografici, gestione chiavi, auditabilità, logging, versioni post-quantum);
● essere valutabile da enti accreditati indipendenti che verificano la conformità al framework normativo europeo (privacy by design, risk assessment, accountability); e
● ottenere un “marchio” o sigillo che facilita la fiducia da parte di clienti, partner commerciali e autorità di controllo.
Dal punto di vista del contesto della CO (crittografia omomorfica), queste certificazioni possono quindi rappresentare un valore aggiunto per mostrare che l’adozione della CO non è solo “innovazione tecnologica”, ma anche “gestione del rischio e compliance normativa” — che facilita ad esempio l’inserimento nei capitolati delle PA, nei marketplace dei dati o nei contratti di outsourcing cloud.
[10] Il vendor lock-in è la situazione in cui un’azienda, dopo aver adottato una certa tecnologia o piattaforma, non può più cambiare fornitore senza costi elevati, perdita di funzionalità o interruzioni operative. Quando parliamo di CO, il rischio di vendor lock-in nasce per vari fattori, tra cui (i) gli schemi e le librerie non sono sempre interoperabili in quanto ogni fornitore o libreria (SEAL, OpenFHE, Concrete, ecc.) usa parametri, formati di cifratura e API differenti. Se un’azienda sviluppa algoritmi, pipeline o modelli AI basati su un certo schema, migrare ad altro provider può richiedere di riscrivere tutto, (ii) se la CO è implementata tramite un servizio cloud proprietario, un compilatore FHE non open source o una piattaforma di AI “confidential” chiusa, l’azienda che lo adotta diventa di fatto legata al fornitore per aggiornamenti di sicurezza, performance e compatibilità futura con standard e hardware, (iii) a causa di particolari parametri crittografici e gestione chiavi, tra cui formati di chiavi non esportabili, strutture di ciphertext non compatibili con altre librerie, e funzioni omomorfiche personalizzate. La standardizzazione riduce (non elimina del tutto) il lock-in, in quanto i percorsi ISO/IEC in corso (ISO/IEC 18033-8, serie 28033, ecc.) puntano a definire formati interoperabili per ciphertext e chiavi, uniformare i parametri di sicurezza e stabilire profili di implementazione comuni.
[11] Si veda https://www.mdpi.com/2076-3417/14/10/4047.
[12] Idem nota 12.
[13] Si veda https://www.mdpi.com/2624-800X/5/3/74.
[14] Nakashima A., Sugizaki Y., Tsuchida H., Hayashi T., Nuida K., Mori K., Isshiki T., Multi-Key Homomorphic Encryption with Threshold Re-Encryption, in: Selected Areas in Cryptography – SAC 2024, Proceedings, Lecture Notes in Computer Science, vol. 15516, Springer, 2025, pp. 84-104. Disponibile online:
https://sacworkshop.org/SAC24/preproceedings/NakashimaSugizakiTsuchidaHayashiNuidaMoriIsshiki.pdf.
[15] Nakashima A., Sugizaki Y., Tsuchida H., Hayashi T., Nuida K., Mori K., Isshiki T., Multi-Key Homomorphic Encryption with Threshold Re-Encryption, in: Proceedings of SAC 2024 (Selected Areas in Cryptography 2024 Workshop), 2024, pp. 1-17. Disponibile online:
https://sacworkshop.org/SAC24/preproceedings/NakashimaSugizakiTsuchidaHayashiNuidaMoriIsshiki.pdf.
[16] Si veda per tutti Regev, O., On lattices, learning with errors, random linear codes, and cryptography, Proceedings of the 37th Annual ACM Symposium on Theory of Computing (STOC 2005), pp. 84-93. Questo lavoro introduce il problema Learning with Errors (LWE), dal quale derivano molti schemi che incorporano rumore intenzionale per garantire la sicurezza. Disponibile online: https://cims.nyu.edu/~regev/papers/qcrypto.pdf?utm_source=chatgpt.com.
[17] Il federated learning (“FL”) consente di addestrare un modello senza centralizzare i dati: ogni ospedale aggiorna il modello in locale e invia solo i parametri.
La differential privacy (“DP”) aggiunge rumore controllato ai parametri o ai risultati, così da impedire la ricostruzione dei dati dei singoli pazienti.
Sono diverse dalla CO perché FL e DP non cifrano i dati durante il calcolo, ma riducono la quantità di informazione condivisa (FL) o aumentano l’irreversibilità degli output (DP).
Combinate con la CO, si ottiene un effetto complementare: i parametri del modello (FL) e gli aggregati protetti da rumore (DP) possono viaggiare cifrati tramite CO, riducendo al minimo sia l’esposizione dei dati sia il rischio di leakage dagli output.
[18] Si veda Khalid N., Qayyum A., Bilal M., Al-Fuqaha A., Qadir J., Privacy-preserving artificial intelligence in healthcare: Techniques and applications, Computers in Biology and Medicine, vol. 158, 2023, 106848. DOI: 10.1016/j.compbiomed.2023.106848. Disponibile online:
https://www.sciencedirect.com/science/article/pii/S001048252300313X.
[19] Si veda Ezeogu A.O., Homomorphic Encryption in Healthcare Analytics: Enabling Secure Cloud-Based Population Health Computations, Journal of Advanced Research (JOAR), Vol. 1, No. 1, August 2025, pp. 42-60. Disponibile online:
https://joaresearch.com/index.php/JOAR/article/download/21/4.
[20] Si veda Olaymi S. E. Z., Performance and security analysis of fully homomorphic encryption in cloud-based healthcare blockchain, Health Informatics Journal, vol. 31, n. 4, Ottobre-Dicembre 2025, DOI: 10.1177/14604582251394616. Disponibile online:
https://journals.sagepub.com/doi/10.1177/14604582251394616.
[21] Si veda Wibawa F., Çatak F. Ö., Sarp S., Kuzlu M., Çalı U., Homomorphic Encryption and Federated Learning based Privacy-Preserving CNN Training: COVID-19 Detection Use-Case, in: Proceedings of the European Interdisciplinary Cybersecurity Conference (EICC ’22), 15-16 giugno 2022, Barcellona, Spagna, ACM, 2022, pp. 1-6. DOI: 10.1145/3528580.3532845
(https://dl.acm.org/doi/10.1145/3528580.3532845).
[22] Si veda Lee, S., Kim, Y., Cho, S., Searchable Blockchain-Based Healthcare Information Exchange System to Enhance Privacy Preserving and Data Usability, Sensors, vol. 24, n. 5, 2024, art. 1582. DOI: 10.3390/s24051582. Disponibile online: https://www.mdpi.com/1424-8220/24/5/1582.
[23] Si veda Shaham S., Hajisafi A., Quan M. K., Nguyen D. C., Krishnamachari B., Peris C., Ghinita G., Shahabi C., Pathirana P. N., Holistic Survey of Privacy and Fairness in Machine Learning, arXiv preprint arXiv:2307.15838, 2023. Disponibile online: https://arxiv.org/pdf/2307.15838v1.pdf.
[24] Per GDPR intendiamo il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali e alla libera circolazione di tali dati, e che abroga la direttiva 95/46/CE (Regolamento generale sulla protezione dei dati – GDPR), in Gazzetta ufficiale dell’Unione europea, L 119, 4 maggio 2016.
[25] Si veda Scheibner J., Ienca M., Vayena E., Health data privacy through homomorphic encryption and distributed ledger computing: an ethical-legal qualitative expert assessment study, BMC Medical Ethics, vol. 23, Art. n. 121, 2022. DOI: 10.1186/s12910-022-00852-2. Disponibile online: https://bmcmedethics.biomedcentral.com/articles/10.1186/s12910-022-00852-2.
[26] Si veda Ike, J. E., Kessie, J. D., Popoola, R., Azeez, M. A., Onibokun, T., A Novel Approach to Cloud Data Encryption using Homomorphic Encryption, Journal of Frontiers in Multidisciplinary Research, vol. 5, n. 2, luglio–dicembre 2024, pp. 19–27. DOI: 10.54660/IJFMR.2024.5.6.19-27. Disponibile online:
https://www.multidisciplinaryfrontiers.com/uploads/archives/20250315192103_FMR-2025-1-010.1.pdf.
[27] Si veda Singh, N., Securing Cloud-Based Internet of Things: Challenges and Proactive Strategies, Sensors, vol. 25, n. 1, art. 79, 2024. DOI: 10.3390/s25010079. Disponibile online:
https://www.mdpi.com/1424-8220/25/1/79
[28] Si veda, nuovamente, https://openfhe.org/.
[29] Si veda, inter alia, https://matomo.org/blog/2025/07/privacy-enhancing-technologies/.
[30] Si veda, inter alia, https://mehttaventuresdubai.substack.com/p/privacy-first-audience-targeting.
[31] Si veda Akindote O. J., Enyejo J. O., Awotiwon B. O., Ajayi A. A., Integrating Blockchain and Homomorphic Encryption to Enhance Security and Privacy in Project Management and Combat Counterfeit Goods in Global Supply Chain Operations, International Journal of Innovative Science and Research Technology, vol. 9, n. 11 (Novembre 2024), DOI: 10.38124/ijisrt/IJISRT24NOV149. Disponibile online:
[32] Si veda Singh N., Buyya R., Kim H., Securing Cloud-Based Internet of Things: Challenges and Mitigations, Sensors, vol. 25, n. 1, art. 79, 2025. DOI:10.3390/s25010079. Disponibile online: https://www.mdpi.com/1424-8220/25/1/79.
[33] Per DPIA si intende il Data Protection Impact Assessment, in italiano Valutazione d’Impatto sulla Protezione dei Dati, prevista dall’art. 35 del GDPR. È uno strumento obbligatorio quando un trattamento presenta rischi elevati per i diritti e le libertà degli interessati (es. dati sanitari, algoritmi di profilazione, biometria, cloud ad alta intensità di dati sensibili).
Serve a: (i) descrivere il trattamento e le sue finalità; (ii) valutare necessità e proporzionalità; (iii) analizzare rischi residui e (iv) indicare misure tecniche e organizzative (PETs, CO, FL, DP, ecc.) per mitigarli. In pratica, è la “due diligence privacy” preventiva che documenta perché un trattamento è conforme e quali misure lo rendono sicuro.
[34] Si veda
[35] Si veda Yang M., Gao R., Zheng Z., Sell Data to AI Algorithms Without Revealing It: Secure Data Valuation and Sharing via Homomorphic Encryption, Poster at NeurIPS Lock-LLM Workshop 2025, 27 ottobre 2025. Disponibile online: https://openreview.net/forum?id=kJRiK2eQ8R.
[36] Si veda Serrano N. E., Cuenca F., A Peer-to-Peer Ownership-Preserving Data Marketplace, in: 2021 IEEE International Conference on Blockchain (Blockchain 2021), 6-8 dicembre 2021, Melbourne, Australia, IEEE, 2021, pp. 1-6. DOI: 10.1109/Blockchain53845.2021.00062 (https://www.researchgate.net/publication/358083773_A_Peer-to-Peer_Ownership-Preserving_Data_Marketplace).
[37] Si veda https://www.didomi.io/blog/data-clean-rooms.
[38] Si veda https://quantumzero.io/strategies-fot-data-monetization/.
















