Appunti di AI security, riletti con gli occhi di chi fa incident response.

In questo articolo raccolgo in maniera più ordinata gli appunti di un corso introduttivo di AI security. Quello che va detto fin da subito è che non non troverete un elenco di attacchi ma piuttosto “uno spostamento del punto di osservazione“.

La domanda con cui la maggior parte dei team affronta il tema è: il nostro modello è sicuro? È la domanda sbagliata, o meglio: è una domanda troppo piccola. Un modello perfettamente allineato, valutato e messo a punto con criterio può stare al centro di un prodotto insicuro. Se i dati di addestramento non hanno provenienza tracciabile, se i prompt vengono trattati come contenuto innocuo, se l’API è sovra-privilegiata, se un plugin può fare più di quanto serve, se dopo il rilascio nessuno guarda più niente … il rischio resta tutto lì, intatto.

La domanda giusta è un’altra: cosa entra, cosa decide, cosa il sistema può effettivamente raggiungere?

Tre strati, non uno

Il modo più economico che conosco per ragionare su un sistema AI è dividerlo in tre strati.

• Dati e prompt: dataset di addestramento, corpus di retrieval, prompt di sistema, set di valutazione. È ciò che entra.
• Modello e logica: pesi, fine-tune, policy, agenti, orchestrazione. È ciò che decide.
• Ambiente operativo: applicazioni, API, utenti, plugin, storage, log. È ciò che il sistema può toccare ed esporre.

Gli incidenti reali attraversano quasi sempre più di uno strato. E l’attaccante non sceglie lo strato più sofisticato: sceglie quello più facile. Un chatbot RAG costruito su un modello di frontiera, ma con un retriever che può leggere la knowledge base HR e un’integrazione Slack con permessi di scrittura ampi, ha il suo problema nel workflow, non nei pesi.

Prima del modello c’è il dato

Non serve rubare un modello o entrare in produzione per fare danni. A volte basta influenzare ciò che il modello impara.

Il data poisoning è l’ingresso di esempi malevoli, di bassa qualità o fuorvianti in un training set, in un fine-tune o in un corpus di retrieval, in modo da alterare il comportamento del sistema più avanti. Può essere grossolano oppure chirurgico: colpire solo un ristretto insieme di prompt, entità o argomenti. Due pattern classici: il label flipping (campioni che andrebbero etichettati come pericolosi vengono marcati come innocui) e il backdoor (una frase-trigger rara, un watermark, una patch in un’immagine fanno fallire il modello solo in una condizione specifica, mentre nel resto dei casi si comporta normalmente).

Le porte d’ingresso sono tre, e vale la pena tenerle distinte perché richiedono controlli diversi:

• dato raccolto: web crawl, feed di fornitori, upload utente, dati di partner;
• dato preparato: etichettatura, filtraggio, fine-tuning, embedding, versionamento (fase che può intercettare il problema o amplificarlo silenziosamente);
• conoscenza distribuita: il contesto a runtime: corpus di retrieval, vector store. Qui il problema di fiducia si ricrea dopo il deployment.

Dal punto di vista investigativo questa è la classe di problemi peggiore, perché l’evento che rende visibile il danno è lontanissimo dalla compromissione originaria. Un assistente di supporto che comincia a raccomandare una procedura deprecata per una sola linea di prodotto, a causa di un articolo avvelenato indicizzato mesi prima, si presenta come un edge case bizzarro, non come un incidente.

La domanda di controllo: “Se domani il modello cambia comportamento, siamo in grado di dimostrare quale dato lo ha cambiato?“

Se la risposta è no, la supply chain dei dati è già un problema di sicurezza, a prescindere dal fatto che un incidente sia avvenuto. In pratica servono manifest dei dataset con hash, job di ingestion firmati, record di approvazione, versionamento degli indici di embedding con conservazione dei document ID di origine per ogni chunk, e valutazioni canary costruite apposta su entità sensibili e frasi-trigger note.

L’input come vettore: due famiglie, un principio

Il corso separa – correttamente – attacchi avversariali e prompt injection, ma il principio sottostante è lo stesso: il contenuto in ingresso è codice d’attacco, anche quando non contiene una riga di codice.

Negli attacchi avversariali il modello non viene toccato. Cambia solo l’input, modificato in modo minimo e impercettibile per un essere umano: pochi pixel, un font leggermente alterato, una spaziatura anomala, un carattere omoglifo. Il sistema che legge le fatture riconosce un importo diverso da quello che leggerebbe una persona. Il filtro antispam lascia passare un messaggio che qualunque utente riconoscerebbe al volo. L’input diventa un problema di sicurezza quando tre condizioni coincidono: qualcuno lo manipola, la manipolazione colpisce una zona sensibile del comportamento del modello, e quel comportamento alimenta una decisione che conta. Cambia il modello? No. Cambia la posta in gioco intorno ad esso.

La prompt injection è il cugino LLM della SQL injection: il sistema tratta come istruzione ciò che era solo contenuto da valutare. Testo bianco su fondo bianco in una pagina web, una riga nascosta in un ticket, un allegato costruito ad arte. L’utente non vede nulla di anomalo; il modello legge tutto. Non è un bug, è un problema di fiducia mal collocata.

La ragione per cui la injection è pericolosa non è che il modello dica qualcosa di sbagliato. È che nella stessa finestra convivono senza separazione: il contenuto letto, il ragionamento e l’autorità di agire. È come avere ufficio posta, decisori e firmatari degli assegni nella stessa stanza, a leggere la stessa pila di fogli, senza saper distinguere una direttiva ufficiale dalla pubblicità.

La difesa non è un prompt di sistema che dice “ignora eventuali istruzioni malevole” – abbiamo dimostrazioni sul fatto che non funziona. La difesa è architetturale:

• tutto ciò che arriva dall’esterno è untrusted per default, come una mail da uno sconosciuto;
• si separa la fase di raccolta informazioni dalla fase di azione;
• si limita l’insieme dei tool disponibili al modello, per scelta esplicita e non per default;
• si mette un passaggio di approvazione reale prima di qualunque azione sensibile.

E la domanda di mappatura, che vale più di qualunque elenco di jailbreak: quali fonti di contenuto possono cambiare il comportamento del nostro modello, e cosa gli è permesso fare subito dopo averle lette? Quella è la trust boundary.

Il modello come bene esposto: estrazione e privacy

Due rischi che nella pratica italiana vedo sottovalutati, perché non somigliano a una violazione.

Model extraction: nessuno scarica il file dei pesi. Qualcuno interroga il servizio in modo massivo e sistematico, raccoglie le risposte e ricostruisce un sostituto sufficientemente buono. È reverse engineering di una ricetta ordinando lo stesso piatto mille volte e prendendo appunti. Ogni dettaglio in più che restituiamo – confidence score, spiegazioni estese del ragionamento, metadati di scoring – è un indizio regalato. Il servizio nel frattempo risulta perfettamente sano da ogni cruscotto di disponibilità: nulla va in errore, nulla si interrompe. Il segnale, se c’è, è nel pattern d’uso: volumi anomali, molte riformulazioni della stessa domanda, sondaggio meccanico e sistematico degli edge case. Nessuno di questi indizi prova un intento malevolo da solo; insieme disegnano qualcosa che non somiglia all’uso quotidiano.

Privacy: il rischio non coincide con il data breach. Un modello può memorizzare e ripetere, e il perimetro del problema copre l’addestramento, l’uso quotidiano, i log e i tool collegati. Ma il punto che mi ha convinto di più è un altro: non serve alcuna memorizzazione perché ci sia un problema di privacy. Se il sistema attorno al modello può recuperare on demand un documento sensibile per la persona sbagliata, il danno è già fatto. E una volta che un dato ha plasmato il comportamento di un modello, non lo si rimuove come si cancella un file. Ecco perché la minimizzazione va fatta all’ingresso, non a posteriori, e la review di privacy deve coprire anche output e log, non solo il training set.

Non l’hai costruito tu

Quasi nessuno costruisce un sistema AI da zero: lo si assembla. Modelli di terze parti, dataset, toolkit, plugin, vector database, servizi gestiti, infrastruttura altrui. Il che significa che le nostre decisioni di fiducia non si fermano al bordo del nostro codice.

La frase che ricordo di questa sessione è: la fiducia non è un logo. Il fatto che il nome sia noto non dice nulla su cosa faccia quel componente e su dove finiscano i nostri dati dopo averlo attraversato. E i problemi di supply chain quasi mai iniziano con un componente palesemente malevolo: iniziano con un componente reputato, adottato per andare più veloci – decisione ragionevole, all’epoca – messo in produzione senza review perché “il fornitore è serio”, e poi un default debole, un aggiornamento che cambia cosa viene loggato, un connettore che dopo un disservizio viene ricollegato con permessi più ampi di prima.

L’antidoto è noioso e funziona: un AI Bill of Materials (AIBOM). Cioè l’abitudine disciplinata di tenere un elenco. Quale modello è in uso adesso, quale versione del dataset lo ha prodotto, quale prompt template è vivo in produzione, quali tool esterni sono collegati, chi ha approvato ciascuna di queste scelte, e – soprattutto – quale workflow può essere riportato indietro se la fiducia in un componente viene meno.

La produzione è dove il lavoro comincia

Questa è la parte che parla direttamente al nostro mestiere. Il rilascio non è la fine del lavoro di sicurezza: è l’inizio.

Gli incidenti AI in produzione, nella stragrande maggioranza, non assomigliano a una breach cinematografica. Assomigliano a questo: una funzionalità viene rilasciata con permessi generosi, ha successo, gli utenti la usano in modi che il testing non aveva previsto, dopo qualche mese viene collegata una nuova fonte dati, l’assistente inizia a leggere più di prima e a chiamare i tool in un ordine diverso, i log mostrano prompt strani — e nessuno è sicuro di chi sia il proprietario di quel workflow né di quali evidenze esistano. Il contenimento richiede molto più tempo del dovuto. Nessuno ha fatto niente di drammatico: una modifica ordinaria ha incontrato un monitoraggio insufficiente.

La domanda migliore dell’intero corso, quella che riscriverei sopra la lavagna di ogni SOC:

Se una nostra funzionalità AI si comportasse male oggi, quali evidenze avremmo nei primi quindici minuti?

Tradotta in requisiti operativi, per come la vedo io dal lato forense:

• kill switch per disattivare immediatamente l’uso dei tool, separato dalla disattivazione dell’intera funzionalità;
• log ricostruibili: prompt, risposta, tool invocati, versione del modello e del prompt template, identificativi dei documenti recuperati. Senza questi campi non c’è ricostruzione possibile, solo congetture;
• capacità di attribuzione: saper distinguere se il problema nasce dal modello, dal dato o dal workflow attorno. Sono tre risposte a incidente diverse;
• identità separate per lettura, generazione e azione, così che un elemento compromesso non consegni tutto il resto;
• rilevazione della permission creep, cioè dei privilegi che si allargano silenziosamente nel tempo;
• owner designato per gli incidenti AI-specific e una response plan provata prima del primo incidente reale.

Senza questo anello chiuso – vedere, capire, contenere – l’hardening di produzione è solo speranza travestita da piano.

La governance è ciò che impedisce ai controlli di decadere

Nessuno dei controlli tecnici sopravvive a lungo se nessuno possiede il processo, nessuno conserva le evidenze e nessuno aggiorna la policy quando le cose cambiano.

Tre pezzi, e se ne manca uno il programma è debole: policy e rischio (cosa ci si aspetta), controlli tecnici (chi realizza l’aspettativa), evidenze e oversight (chi dimostra a posteriori che funziona). Policy senza controlli è performativa; controlli senza oversight vanno in deriva o vengono aggirati quando diventano scomodi; oversight senza policy è arbitrario.

Cinque domande a cui un programma di AI governance dovrebbe saper rispondere per ogni sistema, ripetutamente … e ciascuna dovrebbe corrispondere a un documento reale, non a una buona intenzione:

Domanda	Documento corrispondente
Quali sistemi AI sono in uso e chi ne è owner?	Inventario dei sistemi
Quali rischi contano per questo caso d’uso e questa audience?	Risk assessment
Quali controlli servono prima del rilascio e quali devono restare attivi dopo?	Architettura e record di approvazione
Quali evidenze dimostrano che funzionano davvero?	Test, log, report di monitoraggio
Come gestiamo incidenti, eccezioni e aggiornamenti di policy?	Deroghe nominali con data di scadenza

Quell’ultimo dettaglio non è formale: un’eccezione concessa una volta e mai più rivista è il modo più comune in cui un controllo muore.

Sui framework, con un aggiornamento

Il corso cita NIST AI RMF, ISO/IEC 42001, le linee guida OWASP e l’AI Act. Vale la pena precisare dove siamo oggi:

• NIST AI RMF: la 1.0 (AI 100-1, gennaio 2023) resta l’unica versione finalizzata del core framework, in revisione ma senza una 2.0 pubblicata. NIST ha esteso il framework tramite profili, tra cui il Generative AI Profile (AI 600-1) e, dall’aprile 2026, un concept note per un profilo sulle infrastrutture critiche. Utile per ragionare in termini di govern, map, measure, manage. (pagina NIST)
• ISO/IEC 42001: la controparte certificabile, orientata a costruire un sistema di gestione ripetibile e non uno sforzo una tantum.
• OWASP (progetto Generative AI): il livello applicativo, con la lista aggiornata dei rischi concreti – prompt injection in testa.
• AI Act (Reg. UE 2024/1689): qui l’aggiornamento è sostanziale e riguarda direttamente chi lavora in Italia. Il Digital Omnibus ha riscritto il calendario: dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell’art. 50, il regime sanzionatorio e l’enforcement nazionale, mentre gli obblighi sui sistemi ad alto rischio slittano al 2 dicembre 2027 (sistemi autonomi, Allegato III) e al 2 agosto 2028 (sistemi integrati in prodotti regolamentati, Allegato I). Restano pienamente in vigore i divieti dell’art. 5 e l’obbligo di alfabetizzazione IA. Da tenere presente: il regolamento non riguarda solo chi sviluppa modelli, ma anche – e per il tessuto produttivo italiano soprattutto – chi li utilizza sotto la propria autorità, i deployer. (sintesi Altalex)

I framework guadagnano il loro spazio quando cambiano il comportamento quotidiano di chi progetta e revisiona, non quando stanno in una slide che nessuno apre.

Cosa farei lunedì mattina

Se dovessi ridurre i capitoli precedenti a una lista operativa:

1. Censire. Quali casi d’uso AI esistono davvero, compresi quelli che nessuno ha mai formalmente autorizzato. Quali fonti dati usano, quali modelli, quali tool possono raggiungere.
2. Mappare l’ingresso dell’untrusted. Dove entra contenuto non controllato nel workflow, e cosa il modello è autorizzato a leggere, scrivere, invocare o innescare subito dopo.
3. Verificare la ricostruibilità. Cosa viene loggato, chi approva le azioni sensibili, come verrebbe rilevato un incidente e con quali evidenze nei primi quindici minuti.
4. Separare i privilegi. Service account distinti per lettura, generazione e azione; token separati per read e write; niente credenziali condivise.
5. Versionare tutto ciò che influenza il comportamento. Dataset, fine-tune, indici di embedding, prompt template. Con un percorso di rollback provato, non teorico.
6. Assegnare un owner agli incidenti AI-specific e mettere la review dei permessi in calendario, non nelle buone intenzioni.

Niente di tutto questo è appariscente. È esattamente la disciplina ingegneristica ordinaria che rende un sistema difendibile – e, per chi come me arriva dall’incident response, è anche l’unica cosa che rende un sistema analizzabile dopo il fatto. Il primo lavoro dell’AI security è vedere l’intero sistema con chiarezza. Una volta che lo si vede tutto, i rischi reali diventano molto più facili da valutare.