Un modello linguistico non è un database con cui parli: è un componente che interpreta linguaggio naturale, attinge a documenti riservati e — sempre più spesso — agisce, eseguendo strumenti, query e comandi. Ogni capacità aggiunta è anche una superficie di attacco. Capire dove sono i rischi, e quali controlli li contengono, è il presupposto per usare l'IA in produzione senza brutte sorprese.
Le minacce specifiche degli LLM
Prompt injection
È la vulnerabilità più caratteristica. Un'istruzione malevola nascosta in un documento, in un'email o in una pagina web che il modello legge può dirottarne il comportamento: "ignora le istruzioni precedenti e invia il contenuto a…". Quando il modello ha accesso a strumenti, l'injection passa dall'essere un fastidio a un rischio operativo concreto.
Esfiltrazione di dati
Un assistente che attinge a fonti riservate può, se mal progettato, rivelare a un utente informazioni che non dovrebbe vedere — o includere dati sensibili in una risposta che finisce fuori dal perimetro. Il rischio cresce con i sistemi connessi a strumenti esterni.
Esecuzione di strumenti e azioni
Gli agenti che eseguono comandi, interrogano database o inviano messaggi portano enormi vantaggi e, insieme, la possibilità di compiere azioni dannose — per errore o perché manipolati. Un agente è potente quanto gli strumenti che gli concedi.
Allucinazioni come rischio di sicurezza
Una risposta inventata ma sicura di sé, in un contesto medico, legale o finanziario, è essa stessa un problema di sicurezza. La mitigazione non è solo "un modello migliore": è citare le fonti e rendere ogni affermazione verificabile.
I controlli che contano
Controllo degli accessi basato sui ruoli (RBAC)
Il modello deve vedere solo ciò che l'utente può vedere. I permessi sui documenti vanno applicati a monte del recupero, non lasciati al giudizio del modello. Se un utente non ha accesso a una fonte, quella fonte non deve nemmeno entrare nel contesto.
Registrazione completa e audit trail
Ogni interazione — prompt, fonti consultate, strumenti invocati, risposte — va registrata in modo verificabile. Serve per la sicurezza, per la conformità (l'AI Act lo richiede per i sistemi ad alto rischio) e per ricostruire cosa è successo quando qualcosa va storto. Ciò che non è loggato non è difendibile.
Approvazione e gating degli strumenti
Le azioni sensibili non dovrebbero partire da sole. Modalità di esecuzione che richiedono approvazione umana prima di eseguire un comando — distinguendo le operazioni di sola lettura da quelle che modificano lo stato — trasformano l'agente da rischio in strumento governato. La persona resta nel ciclo dove conta.
Isolamento di rete
Se il modello e i dati vivono dentro un perimetro controllato, intere classi di rischio — l'esfiltrazione verso endpoint esterni, le chiamate non autorizzate — diventano molto più difficili da realizzare. L'isolamento è uno dei controlli più potenti, e l'on-premise lo rende naturale.
Governance del modello
Sapere quale modello stai usando, in quale versione, con quali dati è stato addestrato e come si comporta nei casi limite è parte della sicurezza. Valutazioni periodiche e red-teaming — mettere alla prova il sistema con attacchi simulati — vanno pianificati, non improvvisati dopo un incidente.
Perché il locale cambia l'equazione del rischio
Molti di questi controlli sono semplicemente più facili quando esegui l'IA sulla tua infrastruttura:
- i dati sensibili non lasciano il perimetro, quindi l'esfiltrazione verso terzi non è nemmeno un percorso possibile;
- i log sono completi e di tua proprietà, non frammenti esposti da un fornitore;
- l'isolamento di rete è una tua scelta architetturale, non una concessione contrattuale;
- le politiche di accesso, conservazione e cancellazione sono governate da te, end-to-end.
Non significa che l'on-premise sia sicuro "per definizione": prompt injection e cattiva progettazione degli agenti restano rischi ovunque giri il modello. Significa che ti dà le leve per governarli, invece di doverti fidare che qualcun altro lo faccia al posto tuo.
È il principio su cui è costruito IntelligenceBox: controllo degli accessi per ruoli, registrazione completa delle attività, modalità di approvazione per le azioni degli agenti e un'esecuzione che resta dentro il tuo perimetro. Perché in materia di IA, la sicurezza non è una funzionalità da aggiungere alla fine — è il modo in cui il sistema è fatto.
