Blog / Intelligenza artificiale e processi aziendali

Agente AI nel gestionale: autonomia, controlli e test

Pubblicato l'11 settembre 2026 · Redazione Gestionale sul Web

Un chatbot che spiega lo stato di un ordine e un agente che modifica la data di consegna possono usare lo stesso modello linguistico, ma non hanno lo stesso rischio. Nel secondo caso l'AI non produce soltanto una risposta: entra nel processo, usa strumenti e cambia il sistema che l'azienda considera fonte operativa. Per valutarla servono criteri più concreti di una demo brillante.

Assistente, automazione e agente AI: che cosa cambia davvero

Le etichette commerciali non bastano. Un assistente riceve una richiesta e restituisce una risposta, un riepilogo o una bozza. Un'automazione tradizionale esegue una sequenza definita in anticipo: se accade A, applica B. Un agente AI può invece interpretare un obiettivo, scegliere tra più passaggi o strumenti, osservare il risultato e decidere come proseguire entro regole stabilite.

Questa flessibilità è utile quando il processo contiene varianti, documenti non strutturati o eccezioni. È anche il motivo per cui occorre governare l'agente come un'identità operativa. La domanda decisiva non è “quanto è intelligente?”, ma: quali dati può leggere, quali strumenti può chiamare, quali record può cambiare e chi risponde dell'esito?

Nel gestionale la distinzione si vede bene. Cercare una fattura, spiegare un saldo o raggruppare ticket sono attività informative. Preparare un ordine a fornitore è una proposta. Registrarlo, inviarlo o modificare condizioni economiche sono azioni. Lo stesso caso d'uso può attraversare tutte queste fasi, ma ogni passaggio richiede autorizzazioni e verifiche diverse.

Cinque livelli di autonomia per evitare il salto nel buio

Prima di confrontare prodotti, assegna al caso d'uso un livello di autonomia. Non è una certificazione universale: è una scala pratica per rendere esplicito che cosa si consente oggi e che cosa potrà essere abilitato dopo.

Il livello più alto non è sempre il migliore. Per processi rari, economici o difficili da annullare, la preparazione con conferma può offrire quasi tutto il risparmio senza delegare l'ultima decisione. Microsoft, nella documentazione del suo Approvals Agent per Dynamics 365, distingue una modalità che classifica da una che classifica e approva automaticamente, e raccomanda di testare a fondo prima di attivare l'approvazione automatica. Il principio è generalizzabile: l'autonomia è una configurazione da guadagnare, non un'impostazione predefinita.

Scegliere il primo processo: frequenza, reversibilità e raggio d'impatto

Un buon pilota non parte dal processo più spettacolare, ma da quello che consente di imparare con conseguenze contenute. Valuta almeno cinque fattori: frequenza dell'attività, stabilità delle regole, qualità dei dati, facilità di verifica, reversibilità dell'azione. Aggiungi il raggio d'impatto: quante persone, clienti, documenti o importi può coinvolgere un errore prima che qualcuno lo noti?

Sono candidati iniziali ragionevoli la classificazione di richieste, il controllo di completezza, il confronto tra dati, la preparazione di bozze e la segnalazione di anomalie. Sono più delicati l'invio di comunicazioni esterne, le registrazioni contabili, le variazioni di prezzo, le cancellazioni, la gestione dei permessi e le operazioni che impegnano economicamente l'azienda.

Permessi, approvazioni e audit log: i tre controlli non negoziabili

1. Permessi applicati fuori dal modello

Il modello può proporre un'azione, ma non deve decidere se l'utente è autorizzato. Identità, ruolo, azienda, reparto, record e operazione vanno verificati dal gestionale o da un livello di autorizzazione affidabile a ogni chiamata. Un agente destinato al magazzino non dovrebbe ereditare accesso a contabilità, anagrafiche complete o strumenti di cancellazione “nel caso possano servire”.

OWASP descrive l'excessive agency come combinazione di funzionalità, permessi o autonomia eccessivi. La mitigazione pratica è il privilegio minimo: pochi strumenti, parametri limitati, credenziali separate, autorizzazione completa nel sistema a valle e scadenza delle deleghe. Anche quando un protocollo standard collega l'agente alle API, la connessione non sostituisce il controllo degli accessi.

2. Approvazioni che mostrano la decisione, non un pulsante generico

Una richiesta di conferma utile è un piccolo fascicolo: obiettivo, operazione proposta, record interessati, valori prima e dopo, fonte, regola applicata, conseguenza, reversibilità, eventuali eccezioni e scadenza. “Vuoi procedere?” senza contesto sposta soltanto il rischio sulla persona che clicca.

Definisci l'approvatore per ruolo e soglia, non per disponibilità occasionale. Impedisci che lo stesso agente possa cambiare la regola, scegliere l'approvatore e approvare il proprio risultato. Registra anche rifiuti e correzioni: sono dati essenziali per capire dove il sistema sbaglia e se gli utenti stanno confermando per abitudine.

3. Audit log ricostruibile e proporzionato

Per ricostruire un'azione servono almeno: identità dell'utente e dell'agente, obiettivo ricevuto, fonti consultate, strumenti chiamati, parametri rilevanti, versione di prompt e policy, proposta prodotta, approvazione o rifiuto, record modificati, esito, errori e un identificativo comune a tutta la sequenza. I log devono essere protetti da modifiche non autorizzate e avere una conservazione coerente con scopo, sicurezza e privacy.

Registrare tutto in chiaro non è automaticamente più sicuro. Prompt e risultati possono contenere dati personali, listini, documenti o segreti. Occorre minimizzare, mascherare dove possibile, separare accessi operativi e investigativi e definire chi può esportare le tracce. La tracciabilità deve spiegare l'azione senza creare un nuovo archivio incontrollato.

Dati non affidabili, prompt injection e limiti di esecuzione

Un agente può ricevere istruzioni non soltanto dall'utente, ma anche da email, PDF, note, pagine web o campi del gestionale. Un testo esterno potrebbe tentare di convincerlo a ignorare le regole o a usare uno strumento in modo improprio. Per questo il contenuto recuperato va trattato come dato, non come autorizzazione.

La guida OWASP sulla sicurezza degli agenti raccomanda, tra l'altro, strumenti in allowlist, privilegio minimo, validazione degli input e degli output, approvazione per azioni ad alto impatto, monitoraggio, limiti a costi, tentativi e catene di strumenti, oltre a test dopo cambiamenti di modello, prompt, memoria, retrieval o provider. Il principio operativo è semplice: ogni chiamata deve essere autorizzata e validata per conto proprio, anche se i dati letti in precedenza erano accessibili.

• Limite di volume: numero massimo di record o operazioni per sessione e per giorno.
• Limite economico: importo massimo per singola azione e totale cumulato.
• Limite temporale: finestre in cui l'agente può operare e scadenza delle bozze.
• Limite di strumenti: funzioni e parametri ammessi per quello specifico obiettivo.
• Circuit breaker: arresto dopo errori ripetuti, comportamento anomalo o dati essenziali mancanti.
• Kill switch: comando chiaro, accessibile e verificato per sospendere l'agente senza interrompere il gestionale.

Prima di collegare strumenti e azioni, conviene verificare qualità, significato, aggiornamento e permessi con la guida sui dati gestionali pronti per l'AI. Le API del software gestionale sono il punto in cui trasformare operazioni generiche in funzioni circoscritte e controllabili.

Un collaudo in 30 giorni prima di aumentare l'autonomia

Il collaudo deve partire da casi osservati, non da domande inventate per mettere il sistema a proprio agio. Raccogli un campione rappresentativo del processo, includendo eccezioni, dati incompleti, duplicati, permessi diversi e richieste ambigue. Definisci la risposta o l'azione attesa e chi ne giudica la correttezza.

1. Giorni 1-5 · Perimetro. Nomina proprietario del processo, utenti, fonti, strumenti, azioni vietate, soglie e modalità di arresto.
2. Giorni 6-10 · Modalità ombra. L'agente osserva gli stessi casi degli operatori ma non modifica nulla. Confronta risultati, fonti ed errori.
3. Giorni 11-20 · Proposta. Produce bozze o raccomandazioni. Gli utenti approvano, correggono o rifiutano motivando le eccezioni.
4. Giorni 21-25 · Prove di resistenza. Inserisci dati mancanti, documenti con istruzioni malevole, valori fuori soglia, richieste duplicate e utenti non autorizzati.
5. Giorni 26-30 · Decisione. Confronta qualità, tempo, rischio e costo; mantieni il livello, estendilo a un sottoinsieme o torna al flusso precedente.

Le metriche minime comprendono correttezza, rispetto dei permessi, percentuale di proposte accettate senza modifiche, falsi positivi e negativi, interventi umani, errori per tipo, operazioni annullate, tempo medio, costo per pratica e incidenti. Per le azioni, misura anche il tasso di rollback e il tempo necessario a riconoscere un esito sbagliato. Una media positiva non compensa un solo errore grave non contenuto.

Stabilisci prima le condizioni di uscita: zero accessi oltre ruolo; nessuna operazione finanziaria senza la conferma prevista; arresto se manca un dato obbligatorio; ritorno al processo manuale quando il servizio non è disponibile; revisione dopo ogni cambiamento rilevante. Il test di usabilità resta importante: la guida su come testare un gestionale in demo aiuta a misurare anche comprensione, errori e recupero da parte degli utenti.

Dodici domande da portare in demo o nel capitolato

1. Quali casi d'uso sono assistenza, quali proposta e quali esecuzione?
2. Quali dati, moduli e record può consultare ogni agente?
3. Con quale identità chiama il gestionale e dove vengono verificati i permessi?
4. È possibile separare credenziali di lettura, bozza e scrittura?
5. Quali azioni richiedono conferma e come si configurano soglie e approvatori?
6. Che cosa vede la persona prima di approvare?
7. Come vengono gestiti dati mancanti, conflitti, duplicati e documenti non affidabili?
8. Quali limiti esistono su volume, importo, durata, tentativi e catene di strumenti?
9. Come si sospende l'agente e come si annullano le modifiche?
10. Quali eventi contiene l'audit log, per quanto tempo resta disponibile e chi può leggerlo?
11. Come vengono testate regressioni dopo aggiornamenti di modello, regole, strumenti o dati?
12. Come si esportano configurazioni, risultati, log e costi del progetto?

Inserisci risposte ed evidenze in un capitolato per il software gestionale cloud. Evita promesse assolute di sicurezza o autonomia: chiedi una prova sul tuo processo, con utenti, permessi e casi limite reali.

AI Act: il caso d'uso viene prima dell'etichetta “agente”

Il Regolamento europeo sull'intelligenza artificiale adotta un approccio basato sul rischio e gli obblighi dipendono dal ruolo dell'organizzazione e dall'uso concreto del sistema. La Commissione indica, tra gli elementi centrali per i sistemi ad alto rischio, gestione del rischio, registrazione delle attività, documentazione, informazioni al deployer, supervisione umana, robustezza, sicurezza e accuratezza. Le regole di trasparenza sono entrate in applicazione nell'agosto 2026, mentre altre scadenze possono dipendere dal tipo di sistema e dagli aggiornamenti normativi.

Non ogni agente collegato a un gestionale è automaticamente ad alto rischio, e una pagina editoriale non può classificare il progetto. Un uso per riordini di magazzino è diverso da un sistema impiegato per selezionare candidati, valutare lavoratori o prendere decisioni che incidono su persone. Documenta finalità, dati, soggetti interessati e conseguenze, poi richiedi una valutazione competente quando il processo tocca ambiti regolati, diritti, sicurezza o decisioni rilevanti.

Domande frequenti

Qual è la differenza tra assistente e agente AI nel gestionale?

Un assistente risponde, riassume o prepara contenuti. Un agente può anche scegliere strumenti, eseguire più passaggi e modificare il sistema entro un perimetro. Il nome del prodotto conta meno della lista concreta di dati, strumenti e azioni consentiti.

Un agente AI deve poter scrivere subito nel gestionale?

No. La progressione più controllabile parte dalla sola lettura, passa per proposte e bozze, poi abilita eventuali scritture soltanto dopo test, autorizzazioni specifiche, validazioni e soglie di approvazione.

Quali azioni richiedono approvazione umana?

Di norma quelle finanziarie, irreversibili, esterne o con effetti su accessi, documenti ufficiali e persone. La regola va definita per processo usando importo, reversibilità, destinatario, dati coinvolti ed eccezioni, non una generica percentuale di confidenza.

Che cosa deve contenere l'audit log?

Identità, obiettivo, fonti, strumenti, parametri rilevanti, versioni delle regole, proposta, approvazione, record modificati, esito ed errori. Un identificativo comune deve consentire di ricostruire l'intera sequenza senza memorizzare dati sensibili non necessari.

Come si collauda un agente AI?

Con casi reali e casi limite, utenti con ruoli differenti, dati mancanti o malevoli e soglie definite in anticipo. Correttezza e tempo risparmiato vanno misurati insieme a permessi, interventi umani, rollback, costi e incidenti; il test va ripetuto dopo modifiche importanti.

Vuoi valutare un gestionale cloud con funzioni AI?

Porta in demo un processo reale, i livelli di autonomia consentiti e le prove attese: sarà più semplice distinguere una risposta utile da un'azione davvero controllabile.

Scopri le funzioni AIRichiedi una demo

Fonti: OWASP AI Agent Security Cheat Sheet; OWASP, Excessive Agency; Microsoft Dynamics 365, Approvals Agent; Microsoft, Security for Dynamics 365 ERP MCP; Commissione europea, AI Act; Regolamento (UE) 2024/1689. Consultate l'11 settembre 2026.