Il momento che stiamo vivendo

C'è una parola che nel 2026 si sente in quasi ogni riunione di management legata alla tecnologia: agenti. Agenti AI, AI agent, agentic enterprise. Salesforce ha costruito attorno a questo concetto l'intera narrativa del suo futuro, e i numeri danno ragione alla scommessa: al terzo trimestre del fiscal year 2026, secondo il comunicato ufficiale sui risultati trimestrali, Agentforce aveva già raccolto oltre 9.500 contratti pagati, elaborato più di 3,2 trilioni di token attraverso il proprio gateway LLM, e generato un fatturato annualizzato che ha superato i 500 milioni di dollari con una crescita del 330% anno su anno. L'amministratore delegato Marc Benioff ha dichiarato che sei delle dieci trattative più importanti del trimestre sono state guidate da clienti che volevano semplicemente trasformare il proprio modo di lavorare grazie agli agenti AI.

Non si tratta di hype. Si tratta di una transizione reale, rapida e, per molte organizzazioni, già in corso.

Eppure, mentre scriviamo questo articolo, i dati raccontano un'altra storia, parallela e meno rassicurante. Uno studio del luglio 2025 condotto da MIT Project NANDA su oltre 300 iniziative aziendali, 52 interviste strutturate e 153 survey con senior leader ha prodotto una conclusione netta: nonostante investimenti globali tra i 30 e i 40 miliardi di dollari, il 95% delle organizzazioni non ottiene alcun impatto misurabile su ricavi o costi dai propri progetti di AI generativa.

Come si conciliano queste due realtà? La risposta è semplice, anche se spesso scomoda: gli agenti AI amplificano ciò che trovano. Se trovano dati di qualità, processi definiti e una governance solida, producono valore misurabile. Se trovano frammentazione, duplicati e silos informativi, producono rumore costoso.

Noi lo vediamo ogni giorno, nei progetti che seguiamo. E dopo trent'anni di lavoro sui dati delle organizzazioni del Nordest — manifattura, PA, trasporti, retail — abbiamo sviluppato un punto di vista preciso su cosa separa i progetti che riescono da quelli che restano fermi al proof of concept.

Cos'è davvero un agente AI: oltre il chatbot

Prima di entrare nel merito della data readiness, vale la pena fare chiarezza su cosa sia effettivamente un agente AI applicato a un contesto CRM. Perché c'è molta confusione, spesso alimentata da marketing poco preciso.

Un agente AI non è un chatbot. Non è un assistente virtuale che risponde a domande. Non è nemmeno un sistema di raccomandazione che suggerisce la prossima azione al venditore. Un agente AI è qualcosa di strutturalmente diverso: è un sistema software capace di osservare il contesto, ragionare sulle informazioni disponibili e agire autonomamente all'interno di processi aziendali reali — senza che un operatore umano debba approvare ogni singolo passo.

In un contesto Salesforce, questo significa che un agente può:

• Monitorare in autonomia lo stato delle opportunità nel pipeline e inviare comunicazioni personalizzate ai prospect che non rispondono da N giorni
• Analizzare il comportamento di un cliente nel tempo, identificare i segnali di disaffezione e aprire automaticamente un caso di customer success con le informazioni di contesto già elaborate
• Aggregare dati da più sistemi (CRM, ERP, piattaforma di ticketing), costruire un briefing completo sull'account e renderlo disponibile al commerciale prima di ogni call — senza che nessuno glielo chieda
• Proporre aggiornamenti agli stage delle opportunità sulla base di eventi reali (e-mail ricevute, riunioni completate, contratti firmati) invece di aspettare che il venditore aggiorni manualmente il CRM
• Identificare anomalie nei dati di vendita — valori fuori range, dati mancanti, incoerenze tra sistemi — e escalare automaticamente al responsabile dati

Agentforce, la piattaforma Salesforce dedicata a questi scenari, non è un prodotto standalone: è un livello di orchestrazione che si integra nativamente con tutti i cloud Salesforce — Sales, Service, Marketing, Commerce — e con i sistemi esterni attraverso MuleSoft. Questo è il suo vantaggio competitivo più solido rispetto alle soluzioni AI costruite da zero: il contesto aziendale è già lì, accumulato nel tempo in Salesforce, e l'agente può usarlo immediatamente.

Il deployment medio, secondo il report Valoir commissionato da Salesforce (2025), avviene in circa 4,8 mesi per le aziende che adottano Agentforce — contro i 75 mesi mediamente necessari a chi costruisce un'infrastruttura AI proprietaria equivalente. E secondo le analisi di MIT Project NANDA, i progetti che si affidano a vendor e partner specializzati hanno un tasso di successo di circa il 67%, contro il 33% di chi costruisce tutto in autonomia.

Questo è il punto di forza. Ma il punto critico sta, come sempre, altrove.

Il problema che nessuno racconta: i numeri sulla qualità dei dati

Quando si parla di fallimento dei progetti AI, la conversazione tende a concentrarsi sul modello: "il modello non era abbastanza buono", "serve un LLM più aggiornato", "bisogna fare più fine-tuning". Questa narrazione è comoda per i vendor, ma sbagliata per le organizzazioni.

La ricerca dice una cosa diversa, e con una coerenza impressionante tra fonti diverse:

Secondo l'IBM Institute for Business Value, CDO Study 2025 — condotto su 1.700 responsabili dati in 27 Paesi — il 43% dei Chief Operations Officer identifica la qualità dei dati come la principale priorità nella propria agenda dati. Oltre un quarto delle organizzazioni stima di perdere più di 5 milioni di dollari l'anno a causa di dati di scarsa qualità, e il 7% dichiara perdite superiori ai 25 milioni. Solo il 26% dei CDO si dice fiducioso che i propri dati siano pronti ad abilitare nuovi flussi di ricavo basati sull'AI.

Secondo Informatica, CDO Insights 2025 — survey su 600 data leader globali — gli ostacoli principali al successo dei progetti AI sono: qualità e disponibilità dei dati (43%), mancanza di maturità tecnica (43%), carenza di competenze (35%). Non il modello, non la potenza computazionale, non il budget. I dati. La stessa ricerca rileva che il 97% delle organizzazioni che usano o pianificano l'uso dell'AI fatica a dimostrarne il valore di business.

Questi numeri hanno un significato pratico molto concreto per chi lavora sul CRM: se i vostri dati non sono pronti, l'agente non produce insight. Produce rumore. E nel contesto di una decisione commerciale, di una comunicazione automatica a un cliente, di una proposta generata per un prospect, il rumore ha un costo — economico e reputazionale.

Come si presenta il problema nella realtà dei progetti CRM

Nella nostra esperienza, i problemi di qualità del dato nei sistemi CRM si manifestano quasi sempre in uno dei quattro modi seguenti.

1. L'entità cliente non è univoca

Il cliente "Acme S.r.l." compare come "ACME srl" nell'anagrafica CRM, come "Acme SRL" nel sistema di fatturazione, come "Acme" nel tool di e-mail marketing e come "Acme S.r.l. — Filiale Udine" nelle note di un'opportunità del 2021. Sono quattro record distinti che rappresentano la stessa realtà. Un agente AI che analizza il valore del cliente, la sua storia, le sue interazioni e il suo rischio di churn opererà su quattro fotografie parziali, non su una visione unitaria. Il risultato sarà sistematicamente distorto.

2. I dati non sono aggiornati

I CRM accumulano dati nel tempo, ma non sempre vengono mantenuti. Referenti che non lavorano più in azienda, numeri di telefono obsoleti, opportunità aperte da anni che nessuno ha chiuso, note di conversazioni che si riferiscono a prodotti non più a catalogo. Un agente AI che opera su questi dati assumerà come fatti reali situazioni che non esistono più. La fiducia degli utenti nel sistema crollerà dopo i primi output sbagliati.

3. I dati rilevanti non sono in Salesforce

Le informazioni che contano per prendere una decisione commerciale raramente risiedono tutte nel CRM. I dati di fatturazione stanno nell'ERP. Le interazioni di supporto stanno nel sistema di ticketing. La storia degli ordini sta nel gestionale. I contratti firmati stanno nel document management. Se l'agente ha accesso solo a Salesforce, ha una visione radicalmente incompleta del cliente. L'integrazione non è un optional: è il prerequisito tecnico perché l'agente possa ragionare correttamente.

4. I dati esistono ma non hanno contesto semantico

Questo è il problema più sottile e spesso il più pericoloso. Un campo chiamato "valore" può significare fatturato lordo, margine netto, valore stimato del deal, potenziale di crescita o valore storico del contratto — a seconda di chi lo ha compilato, in quale reparto, in quale anno. Senza un dizionario dati condiviso e regole di governance esplicite, l'agente formula inferenze corrette su dati che significano cose diverse. Il risultato è opaco e difficile da diagnosticare.

Business Intelligence e Machine Learning: le infrastrutture che abilitano gli agenti

In un'architettura AI-ready, la Business Intelligence smette di essere uno strumento di reportistica per il management e diventa qualcosa di più fondamentale: l'infrastruttura semantica che alimenta gli agenti.

Vediamo come funziona concretamente nel nostro stack.

Il ruolo di Tableau

Tableau, nel nostro approccio ai progetti Agentforce, non è il layer di visualizzazione. È il layer di validazione e monitoraggio della qualità del dato. Prima di abilitare qualsiasi agente, costruiamo con Tableau una serie di dashboard operative — non per il management, ma per il team dati — che monitorano in tempo reale:

• Il tasso di completezza delle anagrafiche clienti (quanti campi obbligatori sono effettivamente compilati)
• Il tasso di duplicazione nelle entità principali (account, contatti, opportunità)
• L'aggiornamento delle opportunità (quante non vengono toccate da più di 30, 60, 90 giorni)
• La coerenza tra sistemi (quanti account esistono in Salesforce ma non in ERP, e viceversa)
• Le anomalie di inserimento (valori fuori range, formati non standard, campi obbligatori aggirati)

Questo sistema di monitoraggio non è decorativo: è il presupposto per poter affermare, con evidenza, che i dati su cui opera l'agente sono affidabili. E quando l'agente produce un output inatteso, il primo posto dove andiamo a cercare è qui.

Il ruolo dei modelli di Machine Learning

I modelli ML che sviluppiamo non sono componenti separate da Agentforce: sono fonti di segnale che l'agente consuma attivamente. Tre esempi concreti:

Un modello di scoring del rischio churn applicato agli abbonati di un operatore di servizi produce un punteggio per ciascun cliente ogni settimana. Agentforce legge questo punteggio come un attributo dell'account e, quando supera una soglia definita, attiva autonomamente una sequenza di retention — una comunicazione personalizzata, un'offerta mirata, un'escalation al team di customer success.

Un modello di previsione della domanda applicato a un'azienda manifatturiera produce stime di vendita per famiglia di prodotto nel trimestre successivo. Agentforce legge queste stime e aggiorna in automatico le priorità del pipeline commerciale, segnalando al responsabile vendite quali opportunità meritano attenzione urgente perché allineate con i prodotti che il modello indica come ad alta domanda.

Un modello di anomaly detection sul flusso di dati in ingresso nel CRM identifica in tempo reale inserimenti anomali — un'opportunità con valore dieci volte superiore alla media, un'anagrafica duplicata, un campo critico lasciato vuoto. Agentforce intercetta il segnale e apre automaticamente un task di verifica per il team dati.

In tutti questi casi, il Machine Learning non è il prodotto finale: è il motore silenzioso che rende l'agente più intelligente di quanto potrebbe essere operando solo sui dati grezzi.

Il metodo Deimos: tre fasi prima del go-live

Nei progetti Agentforce che seguiamo, adottiamo un approccio strutturato in tre fasi obbligatorie, tutte precedenti all'attivazione dell'agente in produzione.

Fase 1 — Assessment della Data Readiness (2–4 settimane)

Questa fase produce un documento di analisi che risponde a domande precise: qual è lo stato attuale della qualità dei dati nel CRM? Quali sistemi contengono dati rilevanti per i processi che vogliamo automatizzare? Quali sono i gap più critici da colmare? Quali sono le interdipendenze tra Salesforce e gli altri sistemi?

L'output non è un report estetico: è una lista di priorità di intervento con stima dell'effort necessario, una mappa delle integrazioni mancanti e una valutazione del rischio per ciascun caso d'uso che si intende abilitare con gli agenti.

In questa fase, coinvolgiamo sempre sia il team IT che i responsabili di processo (commerciale, customer service, operazioni). La qualità del dato è un problema organizzativo prima che tecnico, e le decisioni su come risolverlo devono essere prese da chi possiede il processo.

Fase 2 — Data Engineering e Architettura (4–12 settimane, variabile)

In questa fase costruiamo le fondamenta. Le attività tipiche includono:

Deduplication e pulizia. Utilizziamo processi semi-automatici per identificare e risolvere i duplicati nelle entità principali (account, contatti, referenti). Non è un'operazione che si fa una volta: è un processo continuo che va governato nel tempo.

Integrazione tra sistemi. Costruiamo i connettori necessari per portare in Salesforce (o in un layer di dati condiviso) i dati rilevanti dagli altri sistemi aziendali. In questo contesto, l'acquisizione di Informatica da parte di Salesforce è una notizia importante: porta nativamente sulla piattaforma strumenti avanzati di data catalog, data quality e Master Data Management che prima richiedevano integrazioni esterne.

Definizione del modello semantico. Definiamo, insieme ai responsabili di processo, il significato preciso di ciascun campo critico. Il risultato è un dizionario dati condiviso, approvato da tutti gli stakeholder, che diventa la fonte di verità per l'intero sistema.

Costruzione dei modelli ML. Se il caso d'uso prevede scoring, previsione o anomaly detection, sviluppiamo e validamo i modelli in questa fase, in modo che siano pronti per essere consumati dall'agente.

Setup del monitoraggio. Configuriamo le dashboard Tableau di monitoraggio della qualità del dato, che rimarranno attive in produzione come strumento di presidio continuativo.

Fase 3 — Sandbox e Deployment Progressivo

Il primo agente va sempre in un ambiente di test, con un perimetro ben definito. In genere scegliamo un processo circoscritto (un team di vendita specifico, un segmento clienti, un flusso di customer service) che sia rappresentativo ma limitato — abbastanza piccolo da rendere gestibili gli eventuali errori, abbastanza significativo da produrre dati utili per la calibrazione.

In questa fase, il comportamento dell'agente viene confrontato sistematicamente con quello degli operatori umani: a parità di input, l'agente produce lo stesso tipo di output che un commerciale esperto avrebbe prodotto? Dove diverge, e perché? La risposta a queste domande guida la calibrazione dei parametri, la revisione delle soglie e, spesso, la scoperta di ulteriori gap nei dati che non erano stati identificati nella fase di assessment.

Solo dopo che il comportamento in sandbox è stabile e i risultati sono misurabili, procediamo con il deployment progressivo in produzione.

Casi d'uso concreti per i settori in cui operiamo

Trasporto pubblico locale

È uno dei settori in cui vediamo le opportunità più concrete e meno esplorate. Lavoriamo con diverse aziende di trasporto pubblico locale del Nordest, e il quadro che troviamo è quasi sempre lo stesso.

I dati ci sono: le validazioni, i passaggi, gli abbonamenti attivi, le tratte, i reclami. Ma sono spesso silos separati che non dialogano. Un sistema Agentforce correttamente alimentato potrebbe: monitorare in tempo reale il comportamento degli abbonati (frequenza di utilizzo, tratte preferite, calo di utilizzo nelle ultime settimane); identificare automaticamente i segnali di disaffezione prima del mancato rinnovo e attivare una comunicazione personalizzata sulla base dell'uso effettivo; gestire autonomamente i reclami di primo livello — ritardi, soppressioni, problemi di biglietteria — con risposte pre-approvate e escalation intelligente; aggregare i feedback degli utenti dai diversi canali (app, call center, social, sportelli fisici) e produrre report settimanali automatici per il management.

Il prerequisito? Integrare le fonti dati esistenti in una visione unificata dell'utente, e portare quella visione in Salesforce. Non è un progetto di mesi: con le architetture moderne, può essere fatto in settimane.

Manifattura e distribuzione

Per le PMI manifatturiere del Nordest — un tessuto di aziende che conoscono bene i propri clienti ma gestiscono spesso la relazione in modo informale — il valore degli agenti AI è diverso: si tratta meno di automation massiva e più di sistematizzazione della conoscenza commerciale.

Il caso più comune che incontriamo è quello della conoscenza del venditore che non è mai entrata nel CRM: i rapporti di visita incompleti, le note scritte su carta, i prezzi concordati in conversazioni WhatsApp. Un agente ben configurato può diventare il punto di aggregazione di queste informazioni, facilitando l'inserimento e la strutturazione del dato commerciale che poi alimenta le analisi e la previsione.

Scenari più avanzati includono: monitoraggio automatico dei cicli di riordino per cliente (quando un cliente che ordina normalmente ogni 6 settimane non ha ordinato da 10, l'agente lo segnala al commerciale), scoring automatico delle nuove opportunità sulla base della similitudine con i clienti storici di successo, e gestione autonoma delle richieste di offerta standard con popolamento automatico del preventivo da listino.

Pubblica Amministrazione

La PA è un caso particolare, sia per i vincoli normativi sia per la natura del "cliente" — che nella PA è il cittadino o l'ente beneficiario di un servizio. Ma le opportunità sono reali e, in alcuni casi, urgenti.

I Comuni e le Regioni che hanno già adottato Salesforce per la gestione dei servizi ai cittadini possono usare Agentforce per automatizzare i processi di back-office più ripetitivi: la presa in carico delle pratiche, il tracking dello stato, le comunicazioni di aggiornamento al cittadino, l'escalation automatica ai casi che superano le scadenze di legge.

In questi contesti, la governance dei dati non è un'opzione: è un requisito normativo. E il nostro approccio strutturato all'assessment e alla data readiness si traduce anche in un vantaggio di compliance.

Cosa significa "AI-ready" in pratica: una checklist operativa

Prima di avviare qualsiasi conversazione su Agentforce con un cliente, utilizziamo internamente una lista di verifica che riportiamo qui, semplificata, come strumento di autovalutazione.

Se più di quattro di queste domande ricevono una risposta negativa o incerta, il primo passo prima di parlare di Agentforce è un assessment della data readiness.

Una nota sul costo reale dei dati di scarsa qualità

I numeri che abbiamo citato all'inizio — i miliardi persi per dati di bassa qualità — rischiano di sembrare astratti. Proviamo a renderli concreti con un esempio semplice.

Un'azienda con 50 agenti commerciali che ogni mattina dedicano 30 minuti a ricercare manualmente informazioni sui clienti prima di fare le chiamate — aggiornare lo stato del CRM, verificare gli ordini nell'ERP, rileggere le note sparse — sta spendendo 25 ore di lavoro commerciale al giorno per compensare la mancanza di integrazione dati. Su 220 giorni lavorativi, sono 5.500 ore annue di lavoro ad alto costo destinate a una funzione puramente amministrativa.

Un agente AI che automatizza questa funzione — aggregando i dati rilevanti e presentandoli al commerciale in forma strutturata prima di ogni call — libera quelle 5.500 ore per attività che producono valore diretto. Il risparmio non è teorico: secondo il report Valoir, i clienti Agentforce dichiarano in media una riduzione del 75% nel tempo dedicato ad attività preparatorie e amministrative rispetto agli approcci precedenti.

La stessa logica si applica al customer service, alla gestione delle pratiche in PA, al monitoraggio degli abbonati nel trasporto pubblico. Il valore non sta nell'AI: sta nel tempo e nelle decisioni che l'AI libera, una volta che ha dati su cui ragionare.

Il ruolo del partner: perché non si fa da soli

Abbiamo già citato il dato MIT: i progetti che acquistano soluzioni da vendor specializzati e costruiscono con un partner hanno un tasso di successo del 67%, contro il 33% di chi costruisce in autonomia. Questo dato non sorprende chi lavora sul campo.

La ragione principale non è tecnica: è organizzativa. I progetti AI che falliscono non falliscono perché il modello era sbagliato. Falliscono perché non c'era qualcuno che sapesse tradurre il problema di business in un'architettura dati funzionante, che sapesse convincere i responsabili di processo a investire nella qualità del dato prima di vedere i risultati dell'AI, che sapesse calibrare le aspettative in modo realistico e costruire un percorso progressivo anziché un progetto big bang.

Questo è esattamente il lavoro che facciamo: non vendiamo licenze. Costruiamo architetture dati che funzionano, e poi le rendiamo intelligenti.

Conclusione: l'AI è la destinazione, i dati sono la strada

Agentforce è uno strumento potente. Ma come tutti gli strumenti potenti, amplifica ciò che trova. Se trova una base dati ordinata, integrata, semanticamente coerente e monitorata, produce un vantaggio competitivo misurabile. Se trova frammentazione, duplicati e silos informativi, produce output inaffidabili che erodono la fiducia degli utenti e lasciano il progetto in uno stato permanente di "quasi funziona".

La buona notizia è che il percorso per arrivare alla data readiness non richiede anni né investimenti stratosferici. Richiede metodo, prioritizzazione e la volontà di affrontare il problema di dati prima di parlare di AI.

Noi lavoriamo esattamente su questo confine — da trent'anni, con le organizzazioni del Nordest. E nel 2026, finalmente, il mercato ci sta dando ragione.