RPA o AI: automatizzare lo studio senza cambiare gestionale.

Perché il tema "RPA vs AI" riguarda ogni studio che vuole automatizzare

Quasi ogni studio, prima o poi, valuta l'idea di "automatizzare il gestionale": far fare a un software il lavoro ripetitivo che oggi fa un collaboratore — prima nota, riconciliazione, anagrafiche, quadrature. Il problema è che sotto l'etichetta "automazione" convivono due tecnologie molto diverse, con promesse e limiti opposti: la RPA (Robotic Process Automation) tradizionale e l'AI agente di nuova generazione. Confonderle porta a delusioni prevedibili: si compra un bot RPA aspettandosi l'intelligenza di un collega, e ci si ritrova con uno script che si rompe alla prima schermata spostata di dieci pixel.

Questa guida serve a fare chiarezza senza vendere fumo: come funziona davvero l'RPA, dove si rompe, come funziona invece un'AI agente che "capisce" invece di eseguire ciecamente, e perché — per la contabilità in particolare — serve un verificatore esterno al modello, non la fiducia cieca in nessuna delle due tecnologie.

Cos'è davvero l'RPA classica (e perché è fragile)

L'RPA è nata per automatizzare processi ripetitivi e stabili su interfacce che non cambiano: un bot registra una sequenza di azioni — clic sulle coordinate X,Y, digitazione in un campo, tasto invio — e la ripete identica migliaia di volte. Funziona bene finché l'interfaccia resta identica a se stessa.

Il problema è strutturale, non un dettaglio implementativo: uno script RPA non capisce cosa sta guardando. Non sa che quel rettangolo è "il campo P.IVA": sa solo che alle coordinate (420, 180) c'è un campo di testo, e ci scrive dentro. Se il gestionale sposta quel campo — un aggiornamento, un nuovo layout, una finestra ridimensionata, un menu che cambia posizione — lo script clicca nel posto sbagliato, o non trova nulla, e si ferma o (peggio) scrive il dato dove non deve.

• Si rompe a ogni release del gestionale: gli aggiornamenti software di Profis, TeamSystem, Zucchetti e simili sono continui. Ogni volta che cambia una videata, gli script vanno ritestati e spesso riscritti.
• Non generalizza su documenti diversi: uno script tarato sul formato fattura del fornitore A non funziona sul formato del fornitore B, anche se contengono gli stessi identici dati (P.IVA, imponibile, IVA).
• Richiede manutenzione costante: qualcuno in studio (o un fornitore esterno pagato a consulenza) deve tenere aggiornati gli script, spesso più tempo di quanto se ne risparmi.
• Non "capisce" gli errori: se un campo è vuoto o un valore è fuori formato, il bot esegue comunque l'azione programmata, anche se il risultato è sbagliato.

Non è che l'RPA sia inutile in assoluto: su un processo iper-stabile, a volume altissimo, con un'interfaccia che letteralmente non cambia mai, può avere senso. Ma questo scenario è raro in uno studio commercialista reale, dove i documenti arrivano da decine di fornitori diversi, i gestionali si aggiornano periodicamente e ogni cliente ha le sue eccezioni.

Cosa cambia con l'AI agente

Un'AI agente affronta lo stesso compito in un modo diverso nella sostanza, non solo nella tecnologia. Invece di eseguire coordinate memorizzate, osserva la videata o il documento (tramite modelli che leggono immagini, testo e struttura) e ne capisce il contenuto: riconosce che quel campo è "P.IVA" perché ne comprende il contesto — l'etichetta accanto, la posizione tipica, il formato del valore — non perché qualcuno gli ha detto "è alle coordinate 420,180".

Questa comprensione è ciò che permette di generalizzare: un'AI addestrata a riconoscere un campo P.IVA lo trova su un layout di fattura mai visto prima, e lo stesso vale per una videata di gestionale con un menu spostato o rinominato. Non elimina il rischio di errore — nessun sistema è infallibile — ma cambia la natura del problema: da "si rompe a ogni variazione" a "gestisce la variazione, segnala quando non è sicuro".

RPA vs AI: confronto diretto

Criterio	RPA classica (script)	AI agente
Robustezza ai cambi di interfaccia	Bassa: coordinate e sequenze fisse si rompono a ogni variazione	Alta: riconosce il contenuto (etichette, contesto), non le coordinate
Layout / documenti nuovi	Non generalizza: serve uno script dedicato per ogni formato	Generalizza: applica la stessa comprensione a formati mai visti
Manutenzione	Continua e onerosa: ogni release del gestionale richiede interventi	Minima sul lato "layout": l'aggiornamento riguarda soprattutto i casi limite
Verifica degli errori	Nessuna comprensione del dato: esegue comunque, anche se il risultato è sbagliato	Segnala incertezza, ma richiede comunque un verificatore esterno (es. partita doppia) per essere affidabile in contabilità
Scenario in cui ha senso	Processo iper-stabile, alto volume, interfaccia che non cambia mai	Documenti e videate eterogenei, gestionali che si aggiornano, eccezioni frequenti — il caso tipico di uno studio

Il pezzo che manca: la partita doppia come verificatore

Qui però bisogna essere onesti fino in fondo: capire un documento o una videata non basta a rendere un'automazione affidabile per la contabilità. Un modello AI, per quanto bravo, può comunque leggere male una cifra, confondere un fornitore, sbagliare un codice tributo. Il punto non è illudersi che l'AI sia infallibile — è mettere un verificatore esterno tra la proposta dell'AI e la scrittura definitiva.

Per la contabilità, quel verificatore esiste già ed è antico quanto la disciplina stessa: la partita doppia. Dare e avere devono quadrare. I totali dei conti devono tornare. Un codice tributo deve esistere ed essere coerente con il tipo di versamento. Una scrittura che genera uno sbilancio, o che referenzia un conto inesistente, o che non rispetta le regole di quadratura, non deve poter passare — indipendentemente da quanto il modello "si sentisse sicuro".

Questo è il motivo per cui un'automazione seria per lo studio non può essere "solo AI che scrive nel gestionale": deve essere AI che propone + un motore di verifica contabile che convalida + un operatore che conferma. Tre livelli, non uno. Lo script RPA cieco non ha nessuno di questi tre livelli: esegue e basta. Un'AI senza verificatore ne ha solo uno. Serve la combinazione.

Il pattern corretto per operare un gestionale senza API

Molti gestionali contabili italiani (Profis, TeamSystem, Zucchetti, Genya, B.Point, Passcom) non espongono API pubbliche pensate per questo tipo di automazione. Questo porta spesso a due strade sbagliate: rinunciare all'automazione, oppure inseguire integrazioni non ufficiali e fragili. C'è un terzo pattern, più onesto e più solido:

1. Il login resta dell'operatore: l'autenticazione al gestionale avviene sempre con le credenziali e la sessione dell'operatore umano, senza bypassare alcun controllo di accesso.
2. L'AI opera dentro quella sessione già autenticata: osserva le videate come farebbe una persona che guarda lo schermo, e prepara le azioni (inserimento prima nota, riconciliazione, aggiornamento anagrafiche) dentro il perimetro che l'operatore ha aperto.
3. In alternativa, i tracciati di import ufficiali: quando il gestionale espone formati di import strutturati (Excel, CSV, XML), l'AI prepara il file nel formato corretto e lo studio lo carica con la procedura ufficiale del software — nessuna scrittura diretta "sotto banco".
4. Nessuna scrittura senza conferma: sia nel caso della sessione operativa sia nel caso dell'import, la proposta dell'AI passa sempre da una conferma umana prima di diventare definitiva.

Questo pattern — browser/sessione per il login, AI dentro il perimetro autenticato, tracciati ufficiali dove disponibili — è deliberatamente più lento e più prudente di un'integrazione nascosta. È anche l'unico che non richiede fidarsi ciecamente di un accesso non autorizzato al software di terzi, e che sopravvive agli aggiornamenti del gestionale invece di rompersi a ogni release.

Human-in-the-loop: non è un compromesso, è il modello giusto

Questo non è un limite temporaneo in attesa di un'AI "più matura": è il modello corretto anche a regime. La contabilità ha conseguenze fiscali e legali dirette, e la responsabilità della registrazione è del professionista, non del software. Un sistema ben progettato usa il livello di confidenza dell'AI per smistare il lavoro: i casi chiari passano in proposta con conferma rapida, i casi dubbi finiscono in coda di revisione per un controllo umano vero.

Onestà sullo stato dell'arte: dove siamo davvero

Chiunque prometta oggi "l'AI che sostituisce completamente l'operatore sul tuo gestionale, su tutti i software, già disponibile ovunque" sta semplificando troppo. La realtà, allo stato attuale, è più graduale — ed è bene saperlo prima di scegliere un fornitore:

• Operare dentro un gestionale con un'AI che legge videate e documenti è una tecnologia reale ma ancora in fase di adozione, gestionale per gestionale.
• Per i software non ancora coperti da un'integrazione diretta, il punto di partenza pragmatico è la prima nota massiva con i tracciati di import ufficiali (Excel, CSV, XML): meno "spettacolare" di un'AI che clicca da sola nel gestionale, ma già oggi utilizzabile e sicura, perché passa dai canali che il software stesso mette a disposizione.
• Qualunque fornitore parli di operatività diretta su un gestionale dovrebbe specificare se è già live, in pilota o in roadmap — sono tre stadi molto diversi, e la differenza conta quando si tratta di scritture contabili.

Come valutare un fornitore che promette "automazione del gestionale"

Prima di firmare un contratto o partire con un pilota, vale la pena porre queste domande — e diffidare di chi non sa (o non vuole) rispondere con precisione:

1. È RPA a script o AI che generalizza? Chiedi cosa succede quando il gestionale rilascia un aggiornamento con una videata diversa: se la risposta è "va riscritto lo script", è RPA classica, con i limiti descritti sopra.
2. Chi fa il login? Se un fornitore chiede di condividere credenziali per un accesso automatizzato non presidiato dall'operatore, è un segnale d'allarme sul piano della sicurezza e della responsabilità.
3. C'è un verificatore contabile, o solo il modello linguistico? Chiedi esplicitamente se le scritture proposte vengono controllate contro un motore di quadratura (partita doppia, coerenza dei codici tributo) prima di arrivare all'operatore.
4. Cosa succede quando l'AI non è sicura? Deve esistere una risposta chiara: si astiene e passa il caso, non "tira a indovinare".
5. Qual è lo stato reale sul tuo gestionale specifico? Live, pilota o roadmap — con date, non promesse vaghe.

Per un quadro più ampio su come l'AI automatizza concretamente il data entry contabile (estrazione dati da fatture, F24, cedolini, riconciliazione), la guida sull'automazione contabile con l'AI approfondisce il lato "documenti"; questa guida si concentra sul lato "operare il software". Per il caso specifico della prima nota, vedi anche la guida su come automatizzare la prima nota con l'AI.

Conclusione: non è una gara di tecnologia, è una scelta di affidabilità

Il confronto RPA vs AI non è una questione di moda: è una questione di quale delle due tecnologie regge nel contesto reale di uno studio, fatto di documenti eterogenei, gestionali che cambiano e margini di errore che in contabilità non sono ammessi senza controllo. L'RPA a script cieco funziona solo finché nulla cambia intorno a lui — e nello studio qualcosa cambia sempre. Un'AI che capisce documenti e videate generalizza meglio, ma resta affidabile solo se accoppiata a un verificatore esterno (la partita doppia) e a una conferma umana prima di ogni scrittura.

Nessuna automazione seria elimina l'operatore dalla contabilità: lo sposta dal digitare al controllare. Questo è il pattern che Optlyx Clerk segue: login e sessione dell'operatore, AI che osserva e propone dentro quel perimetro (o prepara i tracciati di import ufficiali dove il gestionale li offre), verifica prima della scrittura, conferma umana sempre richiesta.

Domande frequenti su RPA e AI agenti in studio