Integrare l'AI nel gestionale: come collegare un LLM ai dati aziendali

Integrare l'AI nel gestionale significa dare a un modello linguistico un accesso controllato ai dati aziendali, così che i colleghi possano interrogarli o usarli per preparare documenti scrivendo in italiano. Il gestionale resta il posto dove stanno permessi, calcoli e registrazioni: l'AI legge, riassume e propone, e all'inizio lo fa solo in lettura, su un caso d'uso preciso.

I casi d'uso più concreti nascono da domande che oggi richiedono di aprire tre schermate e un foglio di calcolo. Qualche esempio, da prendere come tale:

• «Quali clienti non ordinano da sei mesi e quanto hanno acquistato l'anno scorso?», con la risposta già in tabella.
• Il riepilogo di una pratica o di un cliente prima di una telefonata: ordini, ticket aperti, ultime comunicazioni.
• La bozza di un'offerta o della risposta a un reclamo, costruita sui dati del cliente e rivista da una persona.
• La ricerca in manuali, procedure e schede tecniche, con il riferimento al documento da cui arriva la risposta.
• La classificazione di richieste in entrata, ordini o documenti, da smistare alla persona giusta.

Ci sono anche compiti da non affidargli: i calcoli contabili definitivi, che spettano al gestionale, e le decisioni con effetti importanti sulle persone. Se l'uso riguarda selezione, valutazione o gestione del personale, l'AI Act lo classifica tra i sistemi ad alto rischio, con obblighi specifici che, dopo la modifica approvata nel 2026, si applicano dal 2 dicembre 2027.

Non esiste un'architettura unica. La scelta dipende dal software che usi, da quanto è documentato e da cosa deve fare l'AI. Le strade principali sono cinque:

• Funzioni AI già incluse nel software: diversi gestionali e piattaforme le stanno aggiungendo, come Sidekick nel pannello di Shopify. È la strada più rapida, ma lavora solo sui dati di quel prodotto.
• Assistente sulle API del gestionale: il modello non tocca il database, chiede di eseguire funzioni precise (cerca cliente, leggi ordini) che il tuo codice esegue con i permessi dell'utente. È il meccanismo che OpenAI chiama function calling e Anthropic tool use.
• Model Context Protocol: uno standard open source per collegare le applicazioni AI a sistemi esterni, come database e strumenti di lavoro. Un connettore scritto una volta può servire a più assistenti.
• Domande tradotte in SQL: il modello scrive query sul database a partire dalla domanda. Funziona anche sui sistemi senza API, ma va fatto su una copia in sola lettura e su viste preparate, mai sul database di produzione con permessi pieni.
• Ricerca nei documenti: per manuali, procedure e contratti il modello riceve i passaggi pertinenti trovati da un motore di ricerca interno e risponde citandoli.

Spesso le strade si combinano: API per i dati strutturati, ricerca nei documenti per tutto ciò che vive nei PDF. Se l'assistente deve rispondere anche ai clienti sul sito, valgono in più le regole del chatbot aziendale, a partire dall'obbligo di dichiarare che si sta parlando con un'IA.

È la domanda che decide il progetto. L'ISTAT rileva che tra le imprese che hanno valutato l'AI senza adottarla il 45,2% indica dati non disponibili o di scarsa qualità tra gli ostacoli. Un modello che legge anagrafiche doppie o campi compilati a caso produce risposte sbagliate con molta sicurezza. Prima di scegliere il modello, verifica questi punti:

• Accesso: il contratto con il fornitore del gestionale include le API? Alcuni software le documentano pubblicamente, come Fatture in Cloud, altri le concedono solo su richiesta.
• Significato dei campi: cosa vuol dire «stato 3», quale data conta tra consegna prevista ed effettiva. Queste regole vanno scritte, perché il modello non può indovinarle.
• Qualità: duplicati, campi vuoti, codici usati in modo diverso da reparti diversi.
• Responsabilità: chi risponde di ogni dato e chi decide chi può vederlo.
• Domande di prova: un elenco di domande vere con la risposta corretta già nota, per misurare quanto il sistema sbaglia prima di metterlo in mano ai colleghi.

OWASP, organizzazione che pubblica linee guida aperte sulla sicurezza del software, dedica un rischio specifico all'eccesso di autonomia degli assistenti AI: funzioni, permessi o libertà d'azione superiori al necessario. Le contromisure vanno progettate dall'inizio:

• l'assistente vede solo ciò che può vedere l'utente che lo sta usando, con i suoi permessi e mai con un'utenza amministrativa;
• sul database i permessi si limitano anche riga per riga: PostgreSQL, per esempio, offre le politiche di sicurezza a livello di riga che filtrano i record visibili a ciascun utente;
• si parte in sola lettura, e le scritture arrivano dopo, una funzione alla volta e con la conferma di una persona;
• ogni domanda, query e risposta viene registrata, così si può ricostruire cosa è successo;
• i testi che arrivano da fuori, come email o documenti dei clienti, si trattano come non affidabili, perché possono contenere istruzioni nascoste: è la prompt injection indiretta.

Pensa a un'azienda che collega l'assistente al CRM con un'utenza che vede tutto: un addetto potrebbe chiedere dati di colleghi o di clienti che non gli competono, e il modello risponderebbe. Il difetto in quel caso non sta nel modello, sta nei permessi che gli sono stati dati.

Se nei dati ci sono persone, come clienti, fornitori o dipendenti, e il modello gira in cloud, il fornitore tratta dati personali per tuo conto e va nominato responsabile del trattamento con un contratto. Il GDPR chiede anche di trattare solo i dati necessari e di adottare misure di sicurezza adeguate; se il trattamento può presentare un rischio elevato per le persone, serve una valutazione d'impatto prima di partire.

Sui modelli in cloud verifica per iscritto se i dati servono ad addestrarli e dove vengono elaborati. OpenAI, per esempio, dichiara che i dati inviati alle sue API non vengono usati per l'addestramento salvo consenso esplicito, e prevede per i clienti idonei la residenza dei dati in Europa. In alternativa si possono usare modelli open source installati su server tuoi o in un cloud europeo: più controllo, più lavoro di gestione.

Parti da qualcosa di piccolo e misurabile. Le fasi tipiche sono queste, e quanto durano dipende soprattutto da quanto i dati sono accessibili e ordinati:

• scegli una famiglia di domande o un compito, con un responsabile interno che lo conosce bene;
• misura come si lavora oggi: quanto tempo richiede, dove si sbaglia;
• costruisci un prototipo in sola lettura, collegato a una copia dei dati;
• provalo con le domande di prova e con gli utenti veri, correggendo fonti, permessi e istruzioni;
• estendi solo ciò che funziona: nuove domande, nuove fonti, poi eventuali scritture.

È la stessa logica di un MVP: il minimo che dimostra il valore, prima di investire sul resto. I gestionali su misura sono il terreno più semplice per questo lavoro, perché dati e permessi sono già disegnati attorno ai processi. Per KEY abbiamo sviluppato un CRM interno multi-account, in cui ogni consulente gestisce le proprie pratiche e la direzione ha una vista unica; per Rial Rent un CRM con automazioni che smistano le richieste di noleggio e avvisano il team.

Raccontaci quali risposte restano chiuse nel tuo gestionale perché nessuno ha il tempo di estrarle. Con lo sviluppo software su misura progettiamo l'integrazione partendo da permessi e dati, e per modelli e assistenti lavoriamo con la nostra AI agency.

Articolo a cura diPietro Previtali

Fondatore di My Web Lab, web agency con sede a Segrate (Milano): oltre 150 progetti tra siti su misura, e-commerce e web app. Rivede ogni guida del blog prima della pubblicazione.

Lavora con noi →