Un sistema di AI che non accede ai dati operativi resta un esercizio. Il valore nasce quando legge e scrive nei sistemi che l’azienda usa già.
La distanza tra le due condizioni è quasi interamente lavoro di integrazione. Ed è la voce che, nelle stime iniziali, viene sottodimensionata con maggiore regolarità.
Non per superficialità. Perché è invisibile nelle demo, dove i dati sono statici e i sistemi coinvolti sono simulati.
Perché l’integrazione è la voce più sottovalutata
Tre ragioni ricorrenti.
Il costo non sta nella connessione ma nel dominio. Collegarsi tecnicamente a un gestionale è raramente il problema. Il problema è capire che cosa significano i dati: quale campo contiene lo stato effettivo di una pratica, quali codici sono ancora in uso, quali anagrafiche sono duplicate, quali regole non scritte governano l’aggiornamento di un valore. È lavoro di analisi, e richiede il tempo delle persone che conoscono il sistema.
I sistemi in uso non sono stati progettati per essere interrogati dall’esterno. Molti gestionali, in particolare quelli verticali o personalizzati negli anni, espongono interfacce parziali o non ne espongono affatto. Le alternative — accesso diretto alla base dati, esportazioni periodiche, sviluppo di uno strato intermedio — hanno implicazioni diverse su affidabilità, permessi e manutenzione, e vanno valutate all’inizio.
Le dipendenze organizzative sono più lente di quelle tecniche. L’accesso a un sistema richiede autorizzazioni, il coinvolgimento del fornitore che lo mantiene, talvolta la revisione di un contratto. Sono tempi che non dipendono dal team di progetto e che vanno messi a piano.
Una verifica utile in fase di stima: se il piano di progetto dedica all’integrazione meno tempo che allo sviluppo del sistema di AI, la stima va probabilmente rivista.
API, connettori e standard emergenti
Le modalità di collegamento sono tre, in ordine di preferenza.
Interfacce applicative esposte dal sistema. È la soluzione corretta quando esiste: contrattualizzata, documentata, con gestione dei permessi e degli errori. Va verificato che copra anche le operazioni di scrittura, e non solo la lettura, se il progetto le prevede.
Connettori intermedi. Uno strato che espone in modo uniforme sistemi eterogenei, gestendo autenticazione, trasformazione dei dati e registrazione delle chiamate. Aggiunge un componente da mantenere, ma isola il sistema di AI dalle specificità di ciascun gestionale, il che semplifica le sostituzioni successive.
Accesso diretto ai dati o scambio di file. Soluzione da usare quando le prime due non sono disponibili. Comporta un accoppiamento stretto con la struttura interna del sistema, che può cambiare senza preavviso in occasione di un aggiornamento.
Sul piano degli standard, negli ultimi anni si è affermata la tendenza a definire protocolli comuni per collegare strumenti e sorgenti dati ai modelli linguistici, riducendo lo sviluppo di integrazioni una a una. È un’evoluzione utile e la direzione appare consolidata, ma non elimina il lavoro di analisi del dominio: uno standard uniforma il modo di collegarsi, non il significato dei dati.
Permessi, log e reversibilità
Tre requisiti che vanno definiti prima dello sviluppo, perché condizionano l’architettura.
I permessi. Il sistema deve operare con l’identità e i diritti dell’utente che lo utilizza, non con un’utenza tecnica ad ampi privilegi. È la scelta più frequente e la più rischiosa: un’unica utenza con accesso completo trasforma qualsiasi errore o abuso in un problema di ampiezza non contenibile.
I log. Ogni lettura e ogni scrittura vanno registrate, con l’indicazione di chi ha originato l’operazione, quando e con quale esito. Serve per l’audit e per la diagnosi: senza registrazione, ricostruire perché un record è stato aggiornato in modo errato è impraticabile.
La reversibilità. Per ogni operazione di scrittura deve esistere un percorso di annullamento, o in alternativa un vincolo che la impedisca senza conferma umana. È il criterio che guida la scelta su quali operazioni esporre: la scrittura di uno stato interno è reversibile, l’invio di una comunicazione a un cliente non lo è.
Un principio generale: le operazioni disponibili al sistema vanno definite per inclusione, non per esclusione. Si abilita ciò che serve, non si vieta ciò che non serve.
Un esempio: dalla mail del cliente all’ordine registrato
Un’azienda riceve ordini via email, in forma libera, spesso con allegati.
Il flusso integrato funziona così.
Il sistema legge la comunicazione in arrivo e ne riconosce la natura. Identifica il cliente confrontando i dati con l’anagrafica del gestionale. Estrae le righe d’ordine dal testo e dagli allegati, riconducendo le descrizioni ai codici articolo attraverso il catalogo. Verifica la disponibilità e le condizioni commerciali applicabili a quel cliente, interrogando i dati reali. Segnala le righe non riconosciute o ambigue, con il riferimento al punto della comunicazione da cui provengono. Prepara la bozza dell’ordine nel gestionale, in stato non confermato.
E si ferma. La conferma resta all’operatore commerciale.
Il valore non sta nell’automazione dell’inserimento. Sta nel fatto che l’operatore riceve un ordine già decodificato, con le anomalie in evidenza, e dedica il tempo alle eccezioni invece che alla trascrizione.
Ogni passaggio di questo flusso è un’integrazione: anagrafiche, catalogo, disponibilità, listini, gestione ordini. Il componente di intelligenza artificiale è una parte del lavoro, e non la maggiore.
Che cosa l’integrazione non risolve
Non migliora la qualità dei dati nei sistemi collegati. Anagrafiche duplicate e codici obsoleti diventano visibili, non corretti.
Non elimina la dipendenza dai fornitori dei gestionali. Un aggiornamento che modifica un’interfaccia richiede un intervento, e va previsto nel contratto di manutenzione.
Non riduce i requisiti di sicurezza applicativa. Un sistema che scrive nei gestionali richiede maggiore attenzione al trattamento dei contenuti provenienti dall’esterno, che vanno considerati input non fidato.
E non compensa un processo non definito. Se le regole di accettazione di un ordine variano per prassi, il sistema non può applicarle.
In chiusura
L’integrazione non è la parte accessoria di un progetto di AI. In molti casi è la parte principale, ed è quella che determina se il sistema entra nel lavoro quotidiano o resta a margine.
Conviene affrontarla all’inizio: censire i sistemi coinvolti, verificare che cosa espongono, stimare i tempi delle autorizzazioni.
Se avete un processo che attraversa più sistemi, siamo disponibili a un confronto tecnico su quel caso: quali interfacce esistono, quali operazioni sarebbero necessarie e dove si collocherebbero i punti di conferma umana.
