Caso studio: sistema agentico per analytics operations

Una metric review del lunedì mattina, in una scale-up da circa 200 persone, dura quaranta minuti e decide dove vanno due settimane di lavoro di tre team. Sul tavolo c’è un calo di conversione del 6 per cento in sette giorni, una pipeline di eventi in ritardo di tre ore e una campagna che sembra performare meglio proprio mentre il tracciamento perde colpi. L’analista arriva con dodici query, quattro dashboard e un’ipotesi a metà. Il resto della stanza vuole una risposta netta che i dati, presi così, non possono dare. Questo è il punto in cui un sistema agentico per le analytics operations si gioca tutto: non nella capacità di generare testo convincente, ma nel ridurre l’attrito tra domanda, dato, controllo e decisione senza perdere tracciabilità. La lezione appartiene al binario sistemi-llm.

Il sistema descritto qui è un disegno operativo completo, assemblato da pattern osservati in produzione in contesti simili. Prepara la review settimanale, monitora freshness e qualità, propone query e controlli, apre ticket e bozze di memo. Ogni azione che tocca dati, soldi o comunicazioni esterne passa da un owner umano e lascia una traccia ricostruibile. Il resto gira in autonomia dentro confini dichiarati. Tratterò l’architettura, il contratto dati, i guardrail, l’osservabilità, la gestione degli incidenti e i costi, con codice e numeri dove servono.

Perché un agente per le analytics si giudica dalle operations

Un agente che risponde bene in demo e crolla in produzione ha quasi sempre lo stesso difetto: è stato valutato sulle risposte e non sul ciclo operativo. Nelle analytics il lavoro vero non è scrivere una query ma mantenere un ciclo settimanale fatto di definizioni condivise, controlli ripetibili, soglie di allerta sensate e handoff puliti verso chi decide. Se l’agente accelera la scrittura ma rende opachi questi passaggi, il team va più veloce verso conclusioni più fragili.

Fisso quindi il criterio di giudizio usato per tutto il caso: il sistema è buono se, a parità di domanda, riduce il tempo dalla domanda alla decisione difendibile senza abbassare il tasso di decisioni che reggono a una review indipendente dopo trenta giorni. Velocità e qualità vanno misurate insieme, perché ciascuna da sola mente. Un team che chiude le analisi in due ore ma deve riaprirne una su tre ha peggiorato le operations, non le ha automatizzate.

C’è un secondo motivo per partire dalle operations. Gli errori costosi nelle analytics raramente sono errori di sintassi SQL. Sono errori di perimetro: metrica calcolata sulla popolazione sbagliata, confronto tra periodi non comparabili, segmento letto senza tenere conto della composizione, evento contato due volte dopo un cambio di tracking. Un agente addestrato a produrre output plausibili amplifica proprio questa classe di errori, perché li riveste di un linguaggio sicuro. L’unica difesa è un disegno in cui ogni affermazione numerica è legata a query eseguita, intervallo dichiarato, regola di esclusione e finestra temporale dichiarata.

Il perimetro del caso: cosa entra nel sistema e cosa resta fuori

Il caso riguarda una pipeline decisionale concreta: ogni settimana il sistema prepara la metric review su attivazione, conversione e retention a sette giorni, sorveglia la salute dei dati sottostanti e propone azioni correttive. Gli input sono il data warehouse, il catalogo metriche, i log delle pipeline e il backlog dei ticket. Gli output sono tre artefatti revisionabili: un memo pre-review con ipotesi e controlli, una dashboard annotata con le variazioni che superano le soglie, e ticket già compilati per tracking, dati o esperimenti. Niente di tutto questo viene inviato o applicato senza approvazione umana.

La tabella sotto rende esplicito il confine di autonomia, che è la parte che la maggior parte dei progetti agentici lascia implicita finché non succede un incidente.

Azione	Autonomia	Controllo
Leggere warehouse, log, catalogo	Autonoma	Solo tabelle e colonne autorizzate, query in sola lettura
Eseguire query analitiche	Autonoma entro budget	Timeout, limite di righe, costo stimato per query
Proporre spiegazioni del calo	Autonoma come bozza	Ogni spiegazione deve citare query e controllo alternativo
Aprire ticket di investigazione	Semi-autonoma	Bozza compilata, invio solo dopo approvazione
Modificare pipeline o tracking	Vietata all’agente	Solo umani con change request e code review
Pubblicare dashboard o memo	Vietata come atto finale	L’agente prepara la bozza, l’owner firma

Questa distinzione tra delegabile e non delegabile va scritta prima di scegliere qualsiasi framework. Le query di lettura e le sintesi sono delegabili perché l’errore è reversibile e rilevabile in review. Le scritture su produzione, le comunicazioni agli stakeholder e le decisioni di budget non lo sono, perché l’errore ha effetti esterni. Il resto del disegno discende da qui: permessi stretti, approvazioni esplicite, e un registro che distingue sempre evidenza, ipotesi e raccomandazione.

L’architettura del sistema agentico end-to-end

Il sistema è composto da quattro agenti specializzati coordinati da un orchestratore, non da un unico agente generalista. La scelta è deliberata: un agente solo tende a mescolare compiti con tolleranze di errore diverse, mentre agenti separati permettono permessi, prompt e criteri di valutazione distinti. L’orchestratore riceve la domanda settimanale, la scompone in sotto-compiti, assegna ciascuno all’agente giusto e assembla i tre artefatti finali. Non esegue query direttamente e non scrive output verso l’esterno: il suo lavoro è pianificare, instradare e verificare che ogni affermazione abbia una citazione di provenienza.

I quattro agenti coprono raccolta, analisi, verifica e comunicazione. Il raccoglitore interroga warehouse e log e restituisce tabelle intermedie con metadati di freschezza. L’analista propone segmentazioni e ipotesi leggendo solo quelle tabelle, mai le sorgenti grezze. Il verificatore ripete i calcoli chiave con query indipendenti e segnala discrepanze oltre una tolleranza fissata. Il redattore assembla il memo distinguendo evidenza, ipotesi e raccomandazione. Separare analista e verificatore è la decisione più importante: impedisce che lo stesso processo che genera un numero sia anche l’unico a controllarlo, che è esattamente il meccanismo con cui le allucinazioni numeriche passano inosservate.

Lo stato condiviso vive in un oggetto di contesto versionato, non nella cronologia della chat. Ogni esecuzione settimanale crea un run identificato da un ID, con dentro domanda, finestra temporale, definizioni di metrica usate, query eseguite con i loro hash, risultati intermedi e approvazioni raccolte. Gli agenti leggono e scrivono solo i campi per cui hanno permesso. Questo rende il run riproducibile: rieseguendo lo stesso ID con gli stessi snapshot si ottengono gli stessi numeri, e un reviewer può ricostruire ogni passaggio senza rileggere conversazioni. Quando il contesto supera la finestra utile, l’orchestratore lo compatta conservando definizioni, query e decisioni, e scartando il testo discorsivo.

# Struttura del run settimanale: stato condiviso versionato tra agenti
from dataclasses import dataclass, field

@dataclass
class RunContext:
    run_id: str  # identificatore univoco dell'esecuzione settimanale
    domanda: str  # decisione da supportare, non tema generico
    finestra: tuple[str, str]  # inizio e fine periodo, formato ISO
    definizioni_metriche: dict  # nome metrica -> versione del catalogo
    query_eseguite: list[dict] = field(default_factory=list)  # SQL + hash + righe
    approvazioni: list[dict] = field(default_factory=list)  # chi ha approvato cosa

def puo_pubblicare(run: RunContext) -> bool:
    # pubblicazione consentita solo con evidenza e approvazione entrambe presenti
    ha_evidenza = len(run.query_eseguite) > 0
    ha_owner = any(a["ruolo"] == "owner" for a in run.approvazioni)
    return ha_evidenza and ha_owner

Il coordinamento segue un grafo esplicito con checkpoint umani, non una catena libera in cui ogni agente chiama il successivo a piacere. Il flusso è raccolta, poi analisi e verifica in parallelo, poi redazione, poi approvazione. Se il verificatore trova una discrepanza sopra soglia, il grafo torna all’analisi invece di procedere: il memo non viene mai assemblato sopra numeri contestati. Questo vincolo strutturale vale più di qualsiasi istruzione nel prompt, perché non dipende dal modello che decide di obbedire.

Il contratto dati: metriche, semantic layer e qualità

Nessun agente ragiona bene sopra definizioni ambigue. Il contratto dati del caso è un semantic layer con tre proprietà: ogni metrica ha una definizione SQL versionata, ogni dimensione ha valori ammessi documentati, ogni tabella dichiara freshness attesa e owner. La conversione a sette giorni, per esempio, esiste in versione certificata che conta solo utenti con evento di attivazione valido ed esclude il traffico interno di test. L’agente non sceglie la definizione: la legge dal catalogo e la cita nel memo. Se la definizione manca o è scaduta, il run si ferma su quel punto invece di improvvisare.

La qualità viene controllata prima dell’analisi, non dopo, con una batteria di test leggeri che l’agente esegue a ogni run. Freschezza delle tabelle critiche, completezza delle colonne chiave, unicità degli identificatori, coerenza dei totali tra tabelle aggregate e dettaglio. Ognuno ha una soglia numerica scritta nel contratto, non un giudizio qualitativo. Un esempio reale dal caso: la tabella eventi dichiara un ritardo massimo accettabile di due ore; quando il run trova tre ore e mezza, il memo segnala dati parziali e declassa ogni affermazione sulla settimana corrente da evidenza a ipotesi in attesa. Questa è la differenza tra un sistema che sbaglia con onestà dichiarata e uno che presenta numeri mozzati come definitivi.

Il confronto tra periodi o segmenti compare nel memo sempre con l’incertezza dichiarata, perché senza intervallo un calo del 6 per cento su un segmento piccolo sembra uguale a un calo del 6 per cento sull’intera base utenti, e non lo è. La regola operativa è semplice: sotto una numerosità minima per cella, l’agente non commenta la variazione ma la marca come non valutabile. Sembra prudenza eccessiva finché non si conta quante decisioni sbagliate nascono da segmenti da poche decine di utenti letti come trend.

Guardrail, approvazioni e audit trail in produzione

I permessi del sistema seguono il principio del minimo privilegio applicato alle query prima che ai file. L’agente di raccolta ha accesso in sola lettura a dodici tabelle autorizzate, con viste che mascherano gli identificativi diretti e troncano gli attributi quasi-identificanti. Niente letture integrali sulle tabelle grezze, niente accesso alle credenziali di ingestion, niente esecuzione di DDL o DML. Ogni query passa da un gate che controlla tre cose: sintassi contro un allowlist di costrutti, stima del costo sotto soglia, e assenza di pattern che indicano esfiltrazione come join cartesiani o estrazioni massive di righe utente. Una query che viola una qualsiasi delle tre viene rifiutata prima dell’esecuzione, e il rifiuto entra nel registro del run.

Le approvazioni sono modellate come transizioni di stato, non come reazioni via chat. La bozza di memo nasce in stato bozza, passa a in revisione quando il verificatore la firma, e diventa approvata solo con la firma dell’owner umano. I ticket seguono lo stesso schema: compilati dall’agente, inviati solo dopo approvazione. Questo dettaglio conta perché una approvazione via messaggio libero non dice cosa è stato approvato né in quale versione. Una transizione di stato registra versione dell’artefatto, hash delle query sottostanti e identità del firmatario, e rende l’audit una lettura del registro invece di una ricostruzione a posteriori.

-- Query di verifica indipendente: ricalcola la conversione senza riusare la CTE dell'analista
-- Confronta il risultato con quello dell'analista entro una tolleranza prefissata
SELECT
  COUNT_IF(has_purchase_7d) * 1.0 / NULLIF(COUNT(*), 0) AS conv_7d_verifica,
  COUNT(*) AS n_coorte  -- numerosita: sotto soglia la variazione non si commenta
FROM mart_activation weekly_cohort
WHERE cohort_week = '2026-08-24'  -- finestra dichiarata, mai implicita
  AND is_internal_traffic = FALSE;  -- esclusione traffico test da definizione v3

L’audit trail risultante risponde a tre domande che un revisore farà sempre: da dove viene questo numero, chi lo ha approvato, cosa succede se è sbagliato. Provenienza significa hash della query, snapshot della definizione di metrica e timestamp di esecuzione. Approvazione significa identità e versione firmata. Impatto significa classificazione dell’azione in reversibile o esterna, con piano di rollback per la prima e divieto di autonomia per la seconda. Senza queste tre colonne, il sistema può essere intelligente ma non è esercibile in un contesto dove qualcuno risponde delle decisioni.

Osservabilità, valutazioni e controllo dei costi applicati al caso

L’osservabilità del caso copre tre strati: comportamento degli agenti, salute dei dati, esito delle decisioni. Sul primo strato il sistema registra per ogni run numero di passi, tool chiamati, query rifiutate dal gate, cicli di riprova e token consumati. Sul secondo, freshness, completezza e discrepanze del verificatore. Sul terzo, il destino delle raccomandazioni: accettate, modificate o respinte dall’owner, e dopo trenta giorni se la decisione ha retto. Solo il terzo strato dice se il sistema serve a qualcosa; i primi due dicono perché funziona o si rompe. Un cruscotto che mostra solo token e latenza descrive l’infrastruttura, non il valore.

Le valutazioni sono ancorate a scenari con risposta nota, costruiti dagli incidenti passati del team. Un eval tipico inietta in un dataset sintetico un calo di conversione interamente spiegato da un cambio di mix tra segmenti, e verifica che l’agente segnali l’effetto composizione invece di attribuire il calo al prodotto. Un altro introduce un buco di tracking di sei ore e controlla che il sistema declassi le affermazioni invece di commentare dati parziali come definitivi. La metrica di eval non è la fluenza del memo ma la percentuale di scenari in cui il sistema produce la classificazione corretta di evidenza contro ipotesi. Sotto una soglia concordata, il sistema non viene promosso alla review reale ma torna in laboratorio.

Il controllo dei costi applica a ogni run la somma di chiamate al modello per token in ingresso e uscita più query al warehouse per costo medio. Nel caso, un run settimanale completo consuma l’ordine di poche decine di chiamate e una ventina di query, per un costo unitario che resta trascurabile rispetto a un’ora di lavoro analista. Il rischio non è il singolo run ma la moltiplicazione silenziosa: run orari non necessari, riprove infinite su query fallite, contesti che crescono a ogni iterazione. I freni sono tre tetti rigidi scritti nella configurazione: budget massimo di token per run, numero massimo di riprove per query, e downgrade automatico a modello minore per i sotto-compiti di sintesi quando il budget è sotto pressione.

Incidenti, drift e fallback: quando il sistema deve fermarsi

Il sistema definisce in anticipo le condizioni che lo fermano, perché un agente senza criterio di stop degrada in silenzio. Tre soglie sono scritte nel contratto operativo. Se la freshness supera il ritardo massimo, il run produce solo un bollettino dati senza analisi. Se il verificatore trova discrepanze sopra la tolleranza su due metriche primarie, il memo non viene assemblato e il caso passa a investigazione manuale. Se il tasso di raccomandazioni respinte dall’owner supera il 40 per cento su quattro settimane consecutive, l’autonomia viene ridotta al solo strato di raccolta finché gli eval non tornano sopra soglia. Ognuna di queste regole è stata scritta dopo aver visto il corrispondente failure mode in produzione, non per prudenza teorica.

Il drift merita un trattamento separato perché nelle analytics cambia il significato dei numeri senza rompere nulla tecnicamente. Un cambio di definizione nel tracking, una nuova versione dell’app che modifica il funnel, una campagna che sposta il mix di acquisizione: la pipeline resta verde e le metriche diventano non comparabili. Il sistema contrasta il drift con tre strumenti. Versionamento delle definizioni con date di validità, così un confronto tra periodi con definizioni diverse viene bloccato o annotato. Monitoraggio della composizione dei segmenti, così uno spostamento di mix oltre soglia genera un avviso prima dell’interpretazione. Un registro delle modifiche note, alimentato dai ticket di tracking, che l’orchestratore consulta prima di assegnare i compiti di analisi.

# Gate di stop: il run si ferma o si declassa prima di produrre analisi
def valuta_run(freshness_ore: float, discrepanza: float, definizioni_ok: bool) -> str:
    SOGLIA_FRESHNESS = 2.0  # ore massime di ritardo accettabile
    TOLLERANZA = 0.005  # discrepanza massima tra analista e verificatore
    if freshness_ore > SOGLIA_FRESHNESS:
        return "solo_bollettino_dati"  # dati parziali: nessuna analisi
    if not definizioni_ok or discrepanza > TOLLERANZA:
        return "investigazione_manuale"  # numeri contestati: si ferma tutto
    return "procedi"  # tutti i controlli superati

Il fallback non è un messaggio di errore ma un prodotto utile ridotto. A seconda del gate scattato, il sistema consegna un bollettino dati con tabelle e freshness dichiarata, oppure una lista di controlli manuali suggeriti con le query già pronte, oppure un memo parziale dove ogni sezione porta l’etichetta del suo stato di verifica. L’etichettatura è la parte che richiede disciplina: tre livelli, evidenza verificata, ipotesi con controllo proposto, e non valutabile per numerosità o dati insufficienti. Un memo dove tutto è scritto nello stesso registro linguistico, che sia certo o congetturale, è il failure mode più costoso dell’intero sistema.

La settimana tipo: numeri, controlli e decisione

Per rendere concreto il disegno, seguo un run settimanale completo. Il lunedì alle 7 il sistema si attiva: la coorte di attivazione della settimana precedente conta 8.400 utenti, la conversione a sette giorni è al 21,3 per cento contro il 22,7 della baseline mobile a quattro settimane. Il calo grezzo è di 1,4 punti, circa il 6 per cento relativo. Prima di qualsiasi interpretazione, i test di qualità danno esito misto: freshness della tabella eventi a tre ore e mezza contro un massimo di due, completezza delle colonne chiave al 99,1 per cento, nessun duplicato sugli identificatori. Il run marca subito i dati della settimana come parziali e imposta il registro linguistico di conseguenza.

L’analista propone tre ipotesi: peggioramento reale del funnel, spostamento del mix verso un segmento a bassa conversione, artefatto da ritardo di ingestion sugli eventi di acquisto più recenti. Il verificatore ricalcola la metrica con query indipendente e trova 21,4 contro 21,3, discrepanza dentro la tolleranza, ma la segmentazione mostra che il mix spiega quasi tutto: il segmento a bassa conversione è passato dal 31 al 38 per cento della coorte per una campagna appena lanciata, e a mix costante il calo si riduce a 0,3 punti con intervallo che include lo zero. La terza ipotesi resta aperta perché il ritardo di ingestion colpisce proprio gli ultimi due giorni della finestra, quindi la stima è segnata come provvisoria in attesa del run di consolidamento.

Ipotesi	Controllo eseguito	Esito
Calo reale del funnel	Conversione a mix costante, errore standard	Rientrato: residuo 0,3 punti, non significativo
Spostamento del mix	Quota segmento per settimana, quattro settimane	Confermato: +7 punti di quota al segmento debole
Ritardo di ingestion	Freshness tabella, confronto con run precedente	Aperto: ultimi due giorni parziali, consolidare

Il memo finale consegna una raccomandazione difendibile: non toccare il funnel, verificare il targeting della campagna che ha spostato il mix, e rieseguire il consolidamento dopo il recupero del ritardo prima di qualsiasi comunicazione esterna. L’owner approva con una modifica, aggiungendo un tetto di spesa alla campagna finché il mix non rientra. Il ticket risultante contiene ipotesi, controlli, query con hash e criterio di chiusura. Trenta giorni dopo, la review retrospettiva registra che la decisione ha retto: il funnel era sano, il problema era il mix. Questo è il ciclo completo che il sistema deve produrre ogni settimana, non un report ben scritto ma una decisione che regge al controllo successivo.

Quando questo disegno non funziona e cosa usare al suo posto

Il sistema descritto ha costi fissi che lo rendono sproporzionato sotto una certa scala. Quattro agenti, un semantic layer versionato, eval ancorati a scenari e un registro delle approvazioni richiedono manutenzione continua: definizioni da aggiornare, soglie da ricalibrare, eval da estendere a ogni nuovo failure mode. Per un team di due persone con una dashboard e decisioni reversibili, questo impianto è sovradimensionato. Un singolo assistente di analisi con query in sola lettura e review umana diretta produce quasi tutto il valore con una frazione della complessità. La regola pratica è che l’orchestrazione multi-agente si giustifica quando il volume di decisioni supera la capacità di review diretta, non prima.

Ci sono poi contesti dove l’automazione dell’interpretazione è sconsigliabile a qualsiasi scala. Dati con vincoli legali stretti e identificativi sensibili, metriche che alimentano reporting regolamentato, esperimenti con implicazioni su prezzi o accesso al servizio: qui l’agente resta uno strumento di preparazione con perimetro ridottissimo, e l’interpretazione resta interamente umana. Il segnale che distingue i due casi è la reversibilità dell’errore: se un’interpretazione sbagliata produce effetti esterni difficili da annullare, il guadagno di velocità non compensa il rischio. Il disegno resta valido come schema di tracciabilità, ma l’autonomia va riportata quasi a zero.

Un terzo limite riguarda la maturità dei dati. Se le definizioni cambiano ogni mese senza versionamento, se il tracking perde eventi senza avvisi, se nessuno sa quale tabella fa fede per quale metrica, l’agente non risolve il disordine ma lo accelera. In quel caso il lavoro propedeutico viene prima dell’agentic AI: catalogo metriche minimo, test di qualità sulle tabelle critiche, owner nominati. Solo quando il run manuale è già disciplinato ha senso automatizzarne le parti ripetitive. Automatizzare sopra fondamenta instabili produce memo puntuali pieni di numeri sbagliati, che è peggio di analisi lente ma oneste.

Cosa portarsi a casa per disegnare il proprio sistema

Il filo che attraversa il caso si riduce a cinque decisioni che ogni team deve prendere esplicitamente prima di scrivere il primo prompt. Prima, il confine di autonomia scritto come tabella di azioni permesse, semi-autonome e vietate, con controlli associati. Seconda, la separazione tra chi genera i numeri e chi li verifica, implementata come agenti distinti o almeno come query indipendenti con tolleranza dichiarata. Terza, il contratto dati con definizioni versionate, soglie di qualità numeriche e regola di declassamento quando i dati sono parziali. Quarta, le approvazioni come transizioni di stato con versione e firmatario, mai come assensi informali in chat. Quinta, i criteri di stop che fermano o riducono il sistema quando freshness, discrepanze o tasso di rigetto superano le soglie.

Per chi parte da zero, la sequenza di adozione consigliata segue l’ordine di rischio crescente. Si comincia con l’agente di raccolta in sola lettura sopra poche tabelle, con gate sulle query e registro dei run. Poi si aggiunge il verificatore indipendente e l’etichettatura evidenza-ipotesi-non valutabile nei memo. Solo dopo si introducono ticket semi-autonomi e dashboard annotate, e per ultima l’orchestrazione completa con eval ancorati agli incidenti reali. Ogni stadio resta in funzione almeno quattro settimane con misura del tempo risparmiato e del tasso di decisioni che reggono a trenta giorni, perché promuovere uno stadio senza queste due misure significa automatizzare alla cieca.

Resta una domanda da portare nella propria organizzazione, quella che apre ogni run ben disegnato: quale decisione concreta deve migliorare la prossima settimana, quale numero la sostiene, e quale controllo ci farebbe cambiare idea. Se la risposta sta in tre righe precise, il sistema agentico ha fondamenta su cui costruire. Il resto, agenti, prompt, cruscotti e soglie, è tecnica al servizio di quella chiarezza. La tecnica si copia dai casi studio; la chiarezza sulla decisione va costruita sul proprio lavoro, ed è la parte che nessun agente può delegare.

Verdetto: adotta l’orchestrazione completa solo sopra una scala che la giustifica, con raccolta autonoma, verifica indipendente e owner che firma; sotto scala o con dati immaturi, assistente in sola lettura e review diretta.

Il caso in una frase

Il caso end-to-end mostra come quattro agenti specializzati preparino la review settimanale dentro confini di autonomia scritti e approvazioni tracciate.

La sequenza operativa in cinque passi

1. Fissa il perimetro con tabella di azioni autonome, semi-autonome e vietate.
2. Esegui raccolta, analisi e verifica con query indipendenti e tolleranza dichiarata.
3. Declassa ogni affermazione su dati parziali da evidenza a ipotesi in attesa.
4. Approva memo e ticket come transizioni di stato con versione e firmatario.
5. Ferma o riduci il sistema su freshness, discrepanze o rigetti oltre soglia.

Un caso reale: il costo di un comando senza gate

Il 31 gennaio 2017 GitLab ha cancellato per errore il database di produzione e ha perso circa 6 ore di dati su issue, merge request e commenti. Il ripristino è avvenuto da un backup di 6 ore prima, con il servizio fermo mentre il team ricostruiva tutto in diretta pubblica. Il post-mortem ha portato a backup verificati, runbook provati e permessi ridotti. Il caso mostra perché lineage, backup testati e gate sulle scritture vengono prima dell’automazione: senza, un singolo comando cancella il lavoro di migliaia di team.

Domande per chiudere la lezione

1. Cosa entra nel perimetro del sistema e cosa resta sempre vietato all’agente?
2. Perché analista e verificatore devono restare due agenti separati?
3. Quando un run produce solo un bollettino dati senza analisi?
4. Quali cinque decisioni prendi prima di scrivere il primo prompt?