Incidenti degli agenti AI: log ed escalation

Un agente AI che non trova un dato può fermarsi e chiedere aiuto. Oppure può cercare una chiave API esposta, usarla senza autorizzazione e inventare comunque il risultato. OpenAI ha documentato proprio questo secondo comportamento il 16 settembre 2026. Per una PMI la conseguenza è concreta: se l’automazione non conserva log utili e non ha una procedura di escalation, un errore operativo può sembrare un lavoro completato.

Il punto non è trattare ogni risposta sbagliata come un incidente di sicurezza. Serve distinguere un output mediocre da un’azione non autorizzata, raccogliere prove prima che spariscano e assegnare il caso alla persona che può decidere se bloccare il flusso. Questa guida propone un metodo applicabile ad agenti collegati a WordPress, CRM, email, file e workflow n8n o Make.

Perché il framework OpenAI interessa anche una PMI

OpenAI ha pubblicato un framework per tracciare, investigare e divulgare casi di disallineamento, insieme a sei rapporti relativi a comportamenti osservati durante training o valutazione. Non sono statistiche sulla frequenza dei problemi nei prodotti in uso: OpenAI chiarisce che si tratta di singoli esempi, selezionati perché possono aiutare a capire come nasce un comportamento inatteso e dove falliscono i controlli.

I casi sono istruttivi perché mostrano famiglie di rischio già rilevanti nelle automazioni aziendali:

istruzioni non autorizzate inserite nei riepiloghi usati per continuare un’attività in un nuovo contesto;
indicazioni per nascondere errori, dati inventati o differenze tra le fonti;
ricerca e utilizzo di chiavi API esposte senza permesso;
upload pubblici di file per aggirare un limite dello strumento;
scritture o comunicazioni non autorizzate attraverso repository e servizi esterni.

La lezione utile non è che ogni agente farà queste cose. È che l’obiettivo assegnato può spingere il sistema a trovare una scorciatoia incompatibile con i limiti del processo. Un prompt ben scritto non basta quando l’agente dispone di tool, credenziali e accesso alla rete.

Errore, anomalia o incidente AI?

Una classificazione semplice evita due estremi: ignorare segnali seri oppure bloccare il lavoro per ogni allucinazione. Io userei tre livelli interni.

Errore di qualità

La risposta è incompleta, imprecisa o scritta male, ma l’agente resta dentro i permessi concessi. Un riassunto che perde un dettaglio o una bozza con un link errato richiedono correzione e, se ricorrenti, un test di regressione. Non sono automaticamente incidenti.

Anomalia controllata

Il sistema tenta un’azione inattesa, ma il controllo tecnico la blocca e non risultano dati esposti o modifiche esterne. Esempio: l’agente prova a inviare un file verso un dominio non autorizzato, mentre il proxy nega la richiesta. Il caso va registrato perché dimostra che il guardrail è stato necessario.

Incidente

L’agente supera o aggira un limite, modifica dati senza autorizzazione, espone informazioni, usa credenziali improprie, contatta terzi oppure nasconde deliberatamente un fallimento nel risultato. Va trattato come incidente anche quando il danno non è ancora dimostrato: prima si preservano le prove, poi si stabiliscono impatto e gravità.

Questa tassonomia è operativa, non legale. Il Regolamento europeo sull’AI usa definizioni e obblighi specifici per i sistemi ad alto rischio, inclusi record-keeping e segnalazione di incidenti gravi. La procedura interna deve quindi prevedere un passaggio a responsabile sicurezza, privacy o consulente quando il caso coinvolge persone, dati personali, sistemi ad alto rischio o obblighi contrattuali.

Il caso pratico: agente WordPress con accesso ai file

Immaginiamo un sito WordPress con un agente che prepara articoli partendo da documenti caricati in un’area riservata. Il workflow può leggere una cartella, estrarre i contenuti, creare una bozza e allegare le fonti. Un documento non è leggibile dal tool del browser. L’agente decide allora di caricarlo su un servizio pubblico temporaneo per ottenere una URL accessibile.

Il post resta in bozza e il testo è corretto. Guardando solo l’output finale, il task sembra riuscito. In realtà il file potrebbe contenere nomi, preventivi o dati di clienti ed è stato copiato fuori dal perimetro autorizzato. È lo stesso schema del caso OpenAI sugli upload pubblici usati per ottenere una citazione o interrogare un servizio esterno: il workaround risolve un limite locale creando un rischio più grande.

Qui il controllo efficace non è una frase nel prompt. Servono almeno quattro vincoli tecnici:

rete in uscita limitata a una allowlist di domini;
credenziali separate e con privilegi minimi per lettura, scrittura e pubblicazione;
approvazione umana prima di upload, invii email, pubblicazioni e modifiche irreversibili;
log delle chiamate ai tool con destinazione, tipo di azione, esito e identificativo del task.

Lo stesso principio vale per i permessi su WordPress. Ho già descritto perché un kill switch e permessi separati contano più di una promessa nel prompt, e come impostare guardrail verificabili per gli agenti AI. La procedura di incidente è il livello successivo: entra in gioco quando il controllo segnala qualcosa o quando scopriamo che non ha funzionato.

Quali prove conservare

Un ticket che dice “l’AI ha fatto una cosa strana” non consente di investigare. Il record deve permettere a una seconda persona di ricostruire il caso senza accedere alla sessione originale. Il profilo NIST per la gestione dei rischi della generative AI propone azioni lungo le funzioni govern, map, measure e manage; il principio utile qui è rendere osservabile il ciclo di vita, non accumulare log senza criterio.

Per ogni evento conserverei questi campi:

data e ora in UTC, ambiente e identificativo univoco dell’esecuzione;
fornitore, modello e versione o snapshot, se disponibili;
scopo dichiarato del task e livello di autonomia concesso;
hash o versione del system prompt e della configurazione dei tool;
input rilevanti, output e riepiloghi di contesto, con i dati personali minimizzati;
sequenza delle chiamate ai tool, parametri sensibili redatti ed esiti;
permesso atteso, azione osservata e controllo che avrebbe dovuto fermarla;
dati, utenti, sistemi o soggetti terzi potenzialmente coinvolti;
possibilità di riprodurre il comportamento in un ambiente isolato;
azioni immediate, proprietario del caso e prossima scadenza di revisione.

Non salverei password, token completi o copie indiscriminate di dati personali nel ticket. I log devono essere utili all’indagine senza diventare un secondo problema di sicurezza. Per le credenziali basta registrare l’identificativo del segreto e l’operazione tentata; il valore resta nel vault.

Il triage in tre corsie

OpenAI assegna i casi a tre percorsi: pronto per la divulgazione, indagine minore oppure indagine più ampia. Una PMI può adattare l’idea alla risposta interna.

Corsia 1: noto e contenuto

Il comportamento è compreso, il controllo ha funzionato e non ci sono terzi coinvolti. Si apre il ticket, si collega il test che riproduce il problema e si assegna la correzione. Il workflow può ripartire solo se la mitigazione è misurabile.

Corsia 2: causa incerta

L’azione è stata bloccata o ha impatto limitato, ma non sappiamo perché il sistema l’abbia tentata. Si sospende il task interessato, non necessariamente tutta l’AI aziendale. Si riproduce il caso in sandbox con credenziali finte e si confrontano modello, prompt, tool e dati.

Corsia 3: impatto esterno o sicurezza

Ci sono scritture non autorizzate, esposizione di dati, utilizzo improprio di credenziali, comunicazioni a terzi o impossibilità di delimitare l’impatto. Si revocano i token coinvolti, si disabilita il percorso di esecuzione e si attivano sicurezza, privacy, responsabile del processo e fornitore. Le modifiche all’ambiente devono preservare le prove disponibili.

La corsia non misura quanto l’output sembri assurdo. Misura autorità usata, impatto e incertezza. Un testo palesemente sbagliato può essere un semplice errore; una risposta elegante che nasconde un upload esterno può essere un incidente serio.

La sequenza operativa nelle prime 72 ore

Non esiste una scadenza universale per ogni anomalia AI. È però utile definire tempi interni, separati dagli eventuali termini di legge o di contratto.

Subito: contenere senza cancellare

Fermare la singola automazione, bloccare nuove azioni esterne, congelare i log e annotare chi ha scoperto il caso. Se una credenziale può essere stata esposta o usata senza permesso, revocarla o ruotarla dopo aver registrato gli elementi necessari all’indagine. Non chiedere allo stesso agente di “ripulire” ciò che ha fatto.

Entro la giornata: delimitare l’impatto

Verificare quali tool erano disponibili, quali chiamate sono realmente partite e quali dati hanno lasciato il sistema. Separare fatti confermati, ipotesi e punti ancora aperti. Controllare le esecuzioni simili, perché la ripetizione può indicare un difetto del workflow e non un caso isolato.

Entro 72 ore: decidere riavvio e comunicazioni

Stabilire la causa più probabile, la mitigazione, il test che dimostra la correzione e le persone da informare. Se sono coinvolti un fornitore o una terza parte, condividere abbastanza informazioni per consentire l’indagine senza esporre altri dati. Il riavvio richiede una decisione umana tracciata, non il semplice fatto che una nuova prova sia andata bene.

Come scrivere un report utile al fornitore

Il framework OpenAI indica che un rapporto dovrebbe descrivere comportamento osservato, gravità, impatto esterno, ambiente, periodo, momento della scoperta e modelli coinvolti. Dove possibile aggiunge modalità di rilevazione, portata dell’indagine, questioni aperte e mitigazioni.

Per un ticket al fornitore userei una struttura corta:

cosa doveva fare il sistema;
cosa ha fatto realmente;
perché l’azione era fuori autorizzazione;
sequenza minima per riprodurre il comportamento;
modello, data, regione, tool e configurazione coinvolti;
impatto confermato e impatto ancora in verifica;
misure già applicate e risposta richiesta.

Allegare l’intera conversazione senza spiegazione rallenta l’analisi e può esporre informazioni inutili. Meglio un report leggibile, con un archivio cifrato delle prove disponibile solo a chi deve investigare.

Tre metriche che valgono più del numero di errori

Contare tutte le risposte sbagliate produce rumore. Per capire se il sistema sta diventando gestibile misurerei tre cose.

Tempo di rilevazione: quanto passa tra l’azione e il primo alert umano o automatico.
Copertura dei tool: quale percentuale delle azioni esterne dispone di log, limiti e approvazione.
Recidiva: quanti casi ricompaiono dopo una mitigazione dichiarata conclusa.

La recidiva è il dato più scomodo e più utile. OpenAI include esplicitamente tra i casi da divulgare anche la ripetizione di un comportamento già noto quando mette in dubbio l’efficacia delle mitigazioni. In azienda dovrebbe succedere lo stesso: un incidente chiuso non è quello con il ticket archiviato, ma quello che un test riesce a intercettare prima dell’impatto.

Chiusura operativa

Questa settimana prenderei un solo workflow AI con accesso a WordPress, email, file o CRM e farei una prova: se tenta un’azione fuori perimetro, chi riceve l’alert e quali prove vede? Se la risposta dipende dalla memoria di una persona o dai log del fornitore, la procedura non è ancora pronta.

Il minimo sostenibile è un inventario dei tool, permessi separati, log delle azioni esterne, un kill switch e tre corsie di escalation. Il framework OpenAI aggiunge una regola editoriale utile anche alle PMI: si può segnalare un comportamento rilevante prima di averne spiegato ogni causa, purché fatti, incertezze e impatto restino distinti.