Runbook incident per agenti AI: prevenzione, risposta e recovery misurabili.
Prevenzione e preparazione: confini, policy e osservabilità
Gli incident che coinvolgono agenti AI non assomigliano alle interruzioni IT tradizionali: il vettore non è solo il codice, ma spesso il contenuto che li attraversa. Un HTML con istruzioni nascoste, un documento di knowledge base non sanificato, una catena di tool‑call con parametri improvvidi: la kill chain passa attraverso il “percepire‑decidere‑agire” dell’agente. Per questo serve un runbook specifico che unisca sicurezza, prodotto e operations. L’obiettivo non è “spegnere l’incendio” a caso, ma ridurre impatto e tempo di recupero misurando ciò che conta: Attack Pass Rate (APR), Mean Time To Detect/Remediate (MTTD/MTTR), costo per outcome, copertura audit. Prevenzione e preparazione sono il 50% del lavoro. Definisci i confini prima del problema: principle of least privilege sui tool (scope granulari di lettura/scrittura e TTL), sandbox per ogni write‑access, validatori forti (JSON Schema + controlli semantici) che fermano un output anomalo prima di toccare sistemi reali. Le Policy Card runtime rendono espliciti scopi, basi giuridiche, dati e retention per ciascun workflow (es. sales recap, ticket update) e vanno loggate ad ogni azione. Per standardizzare permessi e audit tra agenti e tool, un riferimento è il Model Context Protocol: Anthropic MCP. Strumentazione e osservabilità sono l’altro 50%. Ogni evento utile deve includere prompt/contesto, tool invocati con parametri, permessi effettivi, citazioni con metadati (provenienza/versione) e costi (token/minuti/storage), oltre ai tempi edge→azione. Tracing distribuito su ASR/LLM/tool/CRM permette di vedere dove si formano i colli di bottiglia e i comportamenti anomali. I pattern per orchestrazione multi‑agent, con ruoli/stati espliciti e handover chiari, riducono loop e leak: vedi Google Multi‑Agent Blog. Sul fronte difese e drill operativi, un riferimento sintetico è la “safety recipe” per sistemi agentici: NVIDIA Safety Recipe. Infine, readiness organizzativa. Nomina owner e canali (marketing/PM/IT/compliance), prepara template di report e dashboard multi‑ruolo e prova il runbook con esercitazioni programmate. I cambi di capability dei vendor possono alterare retry, tool‑use e quote: segui i canali ufficiali per aggiornare runbook e guardrail senza sorprese: OpenAI News (IT) e Anthropic News.
Risposta e recovery: playbook operativo tra persone, processi e tool
Il momento zero di un incident agentico è spesso una sequenza di segnali deboli: latenza che sale, loop rate che raddoppia, tool‑call inattese, risposte senza citazioni. Un runbook efficace definisce chi fa cosa nei primi cinque minuti e come si passa dal contenimento al recupero. Primo: attiva il circuito di contenimento. Blocca o degrada il write‑access (sandbox by default), riduci il numero di step per task e forza un modello più economico/robusto se i costi esplodono. Se il rischio è di data exfiltration o di modifiche indesiderate al CRM, sospendi i connettori più esposti e instrada i job in coda verso una variante read‑only. I pattern di fallback e circuit breaker in sistemi agentici sono sintetizzati qui: NVIDIA Safety Recipe. Secondo: diagnosi guidata da eventi. Il log deve raccontare cosa è successo: input, tool invocati e parametri, permessi effettivi, stato delle Policy Card, citazioni/fonti e costi. Ricostruisci la catena edge→ASR/LLM→tool→CRM con tracing distribuito: quale passaggio ha introdotto errore o abuso? I pattern multi‑agent di Google aiutano a isolare ruoli/stati e a identificare passaggi di responsabilità: Google Multi‑Agent Blog. Terzo: recovery con verifiche e prove. Prima di riaprire il write‑access, esegui una suite di test su golden set e scenari avversari (jailbreak, indirect prompt). Aggiorna o ripristina versioni di prompt/policy e comunica lo stato a stakeholder marketing/IT/compliance con un report board‑ready: cos’è successo, blast radius, APR, MTTD/MTTR, costi evitati. Se l’incident ha toccato dati personali o consensi, prepara export dei log firmati e valuta l’obbligo di notifica secondo policy interne e quadro UE. Infine, memoria e change management. Ogni major release di modello/SDK/framework agentico deve innescare una revisione del runbook, la riesecuzione del golden set e, se necessario, un canary limitato su un dominio (es. sales recap). Le fonti ufficiali aiutano a prevedere breaking change: OpenAI News (IT) e Anthropic News. Questo ciclo chiuso riduce i tempi di fermo, aumenta la fiducia dei team e rende difendibile la continuità operativa.
KPI, drill e report: come misurare e migliorare la risposta
Definire KPI e routine è la differenza tra un runbook teorico e uno che regge al primo vero incidente. KPI fondamentali - Attack Pass Rate (APR): % di attacchi o casi avversari che superano i guardrail; obiettivo in calo mese su mese. Riferimento alle categorie di rischio e controlli: OWASP Top 10 LLM Applications. - MTTD/MTTR: minuti da anomalia a blocco/ripristino; definire soglie per dominio (sales, service) e correlare con impatto su costo per outcome. - Copertura audit/export: % sessioni con log completi, firmati, esportabili; target ≥ 99% con canale indipendente. - Permessi: % azioni write‑access con approvazione esplicita; % tool con scope minimi e TTL. - Efficienza: costo per outcome e latenza edge→azione durante e dopo l’incident; loop rate. Drill e cadence - Drill trimestrali: simulazioni di prompt injection, indirect prompt via HTML/documenti/immagini e escalation di privilegi. Documenta esiti e azioni correttive. - Patch cadence: ogni rilascio di modelli/framework/SDK → riesecuzione golden set, verifica contratti/validator e update delle Policy Card. - Canary e rollback: rilasci progressivi con metriche guardrail; se APR o costo per outcome sforano soglia, switch‑back automatico. Report board‑ready Includi timeline, cause radice, blast radius, APR, MTTD/MTTR, impatti economici evitati, decisioni e follow‑up. Collega fonti ufficiali che hanno motivato cambi di configurazione (es. nuove policy vendor): Anthropic News, OpenAI News (IT). Per casi multimodali (documenti/immagini), cita limiti/capacità aggiornate: Meta Llama 4 multimodal. Con KPI chiari e routine cadenzate, il runbook diventa un prodotto vivo. Team marketing, PM e IT parlano lo stesso linguaggio e l’azienda guadagna resilienza misurabile.