Leader di pensiero

Dove le Norme di Sicurezza dell’Intelligenza Artificiale Si Fermono — e la Protezione in Esecuzione Deve Iniziare

mm
Aggiungi Unite.AI alle tue fonti preferite su Google

Con tutto il parlare dei rischi di sicurezza dell’intelligenza artificiale, un problema che sembra essere trascurato è questo: il fatto che i sistemi di intelligenza artificiale funzionano solo esponendo i loro beni più preziosi — modelli e dati.

A differenza del software tradizionale, l’intelligenza artificiale non esegue semplicemente una logica predefinita. Continuamente combina modelli proprietari con input sensibili per generare output, spesso su infrastrutture che non sono state progettate per proteggere il calcolo.

In questo modo, la sicurezza tradizionale non è sufficiente. La crittografia è efficace quando i dati sono archiviati o trasmessi attraverso una rete, ma non quando i dati sono elaborati o utilizzati. Per l’intelligenza artificiale in particolare, il pericolo sorge quando un modello viene distribuito. I suoi parametri vengono caricati nella memoria, inizializzati ed eseguiti su larga scala – il punto in cui la crittografia si ferma – esponendoli a potenziali accessi non autorizzati. Durante l’inferenza, i dati sensibili fluiscono attraverso lo stesso spazio esposto. Il risultato è una superficie di rischio altamente vulnerabile: i sistemi di intelligenza artificiale che potrebbero sembrare sicuri – ma in realtà sono privi di protezione nei momenti più critici.

Gli organismi di normazione come il National Institute of Standards and Technology (NIST), l’Agenzia dell’Unione Europea per la Sicurezza delle Reti e dell’Informazione (ENISA) e il progetto Open Web Application Security (OWASP) hanno iniziato a definire questo territorio. Descrivono i rischi, nominano le vulnerabilità e delineano i principi di governance. Tuttavia, si fermano prima di prescrivere come proteggere i modelli come proprietà intellettuale e i dati come beni confidenziali una volta iniziata l’esecuzione. Chiudere questa lacuna richiede di ripensare la sicurezza dell’intelligenza artificiale – non come un esercizio di conformità, ma come un problema di calcolo stesso. È qui che la crittografia in uso, o crittografia end-to-end, gioca un ruolo.

Il Punto Cieco nella Sicurezza dell’Intelligenza Artificiale Moderna

La maggior parte delle conversazioni sulla sicurezza dell’intelligenza artificiale orbita ancora attorno a terreni familiari: governance dei dati di training, controlli di accesso, monitoraggio delle API e politiche di utilizzo responsabile. Queste sono necessarie. Tuttavia, nessuna di esse affronta ciò che accade dopo la distribuzione, quando un modello lascia il repository e diventa un sistema vivo.

Una volta distribuito, i parametri di un modello non sono più artefatti astratti. Sono beni vivi e presenti nella memoria, continuamente accessibili durante l’inferenza e spesso utilizzati da più tenant o clienti attraverso servizi di intelligenza artificiale condivisi. Questa esposizione si verifica prima che qualsiasi richiesta di inferenza venga effettuata, aumentando così il rischio introducendo input sensibili e comportamenti osservabili esternamente.

Trattare la protezione del modello come una preoccupazione pre-distribuzione e la sicurezza dell’inferenza come una preoccupazione di runtime non coglie il punto. Nei sistemi reali, questi rischi si sovrappongono. I modelli e i dati sono esposti durante l’inizializzazione, l’esecuzione e l’output. La sicurezza che inizia e finisce con i controlli di archiviazione non affronta queste esposizioni.

Cosa NIST Fa Bene — e Dove Si Ferma

Il quadro di gestione del rischio dell’intelligenza artificiale di NIST è diventato un pilastro per le organizzazioni che cercano di gestire il rischio dell’intelligenza artificiale. La sua struttura — governare, mappare, misurare, gestire — offre un modo disciplinato per pensare alla responsabilità, al contesto, all’impatto e alla mitigazione in tutta la vita dell’intelligenza artificiale.

Cosa NIST fa particolarmente bene è inquadrare il rischio dell’intelligenza artificiale come sistemico piuttosto che accidentale. I fallimenti dell’intelligenza artificiale sono raramente eventi a punto singolo; emergono dalle interazioni tra modelli, dati, persone e infrastrutture. Quell’inquadratura è essenziale.

Dove il quadro si ferma è nel non prescrivere come proteggere i beni di alto valore dell’intelligenza artificiale una volta che i sistemi sono live. I parametri del modello sono trattati implicitamente come artefatti del tempo di progettazione piuttosto che come beni di runtime. Gli ambienti di esecuzione sono assunti come sufficientemente affidabili.

Nella pratica, i parametri del modello sono spesso i beni più preziosi che un’organizzazione possiede. Vengono caricati nella memoria, copiati tra nodi, memorizzati nella cache e riutilizzati. Se la gestione del rischio dell’intelligenza artificiale non tiene conto della riservatezza dei modelli durante la distribuzione e l’esecuzione, un bene critico rimane al di fuori del confine di rischio, come un bersaglio facile.

ENISA e la Realtà delle Minacce Specifiche dell’Intelligenza Artificiale

Il lavoro di ENISA sulla sicurezza informatica dell’intelligenza artificiale spinge ulteriormente la conversazione. Il suo quadro multilivello distingue tra la sicurezza dell’infrastruttura tradizionale e i rischi specifici dell’intelligenza artificiale, riconoscendo che i sistemi di intelligenza artificiale si comportano diversamente — e falliscono diversamente — rispetto al software convenzionale.

Perché è importante? L’intelligenza artificiale introduce minacce che non si adattano perfettamente ai controlli esistenti: estrazione del modello, perdita di parametri, esposizione di co-tenancy e manomissione durante l’esecuzione. Questi rischi non richiedono attaccanti esotici. Sorgono naturalmente quando modelli di alto valore vengono eseguiti in ambienti condivisi o gestiti esternamente.

Il quadro di ENISA riconosce implicitamente che la sicurezza dell’intelligenza artificiale significa la sicurezza del comportamento, non solo del codice. Tuttavia, come la maggior parte delle norme, si concentra su ciò che dovrebbe essere considerato, non su come le protezioni vengono tecnicamente applicate una volta che i modelli sono in esecuzione.

OWASP e il Costo dell’Intelligenza Osservabile

La classifica OWASP dei primi 10 per le applicazioni di modelli linguistici di grandi dimensioni offre una visione più concreta di come i sistemi di intelligenza artificiale si rompono nel mondo reale. Iniezione di prompt, divulgazione di informazioni sensibili, perdita di embedding, eccessiva trasparenza dell’output — queste non sono preoccupazioni teoriche. Sono i sottoprodotti della distribuzione di modelli potenti senza limitare ciò che rivelano.

Sebbene questi problemi siano spesso inquadrati come problemi di livello di applicazione, le loro conseguenze sono più profonde. L’esposizione ripetuta del comportamento del modello può portare a clonazione efficace; gli embedding scarsamente isolati possono rivelare la struttura; e l’abuso dell’inferenza diventa un percorso per la replicazione del modello.

La tassonomia di OWASP rende chiaro un punto: proteggere l’intelligenza artificiale non è solo fermare gli input cattivi. È limitare ciò che i modelli espongono — internamente ed esternamente — una volta che sono operativi.

Una Conclusione Condivisa, un Lavoro Incompiuto

Tra NIST, ENISA e OWASP, c’è un ampio accordo sui fondamentali:

  • Il rischio dell’intelligenza artificiale copre l’intero ciclo di vita
  • I sistemi di intelligenza artificiale introducono nuove categorie di minacce
  • I modelli e i dati sono beni di alto valore
  • L’esposizione in fase di esecuzione è inevitabile

Cosa manca a questi quadri, tuttavia, è un meccanismo per applicare la riservatezza una volta che i modelli sono distribuiti e il calcolo inizia. Quell’omissione non è un difetto, poiché le norme definiscono l’intento e l’ambito. L’implementazione è solitamente lasciata al progettista del sistema.

Tuttavia, lascia un divario critico — uno che si allarga man mano che i sistemi di intelligenza artificiale crescono.

La Crittografia in Uso Cambia l’Equazione

La crittografia in uso sposta il modello di sicurezza. Invece di supporre che i dati e i modelli debbano essere esposti per essere utili, tratta il calcolo come qualcosa che può essere protetto.

In termini pratici, ciò significa:

  • I modelli rimangono crittografati durante la distribuzione, l’inizializzazione e l’esecuzione
  • Gli input non sono mai visibili in chiaro all’ambiente di esecuzione
  • Gli stati intermedi non possono essere ispezionati o modificati
  • L’infrastruttura non ha più bisogno di essere implicitamente affidabile

Ciò non sostituisce i quadri di governance o i controlli di livello di applicazione — li rende operativi. Trasforma i principi di rischio in garanzie applicabili proprio quando i sistemi di intelligenza artificiale sono più vulnerabili.

In altre parole, la crittografia in uso è lo strato mancante tra la politica dell’intelligenza artificiale e la realtà dell’intelligenza artificiale.

Quando la Governance Si Conclude e l’Esecuzione Inizia: Proteggere il Calcolo dell’Intelligenza Artificiale

La sicurezza dell’intelligenza artificiale si rompe in fase di esecuzione. Una volta distribuiti, i modelli e i dati dell’intelligenza artificiale devono essere esposti nella memoria per funzionare, creando una superficie di rischio che i controlli tradizionali — crittografia a riposo, crittografia in transito e quadri di governance — non sono stati progettati per proteggere.

Gli organismi di normazione come NIST, ENISA e OWASP hanno fatto progressi critici nel definire il rischio dell’intelligenza artificiale, la responsabilità e l’abuso. Tuttavia, la loro guida tratta principalmente i modelli come artefatti del tempo di progettazione e assume che gli ambienti di esecuzione possano essere affidabili. Nella pratica, i parametri del modello e gli input sensibili vengono continuamente accessati, riutilizzati e spesso elaborati in ambienti condivisi o gestiti esternamente.

Chiudere questa lacuna richiede di ripensare la sicurezza dell’intelligenza artificiale non come un esercizio di conformità, ma come un problema di protezione del calcolo stesso — quando i modelli sono live, i dati sono in uso e l’esposizione è inevitabile. La crittografia in uso offre un modo efficace per mantenere i modelli e gli input sensibili dell’intelligenza artificiale sicuri in ogni fase del ciclo di vita dell’intelligenza artificiale.

Luigi Caramico, un veterano nell'industria della protezione dei dati, è stato all'avanguardia dell'innovazione nella sicurezza informatica per oltre due decenni. Come co-fondatore e CTO di DataKrypto, Caramico sta aprendo una nuova era di sicurezza dei dati con la tecnologia di crittografia omomorfica (FHE) che promette di rivoluzionare il modo in cui le organizzazioni proteggono le loro informazioni più sensibili nell'era dell'AI.