Il divertimento del chatbot amichevole è ormai svanito. La maggior parte delle applicazioni di intelligenza artificiale aziendale odierne assomigliano più a stagisti troppo entusiasti che sanno riassumere l'ultima riunione, ma non hanno ancora capito come svolgere il vero lavoro. Abbiamo risolto la conversazione. Ora è il momento di risolvere il lavoro.

In molti consigli di amministrazione e dipartimenti di ingegneria in tutto il mondo, c'è una preoccupazione inespressa. Dopo quasi tre anni di entusiastiche spese per l'IA generativa, la maggior parte delle imprese si trova allo stesso punto: le demo sono brillanti e gli stakeholder sono cautamente ottimisti.

Tutte le principali tecnologie di piattaforma che hanno trasformato il business hanno attraversato scenari simili. Hanno iniziato con una dimostrazione di prova di concetto (PoC), poi una prova o un'implementazione pilota, seguita da un massiccio rollout dell'infrastruttura per supportarla. In definitiva, le aziende ne beneficiano attraverso la trasformazione operativa. Allo stesso modo, l'IA aziendale ha un percorso definito da seguire, mentre entriamo nel rollout dell'infrastruttura di quella che chiamiamo IA agentica.

Nel corso dei miei 10 anni come product lead e architetto in trasformazioni tecnologiche nel settore IT – dai progetti di modernizzazione ERP alla migrazione di applicazioni in ambienti cloud-native – ho visto questo schema ripetersi con ogni grande disruption tecnologica. Coloro che alla fine hanno successo non sono tipicamente quelli con i modelli più avanzati o i budget più grandi per la ricerca sull'IA. Piuttosto, sono quelli che risolvono il problema dell'infrastruttura – le "tubature" al di sotto dell'intelligenza.

Il problema del purgatorio della prova di concetto

Il purgatorio del PoC è dove le cose possono impantanarsi. È il risultato di un difetto architetturale fondamentale. Le imprese hanno creato la loro strategia di IA basandosi su un modello completamente passivo: la generazione aumentata dal recupero (RAG). I sistemi RAG sono piuttosto bravi in un compito: consentire a un grande modello linguistico di avere accesso a una base di conoscenza curata in modo che possa rispondere a domande con un contesto pertinente e aggiornato.

Tuttavia, i sistemi RAG sono incapaci di agire. Non possono avviare attività, pianificare, instradare un compito al sistema corretto, recuperare da un'operazione fallita o prendere decisioni in situazioni ambigue. I sistemi RAG sono semplicemente bibliotecari di riferimento molto intelligenti. Ma le imprese non hanno bisogno di un bibliotecario di riferimento più intelligente; hanno bisogno di operatori capaci. È qui che l'IA agentica può aiutare.

I 3 pilastri dei sistemi agentici di livello produttivo

Man mano che il termine IA agentica diventa sempre più di moda, probabilmente perderà la sua definizione. Un flusso di lavoro agentico è un sistema in cui un modello di IA non si limita a rispondere a un prompt. Invece, persegue un obiettivo attraverso passaggi iterativi, utilizzando le risorse disponibili per creare prodotti intermedi, valutando i risultati intermedi e adattando il modo in cui il modello approccia il problema in base a ciò che il modello ha osservato.

I seguenti sono i tre pilastri che compongono i sistemi agentici di livello produttivo:

1. Framework di orchestrazione

Un framework di ciclo di ragionamento è lo stesso di un framework per il comportamento dell'agente. Potrebbe essere LangGraph, AutoGen o le primitive di utilizzo degli strumenti in fase di sviluppo presso Anthropic, tra alcune altre possibilità. Ognuno di questi framework può essere visto come un modello di esecuzione di agenti multi-step e multi-strumento, garantendo che gli agenti seguano flussi di lavoro prevedibili e auditabili. Una delle decisioni ingegneristiche chiave che le aziende devono prendere è come disporre la topologia del grafo della conoscenza per definire il comportamento dell'agente e le relazioni strutturali tra di essi.

2. Integrazione degli strumenti e gestione dello stato

Un agente improduttivo non sarà diverso da un sofisticato chatbot. Un agente influenza il suo ambiente utilizzando strumenti come API, connettori di database, ambienti di esecuzione del codice e browser web. Il Model Context Protocol sta emergendo come standard de facto per la comunicazione da strumento a modello; esso isola la base di conoscenza di un agente dalle sue azioni.

È solo quando cerchiamo di implementare la gestione dello stato in un'applicazione aziendale che ci rendiamo conto di quanto sia difficile avere un sistema altamente dinamico e distribuito pur mantenendo un framework sottostante agile. Un agente responsabile dell'esecuzione di flussi di lavoro aziendali, che possono richiedere ore o giorni per essere completati, deve archiviare una grande quantità di dati che possono includere risultati di analisi, decisioni aziendali, input dell'utente e messaggi di errore. Quindi, la gestione dello stato è solo un altro aspetto della complessità della progettazione di un buon livello di persistenza per la memoria, le richieste senza sessione, i riavvii degli agenti e la parallelizzazione. Non dovrebbe essere ignorata.

3. Guardrail di sicurezza e progettazione human-in-the-loop

Questa è l'area con più opportunità di semplificazione ed è quindi spesso il luogo dove vengono prese più scorciatoie. È anche spesso la fonte dei primi problemi divulgati pubblicamente. Qualsiasi sistema veramente autonomo necessita di uno spazio di lavoro chiaramente definito con un set di politiche di controllo degli accessi per gli strumenti che coprano almeno i casi d'uso leggibili e scrivibili in cui è richiesta l'approvazione umana prima dell'esecuzione.

Questo è un modello di progettazione, non un meccanismo di recupero dai guasti. L'agente agisce autonomamente finché rimane entro un insieme di limiti di confidenza; il problema si manifesta all'operatore umano quando l'agente si trova al di fuori di tali limiti. Agire autonomamente il più a lungo possibile porta a un comportamento del sistema più affidabile. Inoltre, la fiducia che un'organizzazione ripone in un agente crescerà nel tempo, consentendo all'agente di operare in modo indipendente più a lungo.

Il divario di preparazione organizzativa

Nella mia esperienza, l'ostacolo più coerente al successo dell'implementazione di sistemi aziendali agentici non è l'architettura tecnica, ma piuttosto la mancanza di preparazione organizzativa.

L'IA agentica ha messo in evidenza tutte le ambiguità nella progettazione dei processi aziendali che i dipendenti umani hanno compensato attraverso la conoscenza istituzionale, l'escalation informale e il giudizio contestuale. Un agente non saprà come gestire un'eccezione non definita; seguirà semplicemente le regole che gli sono state date. Se tali regole sono incomplete o contrastanti, l'agente fallirà – spesso in un modo che è sia visibile che costoso.

Le organizzazioni serie sull'implementazione di sistemi aziendali agentici dovrebbero considerare la documentazione dei processi come un requisito per un'implementazione di successo, non come un deliverable.

Una roadmap pratica: dal chatbot all'agente

Le seguenti sono le quattro fasi da seguire durante la transizione da un chatbot a un agente:

Fase 1. Audit

Descrivi dai cinque ai dieci flussi di lavoro aziendali che il chatbot o il sistema RAG supporta. Elenca ogni passaggio del flusso di lavoro aziendale end-to-end, inclusi tutti i sistemi coinvolti, le eccezioni e i punti in cui un essere umano deve intervenire. Questo ti fornisce un elenco di flussi di lavoro aziendali adatti all'automazione dell'agente. Evidenzia anche eventuali passaggi che devono essere affrontati prima che il flusso di lavoro possa essere automatizzato.
Fase 2. Strumentazione

Prima di inviare un agente a fare il suo lavoro "nel mondo reale", ci sono alcune configurazioni da fare correttamente. Queste includono la registrazione delle tracce di tutte le chiamate effettuate agli strumenti, la telemetria sulla latenza e i costi delle decisioni, e un buon set di test unitari e di integrazione per rilevare le regressioni. Se i team non possono vedere l'agente al lavoro in produzione, non saranno mai in grado di debuggarli, migliorarli o fidarsi di essi.
Fase 3. Ambito e sandbox

La prima classe di agenti di produzione dovrebbe essere implementata in un caso d'uso ad ampio raggio ma considerato a basso rischio, perché l'agente eseguirà operazioni di lettura anziché operazioni di scrittura, e i criteri di successo sono strettamente definiti. I seguenti sono esempi di questo tipo di caso d'uso:
- Triage delle richieste di supporto clienti.
- Instradamento di documenti generati dal personale.
- Validazione dei dati rispetto a set di dati noti.
Gli agenti dovrebbero funzionare in modalità "ombra" (shadow mode), dove possono eseguire ma non sono vincolati ai passaggi successivi se prendono una decisione errata. Questa metodologia è cruciale per la convalida e l'affinamento prima di un'implementazione completa e autonoma.