L'agente funziona: il progetto è il gestionale
Nei progetti con agenti AI il vincolo non è il modello, è il sistema che tiene i dati dell'azienda. Leggere è la metà facile; scrivere è dove stanno integrità, identità e preventivo.
C'è un punto in cui quasi tutti i progetti con agenti AI rallentano, ed è sempre lo stesso: il momento in cui l'agente deve scrivere dentro il gestionale su cui l'azienda gira davvero. Fino a lì tutto sembra funzionare. L'agente legge un report, incrocia un export, produce una risposta sensata, e la demo convince. Poi arriva la richiesta che chiude il cerchio — registra il documento, apri la pratica, aggiorna l'ordine — e il progetto smette di essere un progetto di AI per diventare un progetto di integrazione.
Leggere è la metà facile
Leggere non ha conseguenze. Una vista, un export notturno, una query in sola lettura: se l'agente sbaglia, ha sbagliato per sé. È la metà che si costruisce in fretta, che si mostra, e che quasi sempre è quella che ha ottenuto il budget.
Scrivere è un'altra cosa. Il gestionale è la fonte della verità e l'agente, nel migliore dei casi, è un ospite. Ha integrità referenziale che l'agente non conosce e non governa. Ha validazioni che scattano lato server, dopo che la chiamata è già partita. Ha documenti che dopo la registrazione non si emendano: si stornano, con un'altra scrittura, che a sua volta è un evento contabile. E ha finestre batch in cui le scritture si accodano invece di fallire, il che è peggio di un errore, perché un errore lo vedi.
Il caso che si paga più caro è il retry. Nel codice dell'agente un tentativo ripetuto sembra innocuo — è la cosa giusta da fare quando una chiamata va in timeout. A valle, se l'endpoint non è idempotente e non c'è una chiave di correlazione che il gestionale rispetta, quel tentativo diventa un secondo ordine. Nessuno se ne accorge finché non arriva la merce due volte.
L'agente ha bisogno di un'identità
C'è poi una domanda che non è tecnica solo in apparenza: chi ha registrato quella scrittura? Se l'agente passa dall'utente di servizio condiviso — quello che esiste da anni, che può tutto, e la cui password sta in tre file di configurazione — la risposta è «l'integrazione». Non è una risposta accettabile per un revisore, e non lo è nemmeno per chi dovrà capire cos'è successo sei mesi dopo.
L'agente vuole un'utenza propria, con permessi stretti sui soli documenti che gli servono, e una traccia che leghi ogni scrittura alla decisione che l'ha generata. L'AI Act chiede la stessa cosa in altri termini, per i sistemi ad alto rischio: eventi registrati e responsabilità ricostruibile. È una richiesta che si soddisfa molto più facilmente se la si progetta prima, e non si aggiunge a un'integrazione già in produzione.
Il sandbox non è la produzione
Ultimo scoglio, quello che sposta le date. Quasi nessun ambiente di test di un ERP replica l'anagrafica di produzione: i clienti sono di fantasia, il piano dei conti è ridotto, i codici articolo sono puliti. L'agente passa i test, va in produzione, e il primo giorno incontra i clienti veri, le anagrafiche duplicate e i codici mezzi migrati da un sistema precedente che nessuno ha finito di sistemare.
Niente di tutto questo è lavoro sul modello. È integrazione: mappature, idempotenza, permessi, gestione degli errori, riconciliazione. È lavoro che non si vede nella demo e si vede in fattura, ed è quasi tutto il preventivo. Per una software house .NET è anche la parte che sa già fare — a patto di averla messa nella stima.
Quando hai stimato l'ultimo progetto con un agente, quanto pesava il gestionale?