Un'automazione che funziona nelle prove del venerdì mattina non è un'automazione collaudata. Il collaudo di un'automazione AI è un lavoro diverso dal controllo che fanno tutti: invece di verificare che faccia quello che deve, provi deliberatamente a farle fare quello che non deve. È la differenza tra accendere un'auto e mandarla contro un muro per misurare quanto regge.
Lo fanno i grandi fornitori, con squadre dedicate e budget di ricerca. Il punto che quasi nessuno dice a una piccola impresa è che la parte più utile di quel lavoro non richiede né ricercatori né strumenti costosi. Richiede mezza giornata, un elenco scritto e la disciplina di annotare cosa è andato storto.
Il collaudo di un'automazione non è il test che conosci
Esistono due controlli distinti e vengono confusi di continuo. Il primo è il set di prova: trenta casi reali, la risposta attesa accanto a ciascuno, e misuri quante volte il sistema ci prende. Ne abbiamo scritto parlando di come si valuta un'AI sul proprio caso d'uso, e serve a rispondere a una domanda sola: è abbastanza bravo?
Il secondo controllo è avversariale e la domanda cambia: come lo faccio sbagliare? Il team AI Red Team di Microsoft, che dal 2021 ha condotto oltre 80 operazioni su più di 100 prodotti di AI generativa, lo mette nero su bianco nella terza delle sue otto lezioni: collaudo avversariale e benchmark di sicurezza sono «distinti, ma entrambi utili e perfino complementari». Il benchmark confronta sistemi su rischi già catalogati; il collaudo scopre categorie di danno che nessuno aveva previsto, nel tuo contesto specifico.
Inoltre cambia il perimetro. Il set di prova guarda l'output. Il collaudo guarda il sistema intero: le credenziali che l'automazione usa, i documenti che legge, i messaggi che manda fuori, le librerie che qualcuno ha installato due anni fa.
Gli attacchi che funzionano sono banali
Qui cade l'obiezione più comune, quella del «serve uno specialista». Lo studio di Microsoft cita una constatazione diventata quasi un modo di dire nel settore: gli attaccanti reali non calcolano gradienti, scrivono prompt. E aggiunge il dato di esperienza: le tecniche elementari «funzionano spesso bene quanto i metodi basati sui gradienti, a volte meglio». Il motivo è pratico: i metodi matematicamente sofisticati costano molto e pretendono accesso completo al modello, che nessun servizio commerciale concede.
Due esempi dal loro lavoro chiariscono il livello. Un modello capace di leggere immagini ha superato le proprie protezioni quando le istruzioni vietate sono state scritte sopra una fotografia invece che nel messaggio di testo: stesso contenuto, canale diverso, guardia aggirata. In un altro caso la falla non era nell'AI: una libreria video obsoleta dentro l'applicazione permetteva, con un file costruito ad arte, di raggiungere risorse interne della rete. Non per caso la settima lezione del gruppo è che i modelli linguistici amplificano le vulnerabilità che hai già e ne aggiungono di nuove.
Tradotto per chi ha un'automazione in azienda: il collaudo di un'automazione si fa con la tastiera e con la testa. Scrivere un'istruzione ostile dentro un'email che l'agente leggerà è alla portata di chiunque — ed è esattamente il motivo per cui conviene farlo prima tu, come abbiamo visto a proposito della prompt injection sugli agenti AI.
Il canale conta: la stessa istruzione vietata scritta sopra un'immagine o dentro un documento aggira controlli che bloccherebbero lo stesso testo nel messaggio.
I quattro obiettivi da cui partire
Senza un elenco, le prove diventano una mezz'ora di tentativi casuali. La tassonomia del NIST sull'adversarial machine learning, nella versione di marzo 2025, offre lo scheletro giusto: quattro obiettivi dell'attaccante, che si traducono in quattro domande da fare alla propria automazione.
- Disponibilità. Si può bloccare? Un documento enorme, cento richieste in un minuto, un allegato in un formato che non ha mai visto: il servizio resta in piedi o smette di rispondere anche per gli altri?
- Integrità. Si può far sbagliare a comando? Qui il NIST usa un'espressione utile: questi attacchi permettono di «usare come arma la fiducia» che le persone ripongono nel sistema. Un preventivo con lo sconto sbagliato fa più danni di un messaggio di errore.
- Riservatezza. Si può far parlare? Le istruzioni interne, le chiavi, i documenti indicizzati per la ricerca: l'automazione li ripete se qualcuno insiste con la domanda giusta?
- Abuso. Si può usare per altro? Un assistente clienti che finisce a scrivere testi che non c'entrano nulla con la tua attività è un problema di reputazione prima che di sicurezza.
Quattro righe diventano quindici o venti tentativi concreti, uno per riga, scritti prima di iniziare. Questa lista è il collaudo: tutto il resto è esecuzione.
Come si organizza mezza giornata di prove
La guida al red teaming dell'AI generativa pubblicata da OWASP a gennaio 2025 indica quattro aree da coprire: valutazione del modello, verifica dell'implementazione, esame dell'infrastruttura e analisi del comportamento a runtime. È una buona griglia proprio perché ricorda che tre quarti del lavoro non riguardano il modello.
Sul metodo, Anthropic ha messo in fila pro e contro di ogni approccio: gli esperti di dominio danno la profondità maggiore ma costano e non scalano; le prove automatiche generano molte varianti in fretta ma rischiano di mancare i vettori davvero nuovi. Microsoft conferma entrambe le metà e aggiunge l'avvertenza che conta: gli strumenti automatici «non vanno usati con l'intenzione di togliere la persona dal ciclo».
Operativamente, in una PMI, il collaudo di un'automazione sta in cinque passi: scrivere in cinque righe cosa il sistema non deve mai fare; trasformarle nei venti tentativi di cui sopra; eseguirli registrando il risultato riga per riga; chiudere con mezza pagina di verbale datato; correggere e rifare il giro. L'ultimo passo non è una formalità — il gruppo di Microsoft lavora per cicli successivi di prova e correzione, finché il sistema regge.
Non finisce: si misura in costo dell'attacco
La conclusione dello studio è la frase più onesta che si possa leggere sul tema: «il lavoro di costruire sistemi di AI sicuri e affidabili non sarà mai completo». L'obiettivo non è l'invulnerabilità, è alzare il costo di chi attacca. Il NIST arriva allo stesso punto per via teorica: sistemi completamente robusti sono forse «matematicamente impossibili» senza ipotesi aggiuntive, e ogni difesa ha un prezzo in prestazioni o in qualità.
C'è un'ultima conseguenza pratica, e riguarda chi compra. Anthropic nota che manca uno standard condiviso, e che questa incoerenza «rende difficile confrontare in modo obiettivo la sicurezza relativa di sistemi diversi». Significa che un fornitore che dichiara «sistema testato» non ti sta dicendo niente di verificabile: il verbale di mezza pagina con la data e l'elenco dei tentativi vale più di qualsiasi dichiarazione. E va rifatto a ogni cambio rilevante, a partire da quelli che decide il fornitore e non tu, come l'aggiornamento del modello sotto la tua automazione.
Se vuoi partire oggi, bastano tre cose: le cinque righe di «non deve mai», venti tentativi scritti e una persona che li esegua con calma. Studiollice progetta agenti e automazioni su misura e il collaudo avversariale fa parte della consegna, non di un servizio a parte: un'automazione che non è stata ancora messa alla prova non è pronta per la produzione.