Per vent’anni, la gestione operativa del software si è basata su una domanda: il sistema è guasto?
Siamo diventati molto bravi a rispondere. Metriche, log e tracce. Sistemi di tracciamento distribuito capaci di seguire una singola richiesta attraverso decine di servizi.
Tutto questo si fonda su un presupposto ragionevole: quando un software non funziona correttamente, prima o poi il problema si manifesta attraverso qualcosa che una macchina può misurare.
Immaginiamo ora un agente AI che gestisce richieste di rimborso. Risponde in 600 millisecondi. Il tasso di errore è pari a zero. Ma comunica a un cliente che ha diritto a un rimborso di 40 dollari, quando in realtà gliene spettano 140, perché il documento che ha recuperato risale al trimestre precedente.
Tutti gli indicatori sulle dashboard sono verdi. Nulla sembra non funzionare.
Eppure, il risultato è sbagliato.
La correttezza va misurata a livello di esecuzione.
Il software ha sempre potuto produrre risultati errati. Ciò che cambia con gli agenti AI è la quantità di comportamenti rilevanti che vengono determinati durante l’esecuzione stessa del software.
Un agente introduce un ulteriore insieme di variabili. Lo stesso agente, eseguendo lo stesso codice, può rispondere correttamente a una richiesta e sbagliare quella successiva. Il risultato dipende da come è stata formulata la domanda, dal contesto recuperato, dal percorso seguito attraverso gli strumenti disponibili e da ciò che il modello ha generato.
Di conseguenza, alla domanda “sta facendo la cosa giusta?” non è più possibile rispondere completamente prima del rilascio del software. Una parte della risposta deve arrivare dall’ambiente di produzione, in modo continuo, attraverso le stesse esecuzioni.
Questo non sostituisce le domande a cui l’osservabilità ha sempre risposto. Ne aggiunge di nuove.
Il lavoro era di buona qualità?
La suite di test eseguita prima del rilascio continua a essere importante e ora può essere affiancata da misurazioni effettuate in tempo reale. L’agente ha selezionato lo strumento corretto? Ha indirizzato la richiesta nel modo appropriato? Quando queste valutazioni vengono associate alla stessa traccia della latenza e del numero di token, un team può verificare che una modifica al prompt non ha rallentato il sistema, ma ha peggiorato sensibilmente la qualità delle risposte ottenute.
Ciò introduce un secondo problema: la qualità deve essere definita in modo sufficientemente esplicito da poter essere misurata.
Le organizzazioni umane possono operare facendo affidamento su una quantità sorprendente di giudizi impliciti. Le persone imparano a riconoscere una buona risposta dagli esempi, dai colleghi e dall’esperienza. Non tutto deve necessariamente essere formalizzato.
Un valutatore, invece, ha bisogno di criteri più concreti. Cosa si intende per decisione corretta in materia di rimborso? Quando l’agente dovrebbe segnalare il caso a un livello superiore?
Costruire sistemi di valutazione costringe quindi i team a trasformare parte di questo giudizio implicito in una definizione operativa di “corretto”. Nella pratica, decidere che cosa misurare può essere utile quanto la misurazione stessa.
In quale punto della catena si è verificato l’errore?
Torniamo all’esempio del rimborso errato. Forse il modello ha seguito un ragionamento sbagliato. Oppure ha fatto tutto correttamente, ma un servizio di pagamento, collocato tre passaggi più avanti nella catena, utilizzava una configurazione obsoleta.
Il team incaricato di analizzare il problema deve poter seguire un’unica catena di cause ed effetti, dalla domanda del cliente alle decisioni dell’agente, fino ai servizi sottostanti. Gli agenti stanno diventando componenti integrati nelle applicazioni, quindi il loro comportamento deve essere osservabile insieme a quello del resto del sistema.
Che cosa distingue le esecuzioni errate?
Le dashboard rimangono utili perché rendono costantemente visibili i segnali più importanti. Sono particolarmente efficaci quando un team sa già quali elementi intende monitorare.
I sistemi agentici introducono domande importanti che potrebbero emergere soltanto dopo il verificarsi di un evento insolito. Perché questa settimana è diminuita l’accuratezza dei rimborsi per i clienti europei? È cambiato qualcosa nel recupero delle informazioni, nella selezione degli strumenti o nei servizi a valle?
La possibilità di porre direttamente queste domande e lasciare che il sistema di osservabilità raccolga i dati di telemetria pertinenti cambia il modo in cui può iniziare un’indagine.
La correzione ha realmente funzionato?
Un’esecuzione errata in produzione non deve necessariamente concludersi con una segnalazione di incidente. Le tracce delle esecuzioni in cui un agente ha commesso un errore possono diventare un dataset. Un team può sperimentare una modifica utilizzando quegli esempi, confrontare la nuova versione con quella precedente, distribuirla e verificare successivamente se il comportamento in produzione sia effettivamente migliorato.
Si crea così un collegamento molto più stretto tra la gestione operativa di un agente e il suo sviluppo. Le stesse evidenze utilizzate per comprendere un errore diventano parte del test necessario a verificare che sia stato corretto.
Una maggiore autonomia richiede maggiori evidenze
Gli agenti acquisiscono più valore man mano che assumono maggiori responsabilità. Ciò che frena le organizzazioni è la capacità di rispondere ad alcune semplici domande: che cosa ha fatto l’agente? Ha agito correttamente? Ce ne accorgeremmo se la situazione cambiasse?
L’autonomia tende a essere concessa gradualmente, proprio come avviene con un nuovo collega. Inizialmente, ogni azione deve essere approvata. Successivamente, soltanto quelle insolite. Poi si passa alla revisione di un campione di attività. Infine, il lavoro viene controllato a posteriori.
La sicurezza segue una logica analoga. Le autorizzazioni continuano a definire i limiti entro cui un agente può operare: se non è autorizzato a emettere rimborsi, non potrà farlo. Ma le autorizzazioni descrivono ciò che è possibile, non se una determinata scelta sia corretta. Una policy può stabilire che l’agente sia autorizzato a concedere rimborsi. Non può però determinare se quello specifico rimborso, a quel cliente e per quell’importo, sia giusto. Una parte sempre maggiore di ciò che conta avviene all’interno di questi limiti. E il modo per comprenderla è lo stesso utilizzato per valutare la qualità: osservare ciò che è realmente accaduto.
In sintesi, il livello di autonomia che un’organizzazione può affidare con fiducia ai propri agenti dipende dalla chiarezza con cui riesce a osservarne il comportamento.
Il rapporto tra autonomia e controllo potrebbe diventare dinamico
Oggi, la decisione su quanta autonomia concedere a un agente viene ancora presa prevalentemente dalle persone. Guardando al futuro, tuttavia, questo rapporto non deve necessariamente rimanere statico. Se gli indicatori di qualità sono disponibili in tempo reale, l’autonomia potrebbe aumentare man mano che un agente accumula un track record e ridursi quando la qualità peggiora, fino a quando non ne siano state comprese le cause. Non siamo ancora arrivati a questo punto, ma stanno iniziando a emergere gli elementi necessari per costruire sistemi di questo tipo.
È in questa direzione che si stanno evolvendo anche le tecnologie di osservabilità. In AWS, ad esempio, abbiamo recentemente introdotto Amazon CloudWatch Omni, con l’obiettivo di integrare il monitoraggio degli agenti AI con quello delle applicazioni e delle infrastrutture e di utilizzare le informazioni raccolte durante le esecuzioni per valutare la qualità dei risultati e contribuire al miglioramento continuo dei sistemi.
Considerazioni finali
Per le attività con conseguenze più rilevanti, molti agenti già utilizzati in produzione richiedono ancora l’approvazione umana prima di compiere azioni importanti. Man mano che raccogliamo evidenze sull’affidabilità del comportamento di questi sistemi, una parte crescente delle attività potrà passare dall’approvazione preventiva alla revisione, al controllo a campione e alla gestione delle eccezioni.
Tutto ciò che abbiamo imparato a osservare fino a oggi rimane importante. Gli agenti operano attraverso servizi, database, reti, code e infrastrutture e tutti questi sistemi devono continuare a essere monitorati e compresi quando qualcosa non funziona.
A questo si aggiunge però una nuova serie di domande. Oltre a comprendere se un sistema stia funzionando come previsto, dobbiamo sempre più spesso capire se il lavoro che sta svolgendo sia effettivamente di qualità.
I team capaci di rispondere a entrambe le domande potranno affidare ai propri agenti maggiori responsabilità con maggiore fiducia.
