Agenti AI in azienda: compiti, permessi e controllo del lavoro

Un agente AI può scegliere passaggi e usare strumenti per svolgere un compito. In azienda, però, “autonomo” non dovrebbe significare autorizzato a fare qualsiasi cosa. Leggere una cartella, preparare una bozza e inviare un’offerta impegnativa sono tre livelli di responsabilità diversi.

Questa guida riguarda l’uso operativo su compiti circoscritti. Non promette dipendenti digitali infallibili né sostituzioni automatiche di ruoli. Un agente può interpretare male un documento, scegliere uno strumento inadatto o ripetere un’azione già svolta. Il progetto deve prevedere questi casi.

Un esempio illustrativo è preparare una bozza di riepilogo per un preventivo: raccogliere gli allegati autorizzati, confrontarli con le specifiche approvate e segnalare le informazioni mancanti. Il risultato può essere verificato dal commerciale prima di qualsiasi invio.

Il compito è meno adatto se richiede una decisione non formalizzata che solo il titolare sa prendere, oppure se l’errore può produrre conseguenze importanti senza un controllo possibile. Non basta che il testo finale “suoni bene”. Serve una prova del collegamento tra fonti, passaggi e risultato.

Se la sequenza può essere definita in anticipo, confronta l’agente con una normale automazione. La guida a chatbot, agenti e automazioni chiarisce questa scelta prima di aggiungere complessità.

Un flusso può usare l’AI senza diventare un agente. Per esempio, un programma riceve un documento, chiede a un modello di estrarre alcuni campi e passa il risultato a controlli già stabiliti. La sequenza rimane definita dal software. Un agente, invece, può scegliere il prossimo strumento in base a ciò che ha trovato, entro le possibilità che gli vengono concesse.

La distinzione è descritta da Anthropic nel confronto tra workflow e agenti. È un riferimento architetturale, non un giudizio secondo cui più autonomia sia sempre migliore. Per un compito stabile, una sequenza esplicita può essere più semplice da verificare e mantenere.

Immagina di dover riconoscere il numero di un ordine e cercarlo in un’anagrafica. Se manca il numero, fermarsi e chiedere un controllo può essere una scelta sufficiente. Permettere al modello di cercare liberamente in email, cartelle e conversazioni aumenta le possibilità, ma anche i dati esposti e il numero di esiti da provare.

Prima di progettare un agente, compila la scheda per scegliere cosa automatizzare. Il motivo per concedere autonomia deve essere legato a una variabilità reale del lavoro, non al desiderio di usare l’etichetta tecnologica più recente.

La scheda del compito deve indicare quali fonti possono essere lette e quali strumenti possono essere eseguiti. L’autorizzazione va controllata dal software che esegue l’azione, non soltanto descritta in un prompt. Un allegato non può diventare un’istruzione per ignorare le regole aziendali.

Per le operazioni rilevanti prevedi un’approvazione che mostri destinatario, contenuto e conseguenze. “Confermi?” senza contesto non permette un controllo. Se il sistema modifica un gestionale, applica le regole della mappa di integrazione AI.

Prepara casi ordinari e difficili, con risultati attesi definiti prima della prova. Ripeti le verifiche dopo modifiche a modello, strumenti o fonti. Un cambiamento può migliorare una parte e peggiorarne un’altra. Conserva una traccia delle versioni usate.

Misura tempo di revisione e correzione oltre al costo delle chiamate. Distingui un errore recuperabile da un’azione non autorizzata. La media dei risultati non deve nascondere un problema grave: la condizione di rilascio va concordata in base alle conseguenze del compito.

Consideriamo una richiesta di preventivo con due allegati, come simulazione. Il primo contiene la specifica tecnica, il secondo una revisione precedente. L’agente deve identificare che non sono equivalenti e indicare quale versione sta usando. Se non riesce a stabilirlo, la risposta corretta è chiedere una conferma, non fondere i due documenti.

La bozza dovrebbe separare informazioni esplicite, deduzioni e campi mancanti. Una misura letta nel documento non ha lo stesso stato di una misura ipotizzata dal contesto. Il commerciale deve poter risalire alla pagina o al passaggio di origine prima di approvare un dato che finirà nell’offerta.

Il secondo test cambia soltanto un dettaglio: il documento riporta un prodotto non più disponibile. Avere estratto correttamente il nome non basta. Il sistema deve interrogare la fonte autorizzata della disponibilità oppure dichiarare che non può verificarla. Non dovrebbe sostituire il prodotto con quello che gli sembra più simile senza una regola approvata.

Il terzo test riguarda l’azione finale. Il modello può proporre un’offerta corretta ma indicare un destinatario sbagliato. Prima dell’invio vanno quindi approvati versione, indirizzo e condizioni. La qualità del testo è una parte della qualità del lavoro. Il sistema commerciale deve registrare anche quale persona ha autorizzato il passaggio.

Un insieme di test non dovrebbe contenere soltanto esempi che sai già risolvere. Inserisci casi mancanti, fonti contraddittorie e richieste fuori dal mandato. Per ciascuno definisci prima quale comportamento sia accettabile: completare, chiedere chiarimenti, passare a una persona o fermare l’esecuzione.

La guida Anthropic alle valutazioni degli agenti distingue il compito, il tentativo e il modo di giudicare il risultato. Per l’azienda, la conseguenza pratica è non confondere una risposta apparentemente corretta con uno stato finale corretto nei sistemi interessati.

Se il compito è creare una sola bozza, il controllo deve trovare una sola bozza, collegata alla richiesta corretta. Se il compito è non inviare nulla senza autorizzazione, un invio indebito non viene compensato da molte risposte ben scritte. Mantieni separati gli errori che rendono necessaria una correzione e quelli che impediscono il rilascio.

Annota anche il costo del controllo umano. Un agente che prepara il documento in pochi secondi ma costringe il referente a ricostruire tutte le fonti può spostare il lavoro invece di ridurlo. La valutazione economica dell’automazione deve includere questa revisione e il tempo necessario a gestire le eccezioni.

Prova questo scenario: l’agente chiede di creare una bozza nel CRM. Il CRM la registra, ma la risposta non arriva entro il tempo previsto. Dal punto di vista dell’agente l’operazione sembra fallita. Ripeterla alla cieca può creare due bozze o due incarichi per la stessa richiesta.

Il software deve poter riconoscere il tentativo già eseguito, per esempio attraverso un identificativo univoco dell’operazione e una verifica dello stato. Se non può accertarlo, deve sospendere quel passaggio e segnalarlo. Il modello non dovrebbe decidere che “riprovare probabilmente va bene” quando l’azione produce conseguenze esterne.

Nella prova registra la richiesta autorizzata, l’esito tecnico e lo stato effettivo nel sistema di destinazione. Non occorre conservare indiscriminatamente tutto il contenuto dei documenti: scegli una traccia sufficiente alla diagnosi, con accessi e conservazione definiti. Il registro non è una ragione per moltiplicare dati personali o riservati.

Un altro caso è un allegato che contiene un comando rivolto all’assistente. Quel testo resta materiale da esaminare, non diventa l’autorità che cambia destinatari o permessi. Per mettere alla prova il confine usa documenti fittizi e controlla l’azione tentata, oltre alla risposta mostrata a video.

Un’istruzione può arrivare anche dentro il materiale da esaminare: una pagina web, un allegato o una nota condivisa. Se il sistema la interpreta come un comando autorevole, può allontanarsi dal compito assegnato. OWASP descrive questo rischio nella voce Prompt Injection.

Il confine va costruito anche fuori dal prompt. Gli strumenti devono rifiutare operazioni non autorizzate e consentire soltanto gli accessi necessari. Per un sistema che prepara riepiloghi, la possibilità di cancellare documenti o modificare credenziali non dovrebbe essere disponibile solo perché l’integrazione la supporta.

Una prova fittizia può includere una frase che invita a spedire l’allegato a un altro destinatario. L’esito atteso è ignorare quel comando e rispettare il mandato. Non usare dati reali o destinatari esterni per improvvisare questa verifica. Preparare un ambiente di test fa parte del lavoro tecnico, non è un extra opzionale.

Dopo la prova, la domanda è chi leggerà gli errori il mese successivo. Servono una traccia delle operazioni, versioni riconoscibili di modelli e istruzioni, un referente per le fonti e un modo per sospendere le azioni. Non è necessario conservare tutto: raccolta e conservazione devono essere limitate a ciò che serve davvero al controllo.

Quando cambi modello o aggiungi uno strumento, ripeti i test rilevanti. Un miglioramento della scrittura può convivere con un peggioramento nel riconoscimento di un’eccezione. Rendi visibile questa differenza prima di sostituire la versione usata dalle persone.

Il NIST AI Risk Management Framework offre un riferimento volontario per organizzare il rischio. Non certifica conformità europea né sostituisce i referenti legali e di sicurezza. Per l’adozione quotidiana occorre anche formare chi userà e controllerà l’applicazione.

Qualcuno deve aggiornare le fonti, leggere gli errori e decidere quando una nuova versione può entrare in uso. Per separare direzione AI e responsabilità tecnica trovi il confronto Head of AI o CTO.

Il servizio agenti AI comprende questa definizione del lavoro. Una demo è un punto di partenza: diventa un’applicazione operativa quando l’azienda può controllarla anche nelle giornate in cui qualcosa non funziona come previsto.