Agenti AI fuori controllo: come proteggere i sistemi aziendali

“Il nostro agente AI ha inviato duecento email sbagliate stanotte. Come si ferma?”

Questa è la telefonata che non vuoi ricevere. Ed è anche quella che arriva più spesso, qualche settimana dopo aver messo un agente AI in produzione senza aver configurato nessun guardrail.
La risposta breve: si ferma revocando le credenziali di accesso o disabilitando il trigger che lo attiva. Ma la domanda giusta è un’altra: come si fa in modo che non succeda più?
Questa guida risponde a quella domanda. Passi numerati, cosa fare e cosa va storto di solito.

Prima di partire: capire cosa può fare davvero un agente AI

Un agente AI non è un chatbot. Un chatbot risponde. Un agente agisce: legge dati, prende decisioni, esegue operazioni su sistemi esterni. Può inviare email, creare record, chiamare API, spostare file, avviare processi.
Questa differenza cambia tutto sul piano dei rischi. Un chatbot che sbaglia produce una risposta brutta. Un agente che sbaglia può modificare duecento record nel CRM, inviare offerte commerciali a clienti sbagliati, o bloccare un flusso di fatturazione.
Gli agenti autonomi sono utili proprio perché operano senza intervento umano continuo. Però quella stessa autonomia, senza limiti espliciti, è la fonte principale dei problemi in produzione.

Passo 1: mappare le azioni che l’agente può eseguire

Cosa fare. Prima di configurare qualsiasi guardrail, scrivi su carta (o su un documento condiviso) tutte le azioni che l’agente è autorizzato a eseguire. Non quelle che “potrebbe” eseguire se avesse accesso, ma quelle che gli hai effettivamente abilitato.
Distingui tre categorie:

1. Azioni di sola lettura (leggere dati, generare report, consultare API).
2. Azioni reversibili (creare una bozza, aggiornare un campo, aggiungere un tag).
3. Azioni irreversibili (inviare email, effettuare pagamenti, eliminare record).

Cosa va storto di solito. La maggior parte delle implementazioni parte con permessi troppo ampi perché “è più comodo in fase di test”. Il problema è che quei permessi rimangono in produzione. Un agente configurato con accesso in scrittura a tutto il CRM “per testare” e poi dimenticato in quella configurazione è un rischio attivo.
Regola pratica: ogni agente deve avere solo i permessi che servono per completare il suo compito specifico. Niente di più.

Passo 2: definire i limiti operativi prima del deploy

Cosa fare. Per ogni azione irreversibile o ad alto impatto, definisci un limite numerico esplicito. Quante email può inviare in un’ora? Quanti record può modificare in un singolo run? Quante chiamate API può fare in un giorno?
Questi limiti non sono opzionali. Sono il primo strato di difesa contro comportamenti fuori controllo, inclusi quelli causati da prompt injection o da dati di input inattesi.
Per gli agenti che gestisci con n8n, per esempio, puoi inserire nodi di controllo intermedi che verificano il conteggio delle operazioni prima di procedere. Se il numero supera la soglia, il workflow si ferma e genera un alert.
Cosa va storto di solito. I limiti vengono impostati “a istinto” senza ragionare sul volume reale dei dati. Un agente che processa lead in entrata può ricevere cinquecento richieste in un giorno di picco se lanci una campagna. Se il limite era impostato a cento, si blocca nel momento peggiore.
Calibra i limiti sui dati storici, non su stime ottimistiche.

Passo 3: implementare log strutturati e alert in tempo reale

Cosa fare. Ogni azione che l’agente esegue deve lasciare una traccia leggibile: timestamp, tipo di operazione, input ricevuto, output prodotto, esito (successo o errore). I log non servono solo per il debug: servono per ricostruire cosa è successo quando qualcosa va storto.
Gli alert in tempo reale sono il complemento necessario. Se l’agente produce più di X errori consecutivi, o se un’operazione supera una soglia di tempo, deve partire una notifica a un indirizzo email o a un canale dedicato. Non il giorno dopo: subito.
Cosa va storto di solito. I log vengono attivati ma non vengono mai letti. Diventano un archivio inutile. Serve una routine minima: qualcuno guarda i log almeno una volta a settimana, e gli alert vengono testati prima del go-live (sì, testati: invia intenzionalmente un errore e verifica che la notifica arrivi).

Passo 4: separare gli ambienti di test e produzione

Cosa fare. L’agente AI non deve mai essere testato direttamente in produzione. Serve un ambiente separato con dati fittizi o anonimizzati, dove puoi verificare il comportamento senza rischi reali.
Questo vale anche per gli aggiornamenti: se modifichi il prompt, la logica di decisione o le integrazioni, il ciclo è sempre test validazione deploy in produzione. Mai il contrario.
Cosa va storto di solito. Le PMI piccole saltano questo passo perché “non abbiamo tempo di mantenere due ambienti”. È una scelta comprensibile ma costosa. Un errore in produzione con dati reali di clienti costa molto di più, in termini di tempo e reputazione, di qualche ora di setup iniziale.
Se vuoi capire come strutturare questo tipo di architettura per i tuoi workflow, parla con noi del tuo progetto.

Passo 5: gestire i permessi con il principio del minimo privilegio

Cosa fare. Ogni agente deve operare con un’identità tecnica dedicata (un utente di sistema, una chiave API, un service account) che ha accesso solo alle risorse che gli servono. Non usare credenziali personali di un dipendente, non condividere la stessa chiave API tra più agenti.
Questo approccio, chiamato “principio del minimo privilegio”, ha due vantaggi: limita il danno in caso di comportamento anomalo, e permette di revocare l’accesso a un singolo agente senza impattare il resto dei sistemi.
Cosa va storto di solito. Le chiavi API vengono inserite direttamente nel codice o nei file di configurazione, e poi dimenticate lì per mesi. Ruotare le credenziali periodicamente è una pratica che quasi nessuna PMI applica, finché non succede qualcosa.

Passo 6: definire chi supervisiona e con quale frequenza

Cosa fare. Ogni agente in produzione deve avere un “proprietario” umano: una persona che sa come funziona, legge i log, risponde agli alert e ha l’autorità di fermarlo se necessario. Non un team generico: una persona specifica.
Stabilisci anche la frequenza di revisione. Un agente che gestisce processi ad alto impatto (comunicazioni con clienti, modifiche a dati finanziari) richiede revisione settimanale. Uno che automatizza attività interne a basso rischio può essere rivisto ogni mese.
Cosa va storto di solito. La supervisione viene assegnata “al team IT” senza che nessuno se ne senta davvero responsabile. Quando arriva un alert alle 23, nessuno risponde perché “pensavo ci pensasse qualcun altro”.

Passo 7: pianificare il rollback prima che serva

Cosa fare. Per ogni agente che esegue operazioni irreversibili, devi avere una risposta pronta a questa domanda: se devo fermarlo adesso, come lo fermo? E se ha già fatto danni, come li riparo?
Questo significa avere backup aggiornati dei dati che l’agente può modificare, una procedura documentata per revocare i suoi accessi in meno di cinque minuti, e almeno una persona che conosce quella procedura a memoria.
Cosa va storto di solito. Il piano di rollback viene scritto dopo il primo incidente, non prima. A quel punto è troppo tardi per le operazioni già eseguite.

Governance AI: non è burocrazia, è controllo operativo

C’è una tendenza a trattare la governance degli agenti AI come un obbligo normativo da soddisfare sulla carta. Questa è, secondo noi, la scelta sbagliata.
La governance non serve al regolatore. Serve a te, per sapere cosa stanno facendo i tuoi agenti mentre tu non li guardi. Un documento di policy non firmato da nessuno e mai aggiornato non protegge niente. Un log che nessuno legge non serve a niente.
La governance efficace è operativa: chi fa cosa, con quale frequenza, con quali strumenti. Se non riesci a rispondere a queste tre domande per ogni agente in produzione, hai un problema di controllo, non di compliance.

Domande frequenti

Q: Quali sistemi di IA sono considerati ad alto rischio per le aziende?
A: Gli agenti AI ad alto rischio sono quelli che operano in autonomia su dati sensibili, eseguono azioni irreversibili (invio email, pagamenti, modifiche a database) o hanno accesso a sistemi critici senza supervisione umana. Il Regolamento UE sull’AI classifica come alto rischio i sistemi usati in HR, finanza e infrastrutture critiche.
Q: Cosa succede se un agente AI commette un errore in produzione?
A: Dipende dai guardrail attivi. Senza limiti configurati, un agente può inviare centinaia di email errate, modificare record nel database o bloccare un processo prima che qualcuno se ne accorga. Con log strutturati e un meccanismo di rollback, l’errore si contiene in pochi minuti.
Q: Quanto tempo serve per implementare una governance base sugli agenti AI?
A: Per una PMI con uno o due agenti già in produzione, una governance minima (log, alert, limiti operativi) si configura in qualche settimana. Una governance completa con audit trail e revisione dei permessi richiede qualche mese, a seconda della complessità dei sistemi collegati.
Q: Chi deve occuparsi del controllo degli agenti AI in azienda?
A: Non esiste una risposta unica. In una PMI piccola, il responsabile IT o il founder stesso deve avere visibilità sui log. In aziende più strutturate, serve un responsabile di processo che conosca sia il business sia i sistemi. Delegare il controllo solo al fornitore esterno è una scelta rischiosa.

Se stai mettendo in produzione agenti AI e vuoi strutturare i controlli prima che qualcosa vada storto, in Press Start possiamo aiutarti a definire l’architettura giusta per il tuo caso. Raccontaci il tuo progetto.