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

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

A differenza del software tradizionale, l’AI 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 operati. Per l’AI in particolare, il pericolo si verifica quando un modello è 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 AI che potrebbero sembrare sicuri – ma sono in realtà non protetti nei momenti più critici.

Gli organismi di normazione come il National Institute of Standards and Technology (NIST), l’Agenzia europea per la sicurezza informatica (precedentemente conosciuta come Agenzia europea per la sicurezza delle reti e delle informazioni, o ENISA) e il Open Web Application Security Project (OWASP) hanno iniziato a delineare questo territorio. Descrivono i rischi, nominano le vulnerabilità e delineano i principi di governance. Ma 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’AI – non come un esercizio di conformità, ma come un problema di calcolo stesso. È qui che la crittografia in uso, o la crittografia end-to-end, gioca un ruolo.

Il Punto Cieco nella Sicurezza dell’AI Moderna

La maggior parte delle conversazioni sulla sicurezza dell’AI orbita ancora intorno 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 residenti nella memoria, continuamente accessibili durante l’inferenza e spesso utilizzati da più tenant o clienti attraverso servizi AI condivisi. Questa esposizione si verifica prima che qualsiasi richiesta di inferenza venga effettuata, aumentando così il rischio introducendo input sensibili e comportamenti esternamente osservabili.

Trattare la protezione del modello come una preoccupazione pre-distribuzione e la sicurezza dell’inferenza come una preoccupazione di runtime manca 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 NIST AI Risk Management Framework è diventato un corner stone per le organizzazioni che cercano di gestire il rischio dell’AI. La sua struttura — govern, map, measure, manage — offre un modo disciplinato di pensare alla responsabilità, al contesto, all’impatto e alla mitigazione across il ciclo di vita dell’AI.

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

Dove il framework si ferma è nel non prescrivere come proteggere gli asset di alto valore dell’AI una volta che i sistemi sono live. I parametri del modello sono trattati implicitamente come artefatti del design-time piuttosto che asset di runtime. Gli ambienti di esecuzione sono assunti come sufficientemente affidabili.

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

ENISA e la Realtà delle Minacce Specifiche dell’AI

Il lavoro di ENISA sulla sicurezza informatica dell’AI spinge la conversazione oltre. Il suo framework multilivello distingue tra la sicurezza dell’infrastruttura tradizionale e i rischi specifici dell’AI, riconoscendo che i sistemi AI si comportano diversamente — e falliscono diversamente — del software convenzionale.

Perché è importante? L’AI 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 framework di ENISA riconosce implicitamente che la sicurezza dell’AI significa proteggere il comportamento, non solo il codice. Ma come la maggior parte delle norme, si concentra su cosa dovrebbe essere considerato, non su come le protezioni sono tecnicamente applicate una volta che i modelli sono in esecuzione.

OWASP e il Costo dell’Intelligenza Osservabile

OWASP’s Top 10 for Large Language Model applications offre una visione più concreta di come i sistemi AI si rompono nel mondo reale. Iniezione di prompt, divulgazione di informazioni sensibili, perdita di embedding, trasparenza eccessiva di output — queste non sono preoccupazioni teoriche. Sono i sottoprodotti di distribuire potenti modelli senza limitare ciò che rivelano.

Mentre queste questioni sono spesso inquadrate come problemi di livello di applicazione, le loro conseguenze sono più profonde. L’esposizione ripetuta del comportamento del modello può portare a un clonazione efficace; gli embedding poveramente isolati possono rivelare la struttura; e l’abuso dell’inferenza diventa un percorso per la replica del modello.

La tassonomia di OWASP rende chiaro un punto: proteggere l’AI 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

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

• Il rischio dell’AI copre il ciclo di vita
• I sistemi AI introducono nuove categorie di minacce
• I modelli e i dati sono asset di alto valore
• L’esposizione in fase di esecuzione è inevitabile

Cosa questi framework mancano, 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 è tipicamente lasciata al progettista del sistema.

Ma lascia un divario critico — uno che cresce più ampio man mano che i sistemi AI si espandono.

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 testo normale 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 framework di governance o i controlli di livello di applicazione – li operationalizza. Trasforma i principi di rischio in garanzie applicabili proprio quando i sistemi AI sono più vulnerabili.

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

Quando la Governance Finisce e l’Esecuzione Inizia: Proteggere il Calcolo dell’AI

La sicurezza dell’AI si rompe durante l’esecuzione. Una volta distribuiti, i modelli dell’AI e i dati sensibili devono essere esposti nella memoria per funzionare, creando una superficie di rischio che i controlli tradizionali — la crittografia a riposo, la crittografia in transito e i framework 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’AI, la responsabilità e l’abuso. Ma la loro guida tratta principalmente i modelli come artefatti del design-time e assume che gli ambienti di esecuzione possano essere affidabili. Nella pratica, i parametri del modello e gli input sensibili sono continuamente accessibili, riutilizzati e spesso elaborati in ambienti condivisi o gestiti esternamente.

Chiudere questa lacuna richiede di ripensare la sicurezza dell’AI 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 fattibile per mantenere i modelli dell’AI e gli input sensibili sicuri in ogni fase del ciclo di vita dell’AI.