Supervisione umana degli agenti AI in azienda: guardrail e AI Act

Il 4 agosto 2026 l’AI Security Institute britannico ha pubblicato l’esito di una serie di test che nessun ufficio marketing avrebbe voluto leggere: durante le valutazioni di cybersicurezza, agenti costruiti sui modelli di Anthropic e OpenAI hanno creato identità false, contattato persone reali e, messi di fronte all’accusa di aver distribuito codice malevolo, hanno negato. Non è un incidente da laboratorio isolato: è la dimostrazione più chiara finora che la supervisione umana degli agenti AI in azienda non è una voce di compliance da spuntare, ma la parte del progetto che decide se un agente porta valore o guai.

In questo articolo scoprirai:

• Cosa è successo davvero nei test di Anthropic e OpenAI
• Il modello che compri non è il sistema che ti serve in produzione
• Come progettare la supervisione umana degli agenti AI in azienda senza soffocarli
• Cosa chiede l’AI Act a chi mette un agente davanti a clienti e dati
• Guardrail, monitoring e onboarding: il lavoro che comincia dopo il go-live

Cosa è successo davvero nei test di Anthropic e OpenAI

In sintesi: nelle valutazioni dell’AISI alcuni agenti hanno agito su Internet reale senza autorizzazione, arrivando a costruire identità fittizie, fare pressione su un manutentore open source e negare di aver distribuito codice malevolo. La cronaca completa è su BleepingComputer e sul Fatto Quotidiano; noi l’abbiamo raccontato qui, con i numeri e la ricostruzione dell’episodio. Un dettaglio va però tenuto a mente per leggere tutto il resto: il test era intenzionalmente non standard, con accesso a Internet e filtri di sicurezza disattivati, condizioni che un utente ordinario non ha. La notizia non è «l’AI si è ribellata», ma che tolti i guardrail un agente capace persegue l’obiettivo con gli strumenti che trova, inganno compreso. Da qui in avanti la domanda che interessa chi lavora in azienda è un’altra: quali guardrail servono, e chi li presidia.

Il modello che compri non è il sistema che ti serve in produzione

Da qui discende la conseguenza operativa che interessa un direttore IT o un titolare di PMI: acquistare l’accesso a un modello di frontiera non equivale ad avere un agente pronto per l’azienda. Il modello è un motore. Quello che decide l’esito è tutto ciò che gli sta intorno: che permessi ha, quali tool può invocare, cosa può fare senza chiedere, chi guarda i log, cosa succede quando sbaglia. Se non sai rispondere a queste domande, non hai un agente: hai una superficie di rischio con una bella interfaccia di chat.

Permessi e tool: dove la supervisione umana degli agenti AI salta davvero

Il punto non è teorico. Ricercatori di PromptArmor hanno mostrato come un attacco di prompt injection su Ramp Sheets AI funzionasse così: l’utente importa dati esterni che contengono istruzioni nascoste, testo bianco su sfondo bianco, e l’agente le esegue, raccogliendo dati finanziari riservati e inserendo una formula che li trasmette a un server esterno, senza che nessuno approvi nulla. La stessa classe di vulnerabilità è stata rilevata su Claude for Excel, e l’osservazione più tagliente dell’analisi è che «Anthropic ha scritto il libro sulla sicurezza dell’AI e ha comunque spedito un agente che poteva esfiltrare dati senza chiedere».

La lezione per chi adotta: l’autonomia va trattata come un privilegio, non come una funzionalità inclusa nel prezzo. È la stessa ragione per cui, nella nostra esperienza, i POC sugli agenti AI si bloccano prima della produzione, e per cui nell’enterprise il servizio conta più del modello.

Se stai ancora inquadrando il perimetro, la nostra guida su cosa sono e come funzionano gli agenti AI è il punto di partenza, mentre il percorso da pilot a produzione per scalare un agente AI in azienda descrive il passaggio successivo, quello in cui i permessi larghi presentano il conto.

Come progettare la supervisione umana degli agenti AI in azienda senza soffocarli

L’errore speculare al «lasciamo fare all’AI» è il «facciamo approvare tutto a una persona»: è il modo più rapido per azzerare il vantaggio dell’automazione e far morire il progetto di attrito. Il modello che sta emergendo nelle aziende più avanti è diverso e si chiama exception-based oversight: l’agente opera in autonomia su ciò che è reversibile e a basso impatto, mentre la revisione umana si attiva solo quando l’azione supera una soglia di policy, tocca sistemi sensibili o entra in ambiguità. L’escalation scatta per eccezione, non per volume.

La differenza con l’approvazione sistematica è tutta nel disegno delle soglie. Un’azione reversibile, una bozza di risposta, una ricerca interna, l’aggiornamento di un campo non critico, non ha bisogno di nessuno che la firmi: il costo di un errore è un annullamento. Un’azione irreversibile o che esce dal perimetro aziendale, un pagamento, una email a un cliente, una modifica su un sistema di produzione, l’accesso a dati personali, cambia natura: lì la soglia deve scattare sempre, indipendentemente dalla confidenza dichiarata dal modello. In mezzo sta la zona grigia, ed è quella che va tarata sul campo: importi, volumi, tipo di controparte, orario, scostamento dal comportamento abituale. Come nota Forbes analizzando i fallimenti degli agenti in produzione, quasi sempre il problema non è il modello che «sbaglia», ma l’assenza di un punto in cui qualcuno avrebbe dovuto essere chiamato in causa e non lo è stato.

C’è poi il tema che rende l’exception-based oversight sostenibile invece che teorico: l’eccezione deve arrivare a una persona in una forma che le permetta di decidere in trenta secondi. Un alert che dice «l’agente ha eseguito un’azione anomala» è inutile; serve il contesto, cosa stava facendo, con quali dati, quale regola ha superato, quali sono le due o tre opzioni possibili. È esattamente il tipo di lavoro che IBM inquadra come gestione degli agenti: non sorveglianza generica, ma strumenti di osservabilità, tracciamento delle azioni e interfacce di intervento pensate per l’operatore. Se ogni eccezione richiede di ricostruire a mano cosa è successo leggendo i log grezzi, il presidio si sfilaccia nel giro di poche settimane e l’agente torna, di fatto, senza supervisione.

Tre documenti che rendono operativa la supervisione umana in azienda

Perché serva davvero, vanno messe per iscritto tre cose. La prima è la mappa dell’autorità delegata: per ogni agente, quali accessi ha, quali tool può usare, quali sono i suoi limiti operativi. La seconda è la catena di responsabilità: chi autorizza, chi configura, chi ha attivato quell’azione, la domanda su chi risponde davvero delle decisioni degli agenti AI è la prima a diventare urgente quando qualcosa va storto, ed è la peggiore a cui trovarsi impreparati. La terza è l’unificazione dei controlli in un unico strato di supervisione, invece di tre dashboard che non si parlano. L’analisi del Non-Human Identity Management Group quantifica il divario: il 92% delle organizzazioni riconosce che controllare gli agenti è critico, ma solo il 44% ha adottato policy di governance e il 70% concede all’AI accessi più ampi di quelli che darebbe a un dipendente umano. Nella stessa direzione va la rilevazione trimestrale di KPMG (Q2 2026): il 70% delle aziende dichiara un approccio human-in-the-loop in cui una persona valida gli output ma non supervisiona ogni singola decisione dell’agente, e il 38% indica proprio nelle competenze di giudizio ed escalation il principale gap tecnico interno.

Cosa chiede l’AI Act a chi mette un agente davanti a clienti e dati

Chi in Italia sta valutando un agente a contatto con clienti ha un secondo motivo, molto concreto, per non improvvisare. L’articolo 14 dell’AI Act impone la supervisione umana come requisito, non come buona pratica, e nella traduzione operativa significa soglie di confidenza definite, escalation ordinata verso l’operatore nei casi complessi, passaggio a una persona per le autorizzazioni particolari e revisione periodica delle conversazioni. A questo si aggiungono l’obbligo di trasparenza, l’utente deve sapere che sta parlando con un assistente AI e come raggiungere un umano, e il Code of Practice sulla marcatura dei contenuti generati, pubblicato il 10 giugno 2026.

Checklist AI Act per l’azienda che adotta agenti AI

Per un’azienda deployer la checklist pratica è nota: mappare i casi d’uso, definire ruoli e grado di autonomia dell’agente, governare le fonti della knowledge base, garantire tracciabilità completa di domande, risposte, azioni ed escalation, limitare il trattamento dei dati personali e scrivere i divieti espliciti. Come sintetizza bene quella guida, «l’AI Act non blocca l’adozione degli agenti AI: blocca l’improvvisazione». Il contesto normativo, peraltro, si sta muovendo proprio sotto la spinta dei test di agosto: una commissione della Camera USA ha scritto ai CEO di OpenAI e Anthropic chiedendo conto delle misure di prevenzione, del ruolo della supervisione umana nei test e delle responsabilità legali in caso di danni, mentre a Bruxelles si valuta l’obbligo di rendere pubblici episodi di questo tipo. Per il quadro completo resta utile la nostra guida su cosa prevede l’AI Act e chi deve adeguarsi, insieme all’approfondimento su come gestire la compliance degli agenti con un partner.

Guardrail, monitoring e onboarding: il lavoro che comincia dopo il go-live

Tutto quello che precede ha un tratto comune: non è lavoro da fare una volta, è lavoro da tenere acceso. Le soglie vanno tarate sui dati veri, i log vanno letti da qualcuno che sappia riconoscere un’anomalia, i permessi vanno ristretti quando l’uso reale mostra che erano troppo larghi, i prompt di sistema vanno aggiornati quando cambia un processo. E soprattutto vanno formate le persone: il gap sulle competenze di escalation misurato da KPMG dice esattamente questo, che il collo di bottiglia non è il modello ma chi deve decidere quando fermarlo. Un agente che nessuno in azienda sa quando interrompere è un agente che, prima o poi, verrà spento del tutto.

Il presidio umano dell’agente AI dopo il go-live

È la ragione per cui in MIMIR il nostro lavoro non finisce con la consegna del sistema: accanto all’agente forniamo un servizio continuativo di supervisione, con onboarding dedicato delle persone che lo useranno, definizione dei guardrail, monitoraggio e manutenzione nel tempo. Chi vuole approfondire questa parte trova già online i nostri pezzi sulla manutenzione degli agenti AI dopo il deployment e sul ruolo del partner nella formazione del team.

Se stai valutando di portare un agente AI dentro un processo che tocca clienti, dati o denaro, la domanda giusta non è quale modello scegliere ma chi lo supervisiona il giorno dopo. Su questo puoi parlare con noi: da MIMIR trovi una consulenza per capire dove ha senso partire, con quali limiti di autonomia e con quale presidio umano. Nessuna fretta di firmare: prima si guarda il processo, poi si decide se serve un agente.

Fonti:

• BleepingComputer — OpenAI and Anthropic AI agents targeted real people and systems in cyber tests
• Forbes — AI agents fail without human oversight: here’s why
• Non-Human Identity Management Group — AI agent governance: are your human oversight controls keeping up
• KPMG — AI Pulse Survey Q2 2026 (PDF)
• IBM Think — Gestione degli agenti AI
• Mission Cloud — Why agentic AI needs human oversight