Un assistente suggerisce. Un agente compie azioni: legge un documento, consulta un gestionale, compila una pratica, apre un ticket.
È la differenza tra un sistema che produce testo e un sistema che modifica lo stato di qualcosa. Cambia il valore potenziale e cambia, in misura molto maggiore, il rischio.
Il termine è oggi molto usato. Vale la pena definirlo in modo operativo, perché la distanza tra la formulazione teorica e ciò che si può mettere in produzione in un’organizzazione con responsabilità formali è considerevole.
Definizione operativa, senza suggestioni
Un agente è un sistema che, ricevuto un obiettivo, decide autonomamente quali passi compiere per raggiungerlo, utilizzando strumenti a cui è stato collegato.
Tre elementi rendono la definizione concreta.
Non riceve una domanda ma un compito. Non “quali documenti mancano in questa pratica” ma “verifica la completezza di questa pratica e richiedi le integrazioni”.
Non esegue una sequenza fissa. Decide passo per passo, sulla base di quello che trova. Se il documento è illeggibile, prende una strada diversa rispetto a quando è leggibile.
Produce effetti fuori da sé. Scrive in un sistema, invia una comunicazione, aggiorna uno stato.
Il terzo punto è quello che cambia tutto. Un assistente che sbaglia produce una risposta da correggere. Un agente che sbaglia produce un’azione da annullare, e non tutte le azioni sono annullabili.
I tre ingredienti
Gli strumenti a disposizione. Un agente può fare solo ciò che gli strumenti collegati gli permettono. Leggere una casella PEC, interrogare un database, scrivere un record, generare un documento, aprire un ticket.
La progettazione degli strumenti è il primo livello di controllo, ed è il più efficace. Uno strumento che consente solo la lettura non può causare un danno diretto. Uno strumento che scrive richiede validazione, limiti e reversibilità. Molte scelte che sembrano di sicurezza applicativa sono in realtà scelte su quali strumenti esporre e con quali parametri.
La memoria del contesto. Per svolgere un compito in più passaggi l’agente deve ricordare che cosa ha già verificato, quali informazioni ha raccolto e quali tentativi sono falliti. Senza questa continuità ripete le stesse operazioni o perde il filo su casi articolati.
La memoria va progettata: che cosa conservare, per quanto tempo, con quale visibilità. In un contesto con dati sensibili è anche una questione di conformità, non solo di funzionamento.
I criteri di arresto. Quando l’agente deve fermarsi. Perché il compito è concluso, perché ha raggiunto un limite di tentativi, perché il livello di confidenza è sotto la soglia, perché sta per compiere un’azione che richiede autorizzazione umana.
Un agente senza criteri di arresto non è un sistema autonomo: è un sistema di cui non si conosce il comportamento nei casi che non sono stati previsti.
La parte difficile non è farlo agire
Costruire un agente che esegue un compito su un caso favorevole richiede oggi un impegno contenuto. Gli strumenti tecnici sono maturi e ampiamente documentati.
La parte difficile è decidere dove deve fermarsi.
Questa decisione non è tecnica. Richiede di stabilire, insieme a chi è responsabile del processo, quali azioni possono essere eseguite senza conferma, quali richiedono un’autorizzazione, quali restano interamente umane. E richiede di definire che cosa accade nei casi dubbi.
Nella nostra esperienza è la parte del progetto che assorbe più tempo di analisi, e quella che determina se il sistema sarà utilizzabile.
Tre criteri aiutano a impostarla.
La reversibilità dell’azione. Una classificazione errata si corregge. Una comunicazione inviata a un cittadino no.
L’impatto verso l’esterno. Tutto ciò che esce dall’organizzazione — una PEC, un preventivo, una comunicazione di esito — merita una soglia più alta di controllo di ciò che resta interno.
Il livello di confidenza. Il sistema deve poter dichiarare che non ha elementi sufficienti. Un agente che porta a termine ogni compito, sempre, non è un agente affidabile: è un agente che non sa riconoscere i propri limiti.
Un esempio su un processo amministrativo
Un ente riceve istanze via PEC. Il processo, dall’arrivo alla presa in carico, coinvolge oggi più passaggi manuali.
Un agente progettato su questo flusso opera così.
Legge la comunicazione in arrivo e ne classifica la tipologia. Estrae i dati identificativi e li confronta con l’anagrafica presente nel gestionale. Verifica quali allegati sono richiesti per quella tipologia e quali sono effettivamente presenti. Se manca un documento, prepara la bozza della richiesta di integrazione. Registra la pratica nel sistema con lo stato corretto e produce una sintesi per l’istruttore, con il riferimento al punto del documento da cui proviene ogni informazione.
E poi si ferma.
L’invio della richiesta di integrazione richiede una conferma umana, perché è una comunicazione verso l’esterno. La valutazione di merito non è compito dell’agente. I casi in cui la classificazione è incerta vengono instradati a un operatore invece di essere risolti d’ufficio.
Il valore non sta nell’autonomia. Sta nel fatto che l’operatore riceve una pratica già letta, verificata e strutturata, e dedica il proprio tempo alla decisione invece che alla raccolta.
Che cosa un agente non risolve
Non compensa un processo non definito. Per stabilire dove l’agente si ferma bisogna sapere come funziona il processo, e in diversi casi questa consapevolezza va ricostruita prima.
Non elimina il lavoro di verifica: lo concentra sui casi che lo meritano. È un guadagno reale, ma va comunicato correttamente alle persone coinvolte, perché la promessa di un’automazione totale genera aspettative che il sistema non manterrà.
Non è adatto a processi in cui ogni caso è un’eccezione. La ripetitività è la condizione che rende sostenibile il costo di progettazione e manutenzione.
E non riduce i requisiti di sicurezza. Un sistema che compie azioni ha una superficie di attacco più ampia di uno che risponde: i contenuti recuperati da email o documenti esterni vanno trattati come input non fidato, e i test avversariali fanno parte del collaudo, non del monitoraggio successivo.
In chiusura
La domanda giusta prima di avviare un progetto di questo tipo non è che cosa l’agente può fare. È quali azioni siete disposti a delegare, con quali controlli e con quale possibilità di intervento.
Da quella risposta discende l’architettura. Ed è una risposta che appartiene all’organizzazione, non al fornitore.
Se avete in mente un processo con passaggi ripetitivi e regole definite, siamo disponibili a un confronto su quel caso: quali strumenti servirebbero, dove si collocherebbero i punti di arresto e quale parte del lavoro resterebbe umana.
