Perché l’AI da sola non basta
Un modello linguistico può leggere un’email, capire che contiene un ordine ed estrarne le righe. Ma finché quelle righe non finiscono nel gestionale, il lavoro non è finito: qualcuno dovrà comunque copiarle. Il valore di un progetto AI in azienda si realizza nell’integrazione con i sistemi che l’azienda usa già — gestionale, ERP, CRM, sistema documentale — non nella capacità del modello in sé.
Integrare significa tre cose: leggere dati dal sistema (anagrafiche, listini, stato degli ordini), scrivere dati nel sistema (bozze, record, documenti) e farlo in modo sicuro, tracciato e reversibile. In questo articolo descriviamo le opzioni tecniche disponibili, i controlli che consideriamo indispensabili e un flusso di esempio dall’email all’operatore che conferma.
Le opzioni di integrazione
Non esiste un’unica modalità corretta. La scelta dipende da ciò che il gestionale espone, dal tipo di operazione (lettura o scrittura), dalla frequenza e dal livello di rischio. Spesso in uno stesso progetto convivono due o tre di queste opzioni.
API
Quando il gestionale espone un’interfaccia applicativa (REST, SOAP, GraphQL o un’API proprietaria documentata), è quasi sempre la strada preferibile. Le API definiscono in modo esplicito che cosa si può leggere e scrivere, applicano le regole di validazione del gestionale stesso e permettono di usare credenziali dedicate con permessi limitati.
Vantaggi: controllo, tracciabilità, regole del sistema rispettate. Limiti: non tutti i gestionali le espongono, e quando esistono possono non coprire tutte le operazioni necessarie.
Middleware
Un livello intermedio (un servizio, una piattaforma di integrazione, un componente sviluppato su misura) che si colloca tra l’AI e il gestionale. Il middleware riceve i dati estratti, li normalizza, applica le regole aziendali, gestisce le code, i tentativi e gli errori, e solo poi comunica con il sistema di destinazione.
È la scelta naturale quando ci sono più sistemi da collegare, quando servono trasformazioni complesse o quando si vuole tenere la logica di controllo fuori dal gestionale e fuori dal modello AI. È anche il punto in cui vivono la coda di approvazione e il log.
Database (quando è appropriato)
In alcuni casi l’unica via di accesso è il database del gestionale. È una modalità che va trattata con cautela: in lettura può essere accettabile (con un utente in sola lettura, su viste dedicate), in scrittura diretta è di solito sconsigliata, perché salta le regole di validazione dell’applicazione e può compromettere l’integrità dei dati.
Quando la scrittura su database è inevitabile, la limitiamo a tabelle di appoggio o di staging previste dal fornitore del gestionale, con la registrazione definitiva affidata alle procedure del sistema stesso.
Webhook
I webhook permettono al gestionale (o al CRM) di notificare un evento — nuovo ordine, cambio di stato, nuovo cliente — a un servizio esterno. Sono utili per attivare flussi AI in risposta a ciò che accade nel sistema, invece di interrogarlo continuamente. Esempio: alla creazione di un’opportunità nel CRM, un flusso prepara una bozza di email di primo contatto.
File strutturati
CSV, XML, JSON, tracciati di importazione: molti gestionali, soprattutto quelli meno recenti, offrono procedure di import/export basate su file. Non è la modalità più elegante, ma è affidabile e spesso già conosciuta dall’azienda. L’AI produce il file nel tracciato previsto, il gestionale lo importa con le proprie regole, l’operatore verifica l’esito.
Confronto rapido
| Opzione | Lettura | Scrittura | Quando usarla |
|---|---|---|---|
| API | Sì | Sì, con le regole del sistema | Preferibile quando disponibile |
| Middleware | Tramite le altre opzioni | Tramite le altre opzioni | Più sistemi, logica di controllo, code e approvazioni |
| Database | Sì, con cautela | Solo su tabelle di appoggio | Quando non esistono alternative |
| Webhook | Eventi in uscita dal sistema | No | Attivare flussi in risposta a eventi |
| File strutturati | Sì (export) | Sì (import) | Gestionali con procedure di import consolidate |
Sicurezza, permessi e logging
L’integrazione con il gestionale è il punto in cui un progetto AI tocca i dati più sensibili dell’azienda. I controlli che seguono non sono opzionali.
Credenziali dedicate. Il flusso AI non usa l’utenza di una persona. Ha un proprio utente tecnico, con un nome riconoscibile nei log del gestionale, e con il minimo insieme di permessi necessario al processo. Se il flusso deve creare bozze di ordini, non ha accesso ai dati bancari dei fornitori.
Separazione tra lettura e scrittura. Le operazioni di lettura e quelle di scrittura usano permessi diversi, e le scritture sono limitate alle entità e ai campi concordati. Un flusso che aggiorna il CRM può creare attività, ma non modificare l’importo di un’opportunità.
Perimetro dei dati. Il modello AI riceve solo i dati necessari all’operazione: non l’intero database, non l’intero storico. Quando si usano servizi AI esterni, va verificato con il fornitore che i dati non vengano conservati o utilizzati per altri scopi, e che le condizioni contrattuali siano compatibili con le policy aziendali.
Log completo. Ogni operazione viene registrata: input ricevuto, dati estratti, controlli eseguiti e loro esito, azione compiuta sul gestionale, esito dell’azione, identità dell’eventuale operatore che ha approvato. Il log deve permettere di ricostruire, per ogni record nel gestionale, da dove è arrivato e chi lo ha confermato.
Reversibilità. Ogni scrittura automatica deve essere annullabile. Nella pratica questo significa scrivere prima in stato “bozza” o “da confermare” e lasciare al gestionale la transizione allo stato definitivo.
L’approvazione umana sulle scritture
La regola che seguiamo è semplice: le letture possono essere automatiche, le scritture definitive passano da una persona finché il flusso non ha dimostrato di essere affidabile su quel tipo di operazione, e alcune scritture restano sempre sotto approvazione.
Rientrano nella seconda categoria, tipicamente: creazione di nuove anagrafiche, modifiche di prezzi e condizioni, cancellazioni, operazioni sopra una soglia di importo, comunicazioni verso l’esterno. La soglia e l’elenco vanno definiti con l’azienda, non dal fornitore della tecnologia.
L’approvazione non deve essere un ostacolo: l’operatore vede la bozza già compilata, con le eventuali anomalie evidenziate, e conferma con un’azione sola. Il tempo passa dal ricopiare al verificare.
Esempio di flusso: dall’email ordine alla conferma dell’operatore
Questo è un esempio di processo automatizzabile, descritto passo per passo.
- Arrivo dell’email. Un cliente invia un ordine alla casella ordini dell’azienda con un PDF allegato.
- Classificazione. Il flusso riconosce che si tratta di un ordine e non, per esempio, di una richiesta di preventivo.
- Estrazione. Dal PDF vengono estratti cliente, riferimento, data di consegna richiesta e righe (codice, descrizione, quantità, prezzo).
- Verifica tramite API in lettura. Il flusso interroga il gestionale: il cliente esiste? Il codice articolo è valido? Il prezzo corrisponde al listino del cliente? La quantità è compatibile con il confezionamento?
- Gestione delle anomalie. Le righe con codice non trovato vengono associate a un candidato tramite la descrizione, con un’indicazione di confidenza; le righe con prezzo diverso dal listino vengono evidenziate.
- Scrittura della bozza. L’ordine viene creato nel gestionale in stato “bozza” tramite API, con un riferimento al messaggio originale.
- Notifica all’operatore. L’operatore riceve una notifica con il riepilogo: righe corrette, righe da verificare, differenze rispetto al listino.
- Conferma. L’operatore corregge se necessario e conferma. Solo a questo punto l’ordine diventa effettivo nel gestionale.
- Log e risposta. Il log registra tutto il percorso; una bozza di conferma al cliente viene preparata e inviata secondo la policy aziendale.
Il punto importante è il passaggio 8: la persona non è stata sostituita, è stata spostata dal lavoro di trascrizione a quello di controllo. Il flusso completo dal lato documentale è descritto nell’articolo su come automatizzare email e documenti con l’AI.
Come iniziare: un processo, un prototipo
L’errore più comune è voler integrare tutto subito. Il percorso che consigliamo è diverso:
- Scegliere un processo. Uno solo, con volume, regole chiare e un responsabile che lo conosce.
- Verificare che cosa espone il gestionale. API, tracciati di import, webhook, accesso al database: questa verifica determina l’architettura.
- Costruire un prototipo in sola lettura. Il flusso legge, estrae, verifica e produce una bozza fuori dal gestionale. Si confronta con il lavoro manuale per alcune settimane.
- Attivare la scrittura in bozza con approvazione. Il flusso scrive nel gestionale in stato non definitivo; l’operatore conferma.
- Estendere il perimetro. Solo dopo aver osservato il comportamento reale, si decide che cosa può procedere senza conferma e che cosa no.
Questo percorso ha un vantaggio pratico: a ogni passo l’azienda può fermarsi, misurare e decidere, senza aver compromesso i dati del gestionale e senza aver cambiato il modo di lavorare delle persone prima di avere prove che il flusso funziona.
Nella pagina dedicata all’integrazione dell’AI con gestionali ed ERP trovi come affrontiamo la fase di analisi tecnica, quali informazioni ci servono sul gestionale in uso e come gestiamo sicurezza e approvazioni. Se vuoi partire da un processo concreto, puoi parlarci del tuo progetto: analizziamo un processo della tua azienda e valutiamo come automatizzarlo.