Audit-ready agents: il logging che ti salva in caso di incidente

Nota di metodo: tutti i casi descritti sono pattern composti da audit reali, modificati per garantire la riservatezza dei clienti coinvolti. Nessun caso identifica un singolo cliente specifico.

Gennaio 2026, weekend lungo, una PMI cliente mia in Lombardia, settore distribuzione, ottanta dipendenti. Sabato sera, alle 23:47, l'agente AI di customer support manda una email a un cliente importante che contiene il listino prezzi confidenziale di un altro cliente.

La domenica mattina, alle 7:30, ricevo una telefonata. Il cliente che ha ricevuto la mail è in copia col loro avvocato. Mi chiede: come è successo? Mi chiede: cosa ha fatto l'agente esattamente? Mi chiede: avete un log che dimostra che non è stato un dipendente in malafede?

Per fortuna li avevamo. Avevamo loggato ogni singola tool call dell'agente, con timestamp UTC, hash del prompt di sistema attivo a quel momento, payload completo della tool call, response. In un'ora ho ricostruito esattamente cosa era successo (un memory poisoning indirect tramite un PDF allegato in conversazione precedente). In due ore avevamo una root cause documentation che ha trasformato la conversazione legale da "minaccia di causa" a "incident report condivisibile". Senza quei log, sarebbe stata una settimana di crisi reputazionale.

La differenza tra incident gestito e incident catastrofico è il logging. Tutto qui.

Cosa devi loggare per essere audit-ready, e cosa NO

Il tradeoff vero del logging per AI agents è tra due forze opposte. Da un lato GDPR Articolo 5(1)(c) sul principio di data minimization: logghi solo i dati strettamente necessari, mai più. Dall'altro DORA Articolo 17 sul reporting: devi essere capace di ricostruire un incident in modo dettagliato per audit di compliance officer e regolatori. Le due richieste sembrano contraddittorie. Non lo sono se progetti il logging come content-aware da subito. Timeline e obblighi compliance dettagliati nel cluster su AI Act + DORA: timeline regolatorio per chi costruisce AI agents.

La regola pratica: logga il "cosa" dell'azione, non il "contenuto" del payload. Logga che l'agente ha fatto una tool call su Salesforce, con quale scope, con quale risultato. Non logga il body completo della response Salesforce in cleartext, perché quasi sempre conterrà PII di clienti innocenti.

Il pattern OpenTelemetry GenAI semantic conventions, ormai standard de facto nel 2026 (vedi OpenTelemetry GenAI observability project), risolve la contraddizione in modo elegante: span attributes per metadata strutturati (agent name, operation, model, tool, route, conversation ID), span events per il payload sensibile loggato in modo separato e con TTL diverso. Lo span del trace dura per sempre, l'event con i payload può essere ruotato dopo trenta giorni.

Lo schema di log minimo che funziona davvero

Nove campi. Non di più, non di meno. Documento mentale che porto in ogni audit.

Timestamp UTC. ISO 8601 con millisecond precision. Mai timezone locale, sempre UTC. Quando un incident attraversa fuso orario è l'unico modo di non confondersi.

Agent ID + version hash. L'agente specifico che ha fatto l'azione, con hash del prompt di sistema attivo in quel momento. Permette di sapere che versione del cervello stava operando, anche se da quel momento il prompt è stato cambiato dieci volte.

Trace ID + parent span ID. Distributed tracing OpenTelemetry-style. Permette di seguire la catena di decisioni dall'input utente fino all'azione finale, includendo eventuali sub-agent invocations.

Tool name + scope. Nome del tool chiamato + scope effettivo dei permessi usati. Risponde alla domanda "questo agente, in questo momento, aveva il permesso di fare quello che ha fatto?". Pattern di scope minimo dettagliato nel cluster su permessi minimi per AI agents: least authority applicato.

Input hash + redacted summary. Hash dell'input completo per integrity verification, plus summary redacted del contenuto (es. "email cliente di 850 caratteri, contiene PII tipo nome cognome, source domain @example.com"). Il content reale va in span event separato con retention più breve.

Output hash + redacted summary. Specchio dell'input.

Decision rationale. Perché l'agente ha scelto questo tool/azione. Spesso è il prompt di sistema + intermediate reasoning chain. Cruciale per spiegare un'azione ex-post a un compliance officer.

Outcome + latency. Successo/errore/timeout, latency in ms.

Human-in-the-loop status. Se questa azione richiedeva un human gate, chi ha approvato, quando, dopo quanto tempo. Se il gate è stato bypassato, perché.

I nove campi insieme producono log che pesano molto poco (qualche KB per tool call), permettono ricostruzione completa di un incident, e rispettano GDPR data minimization.

Storage: cleartext è inaccettabile, encrypted-at-rest è obbligatorio

Tre principi non negoziabili sul layer storage.

Encryption at rest mandatory. AES-256 minimum, key management vault-backed (HashiCorp Vault, AWS KMS, Azure Key Vault). Mai chiavi nello stesso storage del log. Mai chiavi in environment variable senza vault-backing.

Append-only / write-once read-many. Il log non è modificabile dopo la scrittura. Audit-grade significa che un compliance officer può presupporre che ciò che vede è ciò che è stato scritto. S3 Object Lock, Azure Blob immutability policies, oppure soluzioni dedicate tipo AWS CloudTrail / Datadog Audit Trail.

Indexed per query veloci. Il log che impieghi due settimane a interrogare in caso di incident vale zero, perché in due settimane il PR damage è già fatto. Indici su trace ID, agent ID, timestamp, tool name minimo. Permettono di rispondere a query operative ("tutte le azioni di Marco tra le 22:00 e le 24:00 di sabato") in secondi.

I tre insieme costano un budget cloud ragionevole (un paio di euro al giorno per logging volume da PMI). Costano molto meno di una settimana di crisis management.

Retention: il puzzle GDPR vs DORA

Il puzzle è esplicito. GDPR Articolo 5(1)(c) chiede minimization e dichiara che i dati personali devono essere conservati per un tempo non superiore al necessario. DORA Articolo 11 sull'incident management chiede traceability per audit, e DORA Articolo 17 sul reporting impone retention finalizzata a regulatory disclosure.

Le PMI italiane risolvono il puzzle in modo strutturale: tier di retention diversi per layer di log diversi.

Tier 1 (span attributes metadata strutturati): retention 24 mesi minimum. Dato non-personal, basso peso, non viola GDPR perché non contiene PII.

Tier 2 (span events con payload redacted): retention 6-12 mesi. Permette ricostruzione incident senza espore PII.

Tier 3 (span events con payload completo per debug): retention 30 giorni. Solo se proprio necessario, in pratica si può quasi sempre evitare.

Tier 4 (full conversation transcripts per training/eval): solo se hai consenso esplicito GDPR Art. 6, retention come dichiarata nel consenso, mai oltre.

Il modello a 4 tier rende esplicita la trade-off, è auditabile, ed è quello che il legal team del cliente enterprise vuole vedere documentato. Quadro completo dei sette principi operativi nella pillar sulla sicurezza agentica per le PMI italiane.

Il runbook di incident response in 60 minuti

Tre step concreti che, applicati con disciplina, trasformano un incident catastrofico in un incident gestito. È il runbook che ho usato la mattina di domenica del caso opener.

Step uno (primi 15 minuti): contain. Disabilita temporaneamente l'agente in produzione. NON cancellare niente. NON modificare prompt di sistema, NON cambiare credenziali, NON push fix in fretta. Il sistema deve restare congelato esattamente com'era al momento dell'incident, perché se lo modifichi prima di documentare, perdi capacità di ricostruzione.

Step due (minuti 15-45): document. Apri il log della finestra temporale dell'incident. Identifica il trace ID dell'azione che ha generato il problema. Segui il trace upstream: prompt input, retrieval results, intermediate reasoning, tool calls, outputs. Estrai una root cause hypothesis usando come tassonomia di riferimento MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), che nella versione 5.4.0 di febbraio 2026 ha aggiunto tecniche agent-focused tipo "Publish Poisoned AI Agent Tool" e "Escape to Host" specificamente per scenari come quello che stai investigando. Documenta in formato Incident Report con campi standard (datetime, severity, affected systems, root cause hypothesis con classificazione ATLAS, immediate containment actions, downstream impact estimate). Tre pagine. È l'artefatto che fai vedere a clienti, regulatori, compliance officer.

Step tre (minuti 45-60): post-mortem decision. Decidi tre cose: a) Il fix tecnico (cosa cambiare per evitare ricorrenza), b) il communication plan (chi va informato, quando, con che messaggio), c) il follow-up regulatorio (DORA Art. 17 reporting timing se in scope, GDPR breach notification se PII coinvolto).

I tre step in 60 minuti producono qualcosa di mostrabile a chi è in copia con l'avvocato la domenica mattina. Senza i log, i tre step diventano tre giorni di lavoro forensic e tre settimane di damage control. Con i log, sono un'ora.

Il logging è l'investment che paga sempre

C'è una correlazione che ho visto sempre, nelle dieci-quindici PMI italiane che ho auditato negli ultimi mesi (esperienza diretta, non statistica pubblicata). Le aziende che avevano logging serio prima di un incident, sono quelle che sopravvivono all'incident con relazioni cliente intatte. Le aziende che non lo avevano, sono quelle dove l'incident diventa l'inizio di un cambio di management o, peggio, di un'azione legale prolungata.

Il logging è l'unica componente dell'infrastruttura agentica che ti serve solo quando va male, ma quando va male è l'unica cosa che conta. Implementarlo bene una volta, e dimenticarsene fino al giorno in cui ti salva la carriera, è il più alto ROI ingegneristico che vedo nelle PMI italiane in questo momento.

Plus, è artefatto DORA-utile, GDPR-utile, e AI Act Article 50-utile insieme. Investment singolo che soddisfa tre regulatory regime.

Vuoi un audit observability sul tuo agente in produzione? Il calendario è pubblico, prenota un appuntamento e parliamone. Trenta minuti gratis, poi se ha senso costruiamo insieme. Danilo Lapegna · DL Solutions