Integrare agenti AI con ERP e CRM: la sfida dei sistemi legacy

Il momento in cui un progetto di agenti AI smette di essere entusiasmante è quasi sempre lo stesso: quando l’agente deve scrivere una riga in un ordine di vendita. Fino a lì tutto fila, capisce la richiesta, ragiona, propone. Poi incontra l’ERP, e l’ERP non è una conversazione: è un sistema transazionale con vincoli di integrità, permessi, rate limit e vent’anni di personalizzazioni che nessuno ha documentato.

Questo è il vero collo di bottiglia dell’adozione aziendale, e non è un problema di modelli. Un LLM del 2026 è largamente sufficiente per la maggior parte dei processi di back-office. Quello che manca è lo strato che traduce l’intenzione dell’agente in operazioni che l’ERP e il CRM accettano senza rompersi. McKinsey lo inquadra bene nel suo lavoro sul divario tra agenti AI ed ERP: il valore non si sblocca aggiungendo agenti sopra i processi, ma ridisegnando il modo in cui gli agenti accedono al sistema di record.

Se stai ancora valutando cosa sia un agente e in cosa differisca da un chatbot, conviene partire da cosa sono gli agenti AI e perché sono indispensabili per le aziende. Qui diamo per scontato il concetto e andiamo a vedere dove si rompe.

In questo articolo scoprirai:

• "Legacy" non vuol dire vecchio, vuol dire non negoziabile
• I limiti tecnici che nessuna demo ti mostra
• CRM ed ERP non parlano la stessa lingua
• MCP come strato di traduzione, non come scorciatoia
• L'agente non deve essere un superuser

“Legacy” non vuol dire vecchio, vuol dire non negoziabile

C’è un equivoco da sciogliere subito. Legacy non significa necessariamente un AS/400 in sala macchine. Un Dynamics 365 in cloud, aggiornato all’ultima release, è legacy nel senso che conta: è il sistema che decide cosa è vero in azienda, e non puoi modificarne il comportamento per far contento un agente.

Questo produce tre tipi di attrito, in ordine crescente di difficoltà.

Il primo è l’accesso. Alcuni gestionali espongono API REST decenti, altri solo SOAP, altri niente, e ti ritrovi a leggere viste SQL o file scambiati via SFTP. È il livello più fastidioso ma anche il più risolvibile: è lavoro di integrazione classico, con costi prevedibili.

Il secondo è la semantica. Il campo si chiama CustomerNo, ma metà dei record usa il codice fiscale e l’altra metà un progressivo interno introdotto nel 2014. Il flag “bloccato” ha tre valori possibili e solo il responsabile amministrativo sa cosa significano. Un agente che legge lo schema non vede nulla di tutto questo.

Il terzo è la logica di business che non sta nei dati. Lo sconto massimo applicabile è scritto in una customizzazione, il ciclo di approvazione dipende da un workflow che vive nel CRM, e la regola “se il cliente è in fido bloccato l’ordine si inserisce comunque ma non si conferma” non è documentata da nessuna parte. Questo è il livello dove i progetti muoiono, ed è anche il motivo per cui la scelta tra agenti AI custom e soluzioni off-the-shelf si decide più sull’integrazione che sulle funzionalità.

I limiti tecnici che nessuna demo ti mostra

Vale la pena guardare numeri reali, perché è qui che le architetture ingenue si schiantano. Prendiamo Dynamics 365 Business Central, che è tra gli ERP più diffusi nella fascia media italiana e documenta i suoi limiti in modo trasparente.

Sull’endpoint API v2.0, i limiti operativi dichiarati da Microsoft per ambiente prevedono un massimo di 5 richieste OData processate contemporaneamente, 100 connessioni simultanee tra processate e in coda, una coda di 95 richieste e un tetto di 600 richieste al minuto in produzione (300 in sandbox). I limiti per utente, introdotti progressivamente da fine 2023, alzano l’asticella a 6.000 richieste in una finestra scorrevole di 5 minuti, ma restano 5 le richieste concorrenti per utente. Una singola pagina di risposta non può superare 20.000 entità, un $batch non può contenere più di 100 operazioni, e una richiesta ha 8 minuti di tempo prima di ricevere un 408 - Request Timeout.

La documentazione sui rate limit è ancora più esplicita: quando il throttling scatta ricevi 429 - Too Many Requests e sei tu a doverlo gestire, con retry e periodo di raffreddamento, intervalli regolari, incrementali, exponential back-off o randomizzati. Se una richiesta supera i 10 minuti di esecuzione il servizio la abortisce con un 504 - Gateway Timeout, e l’unica strada è spezzarla in richieste più piccole, tornando però a rischiare il 429.

Perché tutto questo conta per un agente? Perché un agente che ragiona liberamente genera pattern di chiamate imprevedibili. Un ciclo mal condizionato che interroga i clienti uno per uno invece di usare un filtro, e hai esaurito la quota di un service principal in pochi secondi. Le raccomandazioni di Microsoft, usare webhook invece di polling, filtrare con $filter su lastModifiedDateTime, recuperare le entità correlate con $expand in una chiamata sola, usare i deep insert per creare documenti con le loro righe, non sono ottimizzazioni facoltative: sono il confine tra un’integrazione che regge e una che viene strozzata. Microsoft suggerisce persino di distribuire il carico in round-robin su più utenti o service principal.

Nessuna di queste cose può essere delegata al ragionamento del modello. Vanno codificate nello strato che sta tra l’agente e l’ERP.

CRM ed ERP non parlano la stessa lingua

Il secondo fronte è l’allineamento tra i due sistemi che l’agente deve attraversare. IBM, nella sua panoramica sull’integrazione tra CRM ed ERP, insiste su un punto che sembra banale e non lo è: i due sistemi descrivono la stessa realtà con modelli incompatibili. Il CRM ragiona per opportunità, contatti e account; l’ERP per anagrafiche, ordini, partite aperte e movimenti di magazzino. Lo stesso cliente esiste due volte, con due chiavi diverse, e spesso con due nomi scritti in modo diverso.

Finché a mediare c’è una persona, la cosa funziona: l’addetto sa che “Rossi Srl” nel CRM è “ROSSI S.R.L.” nell’ERP. Un agente, no. E la conseguenza non è che l’agente si ferma: è che risponde con sicurezza usando il record sbagliato. Prima di collegare un agente a due sistemi, serve una risposta esplicita alla domanda “qual è la chiave che li unisce, e chi la mantiene?”. Se la risposta è “nessuna, si fa a occhio”, quello è il primo progetto da fare, non l’agente.

Attenzione anche alla tentazione di risolvere tutto con il recupero semantico. Il RAG è eccellente per la conoscenza non strutturata, contratti, manuali, policy, storico delle email, ma un saldo contabile non si recupera per similarità: si interroga. Confondere i due piani produce agenti che inventano numeri plausibili, che è il modo peggiore di sbagliare.

MCP come strato di traduzione, non come scorciatoia

Il Model Context Protocol ha reso molto più ordinato il modo di esporre sistemi aziendali a un agente, e vale la pena capire cosa fa davvero. Secondo la documentazione ufficiale sull’architettura, MCP separa due livelli: un data layer basato su JSON-RPC 2.0, che gestisce ciclo di vita, negoziazione delle capability e primitive, e un transport layer che gestisce canali e autenticazione, con due meccanismi supportati, stdio per processi locali e Streamable HTTP per server remoti, dove è raccomandato OAuth per ottenere i token.

Le primitive che un server può esporre sono tre: tools (funzioni eseguibili con un inputSchema JSON Schema), resources (dati di contesto in sola lettura) e prompts (template riutilizzabili). Il client, dal suo lato, può offrire sampling, elicitation, cioè la possibilità per il server di chiedere conferma o informazioni aggiuntive all’utente, e logging. Il protocollo è stateful e supporta notifiche: se cambiano i tool disponibili, il server manda notifications/tools/list_changed e il client rinfresca la lista.

La parte interessante, per chi integra un ERP, è che questa struttura ti costringe a decidere. Un tool non è un endpoint: è un contratto. crea_ordine(cliente_id, righe[]) con validazione, idempotenza e messaggi d’errore comprensibili è una cosa; un tool generico chiama_api(url, metodo, body) è un’altra, ed è un’ottima ricetta per il disastro. Il server MCP è il posto giusto dove mettere il retry sul 429, il batching, i filtri, la normalizzazione dei codici cliente e i controlli che l’ERP non fa. Se vuoi entrare nel dettaglio del protocollo, abbiamo una guida completa agli MCP server.

Un avvertimento: MCP standardizza il trasporto e la scoperta delle capability, non la semantica del tuo gestionale. Il lavoro difficile, decidere quali operazioni esporre, con quali garanzie e con quali limiti, resta interamente tuo.

L’agente non deve essere un superuser

Il modo più rapido di far fallire un progetto in fase di audit è dare all’agente credenziali amministrative “per ora, poi restringiamo”. Le piattaforme serie hanno preso la direzione opposta: in Salesforce, un agente Agentforce opera attraverso un utente agente dedicato, il cui profilo e i cui permission set definiscono esattamente quali oggetti e campi l’agente può leggere e scrivere. Il perimetro è imposto dal modello di permessi della piattaforma, non dalle istruzioni nel prompt, che è l’unico approccio difendibile, perché un prompt si può aggirare con il linguaggio, un permesso no.

Lo stesso principio si applica lato ERP: un service principal per ogni caso d’uso, con i soli permessi necessari, tracciabile nei log. Ha anche un vantaggio pratico, dato che i limiti di throughput sono per utente: separare le identità separa i blast radius e distribuisce il carico.

Un percorso che funziona: leggere prima, scrivere dopo

La sequenza che vediamo funzionare più spesso è deliberatamente noiosa.

Fase 1, sola lettura. L’agente interroga, riassume, incrocia CRM ed ERP, risponde a domande. Zero rischio transazionale, valore immediato per chi passa la giornata a cercare informazioni in tre schermate. È anche la fase in cui scopri quanto sono sporchi i tuoi dati, e la scopri prima di aver messo in produzione qualcosa che li modifica.

Fase 2, scrittura con proposta e conferma. L’agente prepara l’operazione, una persona approva. Serve idempotenza, una chiave che impedisca di creare due volte lo stesso ordine se il retry va male, e serve un log che dica chi ha chiesto cosa e cosa è stato scritto.

Fase 3, scrittura autonoma su un perimetro ristretto. Solo per casi ad alto volume e basso rischio, con soglie oltre le quali si torna all’umano, e solo dopo che la fase 2 ha prodotto abbastanza storia da fidarsi.

Chi salta le prime due fasi non arriva più veloce: arriva a un incidente. Questa gradualità non è timidezza, è la scelta architetturale che discutiamo in architettura enterprise con agenti AI: trasformazione graduale o totale. E vale la pena verificare a monte se l’organizzazione è pronta, con una valutazione onesta di AI agent readiness.

Il costo che nessuno mette a preventivo: mantenere il contratto

Un’integrazione con l’ERP non è un lavoro che finisce. Arriva un aggiornamento del gestionale, qualcuno aggiunge tre campi custom, cambia il piano dei conti, si introduce una nuova società nel gruppo. Ognuna di queste cose può rompere silenziosamente un tool: non con un errore, ma con una risposta sbagliata.

Due contromisure concrete. La prima: test di contratto sui tool, eseguiti in continuo su un ambiente sandbox, che verificano non solo che la chiamata risponda 200 ma che i valori abbiano senso. La seconda: monitoraggio del comportamento in produzione, volume di 429, latenze, tasso di operazioni corrette dall’utente in fase di approvazione. Quest’ultima metrica è la più informativa che esista sulla qualità reale di un agente.

È anche il motivo per cui, in questo dominio, il servizio conta più del modello: la parte difficile non è far ragionare l’agente, è tenerlo allineato a un sistema che cambia.

Da dove partire, concretamente

Se domani dovessi impostare questo lavoro in un’azienda con un ERP consolidato e un CRM separato, l’ordine sarebbe questo:

1. Scegli un processo misurabile e noioso, dove oggi qualcuno copia dati da un sistema all’altro. I candidati migliori stanno nel back-office.
2. Documenta la chiave che unisce CRM ed ERP per quel processo. Se non esiste, creala.
3. Leggi la documentazione dei limiti del tuo ERP prima di scrivere codice, non dopo il primo 429 in produzione.
4. Esponi 3-5 tool con contratti stretti, non un accesso generico all’API.
5. Crea un’identità dedicata con i permessi minimi.
6. Parti in sola lettura per qualche settimana e misura.
7. Coinvolgi da subito le persone che usano quei sistemi: il change management qui pesa quanto l’architettura.

Nessuno di questi passaggi è affascinante, e nessuno richiede il modello più recente. È esattamente per questo che funzionano, e il motivo per cui, quando l’AI generativa non genera ROI, il problema non è la tecnologia. Se vuoi vedere come impostiamo noi questo tipo di integrazioni, Mimír AI Agent nasce proprio da questi vincoli. E per il taglio più operativo, con riferimenti al contesto italiano, c’è la guida all’integrazione di agenti AI con ERP e CRM per le PMI italiane.

Fonti:

• Model Context Protocol — Architecture overview
• JSON-RPC 2.0 Specification
• McKinsey — Bridging the great AI agent and ERP divide to unlock value at scale
• IBM Think — CRM and ERP integration
• Microsoft Learn — API (v2.0) for Dynamics 365 Business Central
• Microsoft Learn — Working with API limits in Dynamics 365 Business Central
• Microsoft Learn — Operation limits in Dynamics 365 Business Central online
• Salesforce Help — Agentforce Agent User