L’agente affidabile non nasce dall’autonomia: nasce dai confini

Quando si parla di agenti AI, la tentazione è quasi sempre la stessa: dare al modello più strumenti, più contesto, più libertà e aspettarsi che da questa somma emerga automaticamente più intelligenza. Il nuovo harness di security operations descritto da Cloudflare va nella direzione opposta. E proprio per questo è interessante.

Nel sistema usato da Cloudflare Managed Defense, la parte più delicata dell’indagine non viene affidata a un agente onnipotente. Prima dell’inferenza c’è codice deterministico che raccoglie le evidenze, fissa lo scope, registra fonti, versioni e timestamp. Solo dopo entrano in gioco agenti specializzati, ciascuno con un compito ristretto e con evidenze già ammesse nel dossier. La sintesi finale, a sua volta, non può andare a cercarsi nuovi dati né inventarsi una classificazione fuori dal vocabolario previsto.

È una scelta architetturale molto più importante del nome del modello utilizzato. Cloudflare racconta di aver provato prima la strada più ovvia: un singolo agente generalista a cui affidare l’intera investigazione. Il risultato produceva analisi utili, ma anche affermazioni non sostenute dalle evidenze, confusione tra ipotesi e prove, scope che poteva spostarsi e fallimenti di lookup che rischiavano di diventare invisibili. La correzione non è stata “scriviamo un prompt migliore”. È stata togliere responsabilità al modello.

Il punto non è rendere l’agente più bravo

Questa distinzione conta perché stiamo ancora progettando molti sistemi agentici come se l’affidabilità fosse una proprietà emergente del modello. Se il modello è abbastanza capace, pensiamo, saprà usare correttamente gli strumenti, capire quali dati sono affidabili, rispettare lo scope e distinguere un dato assente da un controllo fallito.

Ma sono responsabilità diverse. E quando le comprimiamo tutte dentro la stessa inferenza, perdiamo la possibilità di capire dove si è rotto il processo.

Un agente affidabile non è quello a cui concedi abbastanza autonomia da cavarsela. È quello a cui togli abbastanza ambiguità da rendere verificabile ciò che fa.

Nel progetto descritto da Cloudflare, la ricognizione iniziale è eseguita da workflow deterministici con chiamate API versionate. Identità del cliente, cronologia delle detection, baseline del traffico, outcome dei controlli e osservazioni di rete vengono raccolti prima che un modello inizi a interpretare. Questo crea uno snapshot riproducibile: se due analisi divergono, la differenza deriva dall’interpretazione, non dal fatto che nel frattempo un agente abbia interrogato una sorgente diversa o una finestra temporale diversa.

Raccolta e interpretazione sono due mestieri diversi

È qui che il caso SOC diventa un principio generale di progettazione software. Recuperare un dato e interpretarlo non sono la stessa operazione. Stabilire quale tenant si può interrogare e decidere cosa significa il risultato non sono la stessa operazione. Verificare che una citazione appartenga davvero all’indagine e formulare una raccomandazione non sono la stessa operazione.

Se lasciamo che il modello faccia tutto, ogni passaggio diventa probabilistico. Se invece rendiamo deterministiche le parti che possono esserlo, conserviamo l’AI dove serve davvero: nella classificazione di segnali complessi, nel confronto tra evidenze, nella sintesi e nella formulazione di ipotesi.

Cloudflare usa un coordinatore che avvia quattro specialisti in parallelo: analisi del traffico, contesto del cliente, telemetria globale e threat intelligence. Gli specialisti producono risultati tipizzati. Un agente di sintesi li combina, ma non può acquisire nuove evidenze. Inoltre il codice applicativo controlla che le citazioni esistano, appartengano all’indagine e sostengano davvero il claim associato.

Questa è una differenza enorme rispetto al pattern “agente con accesso a tutto”. L’orchestrazione non serve soltanto a dividere il lavoro: serve a ridurre l’autorità di ogni singolo componente.

Un errore deve restare un errore

C’è un dettaglio che considero particolarmente importante: il sistema distingue esplicitamente tra “non controllato”, “controllato senza risultato” e “controllato con evidenza che supporta l’assenza”. Sembrano sfumature linguistiche. In realtà sono stati operativi diversi.

Un lookup che va in timeout non equivale a una sorgente che non contiene indicatori. Un’API non raggiungibile non equivale a un controllo negativo. Quando questi stati vengono appiattiti dentro una risposta naturale, il sistema diventa molto convincente proprio nel momento in cui dovrebbe dichiarare un limite.

È lo stesso principio che vale quando si costruiscono workflow agentici per sviluppo software, automazioni aziendali o processi che spendono denaro. Nel mio articolo sul budget come guard rail per gli agenti AI il confine era economico. Qui il confine è epistemico: cosa è stato verificato, con quale evidenza e dentro quale scope.

La memoria utile non è un prompt più lungo

Il sistema conserva anche la storia delle decisioni: quante volte un alert è comparso, come è stato classificato in precedenza e quale conclusione ha raggiunto l’analista. Ma questa memoria non viene trattata come verità indistinta da riversare nel contesto. È evidenza con provenienza e ruolo.

Questo evita un altro errore frequente: confondere “più contesto” con “più qualità”. Un contesto enorme, senza gerarchie e senza provenienza, può aumentare l’ambiguità. Un dossier più piccolo ma strutturato può invece rendere più facile verificare ogni passaggio.

Lo stesso ragionamento emerge nei benchmark seri per sistemi AI: non basta osservare che una risposta sembra buona. Serve una filiera che renda controllabile il percorso. È il motivo per cui un benchmark per la code review AI diventa interessante quando misura comportamento e risultati invece di limitarsi alla demo.

Human in the loop non significa mettere una persona alla fine

Nel design di Cloudflare l’analista resta responsabile della decisione e della mitigazione. Ma il punto non è semplicemente avere un essere umano che preme “approva”. Il sistema prepara il lavoro in modo che quella decisione sia informata: mostra evidenze, gap di copertura, raccomandazioni e limiti.

Un human in the loop messo alla fine di una catena opaca rischia di diventare una firma burocratica. Se invece l’intera catena conserva provenance, scope e stati di fallimento, l’intervento umano torna ad avere senso perché può contestare la raccomandazione sulla base di qualcosa di osservabile.

L’architettura dell’autonomia

La lezione più utile di questo caso non è che servono quattro agenti invece di uno. Il numero è contingente. Il principio è separare ciò che deve essere deterministico da ciò che può essere inferenziale, ridurre lo scope prima di chiamare il modello e rendere espliciti i fallimenti.

Più un agente può agire su sistemi reali, meno dovremmo affidarci alla speranza che “capisca” i confini dal prompt. I confini importanti vanno implementati nel software: tenant, strumenti disponibili, dati ammessi, vocabolari di output, budget, transizioni di stato, approvazioni e capacità di azione.

È meno spettacolare dell’agente universale che fa tutto da solo. Ma è anche il punto in cui un prototipo comincia ad assomigliare a un sistema.