L’oversight degli agenti AI è ancora debole, dobbiamo renderlo più forte

L’oversight sugli agenti AI in azienda è ancora un’infrastruttura immatura, mentre le capability dei modelli avanzano di settimana in settimana. Jack Clark scriveva di recente su Import AI che il gap fra quello che gli agenti possono fare e quello che riusciamo a controllare si sta ampliando, non riducendo, e che le aziende che mettono agenti in produzione senza un sistema serio di supervisione stanno costruendo debito tecnico e di compliance a velocità insostenibile. Il problema è concreto, riguarda chiunque abbia un agente in produzione o stia per metterlo, e ha risposte operative che si possono iniziare a implementare lunedì mattina.

Il punto di partenza è capire cosa significa davvero oversight nel contesto agentico. Non significa “un umano che guarda ogni decisione” (irrealizzabile sui volumi), né “un umano che riceve un report mensile” (inutile sui rischi). Significa un sistema strutturato che combina logging, escalation, audit, budget cap, revisioni periodiche e capability di red teaming. Le singole componenti sono note al mondo della sicurezza IT da decenni, ma applicate agli agenti AI richiedono adattamenti specifici, perché il comportamento di un agente non è deterministico e i pattern di errore non si predicono con i tool tradizionali di monitoring.

Il rischio politico del passaggio è la prima cosa da nominare. Le aziende che mettono in produzione agenti senza oversight serio si esporranno al primo incidente significativo a perdite reputazionali, sanzioni AI Act per i sistemi ad alto rischio, contenziosi con clienti danneggiati, dimissioni di responsabili IT che si trovano a rispondere di cose che non controllavano. Il caso del database cancellato in nove secondi raccontato di recente da diverse testate non è un caso isolato, è il prototipo di una categoria di incidenti che si moltiplicheranno mentre gli agenti diventano più capaci.

I sette controlli operativi

Il pacchetto minimo di controlli che un’azienda dovrebbe mettere in piedi per supervisionare seriamente gli agenti AI in produzione è composto da sette pezzi, ciascuno dei quali risolve un problema specifico e nessuno dei quali è sufficiente da solo.

1. Logging strutturato delle decisioni dell’agente

Ogni azione dell’agente deve essere registrata in formato strutturato (JSON o equivalente) con timestamp, input ricevuto, output prodotto, tool invocati, risorse modificate, costo della richiesta. Il log non è un file di testo generico, è un dataset interrogabile che permette di ricostruire cosa è successo. Senza questo livello di logging, ogni indagine post-incidente diventa archeologia, e per gli incidenti gravi questo significa impossibilità di rispondere alle autorità di vigilanza. Strumenti utili: stack ELK (Elasticsearch, Logstash, Kibana) classico, oppure soluzioni dedicate come Langfuse o Helicone per il logging specifico degli LLM. La regola: ogni agente in produzione deve scrivere il suo log strutturato, e il log deve essere immutabile per un periodo definito da policy.

2. Policy di escalation a umano

L’agente deve avere regole chiare su quando deve fermarsi e chiedere a un umano. Le regole sono di due tipi: hard rule (l’agente non può mai fare X, per esempio scrivere su database di produzione, inviare comunicazioni a clienti, modificare file fuori da una sandbox specifica) e soft rule (l’agente chiede conferma quando l’operazione supera una soglia di costo, di rischio o di impatto). La policy di escalation va scritta prima di mettere l’agente in produzione, non dopo il primo incidente. Deve essere testata con scenari concreti e revisionata periodicamente, perché i pattern di rischio evolvono con le capability del modello sottostante.

3. Red team interno periodico

Una funzione di red teaming interna deve mettere alla prova l’agente con tentativi sistematici di farlo fallire: prompt injection, jailbreak, scenari adversarial, casi limite. Il red team non è un attacco una tantum, è una funzione continua che opera con cadenza definita (settimanale per agenti critici, mensile per quelli a rischio medio). Il team può essere interno (una persona dedicata in azienda) o esterno (consulenza specializzata in AI security). Lo standard emergente per i sistemi AI ad alto rischio prevede red teaming documentato e replicabile, e questo è uno dei punti richiesti dall’AI Act europeo per i sistemi classificati ad alto rischio.

4. SLA di risposta umana sull’escalation

Quando l’agente chiede conferma a un umano, l’umano deve rispondere entro un tempo definito. Senza SLA esplicito, le richieste di escalation si accumulano e l’agente si blocca, oppure (peggio) l’organizzazione decide di alzare le soglie di escalation rendendo l’agente più autonomo per evitare il collo di bottiglia. L’SLA di risposta è un impegno organizzativo, non un’opzione tecnica. Tipicamente quattro ore lavorative per richieste standard, trenta minuti per richieste critiche, copertura H24 per agenti che operano su processi mission-critical. Senza queste regole l’oversight è solo carta, e prima o poi qualcuno alza la soglia per non perdere produttività.

5. Audit trail integro

Il log di cui al punto 1 è materia prima, l’audit trail è il dato consolidato che permette di rispondere a domande operative: chi ha autorizzato cosa, quale catena di decisioni ha portato a un certo risultato, come si è evoluto il comportamento dell’agente nel tempo. Per i settori regolati (finanza, sanità, pubblica amministrazione) l’audit trail integro è un obbligo normativo già esistente che si estende automaticamente agli agenti AI. Per gli altri settori è una protezione legale che diventa cruciale al primo incidente o al primo contenzioso. La differenza fra log e audit trail è la garanzia di immutabilità (firma digitale o equivalente) e la presenza di metadati di catena di custodia.

6. Revisione settimanale di prompt e output

Un team designato (sicurezza, qualità, business owner) deve dedicare tempo settimanale alla revisione di un campione di prompt ricevuti dagli agenti e di output prodotti. La cadenza settimanale serve per intercettare derive di comportamento prima che diventino sistemiche: agenti che hanno iniziato a rispondere in modo strano, prompt utenti che cercano di forzare il sistema, output che contengono errori ripetuti. La revisione settimanale è un esercizio leggero (un’ora di lavoro) che permette di catturare problemi che nessun dashboard di monitoring automatico riesce a segnalare. Strumenti utili per il campionamento e la revisione: dashboard custom, oppure tool dedicati al monitoring di applicazioni LLM disponibili anche dal lato open source.

7. Budget cap automatico per agente

Ogni agente in produzione deve avere un budget massimo configurato (numero di richieste al giorno, costo massimo in dollari al giorno, numero massimo di tool invocati per sessione), e il sistema deve sospendere automaticamente l’agente quando il budget è esaurito. Senza budget cap, gli agenti che entrano in loop o vengono sfruttati da utenti malevoli possono generare fatturazioni catastrofiche in poche ore. La cifra ricorrente di sviluppatori che hanno ricevuto fatture inattese per centinaia di dollari su agenti Copilot mal configurati è il preludio a incidenti aziendali da decine di migliaia di euro su agenti di customer service o di workflow aziendale. Il budget cap è banale da implementare e protegge da una categoria di problemi non banale.

Come si costruisce il sistema, in pratica

Mettere in piedi i sette controlli non è un progetto da mesi, ma richiede uno sforzo serio nelle prime sei-otto settimane. Il pattern operativo che funziona, basato su quello che fanno le aziende che hanno preso sul serio il tema, prevede tre fasi distinte e sovrapposte.

La prima fase (due-tre settimane) è di assessment: censimento degli agenti già in produzione o in pilot, valutazione dei livelli di rischio per ciascuno, classificazione AI Act, mappatura degli stakeholder responsabili. L’output di questa fase è una matrice di rischio per agente, con livello di oversight richiesto. La fase è di solito sottovalutata, ed è quella che fa la differenza fra un sistema di oversight serio e una collezione di tool scollegati.

La seconda fase (tre-quattro settimane) è di implementazione tecnica: setup del logging strutturato, configurazione dei budget cap, implementazione delle policy di escalation, costruzione dell’audit trail. Per le aziende che già usano stack di sicurezza maturi (SIEM, log management), molto si può integrare nei sistemi esistenti. Per le aziende che partono da zero, vale la pena valutare strumenti dedicati al monitoring LLM (Langfuse, Helicone, Arize Phoenix) che hanno già le primitive necessarie.

La terza fase (due-tre settimane) è di costruzione delle pratiche organizzative: definizione SLA di risposta, organizzazione del red team interno o ingaggio del partner esterno, calendario delle revisioni settimanali, formazione del personale coinvolto. Senza questa fase il sistema tecnico costruito sopra resta inutilizzato, e la sicurezza dell’agente regredisce al livello precedente nei primi mesi.

Per il mercato italiano e gli strumenti consigliati

Per il pubblico italiano, alcuni strumenti meritano attenzione particolare. Sul lato del logging strutturato, le PMI possono partire con stack open source (Elasticsearch, Grafana Loki) che restano in casa o su cloud europei, evitando il trasferimento dei log verso piattaforme USA. Per agenti che operano in ambito AI Act-conscious, Mistral è un’opzione interessante come modello sottostante (sovrana, EU, con audit trail tracciabile lato vendor) invece di Claude o GPT, soprattutto per task non frontier dove la differenza di capability è marginale. Sul fronte gestionale, l’integrazione del sistema di oversight con i tool aziendali già in uso (Atoka, TeamSystem, MailUp, Zucchetti) richiede l’adozione di pratiche standard di logging che molti vendor locali stanno aggiornando proprio per facilitare la conformità.

Sul piano della governance, l’azienda dovrebbe nominare un responsabile AI (può essere il responsabile IT, il responsabile sicurezza, o un ruolo dedicato se la dimensione lo giustifica) che presiede al sistema di oversight. Il responsabile non è il tecnico che configura i log, è la figura organizzativa che risponde di come l’azienda usa l’AI e che dialoga con i vertici, con i clienti e con le autorità. La sua presenza è il segnale che l’oversight non è una pratica IT, è una funzione aziendale a sé. Per aziende che operano in settori regolati il ruolo è già spesso obbligatorio, per le altre è una scelta di maturità.

Il costo del non fare nulla

Sul costo dell’oversight rispetto al costo del non averlo serve un calcolo concreto. Implementare i sette controlli per un’azienda di dimensione media richiede uno sforzo tre-sei mesi di lavoro distribuito, un budget di trenta-ottanta mila euro fra strumenti, integrazione e formazione, e l’allocazione stabile di una risorsa interna (parte del tempo di un responsabile IT senior). Per una PMI di duecento dipendenti che usa agenti su customer service, marketing e supporto alle vendite, l’investimento è significativo ma non esorbitante.

Il costo del non fare nulla è invece molto più alto e meno prevedibile. Il primo incidente serio su un agente in produzione costa tre-cinque volte quello che sarebbe costato il sistema di oversight, fra rilavorazioni, perdita clienti, costi legali, riparazione reputazionale. Per agenti che operano in settori regolati le sanzioni AI Act per non conformità possono arrivare al sette per cento del fatturato globale dell’azienda, cifra che rende il calcolo del business case piuttosto netto. Le aziende che hanno fatto i conti seriamente investono nell’oversight prima che capiti l’incidente, non dopo.

C’è una lettura di sistema che chiude il quadro. La maturità dell’oversight agentico nelle aziende è oggi mediamente bassa, e questo è un’opportunità competitiva per chi si organizza per primo. Le aziende che possono dimostrare ai clienti, ai partner, alle autorità di vigilanza di avere un sistema serio di supervisione degli agenti AI guadagnano credibilità nel momento in cui il mercato sta diventando più attento al tema. Il vantaggio competitivo non sta nell’uso più aggressivo dell’AI, sta nell’uso più affidabile dell’AI. E questo si costruisce esattamente con i sette controlli descritti, applicati con disciplina e mantenuti nel tempo. Iniziare lunedì mattina con il primo punto del logging strutturato è il modo concreto di partire.