Agenti AI in produzione: approvazioni, log e costi sotto controllo dal primo giorno

Per gli agenti AI in produzione, approvazioni, log e costi sono i tre controlli da impostare dal primo giorno. Servono un'approvazione umana per le azioni sensibili, un registro completo di ogni decisione e un tetto di spesa per ogni processo. Senza questi tre elementi, una demo riuscita resta un esperimento.

Questa guida è la terza parte di una serie in tre parti sugli agenti AI nella pratica. La prima parte tratta la costruzione di un primo agente senza codice. La seconda tratta la costruzione di un agente con il codice. Questa terza parte spiega come farlo lavorare in sicurezza e a un costo noto.

Anthropic descrive gli agenti AI come sistemi che perseguono un compito in autonomia, una volta ricevuto un obiettivo, e che dirigono da soli i propri passaggi e l'uso degli strumenti. Se desidera un quadro più ampio, trova un esempio concreto nella nostra guida su che cosa sono gli agenti AI e cosa fanno in azienda.

Un agente in produzione è un agente che lavora su dati reali, per utenti o clienti reali, senza qualcuno che ne osservi ogni passo. Proprio per questo i controlli non si aggiungono dopo il lancio. Si progettano insieme all'agente, perché determinano che cosa l'agente può fare, che cosa resta scritto e quanto costa ogni mese.

L'approvazione umana serve soprattutto sugli strumenti di scrittura, perché sono quelli che cambiano qualcosa nel mondo reale. Il centro assistenza di Claude distingue due famiglie di strumenti. Gli strumenti di lettura permettono a Claude di accedere ai contenuti e leggerli, per esempio una casella di posta o uno screenshot. Gli strumenti di scrittura gli permettono di agire: creare un invito in calendario, cancellare un file, eseguire un comando, fare clic sullo schermo.

Il rischio si concentra dove le due famiglie si incontrano. Secondo Anthropic, un attacco di prompt injection riesce solo se Claude può leggere informazioni fuori dal perimetro di fiducia e può anche compiere azioni che danneggiano l'utente. La prompt injection è un attacco in cui istruzioni malevole vengono nascoste in un contenuto esterno che l'agente legge durante un compito legittimo. Il perimetro di fiducia è l'insieme delle fonti che l'utente considera sicure e sotto il proprio controllo, come i file personali o le comunicazioni aziendali.

Da questa distinzione nasce una regola pratica per ogni agente:

• la lettura di fonti interne può procedere senza conferma;
• ogni azione verso l'esterno, come un messaggio a un cliente, richiede un'approvazione;
• le azioni irreversibili, come una cancellazione, restano bloccate o sempre soggette a conferma.

Questa classificazione va scritta prima di collegare qualsiasi strumento, non dopo il primo incidente.

I prodotti di Anthropic offrono già diversi livelli di approvazione, da scegliere in base al rischio dell'azione. Claude Code, l'agente che scrive e modifica codice, ha per impostazione predefinita permessi di sola lettura. Deve chiedere l'approvazione umana prima di modificare codice o sistemi. L'utente può concedere permessi persistenti per le attività di routine di cui si fida.

Il Model Context Protocol (MCP) è il protocollo open source creato da Anthropic che collega Claude ad altri servizi. Include controlli per consentire o impedire a Claude l'accesso a strumenti specifici. Nell'implementazione di Anthropic si può concedere un accesso una tantum oppure permanente. Sul piano Enterprise, gli amministratori stabiliscono a quali connettori possono collegarsi gli utenti dell'organizzazione.

Claude Cowork aggiunge modalità di approvazione esplicite. In modalità "Automatically approve", Claude esamina comunque ogni azione per la sicurezza prima di eseguirla. In modalità "Skip all approvals", nessuno controlla le sue azioni. La cancellazione definitiva di file richiede sempre il permesso esplicito, in qualsiasi modalità. Le attività pianificate girano nel cloud anche a computer spento, e Anthropic precisa che l'utente resta responsabile delle azioni che Claude compie per suo conto.

Quando in Svennis portiamo un agente in produzione, compiliamo per prima cosa l'elenco di ogni strumento di scrittura e indichiamo accanto a ciascuno chi approva. L'errore che vediamo più spesso è un agente passato dalla demo alla produzione con i permessi ampi del prototipo, che nessuno ha poi ristretto.

OpenTelemetry permette di registrare ogni passo di un agente Claude Cowork e di inviarlo ai sistemi di monitoraggio già in uso. OpenTelemetry (OTel) è uno standard aperto per raccogliere eventi e metriche da un'applicazione. Il monitoraggio OTel di Cowork è disponibile sui piani Team ed Enterprise. Copre le sessioni nel cloud, da desktop, web e mobile, e le sessioni locali su desktop.

Secondo la pagina di Anthropic su il monitoraggio di Cowork con OpenTelemetry, gli eventi trasmessi comprendono:

• il testo completo dei prompt inviati dagli utenti;
• ogni chiamata a strumenti e a MCP;
• gli accessi ai file, le skill e i plugin;
• le decisioni di approvazione umana;
• le richieste API e gli errori.

Un attributo condiviso, prompt.id, collega tutti gli eventi generati da un singolo prompt. In questo modo si ricostruisce tutto ciò che Claude ha fatto in risposta a una richiesta.

La configurazione si trova in Organization settings > Cowork. Si inserisce l'endpoint OTLP del proprio collector e si sceglie il protocollo, HTTP/JSON oppure HTTP/protobuf. Nessun dato viene esportato finché un amministratore non configura l'endpoint. Il flusso funziona con qualsiasi collector OTel standard, per esempio Splunk, Elasticsearch o Datadog.

Il contenuto dei prompt e gli indirizzi email degli utenti sono inclusi per impostazione predefinita. Poiché i log possono consentire un controllo a distanza dei dipendenti, conviene valutarli con il responsabile della protezione dei dati (DPO) anche alla luce dell'articolo 4 dello Statuto dei lavoratori, richiamato dall'articolo 114 del Codice privacy.

Gli audit log di Claude registrano le operazioni amministrative e di utilizzo dell'organizzazione, e sono disponibili solo sul piano Enterprise. Gli Owner e i Primary Owner li esportano da Organization settings > Data and Privacy, con il pulsante "Export logs". L'esportazione raccoglie tutti gli audit log dell'organizzazione degli ultimi 180 giorni. Chi la richiede riceve un'email con un link di download attivo per 24 ore.

Gli audit log hanno limiti precisi, che conviene conoscere prima di un controllo:

• titoli e contenuti di chat e progetti non vengono esportati, solo i loro identificativi univoci;
• gli input e gli output delle chat si esportano a parte, dai Primary Owner, tramite l'esportazione dei dati;
• il pulsante "Export logs" non funziona se l'organizzazione usa chiavi di cifratura gestite dal cliente.

Gli eventi degli audit log sono disponibili anche tramite la Compliance API. La Compliance API copre Cowork e Claude Code insieme alle chat di Claude, e può funzionare in parallelo con OpenTelemetry.

Per un'azienda la conseguenza pratica è semplice. Un intervallo di 180 giorni non basta come archivio permanente. Se un processo richiede una conservazione più lunga, l'esportazione va pianificata a intervalli regolari e salvata in un archivio aziendale, con un responsabile nominato.

Il modo più diretto per fissare un tetto di spesa per processo è dare a ogni agente un proprio workspace nella Claude Console. Un workspace è un modo per organizzare l'uso dell'API all'interno di un'organizzazione, separando progetti, ambienti o team con fatturazione centralizzata. Ogni richiesta gira in un solo workspace e accede solo alle risorse di quel workspace. I limiti di spesa e di frequenza del workspace si possono fissare più bassi di quelli dell'organizzazione, mai più alti. Un'organizzazione può avere fino a 100 workspace per impostazione predefinita.

La seconda leva è il modello. La pagina di Anthropic sui modelli indica questi prezzi, in dollari USA per milione di token:

Anthropic suggerisce di partire da Claude Opus 5.5 quando non è chiaro quale modello usare. Claude Fable 5.1 conviene quando le valutazioni su Opus 5.5, anche con effort più alto, restano insufficienti. Un modello più economico si sceglie dopo averlo provato sul proprio test set, non prima. Per un agente che resterà in servizio a lungo, anche la data di ritiro del modello entra nella decisione.

Un test set è la prova che un agente è pronto per la produzione, e va costruito prima del lancio. Anthropic definisce una valutazione (eval) come un test in cui l'AI riceve un input e una logica di correzione misura il successo del suo output. Nel suo articolo tecnico sulle valutazioni degli agenti AI, Anthropic scrive che 20-50 compiti semplici tratti da errori reali sono un ottimo inizio.

La correzione combina di solito tre tipi di valutatori: basati sul codice, basati su un modello e umani. Le valutazioni di regressione chiedono se l'agente gestisce ancora tutti i compiti che gestiva prima. Per questo devono avere un tasso di successo vicino al 100%. Ogni transcript, cioè il registro completo di una prova con output, chiamate agli strumenti e passaggi intermedi, aiuta a capire perché un compito fallisce.

La misura che conta per un agente rivolto ai clienti è la costanza. Anthropic usa la metrica pass^k, la probabilità che tutte le k prove riescano. Un agente che riesce il 75% delle volte a ogni tentativo supera tre prove di fila solo nel 42% circa dei casi. Un cliente che torna tre volte non vede la media: vede i fallimenti.

Il test set si aggiorna nel tempo. Ogni errore osservato in produzione diventa un nuovo compito, e il set si ripete a ogni modifica di prompt, strumenti o modello.

Un agente di primo contatto sui ticket di Zoho Desk mostra come i tre controlli si combinano in un caso reale. L'agente legge i nuovi ticket, consulta la base di conoscenza interna, propone una categoria e prepara una bozza di risposta. Il suo scopo è ridurre il lavoro ripetitivo del team, non sostituire chi risponde ai clienti.

Approvazioni

La lettura dei ticket e della base di conoscenza è uno strumento di lettura e procede senza conferma. L'invio della risposta al cliente è uno strumento di scrittura verso l'esterno e richiede sempre l'approvazione di un operatore. La chiusura o la cancellazione di un ticket restano fuori dagli strumenti dell'agente. Il testo dei ticket arriva dai clienti, quindi è fuori dal perimetro di fiducia: un motivo in più per non concedere azioni esterne senza conferma.

Log

Se l'agente lavora in Claude Cowork su un piano Team o Enterprise, l'amministratore imposta l'endpoint OTLP in Organization settings > Cowork. Grazie a prompt.id, ogni ticket si ricostruisce dalla lettura alla decisione dell'operatore.

Costi

Se l'agente lavora tramite API, gira in un workspace dedicato soltanto a questo processo, con un limite di spesa inferiore a quello dell'organizzazione. Il modello si sceglie dopo aver eseguito il test set, fatto di 20-50 ticket reali che in passato erano stati smistati male o avevano ricevuto risposte da correggere.

Per un agente come quello descritto, l'articolo dell'AI Act più rilevante è l'articolo 4 sull'alfabetizzazione AI. L'articolo 50 sulla trasparenza entra in gioco quando l'agente comunica direttamente con i clienti, senza un operatore che approvi ogni risposta. Restano fermi i divieti dell'articolo 5 e gli obblighi previsti per i sistemi ad alto rischio. L'articolo 4 si applica dal 2 febbraio 2025 e chiede a fornitori e utilizzatori di sistemi AI di sostenere l'alfabetizzazione AI del personale. La Commissione ha presentato il Digital Omnibus il 19 novembre 2025, e le modifiche all'articolo 4 sono entrate in vigore a metà luglio 2026. L'obbligo resta, ma non viene imposto alcun livello specifico o "sufficiente".

Secondo le FAQ della Commissione sull'alfabetizzazione AI, non serve alcun certificato. Le formazioni e le altre iniziative si possono documentare con un registro interno. L'obbligo, però, consiste nell'adottare misure concrete di alfabetizzazione adeguate al ruolo del personale e al contesto d'uso. Non è richiesta una struttura di governance specifica. La vigilanza spetta alle autorità nazionali di sorveglianza del mercato, che applicano le regole dal 2 agosto 2026.

L'articolo 50 si applica dal 2 agosto 2026. Chi fornisce un sistema AI che interagisce direttamente con le persone deve progettarlo in modo che le persone sappiano di parlare con un'AI, salvo quando è evidente. L'avviso va dato dall'inizio della prima interazione, in modo chiaro. Il fornitore è chi sviluppa un sistema AI, o lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio.

Un'azienda che costruisce un proprio agente per i clienti potrebbe quindi essere il fornitore di quel sistema: è un punto da verificare con un legale. Per la violazione degli obblighi dell'articolo 50 le sanzioni arrivano fino a 15 milioni di euro o al 3% del fatturato mondiale annuo, se superiore. Per le PMI si applica l'importo inferiore; verifichi nel testo consolidato se lo stesso trattamento vale anche per le piccole imprese a media capitalizzazione.

Il testo completo è disponibile nella nostra versione annotata in italiano dell'AI Act. Il quadro normativo AI in Italia raccoglie gli altri obblighi.

La checklist di produzione riassume i controlli da verificare prima che un agente AI lavori su dati e clienti reali. Ogni riga ha un responsabile e un punto preciso in cui si imposta.

Oltre ai sei controlli tecnici, prima del lancio vanno verificati anche tre punti di conformità. Il primo è l'avviso ai clienti che interagiscono direttamente con l'agente, richiesto dall'articolo 50 dell'AI Act dal 2 agosto 2026. Il secondo sono gli adempimenti privacy: accordo sul trattamento con il fornitore del modello, informativa a clienti e dipendenti e valutazione dell'eventuale necessità di una DPIA, cioè una valutazione d'impatto sulla protezione dei dati. Il terzo riguarda i log. Se consentono un controllo a distanza dei dipendenti, servono l'accordo sindacale o l'autorizzazione dell'Ispettorato del lavoro previsti dall'articolo 4 dello Statuto dei lavoratori.

La revisione mensile tiene insieme gli altri cinque controlli. È il momento in cui gli errori osservati entrano nel test set, i permessi si restringono o si allargano con motivazione scritta e la spesa si confronta con il valore prodotto. Registrare anche le formazioni del personale in quella sede aiuta a documentare l'articolo 4 dell'AI Act.

Il primo passo concreto è scegliere un solo processo e compilare per quel processo l'elenco degli strumenti di lettura e di scrittura. Accanto a ogni strumento di scrittura va indicato chi approva. Questo elenco richiede poche ore e rivela subito dove la demo concedeva troppo.

Poi conviene procedere in quest'ordine:

1. nominare il responsabile del processo;
2. creare un workspace dedicato e fissarne il limite di spesa;
3. attivare OpenTelemetry o pianificare l'esportazione degli audit log, in base al piano;
4. raccogliere da 20 a 50 casi reali di errore e trasformarli nel test set;
5. scegliere il modello dopo aver eseguito il test set;
6. verificare con un legale se l'azienda è fornitore ai sensi dell'articolo 50.

Se non è chiaro da quale processo partire, la valutazione della prontezza AI della Sua azienda aiuta a individuare i processi con dati ordinati e rischio contenuto. Per una visione più ampia degli usi possibili, la guida su come ogni azienda può usare l'AI offre esempi per settore.