Le banche che collegano agenti AI nei processi di onboarding, pagamenti e altre attività operano su una rete complessa di sistemi interconnessi. Ogni agente, che può essere costruito su piattaforme diverse e operare con permessi differenti, deve trasmettere le informazioni in modo preciso e affidabile. La sfida principale di QA è quindi dimostrare che tali agenti non solo funzionano in isolamento, ma che il flusso complessivo rispetta i requisiti di sicurezza, governance e compliance.

Il ruolo emergente di IBM watsonx Orchestrate

IBM ha recentemente ampliato le capacità di watsonx Orchestrate, ponendo un quesito pratico per i team di testing dei servizi finanziari: come garantire un processo quando gli agenti coinvolti sono costruiti su piattaforme diverse, operano con permessi differenti e passano lavoro tra di loro?

Nel suo annuncio del 2 ottobre, IBM ha presentato capacità preliminari per scoprire e importare agenti da Microsoft Foundry e Google Gemini Enterprise Agent Platform, oltre all’integrazione esistente con Amazon Bedrock. Ha inoltre annunciato funzionalità di identità agenti in anteprima e caratteristiche di valutazione in produzione che sono diventate disponibili a partire dal 30 settembre.

Per i leader di ingegneria della qualità, queste evoluzioni indicano un problema di testing più ampio. Un agente può produrre una risposta accettabile in isolamento, ma il processo in cui è inserito può ancora gestire male la richiesta di un cliente, ripetere un’azione o proseguire senza approvazione. L’orchestrazione, cioè la coordinazione di compiti, sistemi, agenti e persone, offre un modo per gestire quella complessità, ma la sfida di QA è verificare che la coordinazione stessa si comporti come previsto.

Testing dei passaggi di consegna

Consideriamo un ipotetico processo di onboarding di un cliente. Un agente estrae le informazioni dai documenti, un altro verifica la presenza dei dati richiesti, e un terzo prepara il caso per la revisione. I servizi convenzionali eseguono controlli di identità e aggiornano il record del cliente.

Ogni componente potrebbe superare i propri test, ma l’intero flusso di lavoro potrebbe ancora allegare le informazioni al cliente sbagliato, considerare un controllo incompleto come riuscito o continuare dopo che un revisore ha rifiutato il caso. Il compito di QA è quindi testare il significato e le conseguenze di ogni consegna, inclusi i presupposti che il componente ricevente abbia sui dati ricevuti.

L’approccio di Camunda

Camunda illustra come queste forme diverse di esecuzione possono essere combinate. La sua documentazione descrive l’orchestrazione di agenti AI all’interno di flussi di lavoro utilizzando il modello Business Process Model e Notation (BPMN), unendo compiti umani, regole fisse e decisioni guidate dall’IA in un unico processo.

Per una banca, ciò crea una struttura potenziale per separare le attività in cui l’IA ha la discrezione da quelle che richiedono una decisione prescritta o un'approvazione. Se le frontiere rimangono intatte in caso di errore, informazioni in conflitto o comportamento inatteso dell’agente, resta una questione di testing.

Un passaggio di approvazione visibile in un diagramma di processo è solo l’inizio. I team di assurance devono dimostrare che un agente non possa raggiungere la stessa azione protetta tramite un altro strumento, che un rifiuto blocchi l’esecuzione successiva e che un’approvazione scaduta non sia riutilizzata.

Permessi e recupero

La preview di identità di IBM affronta una preoccupazione correlata. L’azienda afferma che gli agenti possono ricevere identità distinte, con accesso limitato ai loro compiti e record di audit che collegano l’utente richiedente, l’agente in azione e lo strumento chiamato. Queste sono capacità di controllo proposte, piuttosto che evidenza che una particolare implementazione bancaria sia sicura.

Per i tester, gli scenari corrispondenti includono credenziali revocate, token scaduti e tentativi di invocare strumenti al di fuori del ruolo consentito dall’agente. Il risultato previsto deve coprire sia l’azione bloccata sia lo stato del processo circostante.

Il recupero merita attenzione simile. Se un servizio accetta un’istruzione ma la conferma viene persa, un tentativo di ritentare può diventare pericoloso. In un flusso di pagamento, il test dovrebbe dimostrare che il sistema può determinare se un’azione è già avvenuta prima di tentarla di nuovo.

Ciò richiede più di misurare se un agente completi infine il compito assegnato. Le squadre di QA devono ispezionare azioni intermedie, modifiche ai dati condivisi e le condizioni in cui l’esecuzione si interrompe.

Seguire il sentiero di esecuzione

Una ricerca pubblicata a marzo offre un approccio. In un preprint su arXiv, Ciprian Paduraru, Petru‑Liviu Bouruc e Alin Stefanescu hanno proposto un framework di assurance basato sul tracciamento per l’orchestrazione agentica. Registra messaggi e azioni contro requisiti espliciti a singoli passaggi e attraverso l’esecuzione.

I risultati evidenziano fallimenti come non terminazione, drift di ruolo e propagazione di affermazioni non supportate. Il loro framework incorpora anche iniezione di guasti a livello di servizio, recupero e confini della memoria, nonché controlli che possono consentire, riscrivere o bloccare azioni durante l’esecuzione.

"I fallimenti non si limitano a output finali errati", afferma Paduraru. "La proposta è un framework di ricerca, non uno standard bancario, ma è rilevante per i servizi finanziari in quanto rende disponibile il percorso attraverso un processo per l’ispezione, incluso dove si è verificato il primo fallimento e se i suoi effetti sono stati contenuti."

Evidenza di esecuzione da piattaforme commerciali

Le piattaforme commerciali si stanno anche orientando verso una evidenza di esecuzione più dettagliata. L’annuncio di IBM di settembre ha descritto Trace Inspector, che espone il percorso di esecuzione e le chiamate agli strumenti di un agente in esecuzione, e criteri di valutazione personalizzati per casi d’uso specifici.

Ciò supporta l’investigazione, ma il metodo di valutazione resta cruciale. Le ultime capacità in produzione di IBM utilizzano modelli linguistici per giudicare l’attività dell’agente campionata contro misure di qualità. Queste valutazioni possono aiutare le squadre a monitorare le risposte; i leader di QA dovrebbero stabilire separatamente come le regole di transazione, i permessi e i requisiti di approvazione siano verificati.

Assicurare gli agenti di testing

Le stesse domande di orchestrazione stanno raggiungendo la funzione di testing. UiPath descrive Test Cloud come un coordinatore di agenti AI, automazione e umani lungo l’intero ciclo di vita del test, con tracce di esecuzione e accesso basato sui ruoli.

Questa introduzione di un’area di assurance indipendente significa che se un agente crea i test e un altro li interpreta, il team deve capire se un’asserzione errata si sia propagata attraverso entrambe le fasi.

Le modifiche automatizzate ai test dovrebbero mantenere una spiegazione revisionabile di cosa è cambiato e quale requisito è ancora coperto.

Un approccio pratico per i leader di QA

Per i leader di QA dei servizi finanziari, un punto di partenza utile è un flusso di lavoro materiale con conseguenze aziendali chiare. Mappate le consegne, identificate le azioni che modificano i record o spostano denaro, e specificate dove l’esecuzione deve fermarsi o fermarsi. Quindi testate servizi degradati, input in conflitto, esecuzioni interrotte e approvazioni fallite rispetto a tali aspettative.

La prova di rilascio dovrebbe mostrare cosa ha fatto il flusso di lavoro, quali controlli sono stati applicati e come le eccezioni sono state risolte. Un punteggio di completamento da solo non può rispondere a tali domande.

L’opportunità emergente per le piattaforme di orchestrazione

L’opportunità emergente per le piattaforme di orchestrazione è rendere l’esecuzione complessa più gestibile e osservabile. Per i team di assurance bancaria, la prova consiste nel verificare se questa visibilità può supportare prove convincenti che l’intero processo rimanga entro i confini autorizzati.

In definitiva, la sfida QA nelle banche non è più solo verificare la correttezza delle singole componenti, ma garantire che l’intero ecosistema di agenti AI, sistemi e controlli umani funzioni in armonia, rispettando permessi, approvazioni e recupero in modo affidabile e tracciabile.