In tutte le implementazioni di AI che ho esaminato in diversi settori, emerge un modello ricorrente: le organizzazioni cercano il rischio nel posto sbagliato. La loro attenzione tende a concentrarsi sul modello stesso, inclusi i dati di addestramento, i controlli di sicurezza e il comportamento. Ma, nella pratica, è raramente lì che si verificano i problemi.
Molte delle vulnerabilità con l’impatto più elevato emergono nel sistema circostante, nel modo in cui vengono costruiti i prompt, in come i dati esterni vengono reperiti e considerati affidabili, in ciò a cui il modello è autorizzato ad accedere e nelle identità con cui opera. È qui che i sistemi di AI sono più spesso esposti: nei punti di interconnessione tra i componenti, dove la governance è solitamente più debole.
Il problema più profondo è il divario tra aspettativa e realtà. Le organizzazioni prevedono un certo tipo di fallimento, ma i sistemi in produzione falliscono in modi completamente diversi. Il rischio emerge proprio in questo disallineamento — in ipotesi che non reggono alla scala, all’autonomia o all’integrazione.
Le stesse idee sbagliate sulla sicurezza dell’AI ricorrono continuamente. Vale la pena esaminare le cinque più rilevanti.
Idea sbagliata n. 1: se il modello è sicuro, il sistema è sicuro
Questo è l’errore più comune che osservo, ed è facile da commettere. Il modello appare come l’elemento più innovativo, quindi i team si concentrano su guardrail e test, per poi presumere che il lavoro sia concluso.
Ma non è così che questi sistemi falliscono. Il modello è solo un componente di un’infrastruttura molto più ampia, e la maggior parte dei fallimenti avviene nei punti di connessione con dati, strumenti e altri sistemi. Concentrarsi esclusivamente sul modello è come installare una porta ad alta sicurezza in un edificio senza pareti.
Come risolvere: per proteggere un sistema di AI, considera l’intero ambiente come superficie di attacco. Mappa l’intero flusso dei dati — dagli input al recupero e alla memoria, e dagli strumenti agli output — e governa prompt, agenti, archivi vettoriali, identità e connettori come asset di proprietà, con chiari punti di controllo, responsabilità e policy, come faresti per qualsiasi altro sistema critico.
Idea sbagliata n. 2: la prompt injection è solo un altro problema di input
I team di sicurezza con un background web spesso ricorrono a strumenti familiari quando incontrano un nuovo problema. Quando si tratta di mettere in sicurezza l’AI, questo istinto può portarli nella direzione sbagliata.
La prompt injection assomiglia alla SQL injection — in cui i sistemi trattano input malevoli come comandi — ma si comporta in modo molto diverso. Il software tradizionale può imporre una chiara separazione tra istruzioni e dati. I modelli linguistici di grandi dimensioni non possono farlo in modo affidabile. Elaborano istruzioni e dati come un unico flusso di testo e formulano giudizi probabilistici su quale sia cosa.
Il National Cyber Security Centre (NCSC) del Regno Unito è chiaro su questo punto: la prompt injection è strutturalmente diversa dalla SQL injection e deve essere affrontata in modo diverso.
Come risolvere: filtri e rilevatori aiutano, ma non risolvono il problema da soli. Le salvaguardie più efficaci sono di tipo architetturale. Limita l’accesso agli strumenti, applica il principio del privilegio minimo, isola i contenuti non affidabili e valida in modo deterministico le chiamate agli strumenti e i parametri. Richiedi un’approvazione esplicita per le azioni sensibili, esegui in sandbox e monitora in modo aggressivo. Queste misure riducono sia la probabilità sia l’impatto di una compromissione, ma non eliminano il rischio. Se il rischio residuo rimane inaccettabile, il caso d’uso non è adatto a un modello linguistico di grandi dimensioni.
Idea sbagliata n. 3: gli output dell’AI sono solo testo, non creano rischi reali
Le prime implementazioni di AI premiavano l’autonomia. Questa impostazione è stata poi trasferita in ambienti di produzione dove non è appropriata. Gli output dell’AI possono sembrare testo innocuo, ma raramente restano tali. Nel momento in cui vengono passati a un altro sistema, possono portare ad azioni reali — inviare email, interrogare database, eseguire codice o eliminare un record. In questo contesto, una prompt injection riuscita eredita tutte le capacità del sistema.
È qui che il rischio diventa reale: le capacità del sistema diventano le capacità dell’attaccante.
L’Open Web Application Security Project identifica l’eccessiva autonomia come uno dei rischi più gravi nell’AI agentica, mentre l’NCSC sottolinea che è proprio questo il punto in cui la prompt injection smette di essere un fastidio e diventa una violazione.
Come risolvere: è semplice: limita ciò che il sistema può fare, applica il principio del privilegio minimo e considera gli output del modello come non affidabili finché non superano una validazione deterministica al confine di esecuzione. Questo non renderà innocuo un agente compromesso, ma ridurrà significativamente il raggio d’impatto.
Idea sbagliata n. 4: l’uso di dati esterni rende l’AI più affidabile e più sicura
La generazione aumentata dal recupero (RAG), in cui i modelli attingono a dati esterni, migliora l’accuratezza ma non rende i sistemi più sicuri. Ricerche pubblicate da USENIX dimostrano che alterare un piccolo numero di voci nella base di conoscenza è sufficiente per manipolare in modo affidabile gli output RAG su larga scala.
Ogni fonte di dati che colleghi diventa un potenziale punto di ingresso. Se quei dati non sono affidabili, sono obsoleti o manipolati, possono influenzare l’output del modello in modi difficili da rilevare.
Come risolvere: questo è sia un problema di modello sia un problema di dati e di supply chain. Tratta le fonti esterne come dipendenze che richiedono governance. Applica controlli su provenienza, validazione, accesso in scrittura, scansione in fase di ingestione, versioning, separazione delle fonti e gestione delle modifiche.
Idea sbagliata n. 5: AI gestita significa che il fornitore si occupa della sicurezza
Spesso si confondono i servizi gestiti con la sicurezza esternalizzata. In realtà, la responsabilità è condivisa, ma le responsabilità del cliente in materia di sicurezza restano significative.
Il fornitore protegge il servizio in sé. Tu sei responsabile di tutto ciò che lo circonda: quali dati vengono inseriti, chi ha accesso, cosa il modello è autorizzato a fare e come vengono utilizzati gli output.
Come risolvere: sii esplicito su ciò che è di tua competenza, definisci chiaramente la responsabilità condivisa e non presumere che sia sicuro solo perché è gestito. Esamina i controlli del fornitore, quindi colma autonomamente le lacune in materia di identità, gestione dei dati, configurazione, monitoraggio e sicurezza delle integrazioni.
Cosa dovrebbe includere ogni implementazione
La maggior parte delle organizzazioni che valuto è in grado di elencare le soluzioni di AI che ha implementato. Molte meno sanno dirmi chi ne è responsabile, quali dati coinvolgono, di cosa sono capaci o cosa accade quando falliscono. Questo evidenzia un problema di governance.
Le basi non sono particolarmente complesse; sono semplicemente applicate in modo disomogeneo.
Come minimo, dovresti avere:
- Una chiara posizione sulla sicurezza dell’AI, approvata a livello esecutivo, e una propensione al rischio definita, allineata a specifici casi d’uso e tipologie di dati
- Un inventario completo delle tue risorse di AI (modelli, prompt, agenti, dataset, archivi vettoriali, connettori, account di servizio e plugin), con responsabili nominati
- Modelli di minaccia che definiscano i confini di fiducia e applichino policy in punti di controllo prevedibili
- Solidi controlli di integrità lungo la supply chain e la pipeline dei dati, inclusi provenienza, firma, scansione, tracciabilità, versioning e, ove appropriato, registri gestiti
- Accesso agli strumenti basato sul principio del privilegio minimo per gli agenti, con supervisione umana per le azioni ad alto impatto
- Livelli di validazione sugli output prima che qualsiasi azione venga eseguita, registrata o esposta agli utenti
- Valutazione e monitoraggio continui integrati nella gestione delle modifiche
- Procedure operative per gli incidenti testate nella pratica, inclusi scenari di contenimento, disattivazione sicura e rollback
Implementando questi elementi, applichi la stessa disciplina ingegneristica richiesta per qualsiasi sistema critico.
Conclusioni sulla sicurezza dell’AI
La sicurezza dell’AI va oltre la protezione dei soli sistemi o modelli. Riconoscerlo fin dall’inizio ti permetterà di essere in vantaggio rispetto a chi lo comprende solo dopo che qualcosa si rompe.
Non si tratta di un’attività una tantum. I sistemi di AI sono in continua evoluzione e la sicurezza deve tenere il passo. Ciò significa test continui, incluso il red teaming — tentativi deliberati di compromettere il sistema per comprenderne le vulnerabilità.
E se non riesci a valutare chiaramente la tua esposizione tra modelli, integrazioni, pipeline di dati e agenti, questa incertezza è di per sé parte del rischio.