Salesforce Control Plane: agenti AI veloci, governance debole

Che cosa cambia con l'Enterprise AI Harness

Salesforce ha reso pubblica una nuova architettura, l'Enterprise AI Harness, pensata per dare agli agenti una comprensione condivisa del cliente e dell'impresa, come riportato sulla pagina ufficiale^[1].

Il progetto unisce sei capacità, chiamate contesto, agentività, azione, governance, sicurezza e modelli, distribuite attraverso un'architettura comune e componibile. Attorno a queste capacità nasce un nuovo Control Plane, pensato per dare alle aziende un punto unico da cui vedere, gestire e controllare gli agenti man mano che si moltiplicano nell'impresa.

L'obiettivo dichiarato riguarda l'esecuzione di compiti complessi, come rispondere alla domanda "possiamo evadere questo ordine oggi?", che richiede dati sparsi tra CRM, ERP, contratti e policy interne. Un agente deve capire quel contesto, decidere l'azione giusta, e agire dentro i confini stabiliti dall'impresa. La promessa tecnica è alta: reasoning aperto collegato a esecuzione controllata.

Sei capacità, un punto di controllo unico

L'architettura permette ai clienti di usare le sei capacità come sistema integrato, oppure prendere unicamente i pezzi utili, con tecnologia Salesforce, sistemi già esistenti, o entrambi. Questo include modelli, agenti e sistemi di terze parti, un dettaglio che sposta il discorso dal singolo prodotto al layer di orchestrazione.

Il contesto diventa condiviso tra agenti e modelli, e le azioni diventano workflow riutilizzabili in tutta l'organizzazione.

Sulla carta, la componibilità riduce la duplicazione di lavoro tra team che oggi costruiscono agenti isolati. Realtà descritte nel report mensile di AWS mostrano una tendenza simile: framework condivisi per accelerare la messa in produzione di agenti, come indicato nel riepilogo di AWS su agosto 2026^[2]. La domanda che resta aperta riguarda cosa succede quando uno di questi pezzi componibili fallisce dentro una catena di agenti collegati.

Il vuoto architetturale: circuit breaker assenti

La documentazione pubblica dell'Enterprise AI Harness descrive capacità e obiettivi, e resta priva di dettagli tecnici su meccanismi di validazione tra agenti.

Un sistema multi-agente privo di circuit breaker espliciti fallisce in cascata quando l'output di un agente diventa input del successivo, in assenza di controllo indipendente. La loro assenza permette all'errore di propagarsi lungo l'intera catena.

Il Control Plane promette visibilità su chi fa cosa, dove e quando. Nella pagina ufficiale la documentazione manca di riferimenti a limiti di esecuzione per singolo agente, a soglie di errore che bloccano la catena, o a processi di rollback automatico. Questo vuoto documentale conta come debito tecnico dal primo giorno di adozione.

Identità dell'agente: il piano di controllo mancante

Il Control Plane gestisce agenti a scala, e la scala richiede identità verificabili, log nominativi, e la capacità di revocare un permesso in modo puntuale. La pagina Salesforce elenca "governance" e "sicurezza" tra le sei capacità, e manca di specificare come l'identità di ogni agente venga assegnata, tracciata o revocata.

Un'impresa che adotta agenti su scala industriale, in assenza di identità formali per ciascuno di essi, si trova incapace di revocare un permesso quando un agente compie un'azione fuori policy.

Il tema riguarda tutto il settore: il 91% delle imprese dichiara di avere agenti in produzione, e appena il 22% li tratta come identità formali, secondo dati citati in analisi precedenti di questa desk. Salesforce descrive un piano di controllo capace di vedere gli agenti, e manca di chiarire se ogni agente riceva credenziali proprie, distinte da quelle dell'utente che lo ha lanciato. La distinzione conta, perché l'identità dell'agente è il piano di controllo del prossimo ciclo di adozione enterprise.

Il pattern ricorrente: infrastruttura più veloce della sicurezza

Il gap tra orchestrazione e governance segue un pattern già visto nei framework agentici degli ultimi due anni.

Semantic Kernel, Langflow, PraisonAI e Cursor hanno mostrato vulnerabilità critiche capaci di trasformare un documento recuperato in esecuzione remota, con punteggi CVSS vicini al massimo. La sequenza si ripete: adozione rapida in produzione, hardening della sicurezza che arriva dopo, quando il danno è già misurabile.

Kinaxis, nel report pubblicato da Microsoft sulla propria filiera di fornitura, mostra un caso di agenti applicati a processi complessi con benefici operativi documentati, come descritto nel racconto Microsoft su Kinaxis^[3]. Il caso conferma che gli agenti multipli, orchestrati con attenzione, portano valore misurabile in ambienti di produzione reale. Resta da capire quanta parte di quel valore dipenda da controlli specifici, costruiti caso per caso, e quanta dal framework generico adottato.

Tre domande per i team enterprise AI

Prima di firmare un contratto con qualunque vendor di Control Plane agentico, tre domande operative meritano risposta documentata.

1. Quale meccanismo interrompe una catena di agenti quando un output supera una soglia di errore definita?
2. Come viene assegnata, tracciata e revocata l'identità di ogni singolo agente nel sistema?
3. Quale audit trail nominativo esiste per ogni azione compiuta da un agente su dati di produzione?

Decisioni per CTO, Head of Engineering, CFO e Procurement

Per il CTO la domanda riguarda quale parte dello stack esistente vada rivalutata prima di adottare un Control Plane componibile. Per il capo dell'ingegneria la scelta si sposta su quale framework testare in ambiente isolato prima di collegarlo a sistemi di produzione con dati reali.

Per il CFO l'investimento infrastrutturale diventa più rischioso quando il contratto manca di clausole su audit di sicurezza indipendenti e su SLA per la revoca degli agenti.

Il comitato di procurement tecnologico dovrebbe rinegoziare ogni contratto vendor che descrive "governance" e "sicurezza" come capacità generiche, in assenza di meccanismi verificabili elencati esplicitamente. La componibilità dell'architettura, in assenza di questi dettagli, sposta il rischio dal vendor al cliente. Chi adotta oggi un Control Plane privo di specifiche pubbliche su boundary di esecuzione, firma un contratto che accumula debito tecnico dal primo giorno.

Trappola o vantaggio competitivo?

L'Enterprise AI Harness resta un'architettura tecnicamente coerente, capace di riunire capacità che oggi molte aziende costruiscono in modo isolato e ridondante. Il vantaggio competitivo esiste davvero quando l'azienda che lo adotta accetta di costruire, sopra il layer Salesforce, i controlli di validazione che la documentazione pubblica al momento manca di specificare.

La componibilità promessa diventa una trappola architetturale quando i team credono che "governance" e "sicurezza", elencate come capacità, coincidano automaticamente con circuit breaker e identità verificabili già pronti all'uso.

Google Cloud, nel caso KDDI sull'ottimizzazione delle performance RAG tramite Agent Development Kit, mostra come il layer di contesto richieda tuning specifico per funzionare in produzione, come riportato nel caso pubblicato da Google Cloud^[4]. Il parallelo con Salesforce è diretto: zero architetture agentiche arrivano pronte all'uso, in assenza di lavoro di ingegneria dedicato sul layer di controllo.

La domanda che ogni team tecnico deve porsi prima del prossimo ciclo di procurement riguarda cosa succede quando questa architettura si rompe, e chi, dentro l'azienda, ha il compito di rispondere.