Un agente AI che usa il gestionale come un impiegato può aprire la scheda giusta, salvarla e lasciare nel database un valore sbagliato. Sullo schermo, intanto, compare la conferma di salvataggio.
In una prova pubblicata a settembre 2026 su un gestionale vero, uno degli agenti ha premuto «salva» nell'85% dei tentativi e ha scritto il valore corretto nel 3%.
L'agente che usa lo schermo
Un agente che usa il computer (in inglese computer-use agent) lavora come lavorerebbe una persona davanti al monitor. Guarda un'immagine dello schermo, decide dove cliccare, scrive nei campi, preme i pulsanti. Non ha bisogno che il programma abbia un accesso pensato per altri programmi: gli basta l'interfaccia che usano già i dipendenti.
Per un'azienda da trenta persone è un argomento forte. Il gestionale è spesso vecchio, personalizzato negli anni, senza API — il canale con cui un software parla direttamente con un altro — oppure con un'API che costa un modulo aggiuntivo e una giornata di consulenza del fornitore. L'agente che usa lo schermo promette di saltare tutto questo: lo si mette davanti al gestionale e lavora.
Anche gli autori della prova descrivono così il loro scenario: un agente che vede solo immagini dello schermo imita il caso di chi usa un software aziendale da un desktop remoto, dove nessuna API è disponibile.
Resta la domanda che conta: cosa lascia scritto quell'agente, quando dice di aver finito.
Una prova che guarda il database
Lo studio si chiama ERPBench ed è stato pubblicato su arXiv il 15 settembre 2026 da cinque ricercatori del Center for Advanced AI di Accenture (Bhagtani e altri, arXiv:2609.17885).
Il gestionale usato è ERPNext, un gestionale (ERP) open source con contabilità, acquisti, magazzino, vendite e progetti, installato in locale. Gli agenti lo vedono solo attraverso immagini dello schermo a 1280×720 e agiscono con clic e tasti simulati. Niente accesso alla struttura della pagina, niente scorciatoie.
I compiti sono trenta, su tre livelli:
- T1, venti compiti su un solo campo o un record semplice: correggere l'identificativo fiscale di un cliente, spuntare una casella, creare un cliente con pochi dati;
- T2, quattro compiti su un record completo, con sei-nove campi da compilare e collegare;
- T3, sei compiti a catena su più schermate, come da un contatto a un'opportunità, o da un progetto a un'attività e al foglio ore.
Ogni compito è stato ripetuto cinque volte per ogni agente: 150 tentativi a testa.
A decidere se un tentativo è riuscito non è lo schermo. Alla fine di ogni tentativo il sistema legge i campi nel database e li confronta con i valori attesi, e il compito è riuscito solo se ogni campo è giusto. Qui interessa cosa succede quando lo schermo è l'unico canale che l'agente ha.
Salvato non vuol dire scritto giusto
Il risultato che dà il titolo a questo pezzo sta nella tabella che scompone ogni tentativo in fasi: arrivare al record, inserire il valore, salvare, trovare il valore giusto nel database.
Il caso più netto è UI-TARS-7B, un modello aperto addestrato proprio per usare le interfacce. Sui compiti del primo livello arriva alla scheda giusta nel 95% dei tentativi, preme «salva» nel 68%, e lascia il valore corretto nel database nel 9%. Sui record da sei-nove campi del secondo livello salva nell'85% dei tentativi, ma i campi giusti nel database sono il 3%, e nessun compito è completato per intero.
Gli altri modelli aperti vanno nella stessa direzione. Sul primo livello trovano la scheda giusta nel 90-95% dei casi, ma i migliori, Holo3-35B-A3B e Qwen3-VL-32B, completano correttamente solo il 34% e il 32% dei compiti. Sul secondo livello nessun modello aperto completa per intero un solo compito, e sulle catene del terzo nessuno supera il 3%.
Gli autori spiegano perché lo schermo inganna. La conferma che compare dopo il salvataggio dice che l'interfaccia ha accettato un'azione, non che il valore sia arrivato nel database: il testo scritto nel campo a video può non essere mai stato collegato al campo vero, e quello che resta è vecchio, vuoto o sbagliato.
Per un'azienda questo è il caso peggiore. Un agente che si blocca lo vede qualcuno. Un agente che salva un'aliquota sbagliata sulla scheda di un fornitore non lo vede nessuno, finché il dato non passa in una fattura, in un ordine o nella chiusura del mese.
I cinque modi di sbagliare
Il paper classifica i tentativi falliti del primo livello in cinque tipi:
- Pianificazione: l'agente non arriva mai alla scheda giusta.
- Elemento sbagliato: ci arriva, ma agisce sul campo o sul pulsante sbagliato, e il valore non viene inserito.
- Salvataggio mancato: inserisce il valore giusto, ma non salva.
- Valore sbagliato salvato: salva, e nel database finisce un valore errato.
- Cicli senza uscita: resta intrappolato a ripetere le stesse azioni finché non finiscono i turni a disposizione.
Il primo e l'ultimo si vedono. Il secondo spesso anche. Il terzo e il quarto sono fallimenti silenziosi: lo schermo mostra un'operazione andata a buon fine e il registro contiene altro. Sono esattamente quelli che un controllo fatto guardando lo schermo, o rileggendo la sequenza di clic, classificherebbe come successi.
I modelli aperti si perdono poco nella navigazione: sbagliano soprattutto dopo, quando devono mettere il dato giusto nel campo giusto. Per UI-TARS-7B il 59% dei fallimenti è del quarto tipo: valore sbagliato, salvato.
Il modello migliore arriva al livello umano, su trenta compiti
L'eccezione è Claude Sonnet 4.6, il modello di Anthropic usato nella prova: completa correttamente il 94% dei tentativi al primo livello e il 100% al secondo e al terzo. Tre persone hanno fatto gli stessi compiti come riferimento: le due esperte di ERPNext stanno fra il 95% e il 100%, quella che non l'aveva mai usato fra l'87% e il 96%.
Letto da solo, sembrerebbe che il problema sia risolto per chi sceglie il modello giusto. Tre cose ridimensionano il risultato.
È un tetto misurato su pochi compiti. Il 100% del secondo livello viene da quattro compiti ripetuti cinque volte. Su un campione così un risultato perfetto dice che l'agente ce la può fare, non con che frequenza sbaglierà sul millesimo ordine.
Costa di più man mano che il lavoro si allunga. Per ogni tentativo il modello riceve in media 231 mila token — le unità con cui si paga l'uso di un modello — al primo livello, e circa 2 milioni al terzo. Un compito a catena gli richiede in media 36 azioni e poco più di cinque minuti.
Il gestionale era pulito e scelto dai ricercatori. Un ERPNext installato per la prova, con i dati preparati prima di ogni tentativo. Il gestionale di una PMI ha maschere personalizzate, campi riusati per altri scopi, finestre che compaiono solo a fine mese.
Il messaggio della prova non cambia: fra salvare e scrivere giusto c'è uno scarto, e per quasi tutti i modelli misurati è enorme. Anche per quello che sbaglia di rado, qualcuno deve poterlo verificare.
Quanto pesa questa fonte
ERPBench è un paper di otto pagine, sottoposto alla conferenza ICASSP 2027 e non ancora passato da una revisione. Lo firma il laboratorio di AI di Accenture, una società di consulenza che vende alle aziende progetti di AI e di integrazione; nel paper presentano anche lo strumento con cui far lavorare questi agenti in produzione. Le trenta prove girano su un solo gestionale, open source. Il riferimento umano l'hanno fatto gli autori stessi. Il codice della prova e dello strumento non è ancora pubblico: gli autori scrivono che intendono rilasciarlo, senza indicare dove né quando.
Il metodo — giudicare dal database — è dichiarato e sensato, e regge anche con queste avvertenze. I numeri indicano una direzione; per scegliere un fornitore servono prove sul tuo gestionale.
Schermo o integrazione: la domanda da fare prima
Il paper non confronta l'agente sullo schermo con un'integrazione diretta, quindi non dice quale delle due sia migliore. Dice però una cosa utile per la scelta: quando l'agente passa dallo schermo, la sua conferma non basta a sapere cosa è stato scritto.
Da qui il ragionamento che facciamo nei progetti.
Se il gestionale ha un accesso diretto, parti da lì. Un'API, un modulo di importazione, una tabella di scambio che il fornitore sa leggere. L'agente che scrive attraverso un canale del genere riceve una risposta dal sistema, non da un'immagine, e quella risposta si può controllare. Costa una conversazione col fornitore del gestionale, che è la stessa conversazione che l'agente sullo schermo prometteva di evitare. Di solito conviene farla.
Se l'accesso diretto non c'è, lo schermo è una strada, a tre condizioni.
- Il controllo legge il dato, non lo schermo. Anche in ERPBench l'agente scrive dallo schermo, ma il giudice legge il database. Se il tuo gestionale permette almeno di leggere i dati — un'esportazione, un accesso in sola lettura, una stampa — il risultato di ogni operazione dell'agente va confrontato con quello, non con la schermata finale.
- Prima di salvare decide una persona. Nello strumento presentato nel paper, quando lavora in produzione ogni azione viene proposta a una persona, tranne, volendo, quelle classificate come innocue; salvataggi e operazioni irreversibili richiedono sempre una conferma esplicita. I numeri della prova sono stati misurati con quel controllo spento, cioè nelle condizioni di un agente lasciato solo.
- L'agente entra con un'utenza sua. Un agente che clicca nel gestionale ci entra con le credenziali di qualcuno, e ogni valore sbagliato che salva finisce nel registro con quel nome: è il motivo per cui un agente ha bisogno di un'identità propria.
È lo stesso principio con cui è costruito Noeva: gli agenti lavorano sui sistemi del cliente attraverso tool di integrazione, le persone approvano quando serve una scelta, e ogni esecuzione resta tracciata. Una scrittura che non si può verificare non si può nemmeno correggere.
Prima di far entrare un agente nel gestionale
La promessa dell'agente che usa lo schermo è reale: arriva dove le integrazioni non arrivano. Quello che ERPBench misura è il prezzo nascosto di quella promessa. Arrivare alla scheda giusta è la parte facile; mettere il valore giusto nel campo giusto, e salvarlo davvero, è dove quasi tutti i modelli provati si perdono, e dove lo schermo non se ne accorge.
A chi ti propone l'agente conviene chiedere una cosa sola: come si verifica, a fine giornata, che quello che l'agente dice di aver salvato sia davvero nel database. Se per saperlo serve un accesso ai dati che oggi non hai, quell'accesso è il primo pezzo del progetto.
Se domani un agente compilasse cento schede nel tuo gestionale, come faresti a sapere quante sono giuste?