Perche il tuo CRM e la parte piu importante della tua strategia AI

La maggior parte dei progetti AI non fallisce perche il modello era sbagliato. Fallisce perche i dati che alimentano il modello erano sbagliati, incompleti, o bloccati dietro un confine di autorizzazione che l'agente non avrebbe dovuto attraversare. Dopo un anno a osservare aziende che costruiscono proof-of-concept che non arrivano mai in produzione, sono arrivato a una conclusione abbastanza solida: le organizzazioni che otterranno valore duraturo dall'AI sono quelle che hanno gia i dati in ordine. E per la maggior parte delle PMI, la cosa piu vicina a una "casa dei dati" e Salesforce.

Non e un discorso commerciale. E un'osservazione architetturale.

Il cimitero dei POC e un problema di dati

C'e un pattern ben documentato nell'AI enterprise in questo momento. Un team dimostra un agente funzionante in un ambiente di test, il management si entusiasma, poi tre mesi dopo il progetto viene silenziosamente archiviato. Le ragioni usuali sono variazioni dello stesso tema: l'agente ha attinto a dati che non avrebbe dovuto vedere, i risultati erano inconsistenti, nessuno riusciva a fare audit di cio che era successo, o l'IT ha bloccato l'integrazione perche non riusciva a soddisfare una domanda di compliance.

La ricerca di Salesforce stessa lo rende concreto. Un benchmark chiamato CRMArena Pro ha testato quanto bene gli agenti LLM di uso generale gestiscono i task CRM reali. I risultati erano scarsi su tutta la linea. Piu preoccupante, alcuni agenti [hanno fatto trapelare dati tra account utente diversi](https://www.theregister.com/2025/06/16/salesforce_llm_agents_benchmark/), mostrando le informazioni di un cliente a un altro. Non e un problema del modello. E quello che succede quando colleghi un'AI a un'infrastruttura dati priva di un layer di controllo degli accessi coerente.

Cosa ti da davvero Salesforce (che un data lake non ti da)

Quando le persone pensano a Salesforce nel contesto dell'AI, tendono a pensare ad Agentforce, il layer di costruzione degli agenti che sta sopra. E interessante, ma non e questo il punto. Il punto e cio che sta sotto.

Dati strutturati e tipizzati. Ogni record in Salesforce ha uno schema definito. Contatti, account, casi, opportunita: tutto e strutturato, etichettato e collegato in modo relazionale. Quando un agente AI lo interroga, ottiene dati puliti e coerenti, non un cumulo di CSV con nomi di colonna inconsistenti provenienti da cinque team diversi. Quella coerenza vale piu di quanto la maggior parte delle persone realizzi.

Controllo degli accessi che funziona davvero. Il modello di permessi di Salesforce, profili, permission set, regole di condivisione a livello di record, sicurezza a livello di campo, e granulare e verificabile. Quando costruisci un agente sopra di esso, quei permessi viaggiano con i dati. La partnership tra Salesforce e Databricks annunciata nel 2026 lo dice esplicitamente: l'obiettivo e un singolo modello di permessi coerente su entrambe le piattaforme, in modo che [gli agenti non possano agire su dati che non dovrebbero toccare](https://www.salesforce.com/news/stories/salesforce-databricks-shared-foundation-of-human-agent-work-announcement/).

Residenza dei dati e sovranita. Per le aziende britanniche in settori regolamentati, il luogo fisico in cui risiedono i dati conta. Salesforce offre opzioni di residenza dati nell'UE e nel Regno Unito. La domanda "dove vanno i dati quando l'AI li elabora?" ha gia fatto naufragare piu di qualche progetto AI partito con integrazioni LLM pronte all'uso e nessun piano al riguardo.

Accesso ai dati senza consumo di token. Quando il tuo agente legge un record Salesforce, non paghi per ogni campo che esamina. Il modello di accesso ai dati e flat, non misurato a carattere. Questo cambia l'economia della costruzione di agenti che devono estrarre dati contestuali ricchi per ogni interazione. Elimina anche la tentazione di ridurre artificialmente il contesto per risparmiare costi, che e uno dei modi in cui gli agenti diventano inaffidabili.

Unificazione e resilienza dei dati. Salesforce e spesso l'unico sistema di riferimento che sopravvive a fusioni, cambi di team e proliferazione di strumenti. Data Cloud, il layer dati cliente di Salesforce, e progettato specificamente per unificare l'identita tra le fonti. Un agente che ragiona su un profilo cliente unificato produce risposte migliori rispetto a uno che ragiona su quattro fogli di calcolo separati che non concordano nemmeno sul nome del cliente.

Fallimenti architetturali, non fallimenti del modello

Il team di ingegneria di Salesforce ha pubblicato un'analisi dettagliata di un agente in produzione che avevano costruito per automatizzare l'ottimizzazione dei costi cloud. La conclusione principale e istruttiva: [la maggior parte dei fallimenti degli agenti sono fallimenti architetturali, non fallimenti del modello](https://engineering.salesforce.com/how-to-build-reliable-ai-agents-5-engineering-patterns-from-a-production-system/). L'agente continuava a dare risposte inconsistenti non perche l'LLM fosse scarso, ma perche ragionamento ambiguo e calcolo preciso venivano inviati allo stesso strumento. La soluzione e stata separare i compiti: LLM per i giudizi ambigui, solver deterministico per i calcoli, output validati contro controlli reali.

La stessa logica si applica ai dati. Un agente che ragiona su dati vaghi, non strutturati o privi di controllo degli accessi produrra output vaghi, non strutturati o pericolosi. Il modello non e la variabile da ottimizzare per prima.

Questo e solo l'inizio. Ecco dove andare dopo.

Questo post e l'introduzione a una serie. Abbiamo cercato di spiegare perche le proprieta a livello di piattaforma, cose come sicurezza, controllo degli accessi, struttura dei dati e residenza, sono cio che separa i progetti AI che arrivano in produzione da quelli che non ci arrivano.

Se vuoi approfondire:

• Per i team tecnici: Abbiamo scritto un documento tecnico dettagliato che copre come l'architettura dati di Salesforce, il modello dei permessi e i pattern di integrazione degli agenti reggono in condizioni di produzione reali. E il posto giusto se stai costruendo o valutando.

• Per i decision-maker e i dirigenti: C'e un documento complementare scritto per chi non e interessato ai meccanismi tecnici, ma deve capire quali domande porre prima di impegnare il budget e approvare un deployment.

• Per tutti nella stanza: Abbiamo preparato un breve elenco di domande che ogni stakeholder, tecnico, commerciale o operativo, dovrebbe porre prima che un progetto AI passi dal POC alla produzione. Stampalo. Portalo alla prossima riunione.

La domanda non e se l'AI cambiera il modo in cui opera la tua azienda. Quasi certamente lo fara. La domanda e se la tua infrastruttura dati e pronta a supportarla, o se stai per costruire qualcosa di impressionante che crollerebbe silenziosamente sotto il proprio peso.

Perché Salesforce è più utile per l'AI di quanto non lo sia mai stato per il CRM

Nei team di ingegneria circola un'idea diffusa: Salesforce è il sistema legacy attorno al quale costruire le integrazioni. Il budget è già allocato, gli utenti ci lavorano dentro, quindi si costruisce il progetto AI a fianco di esso, estraendo dati via API, reinserendo i risultati, sperando che la sincronizzazione regga abbastanza a lungo da poter chiamare il tutto "production-ready". Questa prospettiva è esattamente rovesciata. Le caratteristiche che hanno reso Salesforce uno strumento radicato nelle organizzazioni si rivelano essere le stesse proprietà più difficili da costruire da zero quando si ha bisogno che un sistema AI si comporti in modo affidabile in produzione. Confini di sicurezza, controllo degli accessi strutturato, dati unificati con schema applicato, un layer di governance integrato sotto il livello applicativo, e un primitivo di esecuzione deterministica. Questi non sono aspetti marginali della piattaforma. Sono esattamente gli ingredienti che mancano alla maggior parte dei progetti AI quando si bloccano.

E la maggior parte si blocca. [Gartner rileva che almeno il 50% dei progetti di intelligenza artificiale generativa viene abbandonato dopo la proof of concept per via di scarsa qualità dei dati, controlli del rischio inadeguati, costi crescenti o valore aziendale non chiaro](https://www.gartner.com/en/articles/genai-project-failure). Non è un problema di modello. È un problema di infrastruttura e dati. I demo dei vendor girano su dataset curati con schemi puliti e volumi controllati. La produzione gira su anni di dati inconsistenti, mal governati e poco documentati che nessuno ha mai ripulito perché nessuno ne aveva mai avuto bisogno prima. Quel divario è dove muore la maggior parte dei progetti AI, ed è un problema di qualità dei dati e di integrazione delle pipeline, non un problema di modello.

Le aziende che arrivano davvero in produzione condividono un tratto comune. Hanno iniziato con dati già governati, già strutturati, già soggetti a controllo degli accessi. Per la maggior parte delle PMI, questo descrive esattamente un sistema. Salesforce.

---

Il problema dei token non è quello che pensi

Le discussioni sul costo dell'AI ruotano quasi sempre attorno al prezzo dei token. È il frame sbagliato per i sistemi in produzione. Il vero costo del consumo di token non è la fattura del provider del modello. È la pressione architettonica che ti spinge a inserire il contesto in un prompt che diventa il muro portante della tua applicazione.

Quando la conoscenza che l'agente ha di un cliente vive in un prompt, ogni informazione su quel cliente diventa una decisione sul budget di token. Devi recuperarla, pulirla, formattarla, inserirla nel contesto e sperare che il modello vi presti attenzione nella parte giusta durante l'inferenza. Quella pipeline è fragile. È costosa da mantenere. È difficile da controllare. E quando si rompe alle 2 di notte perché il job ETL a monte è caduto, il tuo sistema AI non sa quello che non sa.

Salesforce inverte quell'architettura. Data Cloud fornisce agli agenti Agentforce accesso a bassa latenza ai record reali tramite retrieval-augmented generation. Salesforce ha integrato nativamente la ricerca vettoriale in Data Cloud. Quando un agente ha bisogno di contesto rilevante, può effettuare ricerche semantiche sull'intera storia di un cliente senza che un essere umano scriva una query precisa. Si tratta di una decisione architettonica significativa: invece di collegare un LLM a un database vettoriale separato, l'infrastruttura di retrieval vive all'interno del layer dei dati. Gli agenti ottengono dati strutturati e non strutturati dallo stesso posto.

La conseguenza è che i record CRM, i casi, le opportunità, i contatti e la cronologia degli account non devono mai essere serializzati in token perché l'agente possa ragionarci sopra. Il framework di metadati di Salesforce è centrale per come gli agenti comprendono il contesto aziendale. Un agente Agentforce non riceve solo un prompt in linguaggio naturale: ha accesso all'intero schema CRM, account, opportunità, casi, contatti, e può leggere e scrivere su quegli oggetti. Questo significa che un agente che gestisce un'escalation può cercare il livello di account del cliente, verificare lo stato dell'opportunità correlata, rivedere la cronologia dei casi precedenti e attivare un workflow, tutto senza che un essere umano faccia ricerche nel database.

Non è RAG su un blob di testo. È accesso tramite query strutturate su uno schema governato. Le caratteristiche di latenza sono fondamentalmente diverse, e soprattutto, i modi di fallimento sono fondamentalmente diversi. Una query SOQL fallita genera un'eccezione. Un retrieval RAG fallito produce un'allucinazione con aria di certezza.

C'è un'altra dimensione. La latenza degli agenti non è la stessa della latenza software tradizionale. Spesso il problema non è una query lenta o un ritardo dell'API, ma il costo composto di più chiamate LLM, ognuna in attesa della precedente. Su scala enterprise, questo può produrre ritardi fino a 20 secondi tra le interazioni degli agenti. Per affrontarlo è stato necessario ricostruire il runtime di Agentforce: ridurre le chiamate LLM da quattro a due prima del primo token di risposta, sostituire i controlli di sicurezza degli input basati su LLM con filtri deterministici, e distribuire un modello linguistico proprietario di piccole dimensioni che gestisce la classificazione degli argomenti 30 volte più velocemente del modello general-purpose. Il segnale è chiaro: le pipeline token-intensive non costano solo denaro. Introducono latenza che rende l'agente percepito come rotto.

---

Data residency e l'architettura di cifratura che conta davvero

La maggior parte dei team di ingegneria tratta la data residency come un adempimento burocratico, qualcosa da delegare al team legale perché lo accordi con il vendor. Voglio essere preciso su cosa significa architetturalmente, perché sbagliarlo è una fonte sempre più frequente di fallimenti nei mercati regolamentati.

La domanda fondamentale è: dove risiedono fisicamente i tuoi dati quando un LLM li elabora? In una pipeline RAG generica, la risposta è "ovunque giri l'infrastruttura di inferenza del provider del modello", che spesso è negli Stati Uniti, spesso fuori dai territori di adeguatezza GDPR, e quasi mai impegnata per iscritto a livello di campo. È un'esposizione significativa per qualsiasi PMI che gestisce dati personali.

Salesforce affronta questo attraverso due meccanismi distinti che vanno compresi separatamente.

Il primo è Hyperforce, il layer infrastrutturale. Questa architettura consente alle istanze Salesforce di girare su infrastruttura cloud pubblica in varie regioni, offrendo ai clienti maggiore scelta sulla localizzazione dei dati. Per le organizzazioni in regioni con leggi rigide sulla residenza dei dati, come l'UE, è possibile assicurarsi che Salesforce ospiti i dati dell'organizzazione in-country o in-region, e impegnarsi a mantenerli lì. Questo comporta sia l'abilitazione tecnica tramite il deployment Hyperforce nella regione scelta, sia accordi contrattuali a sostegno legale.

Il secondo è Shield Platform Encryption, che opera a una granularità più fine. Salesforce Shield consente di cifrare i dati Salesforce con crittografia AES a 256 bit a livello di campo, nonché di gestire le proprie chiavi di cifratura. La crittografia a livello di campo non è fornita nativamente da Salesforce. L'architettura sottostante vale la pena di essere capita nel dettaglio. I componenti critici di Shield Platform Encryption, inclusi i segreti KDF, il salt KDF, le chiavi di wrapping e le chiavi di cifratura dei dati, sono protetti da una struttura a livelli che incorpora chiavi wrapped, firma e derivazione delle chiavi. Con la cifratura a livello di campo, quando gli utenti inviano dati, il server applicativo cerca la chiave di cifratura dei dati specifica dell'organizzazione nella propria cache. Se non è presente, il server applicativo ottiene il segreto tenant cifrato dal database e chiede al server regionale di gestione delle chiavi di derivare la chiave. Il servizio Shield Platform Encryption cifra quindi i dati sul server applicativo.

L'implicazione pratica: quando un agente Agentforce recupera un record cliente, i campi sensibili cifrati tramite Shield vengono decifrati sul server applicativo sotto il tuo materiale di chiave, non sotto quello di Salesforce. L'LLM riceve i valori in chiaro, ma il tuo materiale di chiave non lascia mai il confine del KMS che controlli. Il materiale di chiave non viene mai salvato o condiviso tra le organizzazioni. Puoi scegliere di far generare il materiale di chiave da Salesforce, oppure di caricarne uno tuo. Per default, Shield Platform Encryption usa una funzione di derivazione delle chiavi per derivare le chiavi di cifratura dei dati su richiesta da un segreto primario e dal materiale di chiave specifico dell'organizzazione.

Un dettaglio implementativo che sorprende molti team: Shield offre schemi di cifratura sia probabilistica che deterministica. Shield Platform Encryption offre due schemi di cifratura, ognuno con diversi compromessi tra sicurezza e funzionalità. La cifratura probabilistica va usata quando i dati in un campo non necessiteranno di filtri o ricerche. La cifratura deterministica va riservata solo ai campi dove la capacità di filtraggio è essenziale per le operazioni aziendali. Se cifri un campo con cifratura probabilistica e poi provi a usarlo in una clausola WHERE in SOQL, la query fallisce. Il codice Apex esistente fallisce a runtime con errori sui campi cifrati nelle clausole WHERE. La soluzione è usare SOSL per gli scenari di ricerca, oppure configurare il campo per la cifratura deterministica se la ricerca è necessaria. Non è una preoccupazione teorica: riguarda direttamente il comportamento delle query di routing degli argomenti e di ricerca delle azioni di Agentforce sui campi di contatto o di caso cifrati.

Poi c'è Einstein Trust Layer, che si posiziona sopra entrambi questi meccanismi. Data Cloud applica l'Einstein Trust Layer. È il meccanismo di governance integrato di Salesforce che impedisce che i prompt degli agenti vengano usati per addestrare modelli esterni, maschera i PII sensibili prima che raggiungano un LLM e registra tutte le attività degli agenti a fini di audit. L'impegno di zero data retention significa che quando un agente Agentforce chiama un provider di modelli esterno, la richiesta di inferenza non viene registrata né trattenuta da quel provider. È un impegno contrattuale, non solo un'opzione di configurazione, ed è una distinzione rilevante quando si spiega la gestione dei dati a un DPO.

---

L'architettura di federazione dei dati che elimina il middle layer ETL

Per i progetti AI, il pattern di fallimento più comune non è che il modello sia cattivo. È che i dati che il modello vede sono obsoleti, incompleti o inconsistenti perché sono stati copiati attraverso troppe pipeline. Uno studio Databricks del 2025 ha rilevato che il 68% delle iniziative AI enterprise cita la qualità dei dati come uno dei tre principali blocchi, eppure gli investimenti nell'infrastruttura dati continuano a essere inferiori a quelli negli strumenti AI.

L'approccio tradizionale dell'ETL in Salesforce ha un costo specifico. Estrarre dati dal warehouse, trasformarli, caricarli in Salesforce, mantenere la pipeline e riconciliare le copie costa 2.000 crediti Data Cloud per milione di record. La federazione Zero-Copy costa 70 crediti per milione. È una riduzione di 28,5 volte nel costo per record. Ma il dato sui costi sottovaluta il vantaggio architetturale. Il vantaggio più grande non è il risparmio economico. È che i tuoi dati sono sempre aggiornati, sempre governati alla fonte, e mai duplicati. Nessuna copia obsoleta. Nessun conflitto di sincronizzazione. Nessuna pipeline ETL da mantenere alle 3 di notte.

Il meccanismo sottostante della federazione zero-copy di Data 360 merita di essere compreso. Le sorgenti dati esterne come data warehouse o data lake vengono interrogate in tempo reale da Salesforce Data 360, che consente di accedere e usare i dati senza copiarli nei sistemi Salesforce. Questa capacità di federazione funziona in due modalità principali: query federation e file federation. Il fondamento è Apache Iceberg. Salesforce Engineering riporta che Data Cloud gestisce attualmente 4 milioni di tabelle Iceberg su 50 petabyte di dati, alimentati dai motori Spark, Hyper e Trino. Poiché Iceberg è uno standard aperto, i motori di query di Data Cloud possono leggere nativamente le tabelle Iceberg esterne. Questo è ciò che rende possibile la file federation a livello di storage senza lock-in proprietario.

I compromessi sulle prestazioni non sono sempre evidenti. Una query live in cui tutti i dati sono remoti può essere estremamente veloce, ma solo se l'intera operazione di calcolo può essere trasferita con successo al sistema remoto, che poi esegue l'operazione e restituisce solo il piccolo set di risultati finale. Le prestazioni della query federation live su tabelle grandi dipendono principalmente da dove risiedono i dati. Se tutti i dati per una query sono remoti e l'intera query può essere trasferita, le prestazioni sono al massimo. Ma se i dati sono distribuiti sia nel sistema remoto che in Data 360, il trasferimento è limitato.

Quest'ultima frase conta in pratica. Se hai un agente Agentforce che unisce dati di warehouse federati con un profilo cliente nativo Salesforce, stai facendo un join cross-system dove il pushdown non può essere completo. La soluzione è pianificare la residenza dei dati in modo che i dati frequentemente uniti siano co-localizzati. I tuoi dati Snowflake rimangono nel formato Snowflake. I tuoi dati Databricks rimangono in Delta Lake. Data Cloud legge entrambi tramite l'astrazione Iceberg. L'impatto pratico: un'azione cliente alle 20:00, un carrello abbandonato, un reclamo in garanzia, una richiesta di servizio, è immediatamente disponibile per gli agenti Agentforce, i journey di Marketing Cloud e i workflow di Service Cloud. Nessuna attesa per il batch sync del giorno successivo.

C'è un argomento contrario che vale la pena prendere sul serio. Perché Salesforce Data Cloud possa interrogare e aggregare i tuoi dati, tutti gli oggetti nel tuo data warehouse devono essere mappati direttamente sul Customer 360 Data Model standard di Salesforce. Non puoi portare i tuoi dati così come sono e devi limitarti a mapparli esplicitamente sul modello dati di Salesforce. Questo è difficile da fare e richiede anche di montare questi dati rifattorizzati in tabelle Iceberg. È reale, e i team lo sottovalutano. Mappare uno schema ERP legacy sul Customer 360 Data Model non è un lavoro da weekend. Richiede decisioni su chiavi primarie, risoluzione delle relazioni e strategia di deduplicazione che si propagheranno in ogni funzionalità AI downstream. Assicurarsi che la chiave primaria usata nel sistema sorgente sia allineata con l'architettura di Data Cloud. Quando si integra un sistema di fatturazione, usare il billing_account_id come chiave primaria aiuta a collegare i dati di fatturazione con i profili di account. Se sono necessari più identificatori per garantire l'unicità, considerare la creazione di una chiave primaria composita, come la combinazione di customer_id e billing_id, per evitare record duplicati durante l'unificazione dei dati. Il lavoro di mapping ha un costo elevato inizialmente, ma il ritorno si distribuisce su ogni azione agente che successivamente dovrà unire dati tra domini. Lo fai una volta sola.

---

Il controllo degli accessi come primitivo di sicurezza AI di primo livello

Il modello di controllo degli accessi di Salesforce è più granulare di quanto la maggior parte dei team realizzi, e si mappa quasi direttamente sui problemi di controllo degli accessi che gli agenti AI in produzione creano.

Il modello di sharing standard include impostazioni predefinite a livello di organizzazione, gerarchie di ruoli, regole di sharing e sharing manuale, che controllano l'accesso a livello di record. La field-level security controlla quali campi un dato profilo o permission set può leggere o modificare. L'object-level security controlla se l'utente può interrogare l'oggetto in assoluto. Questi tre layer interagiscono: un utente con accesso in lettura all'oggetto Account ma senza lettura FLS sul campo Annual Revenue non vedrà quel campo, nemmeno nei risultati SOQL.

Quando un agente Agentforce viene eseguito, gira nel contesto di una named credential o di una connected app, a sua volta governata da permission set. Questo significa che l'accesso effettivo ai dati dell'agente è delimitato dallo stesso modello di permessi che governa gli utenti umani. Un agente che gestisce un caso di servizio non può vedere le cifre di fatturato delle opportunità se il profilo di servizio sotto cui gira non ha accesso FLS in lettura su quel campo. Non devi costruire un layer di controllo degli accessi separato per l'AI. Ne erediti uno che hai già configurato.

Questo è qualitativamente diverso da ciò che si affronta quando si costruisce un agente personalizzato contro tabelle di database raw o un API layer. In quel pattern, il controllo degli accessi è tipicamente applicato a livello API, e la context window dell'agente diventa un bypass se non si presta attenzione. La ricerca di Salesforce ha messo in evidenza questo problema in modo empirico: il benchmark CRMArena Pro ha mostrato che alcuni agenti facevano trapelare dati tra account utente diversi, ossia informazioni destinate a un cliente potevano emergere per un altro. Lo studio mostra che collegare un agente AI general-purpose a un sistema CRM sperando che vada bene non è una strategia sicura. Valutazioni mirate e controlli sulla privacy non sono optional.

L'implicazione per la progettazione di sistemi AI è significativa. Quando costruisci su Salesforce, stai ereditando un sistema di controllo degli accessi con vent'anni di storia, testato sotto pressione dai requisiti di conformità enterprise. La tua AI non ottiene privilegi speciali solo perché è un'AI. Questo è un vantaggio, non un limite.

Il layer di esecuzione deterministica rafforza ulteriormente questo aspetto. AgentScript offre agli sviluppatori un singolo file leggibile che definisce un intero agente. Certi step sono hardcoded per girare in un ordine fisso e garantito. Altri sono lasciati all'LLM, dove la flessibilità è effettivamente utile. Nei workflow sensibili alla sicurezza, gli step di autenticazione, i controlli dei permessi e le scritture di audit possono essere bloccati nel path deterministico. L'LLM può ragionare solo entro i guardrail che hai esplicitamente aperto. Agent Script consente di definire il comportamento dell'agente con un linguaggio espressivo leggibile dall'uomo, abilitando logica condizionale, uso preciso degli strumenti e controlli deterministici guidati. Questo nuovo livello di controllo consente ad Agentforce di affrontare anche i task più complessi con sicurezza.

---

Il pattern architetturale di produzione che effettivamente arriva live

Voglio essere concreto su come questi elementi si combinano, perché l'affermazione che sto facendo non è che Salesforce risolva l'AI. È che Salesforce risolve i problemi infrastrutturali che impediscono all'AI di raggiungere la produzione.

Il pattern che funziona per le PMI, basato su ciò che vediamo arrivare in produzione rispetto a ciò che si blocca, è questo:

Prima l'unificazione dei dati. Mappa i tuoi oggetti operativi chiave in Data 360. Non cercare di federare tutto dal primo giorno. Inizia con gli oggetti da cui dipende il tuo caso d'uso AI: Account, Contatti, Casi e le una o due tabelle esterne dal tuo ERP o warehouse che devi assolutamente unire. Fai funzionare la risoluzione delle identità in modo che un cliente sia lo stesso cliente nel tuo CRM e nel tuo sistema di fatturazione. È un lavoro noioso, non spettacolare, ed è la differenza tra un demo e un sistema in produzione.

Il modello dei permessi prima del modello degli agenti. Prima di scrivere una singola istruzione di argomento per l'agente, definisci il permission set sotto cui girerà. Quali oggetti può leggere? Quali campi sono esclusi? Può scrivere, o solo leggere? Tratta questo come un esercizio di progettazione della sicurezza. Revisionalo con la persona nella tua organizzazione che è responsabile della conformità dei dati. Fallo approvare. Poi costruisci l'agente entro quei vincoli.

Shell deterministica, core probabilistico. Usa AgentScript o Flow per bloccare gli step dove la sequenza e il risultato devono essere garantiti: autenticazione, recupero dei dati da campi sensibili, operazioni di write-back, logging di audit. Usa l'LLM per i task di ragionamento all'interno di quella shell: interpretare un messaggio del cliente, classificare l'intent, generare una risposta. Il dato chiave dall'ingegneria di produzione interna di Salesforce è che la maggior parte dei fallimenti degli agenti sono fallimenti architetturali, non fallimenti del modello. Separare il ragionamento LLM dal calcolo deterministico e validare gli output con verifiche oggettive piuttosto che con agenti revisori sono le leve ingegneristiche pratiche.

Osservabilità dal primo giorno. Agentforce Observability fornisce il tracciamento delle conversazioni a livello di sessione, che cattura l'intero percorso di ragionamento, la categorizzazione degli intent che segnala quando gli utenti chiedono cose per cui l'agente non è stato progettato, e l'alerting sulle anomalie che si attiva sulla deriva comportamentale piuttosto che sugli errori di sistema. Configuralo prima di andare live, non dopo. Non puoi migliorare un agente che non riesci a vedere.

Il modo in cui falliscono i team che non seguono questo pattern è consistente. Il "pilot purgatory" si verifica quando la validazione tecnica ha successo ma lo scaling operativo fallisce. La tua proof of concept funziona magnificamente in un ambiente controllato. Poi provi a distribuirla nell'organizzazione e tutto cade a pezzi. L'ambiente controllato di solito ha dati puliti, un singolo utente, nessun requisito reale di controllo degli accessi e nessuna revisione di conformità. La produzione non ha nessuna di queste proprietà. Salesforce sì.

---

Gli argomenti contrari che vale la pena prendere sul serio

Voglio essere onesto sui punti dove i vincoli fanno male.

La cifratura Shield aggiunge latenza. Decifrare i campi sul server applicativo a ogni richiesta è misurabile, in particolare per le operazioni batch. Se il tuo agente elabora migliaia di record in un batch, devi fare il benchmark della tua configurazione Shield rispetto al tuo SLA prima di impegnarti.

La mappatura del Customer 360 Data Model è lavoro reale. Se il tuo patrimonio dati è molto non standard, lo sforzo per modellarlo nello schema Salesforce può essere considerevole. La federazione zero-copy aiuta perché non sposti fisicamente i dati, ma la mappatura la devi fare comunque. Molte aziende faticano a usare appieno i propri dati perché sono intrappolati in silos, frammentati e difficili da accedere. Un recente rapporto IDC ha evidenziato che le aziende perdono fino al 30% di ricavi annualmente a causa delle inefficienze causate dai silos di dati. Lo zero-copy non risolve la mappatura dei silos. Rimuove solo il costo di manutenzione della pipeline una volta che l'hai fatto.

Agentforce non è model-agnostic nel modo in cui lo è una pipeline LangChain costruita a mano. Lavori entro le scelte del reasoning engine di Salesforce e l'architettura topics-and-actions. Per i team che hanno bisogno di un controllo molto fine sulla selezione dei modelli o che vogliono eseguire modelli open-weight on-premises, questo è un vincolo reale. Il compromesso è che ciò che si perde in flessibilità si guadagna in governance, tracciabilità e un arrangement di hosting production-grade che una PMI non potrebbe permettersi di costruire da zero.

Il requisito di qualità dei dati è non negoziabile. Salesforce rende più facile governare i dati, ma non può pulire dati che non sono mai stati governati. Gartner prevede che il 60% dei progetti AI non supportati da dati AI-ready verrà abbandonato entro il 2026. Se il tuo org Salesforce ha account duplicati, convenzioni di naming inconsistenti, campi obbligatori mancanti e oggetti custom costruiti da admin diversi nell'arco di un decennio senza uno standard di schema, quei problemi ti seguono nel sistema AI.

---

Cosa significa per i prossimi sei mesi

La domanda pratica per qualsiasi team che sta eseguendo una proof of concept AI è: cosa ci vorrebbe per arrivare in produzione? Nella mia esperienza, la risposta non riguarda quasi mai un modello migliore. Riguarda dati migliori, un controllo degli accessi più chiaro, un audit trail che il team di conformità possa approvare, e un layer di esecuzione deterministica attorno alle parti del workflow dove non ci si può permettere un comportamento probabilistico.

Salesforce fornisce tutto questo, e lo fa da anni, a uno standard che la maggior parte delle infrastrutture custom semplicemente non riesce a replicare senza investimenti significativi. I team che vedo arrivare più velocemente all'AI in produzione non sono quelli che hanno costruito lo stack bespoke più sofisticato. Sono quelli che hanno riconosciuto che i problemi più difficili nell'AI in produzione sono i dati, la governance e la sicurezza, e che la loro implementazione Salesforce aveva già risolto buona parte di tutti e tre.

Il modello AI non è il collo di bottiglia. Lo è la tua infrastruttura dati. E per un numero sorprendente di PMI, l'infrastruttura dati più production-ready che possiedono sta già girando su Salesforce.

Perché il tuo CRM è diventato il tuo asset AI più importante

La maggior parte dei progetti AI non muore per colpa del modello. Muore prima ancora di raggiungere gli utenti reali, perché i dati sottostanti non erano mai stati pronti. Una ricerca IDC condotta in partnership con Lenovo ha rilevato che l'88% dei proof of concept osservati non supera la soglia del deployment su larga scala. Su 33 POC avviati da un'azienda, solo quattro arrivavano in produzione. Un altro studio formulava la cosa ancora più nettamente: l'iniziativa NANDA del MIT ha riscontrato che circa il 5% dei programmi pilota AI raggiunge un'accelerazione rapida dei ricavi, mentre la grande maggioranza si arena, senza produrre alcun impatto misurabile su P&L.

Ho visto troppe volte leadership team di PMI investire budget significativi in strumenti AI, solo per scontrarsi con lo stesso muro a distanza di tre mesi circa. La demo aveva funzionato. Il rapporto con il vendor sembrava promettente. E poi, silenziosamente, il progetto si fermava. I dati erano frammentati tra sistemi diversi. I controlli di sicurezza non si riuscivano a completare. Nessuno sapeva con certezza dove si trovassero fisicamente i dati dei clienti. L'AI era a posto. Tutto il resto no.

La conclusione scomoda è questa: le aziende che ottengono valore reale e continuativo dall'AI non sono necessariamente quelle che dispongono dei modelli migliori. Sono quelle che hanno i dati più puliti, più strutturati, meglio governati. E per la maggior parte delle PMI nel Regno Unito, la cosa più vicina a quella condizione che già possiedono è Salesforce.

Questo articolo si rivolge ai decision-maker, non agli sviluppatori. Non è necessario capire come funziona Salesforce sotto il cofano. Ciò che è necessario capire è perché una piattaforma Salesforce ben configurata rende il vostro investimento AI molto più probabile che sopravviva al contatto con la realtà, e perché trascurarla rende quasi impossibile scalare anche il prototipo AI più impressionante.

---

Il cimitero delle buone demo

C'è uno specifico pattern di fallimento che vedo più di qualsiasi altro. Un team di leadership vede una dimostrazione AI convincente, di solito costruita su dati campione caricati in un notebook o in un ambiente cloud temporaneo. Sembra genuinamente impressionante. Il vendor è fiducioso. Il board approva il pilota.

Tre mesi dopo, il progetto è bloccato. Il divario tra POC e produzione si riferisce alla disconnessione sistemica tra l'ambiente controllato in cui i pilota AI hanno successo e la realtà complessa e disordinata dei sistemi di produzione aziendali. Un pilota opera in una sandbox con dati puliti, attenzione dedicata e requisiti di performance ridotti. La produzione richiede scalabilità, affidabilità, sicurezza, conformità e adozione organizzativa.

La causa principale, in quasi ogni caso, non è l'AI in sé. Il fallimento non riguarda quasi mai il modello. Riguarda la disponibilità dei dati, l'integrazione nei flussi di lavoro e l'assenza di un risultato definito prima che la costruzione inizi. Le persone che hanno costruito il pilota hanno lavorato con una fetta accuratamente selezionata dei vostri dati, ripulita per l'occasione. Quando il sistema ha dovuto ingerire il materiale reale, dodici anni di account distribuiti su tre CRM, due fogli Excel e un ERP legacy, non è riuscito a produrre risposte coerenti.

Il VP di IDC Group Ashish Nadkarni l'ha detto chiaramente: "L'elevato numero di AI POC ma la bassa conversione in produzione indica il basso livello di preparazione organizzativa in termini di dati, processi e infrastruttura IT."

Questo è il punto centrale. La prontezza per l'AI non è un problema di modello. È un problema di infrastruttura dei dati. Ed è esattamente per questo che piattaforme come Salesforce, che molti leader considerano uno strumento per le vendite o il customer service, sono diventate qualcosa di più fondamentale: il substrato su cui l'AI può effettivamente funzionare in modo sicuro e scalabile.

---

I dati strutturati non sono noiosi. Sono il prerequisito.

C'è qualcosa che sorprende la maggior parte dei leader non tecnici quando lo sentono per la prima volta. I large language model, la tecnologia alla base della maggior parte degli strumenti AI commerciali, consumano enormi quantità di testo nelle loro risposte. Ogni parola che gli si passa costa denaro, richiede tempo e introduce la possibilità di incoerenza. Quando un agente AI deve leggere un record cliente con 40 campi, una serie di email e tre documenti solo per rispondere a una domanda, i costi e la latenza si accumulano rapidamente.

Salesforce gestisce i propri dati in modo diverso. Record dei clienti, storico dei contatti, fasi di pipeline, casi di assistenza e interazioni sono archiviati in un formato strutturato e relazionale. Questo significa che un agente AI che lavora all'interno di Salesforce, specificamente tramite Agentforce, il livello agentico nativo di Salesforce, non ha bisogno di convertire tutto in testo e passarlo attraverso un modello linguistico ogni volta. Può leggere direttamente i campi strutturati. Il fattore più determinante per il successo di un agente non è il modello che lo alimenta, ma l'architettura costruita intorno ad esso: quali dati può vedere l'agente, sotto quali permessi opera, a quali sistemi può accedere e cosa gli è esplicitamente impedito di fare.

Questo ha implicazioni di costo reali per le PMI. Se si costruisce AI su dati grezzi e non strutturati, si paga per ogni token di contesto elaborato. Se si costruisce su record Salesforce ben strutturati, si accede a quel contesto in modo più diretto, a costo inferiore e con maggiore coerenza. Le decisioni architetturali più importanti in un deployment Agentforce non riguardano la selezione del modello. Riguardano l'integrazione con Data 360, la configurazione dei permission set, la qualità della knowledge base e la governance del trust layer. Un modello brillante con accesso ai dati sbagliato fa errori con sicurezza. Un agente ben governato con il contesto giusto semplicemente funziona.

Il lavoro noioso e meticoloso di mantenere il CRM pulito e completo è, in effetti, una riduzione dei costi per ogni progetto AI che si gestirà da questo momento in poi.

---

Data residency, sicurezza e le domande a cui il tuo vendor AI non sempre sa rispondere

Ogni PMI con cui parlo che gestisce dati dei clienti nel Regno Unito o in Europa sta, giustamente, ponendo due domande sull'AI: dove andranno i miei dati, e chi potrà vederli?

Non sono domande paranoiche. Sono le domande che il vostro team legale, il vostro responsabile GDPR e, sempre più spesso, i vostri clienti enterprise porranno prima di firmare un contratto che tocca i loro dati. Quando si inseriscono informazioni sui clienti in un modello AI di terze parti, si stanno, nella maggior parte dei casi, inviando dati a infrastrutture che non si controllano pienamente, in posizioni che potrebbero non essere specificabili.

L'architettura Hyperforce di Salesforce affronta la questione diversamente. Hyperforce è l'architettura infrastrutturale di nuova generazione di Salesforce, costruita per il cloud pubblico. L'infrastruttura è composta da codice anziché da hardware, in modo che la piattaforma e le applicazioni possano essere distribuite rapidamente e in modo affidabile in tutto il mondo, dando ai clienti maggiore scelta e controllo sulla data residency. Per le aziende britanniche nello specifico, Hyperforce supporta la residenza dei dati in numerosi paesi, incluso il Regno Unito. È possibile confermare, contrattualmente, che i dati rimangono nel UK. Questo conta quando un cliente chiede dove sono conservate le informazioni del suo account.

Il livello di sicurezza va più in profondità della geografia. Salesforce Shield è una suite premium di strumenti di sicurezza e conformità integrati nella piattaforma. È stata progettata per le aziende che gestiscono dati sensibili dei clienti o operano in settori fortemente regolamentati, e aggiunge un ulteriore livello di protezione all'ambiente Salesforce esistente. Shield offre crittografia a livello di campo, audit trail a lungo termine, monitoraggio degli eventi e rilevamento dei dati sensibili per proteggere le informazioni più preziose dell'organizzazione.

In termini concreti: è possibile cifrare campi specifici in modo che nemmeno le persone con accesso completo al sistema possano leggerli. È possibile tracciare, fino al singolo campo, chi ha modificato cosa e quando, con Field Audit Trail che estende il monitoraggio della storia fino a dieci anni. È possibile impostare controlli di accesso in modo che un agente AI, o un utente umano, possa vedere solo i dati che è esplicitamente autorizzato a vedere. Nulla di tutto ciò è teorico. Per le organizzazioni soggette a framework normativi come HIPAA, GDPR, CCPA, PCI-DSS, SOX e FINRA, Salesforce Shield fornisce i controlli tecnici necessari per dimostrare la conformità. Platform Encryption soddisfa i requisiti di cifratura a riposo, Event Monitoring soddisfa i requisiti di audit logging, e Field Audit Trail soddisfa i requisiti di conservazione dei dati e tracciamento delle modifiche.

Quando il vostro progetto AI raggiunge una security review, e lo farà, la domanda è se la vostra infrastruttura dati può produrre risposte in giorni o in mesi. Un Salesforce org ben configurato può farlo. Un insieme disperso di strumenti SaaS non connessi e fogli di calcolo, di norma, no.

---

Unificazione dei dati senza l'eterno progetto preliminare

Uno degli errori più costosi che le PMI commettono è trattare l'unificazione dei dati come un progetto separato e preventivo che deve essere completato prima che il lavoro AI possa iniziare. In pratica, questo approccio produce programmi da 18 mesi che spesso sono già obsoleti nel momento in cui terminano.

La piattaforma Data 360 di Salesforce, l'evoluzione di quello che era precedentemente chiamato Data Cloud, affronta la questione diversamente. La sua capacità di integrazione zero-copy significa che è possibile connettere i dati Salesforce a data warehouse come Snowflake o Databricks senza spostare o duplicare fisicamente i dati. Zero copy è una tecnologia di federazione dei dati che consente alle aziende di accedere e interrogare i dati senza copiarli. Sebbene una qualche forma di federazione dei dati esista da anni, l'adozione è stata lenta a causa della complessità e della mancanza di integrazione nativa nelle piattaforme enterprise. Zero copy di Data 360 si distingue non solo perché elimina la necessità di replicazione tradizionale dei dati via ETL, ma anche perché può scalare per soddisfare le esigenze delle applicazioni aziendali e degli agenti.

La conseguenza pratica è significativa. Zero copy elimina i silos di dati abilitando l'accesso diretto ai dati senza duplicazione o migrazione, mantenendoli nel loro ambiente sicuro originale, e alleviando i rischi e le complessità della gestione e migrazione delle informazioni di identificazione personale. Il profilo del cliente in Salesforce può essere arricchito con i record finanziari dell'ERP e i dati di interazione dalla piattaforma di assistenza, senza che nessuno di questi dati lasci la propria sede originale.

Non si tratta solo di una comodità tecnica. Affronta direttamente una delle ragioni più comuni per cui i progetti AI falliscono su scala: il modello ottiene risposte diverse da sistemi diversi perché i dati erano stati copiati, invecchiati e incoerenti. Genpact, leader globale nei servizi tecnologici avanzati, ha utilizzato Salesforce Data Cloud e le capacità zero copy per unificare dati provenienti da più fonti, tra cui sistemi finanziari e clienti, senza duplicare o spostare le informazioni. Questo ha dato ai team una visione armonizzata e affidabile di oltre 500.000 record per AI analytics in tempo reale. Zero copy ha semplificato drasticamente la conformità e la governance per l'azienda, eliminando al contempo costose pipeline di dati.

Per una PMI senza un team dedicato di data engineering, questo conta enormemente. Non si costruisce l'integrazione da zero. Si configura una piattaforma consolidata che ha già risolto i problemi difficili.

---

Controllo degli accessi: il meccanismo di sicurezza sottovalutato per gli agenti AI

C'è un rischio specifico che ritengo attualmente sottovalutato dai leader aziendali che distribuiscono AI agentici. Quando si dà a un agente AI accesso ai propri sistemi, si sta, in effetti, creando un nuovo tipo di utente. Quell'utente può agire alla velocità di una macchina, può avviare aggiornamenti e azioni automaticamente e, se non adeguatamente vincolato, può accedere a dati ben oltre la portata di qualsiasi singolo dipendente umano.

La domanda non è se ci si fida del modello. La domanda è se si dispone di confini definiti e applicabili su cosa può vedere e fare. Il modello dei permessi di Salesforce è uno dei più maturi nel software enterprise. Profili, permission set, regole di condivisione e gerarchie di ruoli si combinano per dare agli amministratori un controllo preciso su chi, o cosa, può accedere a ogni singolo dato.

Quando un agente Agentforce gira all'interno di Salesforce, opera all'interno di quello stesso modello di permessi. Agentforce affronta le questioni di sicurezza attraverso un modello di gateway fidato che consente agli amministratori di definire a quali server MCP un agente può accedere, con trail di audit completi. L'agente non può vedere i termini contrattuali di un cliente se l'utente nella cui sessione opera non ha accesso ai contratti. Non può aggiornare un record finanziario se quel permesso non è stato esplicitamente concesso. Non è una funzionalità di nicchia. È la differenza tra un sistema AI distribuibile e una responsabilità.

L'alternativa è costruire il proprio livello di controllo degli accessi sopra un'API AI generica. Le aziende che costruiscono AI da zero su API raw devono costruire autonomamente i livelli di sicurezza, conformità e integrazione. Molte PMI sottovalutano il tempo e il costo di quel lavoro fino a quando non si trovano nel mezzo di esso. Ottenere la giusta architettura di sicurezza per un sistema AI costruito su misura può facilmente aggiungere sei mesi a un progetto che avrebbe dovuto richiederne tre.

---

Cosa significa questo per la vostra decisione AI adesso

Voglio essere chiaro su una cosa: non sto sostenendo che Salesforce elimini la difficoltà dei progetti AI. Non lo fa. Portare un agente AI in produzione richiede una progettazione attenta, una buona governance, l'architettura giusta e un'implementazione esperta. La pubblicazione del team di ingegneria di Salesforce sulla costruzione di un agente AI in produzione descrive esattamente questo: la maggior parte dei fallimenti degli agenti sono fallimenti architetturali, non fallimenti del modello. Separare il ragionamento LLM dal calcolo deterministico, gestire il contesto con cura e validare gli output con controlli oggettivi, non con agenti revisori, è ciò che ha prodotto risultati affidabili.

Quello che sto sostenendo è che se avete investito in Salesforce e lo avete configurato ragionevolmente bene, state partendo da una posizione significativamente più solida della maggior parte. I vostri dati sono strutturati. Il vostro modello di sicurezza esiste. La vostra residenza può essere fissata all'infrastruttura UK. I vostri controlli di accesso sono in vigore. Quando il progetto AI raggiunge la produzione, queste fondamenta lo portano attraverso il divario che uccide la maggior parte dei piloti.

Il contrargomento è il costo. Un chatbot che gestisce 10.000 richieste al giorno potrebbe costare solo 150 sterline al mese in token grezzi, ma con i costi generali di integrazione e conformità, la spesa complessiva può facilmente superare Agentforce. Il percorso "costruiscilo tu stesso" sembra più economico all'inizio perché si sta solo prezzando il modello. Non si sta ancora prezzando i sei mesi di ingegneria per mettere i dati in forma, il lavoro sull'architettura di sicurezza, la costruzione del controllo degli accessi, il progetto di conformità sulla residenza o l'audit trail. Quando si prezza tutto ciò, la piattaforma con quelle funzionalità già integrate inizia ad apparire diversamente.

E l'argomento del timing conta specificamente per le PMI. S&P Global ha riscontrato che la percentuale di aziende che abbandonano la maggior parte delle proprie iniziative AI è passata dal 17% nel 2024 al 42% nel 2025. Le aziende che stanno guadagnando terreno non sono quelle che hanno sperimentato di più. Sono quelle che hanno portato qualcosa in produzione. Questo richiede un'infrastruttura pronta per la produzione fin dall'inizio, non pronta in teoria una volta ricostruita metà dell'architettura dati.

L'implicazione pratica, per qualsiasi leadership team di una PMI che considera un investimento AI nel 2025 o 2026, è questa: prima di firmare un contratto con un vendor AI, chiedetevi se la vostra attuale infrastruttura dati può rispondere chiaramente alle seguenti domande. Dove risiedono i dati dei clienti? Chi può accedervi? Riuscireste a dimostrarlo a un revisore? Un agente AI può operare automaticamente entro quei confini? Se Salesforce è già nella vostra azienda e quelle risposte sono chiare, siete più vicini a un AI production-grade di quanto pensiate. Se non lo sono, quel lavoro viene prima, indipendentemente da quale strumento AI acquistate.

L'AI che creerà valore reale per la vostra azienda non sarà il modello più sofisticato. Sarà quello che sta effettivamente girando.