L’arrivo degli AI agents sta accelerando una trasformazione profonda nel mondo del software enterprise. Non si tratta semplicemente di nuove funzionalità o strumenti più intelligenti, ma di un cambiamento strutturale che sta riportando al centro temi come workflow, contesto operativo, governance e qualità del dato. Le riflessioni che seguono nascono dall’osservazione dell’evoluzione di piattaforme come ServiceNow e, più in generale, del modo in cui il software enterprise si sta muovendo verso modelli operativi sempre più autonomi, distribuiti e agent-driven.
L’evoluzione digitale
Negli ultimi vent’anni il digitale nelle aziende ha seguito una traiettoria abbastanza chiara. All’inizio la priorità era digitalizzare i processi. Poi integrare sistemi diversi. Poi automatizzare workflow, centralizzare dati, creare visibilità operativa e costruire piattaforme trasversali in grado di collegare funzioni aziendali che storicamente lavoravano in silos. È il motivo per cui negli anni sono diventati così importanti ERP, CRM, ITSM, piattaforme HR, sistemi di monitoring e workflow engine. Il vero problema enterprise non era soltanto raccogliere dati, ma creare coordinamento operativo tra persone, applicazioni, processi e infrastruttura.
L’evoluzione di ServiceNow
ServiceNow nasce nel mondo ITSM. All’inizio l’obiettivo era soprattutto digitalizzare processi IT come incident, request e change management. Nel tempo però la piattaforma ha iniziato a espandersi molto oltre l’IT. Prima HR, customer service, security operations, governance, procurement e workflow enterprise trasversali. Poi progressivamente integrazione tra sistemi, automazione cross-domain, orchestration e gestione del lavoro operativo enterprise. Negli ultimi anni il messaggio di ServiceNow è diventato sempre più quello della “platform of platforms”.
L’idea era che le aziende avessero ormai decine di sistemi diversi — ERP, CRM, sistemi HR, cloud, monitoring, security tools, collaboration platform — ma mancasse un layer comune in grado di coordinare workflow, processi, approvazioni, dati operativi e automazioni tra tutti questi domini. In pratica ServiceNow stava già cercando di diventare una piattaforma di coordinamento operativo enterprise. Con l’arrivo degli AI agents questa architettura assume improvvisamente un valore completamente diverso.
Con i foundation model entriamo in una nuova era
Negli ultimi anni è successo qualcosa di nuovo. Per la prima volta il software non si limita più a seguire regole definite in anticipo. Inizia a interpretare contesto, prendere decisioni e interagire dinamicamente con sistemi diversi.
Per un po' di tempo abbiamo pensato all’AI enterprise soprattutto come copilots, chatbot o strumenti di supporto al knowledge worker. Oggi invece la direzione sta cambiando rapidamente. Gli agenti AI non devono più soltanto assistere le persone. Devono eseguire attività, coordinare workflow, operare su sistemi enterprise e prendere decisioni operative.
Questo porta inevitabilmente verso un modello di workforce ibrida, dove persone e agenti lavorano insieme sugli stessi processi. Alcune attività restano umane, soprattutto quelle decisionali o relazionali. Altre diventano sempre più autonome.
Inizia già a vedersi molto bene nell’IT support. Per anni abbiamo parlato di self-service, cioè dare agli utenti strumenti per risolvere autonomamente problemi semplici senza passare dall’help desk. Ora il paradigma sta cambiando ancora. Si va sempre di più verso modelli di self-healing e zero-touch support. Non un utente che apre un ticket e aspetta risposta, ma sistemi che rilevano problemi, capiscono il contesto operativo, fanno triage, identificano la causa probabile ed eseguono automaticamente remediation o workflow correttivi. In pratica l’obiettivo non è più soltanto automatizzare il supporto, ma eliminare completamente interazioni operative non necessarie. Ed è qui che il contesto enterprise diventa fondamentale.
Per fare self-healing reale, un agente deve capire dipendenze tra sistemi, impatti applicativi, ownership, stato infrastrutturale e relazioni operative. Deve sapere cosa può fare, quali workflow eseguire e quali rischi introduce ogni azione.
La stessa dinamica si vede nel mondo cyber. Anche il SOC tradizionale sta andando verso modelli molto più autonomi. Gli alert aumentano continuamente, mentre gli analisti rimangono limitati. Di conseguenza sempre più attività di triage, correlazione, prioritizzazione e remediation iniziano a essere delegate ad agenti AI che operano direttamente sui workflow di sicurezza. Quando arrivi a questo punto il problema cambia completamente. Non basta più avere un buon modello AI. Serve un sistema enterprise che abbia contesto operativo coerente, stato live dei processi, relazioni tra sistemi, governance, permissions e visibilità trasversale dell’organizzazione.
La real-time data foundation come operational graph
Uno dei concetti più interessanti emersi durante questi giorni è la “real-time data foundation”. Guardando insieme gli annunci e la direzione della piattaforma emerge abbastanza chiaramente l’idea di costruire un vero e proprio operational graph enterprise pensato per gli agenti AI.
La logica ricorda abbastanza Palantir Ontology. Non si parla di un enorme data lake centralizzato dove tutti i dati vengono spostati fisicamente, ma di un layer condiviso costruito sopra sistemi enterprise distribuiti. I dati possono continuare a vivere nei sistemi già esistenti; quello che conta è creare un modello operativo comune che permetta agli agenti di lavorare usando relazioni, workflow, permissions e stato live enterprise.
Per anni abbiamo pensato ai dati enterprise soprattutto in termini di analytics, BI e reporting. Qui invece il dato viene trattato come contesto operativo in tempo reale. Non serve solo per capire il business, ma per permettere agli agenti di prendere decisioni e agire autonomamente.
Gli agenti AI enterprise non hanno bisogno soltanto di documenti o knowledge retrieval. Hanno bisogno di operational context live. Devono capire come funziona davvero l’azienda, quali workflow sono attivi, quali sistemi dipendono da altri, chi approva cosa, qual è lo stato operativo corrente e quali relazioni esistono tra processi, applicazioni, team e infrastruttura. Ed è probabilmente qui che ServiceNow pensa di avere uno dei vantaggi più forti, perché già oggi possiede una parte enorme di questo layer operativo.
Il ritorno strategico del CMDB
Ed è probabilmente per questo che torna improvvisamente centrale anche un tema che per anni è stato considerato quasi “noioso”, il CMDB.
Per chi non conosce il tema, il CMDB è sostanzialmente il sistema che descrive come è fatta l’azienda dal punto di vista tecnologico e operativo. Contiene informazioni su applicazioni, server, servizi, cloud resources, ownership, dipendenze tra sistemi, relazioni infrastrutturali e processi collegati.
In teoria dovrebbe rappresentare il modello operativo dell’azienda.
Il problema è che storicamente mantenere un CMDB aggiornato è sempre stato estremamente difficile. Le aziende cambiano continuamente. Nascono nuove applicazioni, vengono migrate infrastrutture, cambiano ownership, vengono aggiunte integrazioni, cambiano processi e dipendenze operative. Nel cloud tutto questo avviene ancora più velocemente. Per questo motivo molti CMDB nel tempo sono diventati incompleti, incoerenti o semplicemente poco affidabili. Ed è anche il motivo per cui per anni sono stati percepiti più come un obbligo operativo che come un asset realmente strategico.
Nell’era agentica però cambia completamente prospettiva. Se un agente deve operare davvero dentro l’azienda, allora ha bisogno di capire relazioni tra sistemi, dipendenze applicative, stato infrastrutturale, impatti operativi e ownership. In pratica ha bisogno di un modello coerente dell’ambiente enterprise. Ed è qui che succede una cosa interessante. La parte agentica potrebbe finalmente aiutare anche a mantenere vivo quel modello operativo.
Per la prima volta hai sistemi AI che possono osservare continuamente eventi, workflow, cambiamenti infrastrutturali, accessi, incident, configurazioni e relazioni operative distribuite nell’azienda. Questo potrebbe rendere molto più realistico mantenere un CMDB continuamente aggiornato e coerente rispetto al passato.
Paradossalmente quindi l’AI agentica non solo dipende dalla qualità del CMDB, ma potrebbe anche diventare uno degli strumenti che ne migliora automaticamente accuratezza e manutenzione. Più il modello operativo enterprise è coerente, più gli agenti possono operare bene. E più gli agenti operano bene, più possono contribuire a mantenere aggiornato quel modello operativo.
Senza qualità del dato non esiste AI agentica
Pensavate veramente di scamparvela? Il tema ritorna sempre qui. Finché un copilot suggerisce testo o recupera informazioni, dati incompleti o incoerenti sono spesso tollerabili. Ma quando un agente deve orchestrare workflow, eseguire azioni o prendere decisioni operative, allora data quality e operational consistency diventano fondamentali.
Se workflow, identity, CMDB e process state sono incoerenti, gli agenti diventano rapidamente inaffidabili. L’automazione si rompe. La governance collassa. E il rischio operativo cresce molto velocemente. L’AI agentica renderà probabilmente molto più visibili tutti quei problemi enterprise che per anni sono rimasti nascosti sotto il tappeto. Sistemi frammentati, processi inconsistenti, dati poco affidabili e assenza di una vera operational visibility condivisa.
Da system of record a runtime operativo dell’impresa agentica
È probabilmente qui che si capisce davvero la direzione che ServiceNow sta prendendo. Per anni è stata principalmente un system of record e workflow orchestration layer. Una piattaforma dove transitavano processi, approvazioni, incident, richieste operative e automazioni enterprise.
Con l’arrivo degli AI agents il ruolo della piattaforma cambia radicalmente. Non si tratta più soltanto di registrare workflow o orchestrare task tra persone e sistemi. La piattaforma inizia a diventare il contesto operativo dentro cui gli agenti lavorano, prendono decisioni ed eseguono azioni. Un agente enterprise non può operare soltanto con accesso a documenti o knowledge base. Deve sapere come è fatta l’azienda, quali sistemi sono coinvolti, quali workflow sono attivi, quali dipendenze esistono, quali permessi ha e quali impatti può generare ogni azione. In pratica il workflow layer evolve in una sorta di runtime operativo dell’impresa agentica. Ed è qui che secondo me cambia anche completamente il dibattito sul valore di piattaforme come ServiceNow.
Ultimamente sento sempre più spesso discussioni sul classico “make or buy”. Con l’arrivo dei foundation model molti iniziano a chiedersi se abbia ancora senso investire in piattaforme enterprise così ampie oppure se convenga costruire tutto internamente usando Claude, AI Foundry, framework open source, orchestration custom e agenti sviluppati ad hoc.
Secondo me però, se si capisce davvero la direzione verso cui sta andando il mondo, ci si rende conto che costruire tutto questo da zero diventa quasi irrealistico. Perché non stiamo parlando semplicemente di sviluppare chatbot o workflow AI. Stiamo parlando di costruire un layer operativo enterprise fatto di workflow graph, identity, governance, CMDB, operational context, runtime security, orchestration, permissions, observability e integrazione continua tra sistemi distribuiti. E soprattutto stiamo parlando di mantenerlo vivo nel tempo mentre l’azienda evolve continuamente.
È qui che piattaforme come ServiceNow mantengono un valore enorme. Non tanto perché “fanno AI”, ma perché possiedono già gran parte del modello operativo enterprise su cui gli agenti devono lavorare.
Qui si inserisce anche l’evoluzione dell’AI Control Tower, che secondo me è uno degli elementi più strategici annunciati da ServiceNow. L’idea è creare un layer centralizzato di osservabilità, governance e controllo operativo degli agenti AI distribuiti nell’azienda. Non solo gli agenti costruiti dentro ServiceNow, ma anche quelli sviluppati in altri ecosistemi. AI Control Tower serve a capire quali agenti stanno operando, quali workflow stanno eseguendo, quali dati stanno utilizzando, quali permessi possiedono, quali sistemi stanno toccando e quali azioni stanno prendendo.
Ma il punto importante è che non si parla solo di monitoraggio passivo. Se un agente si comporta in modo anomalo, tenta operazioni fuori policy, viene compromesso o diventa vettore di attacco, il sistema deve poter reagire automaticamente. Bloccare workflow, revocare accessi, limitare permessi, isolare agenti, attivare remediation e aprire processi di incident response. Che sia un agente che gira su Microsoft, SAP, o Workday poco importa. In pratica gli agenti iniziano a essere trattati come vere entità operative enterprise, con identità, privilegi, audit trail, comportamento runtime e superfici di attacco proprie. Ed è interessante perché qui ServiceNow entra in uno spazio dove stanno convergendo anche altri vendor, anche se partendo da direttrici completamente diverse. Microsoft arriva soprattutto dal productivity layer. M365, Teams, Copilot, identity, collaboration, developer tooling e Azure stanno convergendo progressivamente verso un unico ecosystem graph enterprise. IBM invece arriva molto più dal mondo middleware, integration, hybrid infrastructure e governance runtime enterprise. Salesforce si muove partendo dal customer graph e dalle customer operations, mentre MuleSoft prova a posizionarsi come integration e orchestration layer distribuito.
ServiceNow però arriva da una posizione diversa rispetto a tutti gli altri. Parte direttamente dal workflow graph enterprise, dal process state, dalle approvals, dal CMDB e dal contesto operativo reale dell’azienda. Ed è probabilmente questo il motivo per cui la piattaforma sembra particolarmente naturale per orchestrare workforce ibride fatte di persone e agenti AI che lavorano sugli stessi processi.
Anche Build Agent va letto in questa chiave. A prima vista potrebbe sembrare semplicemente un tool di sviluppo AI-assisted. In realtà dietro c’è una strategia molto più ampia. L’idea non è imporre un IDE proprietario o un ambiente di sviluppo chiuso. Al contrario, ServiceNow sembra assumere che gli agenti verranno costruiti ovunque, usando modelli diversi, framework diversi e tooling diversi. Ed è qui che entrano in gioco MCP e tutta la logica di interoperabilità. Se gli agenti diventano realmente distribuiti e multi-vendor, allora il problema principale non è più dove vengono sviluppati, ma come vengono collegati ai sistemi enterprise e come vengono governati runtime. Build Agent, MCP e AI Control Tower iniziano quindi a diventare pezzi della stessa architettura. Gli agenti possono essere costruiti ovunque, ma execution, workflow access, permissions, governance e operational behavior vengono ricondotti dentro un layer centrale.
È una dinamica che ricorda molto quello che Kubernetes ha rappresentato per il cloud. Tooling eterogeneo sopra, control plane centralizzato sotto. Ed è probabilmente qui che si sta spostando il vero valore enterprise dell’AI agentica.
Le aziende dovranno fare rewire, non semplicemente adottare AI
L’impressione sempre più chiara è che l’AI agentica non possa essere trattata come una semplice evoluzione tecnologica o come un layer aggiuntivo sopra i processi esistenti. Ne parlavo a pranzo con un partner McKinsey, quello che serve è un vero rewire dell’azienda. Non si parla solo di introdurre nuovi strumenti AI, ma di ripensare operating model, workflow, ruoli, governance, processi decisionali e interazione tra persone e sistemi autonomi. Con una workforce ibrida fatta di persone e agenti, cambia inevitabilmente il modo in cui il lavoro viene eseguito. Alcune attività diventano completamente autonome. Altre vengono supervisionate da persone. Altre ancora vengono ridisegnate attorno a modelli human-agent dove decisioni, orchestrazione ed execution sono distribuite tra sistemi AI e team umani.
Questo tipo di trasformazione non può essere confinato all’IT o a qualche team innovation. Richiede un cambiamento pervasivo che attraversa tutta l’azienda. Tecnologia, processi, organizzazione, governance, operations, sicurezza, sviluppo software, supporto, customer operations e gestione del dato iniziano a convergere dentro un unico modello operativo agentico.
Siamo veramente agli albori di un nuovo modo di costruire un’azienda. Questo passaggio da modello basato su silos verso un modello AI-native (o come Microsoft ama definirlo - Frontier Organisation), richiederà sicuramente tantissimi anni. Tutte le aziende oggi sono costruite con team business separati dall’IT. Dati distribuiti e spesso incoerenti. Processi costruiti intorno alle persone più che intorno ai sistemi. Automazioni locali senza una vera orchestrazione end-to-end. Con gli agenti questo approccio inizia rapidamente a mostrare tutti i suoi limiti.
Per costruire un modello operativo realmente agentico servono alcune fondamenta molto precise. Una roadmap guidata dal business e non da singole sperimentazioni tecnologiche. Una forte evoluzione della workforce, dove competenze software, dati e AI iniziano a convergere anche fuori dall’IT tradizionale. Un operating model progettato per workforce ibride fatte di persone e agenti che lavorano sugli stessi workflow. Architetture moderne e modulari in grado di collegare sistemi distribuiti. Dati semanticamente coerenti, continuamente aggiornati e facilmente consumabili dagli agenti. E soprattutto serve la capacità di ripensare workflow end-to-end. Perché il punto non è semplicemente automatizzare attività esistenti. Il punto è ripensare come il lavoro viene eseguito quando il software inizia a interpretare contesto, prendere decisioni e operare autonomamente sui sistemi enterprise.
Un ringraziamento al team italiano di ServiceNow per l'organizzazione, agli altri partner che ho avuto il piacere di incontrare ed alle belle chiacchierate che mi permettono sempre di acquisire informazioni vitali per svolgere al meglio il mio lavoro.
