Portare l’AI nel gestionale aziendale non significa comprare un nuovo ERP “con l’intelligenza artificiale dentro”. Nella maggior parte delle PMI la strada più rapida e meno rischiosa è un’altra: lasciare il gestionale e il CRM dove sono e costruire sopra un agente AI che li legge, li interroga e, solo dove serve e con le giuste conferme, ci scrive. I dati restano nel sistema che già conoscete, le persone non devono cambiare abitudini e l’investimento si concentra sull’integrazione, cioè sulla parte che produce valore.
In questo articolo spiego come lo imposto: cosa può fare un agente collegato al gestionale, come si collega tecnicamente, come si gestiscono permessi e sicurezza e da quale processo conviene partire.
Perché partire dal gestionale che avete già
I dati raccolti dall’indagine Istat Imprese e ICT 2025, riportati da PMI.it, dicono che il 48,8% delle PMI usa un sistema ERP e il 21,1% un CRM. Lo stesso quadro, ripreso anche da Confartigianato Liguria, segnala che tra le imprese che non usano l’AI il 70% dichiarava di non sapere come introdurla nei propri processi, mentre tra chi la usa l’applicazione più diffusa è l’estrazione di informazioni dai documenti.
Letti insieme, questi numeri indicano una cosa pratica: in molte aziende il sistema che contiene clienti, articoli, ordini, listini e scadenze esiste già. Manca il pezzo che collega quei dati al lavoro quotidiano, quello fatto di email, PDF, telefonate e domande ripetute ai colleghi. Cambiare gestionale per “avere l’AI” vuol dire affrontare migrazione dati, formazione, mesi di doppio lavoro. Aggiungere un agente sopra quello esistente vuol dire lavorare sull’integrazione e lasciare intatto il resto.
Cosa fa concretamente un agente AI collegato a ERP e CRM
Un agente AI è un modello linguistico a cui si danno strumenti: funzioni precise che può chiamare, come “cerca cliente”, “leggi ordini aperti”, “crea bozza di offerta”. Il modello decide quale strumento usare in base alla richiesta; il codice dell’integrazione esegue l’operazione sul gestionale. Ho approfondito la logica in come gli agenti AI scelgono lo strumento giusto.
Operazioni in lettura
- Domande in linguaggio naturale: “Quali ordini del cliente Rossi sono ancora da evadere?”, “Quanto abbiamo fatturato a questo cliente quest’anno?”, “Che giacenza ha l’articolo X nel magazzino di Ravenna?”. Oggi spesso queste risposte richiedono di aprire tre maschere o chiedere all’amministrazione.
- Preparazione delle chiamate commerciali: prima di un appuntamento l’agente riassume storico ordini, insoluti, ultime interazioni registrate nel CRM e offerte aperte.
- Controlli incrociati: confrontare un ordine ricevuto via email con listino e condizioni di pagamento del cliente, segnalando differenze.
Operazioni in scrittura (con controllo)
- Aggiornare il CRM dopo una email o una riunione: l’agente propone nota, prossima attività e fase dell’opportunità, la persona conferma.
- Bozze di offerte e preventivi costruite su articoli e prezzi reali del gestionale, non inventati dal modello.
- Inserimento dati da documenti: ordini, DDT, conferme d’ordine dei fornitori. Il caso specifico degli ordini l’ho descritto in automazione ordini clienti dall’email al gestionale.
Un dettaglio utile per chi opera in Italia: le fatture elettroniche passate dallo SdI sono file XML strutturati. Sono una fonte di dati pulita e già disponibile, spesso più affidabile dei PDF, per analisi su fornitori, prezzi d’acquisto e scadenze.
Come si collega un agente al gestionale: quattro strade
Il metodo di collegamento dipende da cosa il vostro gestionale permette. In ordine di preferenza:
- API ufficiali. Se il gestionale o il CRM espone API (REST o simili), è la scelta migliore: operazioni documentate, permessi gestiti dal fornitore, aggiornamenti del software che non rompono l’integrazione. Va verificato cosa è incluso nella vostra licenza: a volte le API sono un modulo a parte.
- Accesso al database in sola lettura. Per gestionali installati in sede senza API, si può creare un utente database con permessi di sola lettura e viste dedicate che espongono solo le tabelle necessarie. Le scritture invece non vanno mai fatte direttamente sul database: si rischia di saltare le logiche interne del programma (numerazioni, movimenti di magazzino, contabilità).
- Import/export di file. Molti gestionali importano CSV o XML con tracciati definiti. L’agente prepara il file, il gestionale lo importa con i suoi controlli. È meno elegante ma robusto.
- RPA o automazione dell’interfaccia. Simulare clic e digitazione è l’ultima risorsa: funziona, ma è fragile a ogni aggiornamento grafico. La uso solo quando non esiste alternativa.
Sopra questi collegamenti c’è lo strato di orchestrazione: un workflow in n8n o un servizio scritto su misura che espone gli strumenti all’agente. Sempre più spesso li rendo disponibili tramite Model Context Protocol (MCP), così lo stesso connettore al gestionale può essere riutilizzato da più assistenti senza riscriverlo.
Permessi, sicurezza e tracciabilità
Un agente con accesso al gestionale è, a tutti gli effetti, un nuovo utente del sistema. Va trattato come tale, con regole precise:
- Utente tecnico dedicato, mai le credenziali di un dipendente. Così si sa sempre cosa ha fatto l’agente e lo si può disattivare in un attimo.
- Minimo privilegio: se l’agente serve al commerciale, non deve vedere buste paga o centri di costo riservati. Meglio strumenti stretti (“leggi ordini del cliente”) che strumenti generici (“esegui query”).
- Prima la lettura, poi la scrittura. Si parte con un agente che consulta e propone; le scritture si attivano solo dopo aver visto come si comporta su casi reali.
- Conferma umana sulle azioni che contano: invio offerte, modifica prezzi, cambi di anagrafica. È il principio dello human-in-the-loop.
- Log completi: richiesta, strumento chiamato, parametri, risultato. Senza log non si può né correggere né rispondere a un cliente che contesta un dato.
Sul fronte privacy, se l’agente tratta dati personali di clienti o dipendenti va valutato dove gira il modello, quali dati gli vengono inviati e cosa prevede il contratto con il fornitore. Per dati particolarmente sensibili si può valutare un modello ospitato su infrastruttura propria.
Da dove partire: un percorso in cinque passi
- Scegliere una domanda ricorrente. Non “mettere l’AI nel gestionale”, ma “rispondere alle richieste di stato ordine che arrivano via email” o “preparare la scheda cliente prima delle visite”.
- Mappare i dati necessari: in quali tabelle o endpoint stanno, chi ne è responsabile, quanto sono affidabili. Se le anagrafiche hanno duplicati, l’agente li erediterà.
- Verificare il metodo di accesso tra le quattro strade descritte sopra, coinvolgendo se serve il fornitore del gestionale.
- Costruire un prototipo in sola lettura e farlo usare a due o tre persone su richieste vere, raccogliendo errori e domande non previste.
- Misurare e decidere: tempo risparmiato per richiesta, errori evitati, risposte sbagliate dell’agente. Solo a quel punto si allarga il perimetro o si aggiungono le scritture.
Errori che vedo più spesso
- Dare all’agente accesso a tutto “per vedere cosa sa fare”. Il risultato sono risposte imprecise e un rischio inutile.
- Lasciare che il modello calcoli totali, sconti o giacenze. I numeri li calcola il gestionale o il codice; il modello li riporta e li spiega.
- Ignorare la qualità dei dati: un agente rende visibili in fretta anagrafiche sporche e codici articolo incoerenti.
- Non prevedere cosa succede quando il gestionale non risponde: timeout, manutenzioni, aggiornamenti. L’agente deve dirlo chiaramente, non improvvisare una risposta.
Domande frequenti
Serve cambiare gestionale per usare l’AI?
Nella maggior parte dei casi no. Se il gestionale ha API o un database accessibile in lettura, un agente può lavorarci sopra. Il cambio di sistema ha senso per altri motivi (software non più supportato, limiti funzionali), non per aggiungere l’AI.
Funziona anche con un gestionale installato in sede?
Sì. Si può esporre un connettore sicuro sulla rete aziendale, con viste in sola lettura sul database o con import di file per le scritture. Va progettato con attenzione l’accesso dall’esterno.
L’agente può sbagliare un dato del gestionale?
Il rischio si riduce molto se l’agente recupera i dati tramite strumenti e non dalla propria “memoria”, e se i calcoli restano al gestionale. Le scritture importanti passano comunque da una conferma umana.
Quanto tempo serve per un primo prototipo?
Dipende soprattutto dal metodo di accesso ai dati: con API documentate si procede in fretta, con sistemi chiusi serve più analisi. Per questo il primo passo è sempre una verifica tecnica del gestionale.
Portare l’AI sul vostro gestionale
Il valore dell’AI per una PMI non sta nel modello più recente, ma nel collegamento con i dati su cui l’azienda lavora ogni giorno. Se volete capire come mettere un agente AI sopra il vostro ERP o CRM, partendo da un processo concreto e con accessi e controlli progettati bene, contattatemi: analizziamo insieme il gestionale che usate e il primo caso d’uso da cui conviene iniziare.
