Leader di pensiero
Il tuo prossimo utente software sarà un agente IA. La tua architettura è pronta?

Immagina un agente IA che gestisce una contestazione relativa alla fatturazione di un cliente. Legge il reclamo, controlla lo storico del conto e stabilisce che è opportuno concedere un accredito. Il tutto in pochi secondi.
Impressionante. Ora chiedigli di effettuare davvero l’accredito.
Il contratto con il cliente si trova in un altro sistema. Le regole di approvazione sono sepolte nel codice dell’applicazione. Lo strumento di fatturazione richiede che una persona faccia clic su diverse schermate.
L’agente sa cosa deve fare, ma l’architettura non gli consente di portare a termine il lavoro.
È il problema che mi aspetto incontreranno sempre più aziende man mano che l’IA agentica entra in produzione. Eppure, la cosa sorprendente è che l’ostacolo che impedisce di completare l’attività ha ben poco a che fare con l’intelligenza dell’agente.
Per anni abbiamo modernizzato il software aziendale per le persone che lo utilizzano. Ora dobbiamo modernizzarlo per gli agenti che lo gestiranno sempre più spesso.
L’interfaccia utente non è mai stata l’intero prodotto
Pensiamo a come funziona oggi il software aziendale. Le persone aprono applicazioni, consultano dashboard, prendono decisioni e trasferiscono il lavoro da un sistema all’altro. L’interfaccia utente è il modo in cui interagiscono con l’azienda.
Un agente non ha necessariamente bisogno di quelle schermate. Può recuperare informazioni e avviare operazioni tramite API, server Model Context Protocol (MCP) e altre interfacce programmabili. È uno degli aspetti della transizione verso un’architettura headless.
Ma headless non significa che l’applicazione scompaia. I suoi dati, le regole aziendali, le autorizzazioni e i requisiti di conformità continuano a essere importanti. Anzi, direi che lo sono ancora di più.
Per anni, i fornitori di software hanno costruito vantaggi competitivi puntando su interfacce utente curate, abitudini degli utenti e costi di riqualificazione del personale. Questi vantaggi si riducono quando gli agenti svolgono più attività senza aprire l’interfaccia utente dell’applicazione. Acquistano invece maggiore valore i sistemi di riferimento sottostanti: dati affidabili, logica di dominio convalidata, governance operativa e transazioni verificabili.
C’è anche una conseguenza commerciale: entro il 2030, fino a 234 miliardi di dollari di spesa per applicazioni aziendali potrebbero essere esposti alle perturbazioni causate dall’IA agentica. Si tratta di spesa a rischio di perturbazione, non di spesa destinata a scomparire. Inoltre, quando gli agenti svolgono attività che prima venivano eseguite dalle persone nelle dashboard, i modelli tariffari per postazione potrebbero essere sostituiti sempre più spesso da modelli basati sull’utilizzo, sulle azioni o sui risultati.
Per i fornitori di software, è una sfida al modello di business. Per le aziende che fanno affidamento sulle loro applicazioni, è una sfida architetturale.
Abbiamo modernizzato i singoli componenti, non il flusso di lavoro
La maggior parte delle aziende porta avanti da anni progetti di modernizzazione. Un team aggiorna le applicazioni legacy. Un altro riunisce dati frammentati in una piattaforma moderna. Un terzo sviluppa integrazioni o si limita a rinnovare l’interfaccia utente.
Ciascun progetto può riuscire per conto proprio. I problemi iniziano quando un agente deve eseguire un flusso di lavoro che coinvolge tutti questi elementi.
Puoi fornire a un agente informazioni accurate sui clienti, ma se l’applicazione incaricata di agire sulla base di quelle informazioni mantiene regole essenziali sepolte nel codice legacy, cosa succede? Oppure puoi esporre un’API ben progettata, mentre i dati sottostanti restano incoerenti. L’agente può agire, ma puoi fidarti della decisione?
In entrambi i casi, abbiamo modernizzato parti della tecnologia senza modernizzare il lavoro.
All’IA agentica non interessa quale progetto di modernizzazione abbia avuto successo. Le interessa che funzioni l’intero flusso di lavoro.
Ecco come si traduce nella pratica. Un cliente doveva accelerare la preparazione dei preventivi per riparazioni complesse di motori, per le quali i contratti stabiliscono quali componenti possono essere riparati, sostituiti o revisionati. Ogni preventivo richiedeva giorni, a volte settimane, di ricerche manuali tra contratti e manuali di manutenzione. Il cliente aveva già modernizzato la propria piattaforma dati, ma i preventivi non venivano preparati più rapidamente, perché il collo di bottiglia non erano mai stati i dati. Era la ricerca. Abbiamo riprogettato quel flusso di lavoro attorno a una suite di agenti di ricerca, ridotto dell’80% il tempo dedicato alle ricerche e i preventivi hanno iniziato a essere preparati a una velocità del tutto diversa.
Ecco perché la modernizzazione delle applicazioni e quella dei dati non possono essere pianificate come due flussi di lavoro indipendenti. L’architettura deve supportare il risultato aziendale complessivo.
Un’API non rende un sistema pronto per gli agenti
Si potrebbe essere tentati di pensare che la soluzione sia semplice: esporre gli endpoint, collegare l’agente e il gioco è fatto.
Magari fosse così facile.
Recuperare informazioni è una cosa. Emettere un accredito, aggiornare un documento contabile o ordinare un ricambio è tutt’altra cosa. Qui si parla di esecuzione, non solo di accesso.
È qui che uso il termine superficie di controllo degli agenti: l’interfaccia circoscritta e regolamentata attraverso la quale gli agenti leggono e scrivono nei sistemi di riferimento.
Le API e i server MCP possono mettere strumenti e dati a disposizione degli agenti. Ma MCP non applica automaticamente le regole aziendali né stabilisce chi è autorizzato ad agire. Questi controlli devono comunque essere progettati e integrati nei sistemi e nei flussi di lavoro sottostanti.
L’agente può recuperare dati autorevoli? Le regole aziendali sono esplicite e vengono applicate in modo coerente? Può consigliare un’azione, ma eseguire solo quelle che è autorizzato a compiere? Se qualcosa va storto, possiamo ricostruire l’azione, gestire l’eccezione e, quando possibile, annullarla?
Non sono problemi che un modello migliore possa risolvere da solo. Riguardano il flusso di lavoro, la progettazione delle applicazioni, l’architettura dei dati, l’integrazione e la governance. E vanno affrontati tutti insieme.
Partire dal lavoro, non dalla tecnologia
Da dove cominciare, allora?
Non comincerei rendendo prive di interfaccia utente tutte le applicazioni né esponendo tutte le API disponibili. Partirei da un flusso di lavoro aziendale significativo.
Seguitelo dall’inizio alla fine. Quali sistemi contengono i dati? Dove si trova la logica aziendale? Di quali dati può fidarsi l’agente? Quali decisioni richiedono l’approvazione umana? Che cosa succede se un sistema si guasta a metà del processo? Come viene mantenuta la governance?
Individuerete le lacune più importanti. Questa è la vostra roadmap di modernizzazione: un piano coordinato di attività per applicazioni, dati, integrazioni e controlli, guidato da un risultato aziendale anziché da progetti tecnologici scollegati tra loro.
E misurate i progressi di conseguenza: non in base al numero di API esposte o alla quantità di dati migrati, ma valutando se il flusso di lavoro si completa in modo affidabile, come vengono risolte le eccezioni e se i risultati aziendali migliorano.
L’obiettivo non è rendere tutto autonomo, ma garantire un’esecuzione affidabile e degna di fiducia, lasciando spazio al giudizio umano dove serve.
Il vero cambiamento va oltre l’assenza di interfaccia
Ciò che mi entusiasma non è eliminare le dashboard, ma quello che accade quando le persone non devono più trasferire manualmente il lavoro da un sistema scollegato all’altro per portare a termine le attività.
Ma non ci arriveremo sovrapponendo un agente a un’architettura che non è mai stata progettata per accoglierlo.
La prossima generazione di software aziendale non sarà definita soltanto da ciò che permette alle persone di vedere, ma anche da ciò che consente agli agenti di fare, in modo affidabile e responsabile.











