Agenti AI in azienda: autonomia, permessi e controlli prima della produzione

Il momento in cui una risposta diventa un’azione

Un assistente che suggerisce una mail lascia una decisione evidente a chi la legge. Un agente che recupera informazioni, modifica un record e invia la mail cambia il perimetro. Il risultato non è più soltanto un testo: è un effetto su persone e sistemi. Prima di autorizzarlo, la direzione dovrebbe capire dove quell’effetto può arrivare.

La distinzione tra workflow e agenti proposta da Anthropic nel 2024 resta utile come riferimento architetturale: nei primi il percorso è definito; nei secondi il modello determina dinamicamente parte del percorso e dell’uso degli strumenti. La documentazione segnala che il panorama dei prodotti è evoluto. Uso qui la distinzione, non un elenco di funzionalità commerciali aggiornato per ogni piattaforma.

Quanta libertà serve al compito?

Per acquisire un modulo, controllare campi obbligatori e aprire una pratica, una sequenza esplicita può essere sufficiente. Se il sistema deve cercare fra fonti diverse, valutare ciò che manca e scegliere una prossima azione, un agente può avere senso. Questa libertà ha un prezzo: più percorsi possibili significano più situazioni da osservare e testare.

La domanda da porre al fornitore è: quale passaggio non possiamo descrivere con regole sostenibili e perché il modello dovrebbe gestirlo meglio? Se la risposta è soltanto che “gli agenti sono il futuro”, manca una motivazione di progetto. Mi interessa la capacità di risolvere un compito, non la quantità di autonomia esibita in una demo.

Definirei quattro livelli distinti: consultare, preparare, proporre una modifica, eseguirla. Un agente che confronta listini non deve necessariamente poterli cambiare. Uno che prepara una risposta non deve inviarla a qualsiasi destinatario. Credenziali dedicate e permessi minimi rendono il confine verificabile.

Un’approvazione umana dovrebbe mostrare oggetto, destinatario, conseguenze e informazioni usate. Un generico pulsante “continua” aiuta poco. Per azioni ripetitive a basso impatto si possono definire soglie e regole; per quelle più sensibili servono passaggi espliciti. La scelta dipende dal processo e va concordata con chi ne risponde.

I contenuti letti dall’agente possono contenere istruzioni malevole o fuorvianti. Il sistema deve trattarli come dati, non come autorizzazioni. Questo richiede controlli tecnici sugli strumenti e sulle destinazioni: non affiderei l’intero confine di sicurezza a una frase nel prompt.

Misurare il percorso, non l’eloquenza

Un test credibile comprende richieste incomplete, strumenti non disponibili, risposte contraddittorie e ripetizioni. Verificherei che un tentativo ripetuto non generi duplicazioni e che il sistema sappia fermarsi quando manca un’informazione. Anche chiedere aiuto è un risultato corretto, se evita un’azione non giustificata.

Registrerei i passaggi necessari a ricostruire l’operazione, limitando la presenza di dati personali nei log. Chi può leggerli, quanto vengono conservati e come si gestiscono le credenziali sono decisioni operative. Un agente troppo opaco rende difficile correggere; uno che registra tutto senza criterio crea un’altra esposizione.

Seguiamo una richiesta fino al punto di rischio

Consideriamo un processo illustrativo: un cliente chiede una nota di credito per una consegna incompleta. L’agente legge la richiesta, consulta ordine e spedizione, verifica le condizioni e prepara una proposta. Fin qui il valore può essere significativo anche senza autonomia esecutiva. Il sistema riduce il tempo necessario a ricostruire il caso e lascia al responsabile una decisione più informata.

La situazione cambia quando l’agente può emettere il documento. Ora occorre stabilire chi autorizza l’importo, come si evita una duplicazione e cosa succede se la spedizione viene corretta mentre la pratica è in corso. Una risposta linguisticamente impeccabile non risolve nessuno di questi problemi. La qualità si misura sullo stato finale dei sistemi e sulla coerenza economica dell’operazione.

Il contenuto ricevuto dal cliente deve restare un’informazione da valutare. Non può diventare un’istruzione che modifica i poteri del sistema. Un allegato potrebbe contenere testo che invita a ignorare controlli o a inviare dati altrove. La difesa deve comprendere confini tecnici: funzioni consentite, destinatari ammessi, validazioni sugli importi e autorizzazioni applicate dal servizio che esegue l’azione. Chiedere al modello di comportarsi bene è solo una parte del presidio.

Anche una richiesta autentica può produrre un errore senza alcun attacco. Se il collegamento si interrompe dopo l’emissione, il sistema potrebbe non sapere che l’operazione è riuscita e ripeterla. Occorre riconoscere la stessa pratica e impedire una seconda esecuzione. Questo requisito appartiene all’ingegneria del processo; diventa particolarmente importante quando il percorso viene composto in modo dinamico.

Un’autonomia che si può aumentare, ma anche ritirare

Proporrei di partire con azioni preparatorie e osservare un campione rappresentativo delle richieste. Il passaggio successivo può riguardare solo casi semplici, sotto una soglia e con condizioni esplicite. Le eccezioni restano affidate alle persone. La soglia non dovrebbe essere scelta per rendere il progetto più spettacolare: dipende dall’esposizione accettabile e dalla capacità di rilevare e correggere un errore.

La revisione umana ha un costo che va misurato. Se il responsabile deve ricostruire ogni volta l’intero caso, il beneficio si riduce. L’agente dovrebbe presentare evidenze, fonti e passaggi compiuti, facendo emergere le informazioni mancanti. Un pulsante di approvazione accanto a una conclusione persuasiva può incoraggiare una firma frettolosa; una proposta verificabile rende invece il controllo un’attività praticabile.

Prima della produzione fisserei le condizioni che fanno tornare il sistema a un livello inferiore di autonomia. Un aumento delle correzioni, un cambiamento nelle regole commerciali o un’integrazione instabile possono giustificare il ritorno alla sola preparazione. Ritirare temporaneamente un permesso deve essere semplice. Se richiede un nuovo progetto, l’organizzazione tenderà a convivere con il rischio per non interrompere il servizio.

Serve poi un proprietario operativo con disponibilità reale. Qualcuno deve poter bloccare le azioni, identificare le pratiche coinvolte e organizzare la gestione manuale. La reperibilità non si risolve scrivendo un nome in un documento. Occorrono accessi, istruzioni e una copertura compatibile con gli orari in cui l’agente lavora. Se il servizio opera la notte, quella scelta porta con sé un costo.

Nel confronto con un fornitore chiederei di vedere un caso fallito. Vorrei capire quali tracce restano, quali dati sono conservati, come vengono limitati gli accessi e se è possibile cambiare modello senza perdere la logica del processo. Una dimostrazione costruita solo su richieste perfette racconta poco della capacità di esercizio.

Il verbale di rilascio dovrebbe infine contenere un confine comprensibile al business: quali operazioni l’agente può compiere, entro quali limiti, chi gestisce le eccezioni e quando si riesamina la scelta. Questo documento aiuta anche a contenere l’espansione informale delle funzioni. Aggiungere “già che ci siamo” un’altra azione può modificare radicalmente l’esposizione, pur sembrando una piccola evoluzione tecnica.

L’autonomia ha valore quando libera attenzione mantenendo il processo comprensibile. La curiosità verso questi sistemi mi spinge a sperimentare; la responsabilità di portarli in azienda mi impone di chiedere come funzioneranno nel giorno meno favorevole, con dati incompleti e persone già impegnate altrove.

Un controllo economico completa quello tecnico: limiti di spesa per esecuzione e per periodo, allarmi su consumi anomali e un comportamento definito quando il limite viene raggiunto. Un compito che continua a tentare senza concludere può consumare risorse pur senza produrre un errore applicativo. Anche questo esito deve essere osservabile e interrompibile.

Un costo per compito realmente concluso

Le chiamate al modello sono solo una voce. Vanno aggiunti uso degli strumenti, tentativi falliti, supervisione, gestione delle eccezioni e aggiornamento delle integrazioni. Un costo per conversazione basso può nascondere un costo per pratica corretta alto. Metterei limiti a durata, numero di tentativi e spesa per esecuzione, con una destinazione chiara per i casi interrotti.

Prima della produzione chiederei un campione di esiti verificati, la procedura di arresto e la modalità di ritorno al lavoro ordinario. Chi riceve l’allarme deve avere tempo e potere per intervenire. L’autonomia non elimina il presidio: ne cambia il punto di applicazione.

La parte entusiasmante degli agenti è la possibilità di collegare capacità prima separate. Per renderla utile in azienda, io partirei da un confine piccolo e visibile. Lo allargherei solo quando i risultati, inclusi gli errori e il loro recupero, dimostrano che possiamo farlo con ragionevole fiducia.