Soluzione · AI Operations
Gestione degli incidenti degli agenti IA: la funzione che risponde quando qualcosa si rompe in produzione — triage, reperibilità, rollback e postmortem — non quando il cliente reclama
La monitorizzazione rileva che qualcosa non va; qualcuno deve rispondere. Senza una funzione di gestione degli incidenti, ogni guasto di un agente in produzione è una corsa improvvisata: nessuno sa chi risponde, che severità ha, se fare rollback o resistere, né perché è tornato la settimana dopo. Non è spegnere un fuoco una notte; è la funzione che gira — severità, reperibilità, runbook, rollback, causa radice e azioni correttive — perché un incidente IA si risolva in fretta e non si ripeta.
Il problema
Quando un agente si guasta in produzione, nessuno sa chi risponde, con che priorità, né come si chiude perché non torni
- L'incidente lo gestisce chi stava guardando, a mano e a memoria: niente severità, niente reperibilità, niente runbook, così lo stesso guasto riceve una risposta diversa a seconda di chi lo prende.
- La decisione di fare rollback o resistere si prende a caldo e senza criterio: a volte si lascia un agente rotto a dare risposte sbagliate per ore, a volte si abbatte tutta la produzione per un difetto minore.
- Niente causa radice né postmortem: si spegne il fuoco, si respira e si va avanti — finché lo stesso incidente torna la settimana dopo perché nessuno ha chiuso l'azione correttiva.
- Il costo dell'incidente è invisibile finché non è enorme: risposte sbagliate ai clienti, un ciclo di agente che fa esplodere la fattura, o un'azione errata su un sistema reale, senza nessuno che misuri quanto ci vuole a rilevare e a risolvere.
Il costo di lasciare tutto com’è
Un agente in produzione senza gestione degli incidenti non è uno che non si guasta — è uno in cui, quando si guasta, il danno corre libero mentre qualcuno improvvisa la risposta. La differenza tra un incidente di dieci minuti e uno di due giorni non è la fortuna: è avere o no la funzione che risponde. E un incidente che non si chiude con una causa radice non è un incidente, sono tutti quelli che vengono: ciò che non si impara, si ripete, e ogni ripetizione è la stessa fattura — in fiducia del cliente, in costo e nel tempo del team che rispegne lo stesso fuoco.
La soluzione
Una funzione di risposta agli incidenti per i tuoi agenti: severità, reperibilità, runbook, rollback e postmortem — montata e operante
- 1Definiamo severità e classificazione: cos'è un incidente critico (un agente che agisce male su un sistema reale o fa esplodere il costo) rispetto a uno minore, perché la risposta sia proporzionata e non dipenda da chi lo prende.
- 2Montiamo la reperibilità e l'escalation: chi risponde, in che ordine e con quale runbook per tipo di incidente — incluso il rollback sicuro dell'agente, del prompt o del modello all'ultima versione buona — con il contesto già raccolto dalla monitorizzazione.
- 3Chiudiamo ogni incidente con causa radice e postmortem: cosa è successo, perché, quale azione correttiva evita che torni, e chi la possiede. L'azione si segue finché è fatta, non finché si dimentica.
- 4Lo lasciamo con un cruscotto: tempo per rilevare, tempo per risolvere (MTTR), incidenti per severità e % di ricorrenza. Una funzione che gira, non un eroe di reperibilità che si brucia.
Cosa cambia
Quello che smetti di perdere
L'incidente si risolve per processo, non per chi stava guardando: severità, runbook e reperibilità danno allo stesso guasto la stessa risposta rapida ogni volta.
Meccanismo
Il guasto smette di ripetersi perché ogni incidente si chiude con una causa radice e un'azione correttiva con responsabile e follow-up, non con un «fatto, andiamo avanti».
Meccanismo
Cosa misuriamo: tempo per rilevare, tempo per risolvere (MTTR), incidenti per severità e % di incidenti ricorrenti.
Cosa misuriamo
Scheda tecnica
- Lavoro che elimina
- rispondere ai guasti degli agenti in produzione alla carlona, senza severità, senza runbook e senza chiudere la causa radice
- Implementazione tipica
- 2–4 settimane
- Ingresso
- un'allerta dalla monitorizzazione o un guasto di un agente in produzione
- Uscita
- incidente triageato, gestito per runbook (con rollback se serve) e chiuso con una causa radice e un'azione correttiva con un responsabile
- Compatibile con
- PagerDutyOpsgenieJira
- Può collegarsi con
- I tuoi agenti e i loro registri di produzioneLa tua monitorizzazione / observability IAIl tuo gestore di incidenti o ticketingIl tuo canale di allerte e la tua reperibilità
- Cosa misuriamo
- tempo per rilevare un incidentetempo per risolvere (MTTR)incidenti per severità% di incidenti ricorrenti
- Adatto per
- aziende con agenti IA in produzione che già monitorizzano ma rispondono agli incidenti alla carlona, senza severità, reperibilità né postmortem
- Non adatto per
- il rilevamento in diretta del problema (è la monitorizzazione, a monte) e la decisione di business su cosa fa l'agente, che resta nel tuo team
Domande frequenti
Sono complementari e consecutive, non la stessa cosa. La monitorizzazione è a monte: sorveglia in diretta latenza, costo, guasti e deriva, e lancia l'allerta quando qualcosa devia. La gestione degli incidenti è ciò che succede dopo quell'allerta: chi risponde, con che severità, quale runbook si segue, se si fa rollback e come si chiude con una causa radice perché non torni. Monitorizzare senza gestione degli incidenti è avere allarmi che nessuno sa gestire; gestire incidenti senza monitorizzazione è rispondere al buio. Si montano insieme, ed è per questo che entrambe puntano all'ombrello AI Operations.
Tenere d'occhio non è una funzione; è una persona che si brucia e un processo che si rompe il giorno in cui quella persona è in ferie. Una vera funzione di incidenti dà ciò che la buona volontà non può: severità perché la risposta sia proporzionata, reperibilità perché ci sia sempre chi risponde, runbook perché il guasto si risolva uguale chiunque lo prenda, e postmortem perché se ne impari. La differenza tra un incidente di dieci minuti e uno di due giorni non è l'attenzione; è avere il processo montato prima che accada.
Gira. Non ti consegniamo un PDF di «policy di incidenti» e ciao: montiamo le severità, la reperibilità e l'escalation nel tuo gestore di incidenti, i runbook di risposta e il rollback sicuro collegati ai tuoi agenti, e il ciclo di postmortem con le azioni correttive seguite fino alla chiusura. E lo lasciamo con un cruscotto — MTTR, incidenti per severità, ricorrenza — perché tu veda la funzione operare, non esistere in un documento. Una funzione con un responsabile, non un manuale in un cassetto.
Lo montiamo nella tua azienda?
Hai individuato il problema. Noi consegniamo la soluzione e la lasciamo misurata.