Sushil Kumar, CEO di Cyara – Serie di Interviste

Sushil Kumar, CEO di Cyara è un dirigente esperto di software aziendale e imprenditore con oltre 25 anni di leadership nell’intelligenza artificiale, DevOps, infrastruttura cloud, strategia di prodotto e test del software. È entrato in Cyara come CEO nel dicembre 2025, dopo aver ricoperto il ruolo di cofondatore e CEO di RelicX.ai, dove ha costruito una piattaforma di automazione dei test basata su IA generativa e intenti, successivamente acquisita da Harness. Ha poi guidato l’integrazione della tecnologia di RelicX in Harness e contribuito a definire la sua strategia di Automazione dei Test IA. All’inizio della sua carriera, Kumar è stato General Manager di DevOps presso Broadcom, Senior Vice President of Products presso CA Technologies, e ha trascorso più di 16 anni in Oracle, dove ha ricoperto ruoli di senior product leadership e ha aiutato a scalare importanti business di software enterprise. In tutti questi ruoli si è concentrato sulla costruzione e scalabilità di piattaforme IA, cloud, DevOps e di automazione per grandi imprese. La sua nomina in Cyara è mirata ad espandere le capacità di garanzia dell’esperienza cliente potenziate dall’IA e la presenza globale dell’azienda.

Cyara è un’azienda di garanzia dell’esperienza cliente che aiuta le imprese a testare, monitorare e convalidare le interazioni con i clienti attraverso canali vocali, digitali, di messaggistica e di IA conversazionale. La sua Cyara Agentic Platform è progettata per affrontare le crescenti sfide create dalle esperienze cliente guidate dall’IA, inclusi il testing di agenti IA non deterministici, il rilevamento di allucinazioni e deriva comportamentale, la convalida della conformità, il monitoraggio dei sistemi di produzione e la valutazione dei percorsi cliente end‑to‑end. La piattaforma combina test di agenti IA, monitoraggio della produzione, garanzia voce e telecomunicazioni, test dei canali digitali e osservabilità CX, supportando oltre 350 milioni di percorsi cliente all’anno su una presenza globale che copre più di 140 paesi. Man mano che le imprese distribuiscono agenti IA sempre più autonomi nei flussi di lavoro a contatto con i clienti, Cyara posiziona la sua tecnologia come strato di garanzia per valutare se tali sistemi si comportano in modo affidabile, sicuro e coerente prima e dopo il deployment.

Hai dedicato gran parte della tua carriera alla costruzione e alla scalabilità di software aziendali, da Oracle e CA/Broadcom alla fondazione di Relicx e ora alla guida di Cyara. In che modo questa esperienza ha plasmato la tua visione secondo cui gli agenti IA dovrebbero essere gestiti meno come software tradizionali e più come membri di una forza lavoro?

Ho trascorso la maggior parte della mia carriera a costruire e scalare software enterprise, e la disciplina che abbiamo sviluppato lì era incentrata su sistemi deterministici. Sai cosa dovrebbe fare il software. Lo verifichi rispetto a quella aspettativa. Quando si guasta, ti segnala: un errore, una transazione fallita, un avviso.

Gli agenti IA non funzionano così. Sono non deterministici, quindi lo stesso input può seguire percorsi diversi. Ancora più importante, possono agire per conto dell’azienda. Prendono impegni: rimborsi, politiche, promesse. E quando uno di questi è errato, nulla si rompe. Una risposta sbagliata suona esattamente come una corretta. La transazione ha successo, il cruscotto rimane verde e il cliente si allontana con qualcosa che l’azienda non ha mai accettato.

Quando il software può prendere decisioni e impegni, e può sbagliare senza avvisarti, necessita di un modello operativo diverso.

Ecco dove il paragone con la forza lavoro trova valore. Non gestisci un dipendente scrivendo uno script per ogni decisione che prenderà. Gli assegni un ruolo, stabilisci l’autorità che ne deriva e la espandi man mano che la guadagna. Un agente si comporta allo stesso modo all’interno della stessa struttura.

La mia interpretazione è che l’autonomia non sia una decisione di deployment. È una serie di promozioni. Un agente guadagna ciascuna dimostrando di saper svolgere il lavoro, rimanere entro la propria autorità e riconoscere quando ha bisogno di aiuto.

Come appare concretamente un modello operativo \”simile a HR\” per gli agenti IA all’interno di un’impresa, e quali elementi dovrebbero le aziende implementare per primi?

Inizia dal ruolo. Ogni agente dovrebbe avere una sorta di descrizione del lavoro prima di avvicinarsi alla produzione. Qual è il suo obiettivo, quali informazioni sono autoritative per lui, quali dati cliente può utilizzare, quali decisioni può prendere autonomamente e dove termina la sua responsabilità. Se un’azienda non riesce a scriverlo in un paragrafo, l’agente non è pronto per un ruolo. È pronto per una dimostrazione.

Da quel ruolo derivano quattro elementi, e l’ordine è importante. Evidenza prima del lancio, cioè dimostrare che l’agente può svolgere il lavoro in condizioni che somigliano al mondo reale anziché a un test controllato. Supervisione durante l’esecuzione, così da sapere cosa ha effettivamente fatto l’agente e non solo se il sistema ha risposto. Gate di promozione, in modo che più autorità venga concessa quando ci sono prove a supporto e non prima. E un responsabile nel business, non in ingegneria, che sia responsabile di ciò che quell’agente è autorizzato a fare.

Se l’ordine è sbagliato, il resto non regge. Se la responsabilità è vaga, è impossibile dimostrare una buona performance, così come il fallimento. Il ruolo viene prima, e l’evidenza segue.

Se a un agente IA viene assegnato un ruolo specifico, come dovrebbero le organizzazioni definire le sue responsabilità, autorizzazioni e confini prima di consentirgli di interagire con i clienti o con sistemi critici?

Il ruolo indica a cosa serve l’agente. Le autorizzazioni indicano a cosa può accedere. Sono due conversazioni diverse e le aziende tendono ad avere solo la prima.

Sii esplicito su tre aspetti. Quali sistemi e dati l’agente può toccare, e in quale direzione, perché leggere un record cliente e modificarlo non sono la stessa autorizzazione. A cosa può impegnarsi autonomamente, dove risiedono denaro e responsabilità: un rimborso, un credito, un’eccezione alla politica. E cosa costringe a un trasferimento, sia i casi che puoi nominare in anticipo sia il segnale che l’agente è uscito dalla sua competenza.

Non si tratta di decisioni da delegare al team tecnologico. Sono loro a determinare il rischio che l’azienda sta assumendo. Le persone responsabili dell’esperienza cliente e dell’esposizione alla conformità devono avere voce in capitolo su dove tracciare queste linee, e di solito sono le ultime a essere consultate.

Poi devi dimostrare che l’agente rimane entro tali limiti. L’obiettivo non è eliminare ogni possibile errore. Ci saranno errori. La questione è se l’agente comprende i propri confini, sa quando fermarsi e può svolgere il compito assegnato senza generare conseguenze altrove nel percorso del cliente.

Sostieni che una maggiore autonomia dovrebbe essere guadagnata piuttosto che concessa fin dall’inizio. Cosa dovrebbe dimostrare un agente IA prima che un’impresa ampli il campo delle azioni che può compiere in modo indipendente?

Ora è facile costruire un agente IA. La parte difficile è dimostrare che merita l’autonomia.

Prima di ampliare ciò che un agente può fare autonomamente, un’impresa ha bisogno di prove che svolga il compito assegnato in modo costante e rimanga entro i propri limiti. Ciò significa come gestisce le situazioni previste e anche quelle non anticipate. Un agente può apparire efficace in condizioni controllate e comportarsi diversamente quando il contesto o i sistemi circostanti cambiano.

Un cliente può iniziare con una semplice domanda di fatturazione e diventare frustrato dopo un pagamento fallito. L’agente deve riconoscere questo cambiamento mentre avviene e modificare rotta, invece di proseguire sul percorso con cui è stato validato.

Tre aspetti dovrebbero essere veri prima che l’autorità si espanda. L’agente svolge il lavoro in condizioni reali, non solo in quelle ideali. Conosce i limiti della propria competenza e si ferma lì. E qualcuno può fornire le prove per entrambi su richiesta.

Il livello di prova deve corrispondere al livello di autonomia. Decisioni minori, prove leggere. L’accesso a un sistema di pagamento o la capacità di impegnare l’azienda in un’eccezione di politica richiedono criteri notevolmente più elevati.

Come dovrebbero le aziende valutare continuamente le prestazioni degli agenti IA una volta distribuiti, soprattutto quando la qualità delle loro decisioni non può essere catturata solo dalle metriche tradizionali di test del software?

Qui il pensiero tradizionale sul software si infrange. Con il software deterministico si verifica se qualcosa è passato o fallito. Con un agente IA si può ottenere una risposta di successo dal sistema e avere comunque un’interazione cliente fallita.

Quindi si valuta il risultato, non la risposta. L’agente ha capito cosa il cliente stava cercando di ottenere? Ha usato le informazioni corrette? Ha completato il percorso? È rimasto entro i propri limiti e ha effettuato l’escalation quando era necessario?

Le valutazioni di base, che confrontano le risposte con un set di riferimento, rappresentano il minimo. Ogni azienda ne avrà. Le dimensioni che determinano se un cliente continua a fidarsi di te sono quelle sottostanti: conformità, bias, uso improprio e come l’agente si comporta con chiamanti reali, i loro accenti, il rumore di fondo, il telefono economico, l’interruzione a metà frase. Nella voce questo conta più di quanto ci si aspetti, perché ogni punteggio è basato su una trascrizione. Se lo strato vocale fraintende la domanda, l’agente risponde a una domanda che nessuno ha posto.

Vale la pena riflettere sull’aritmetica. Un punteggio del 99 % in valutazione sembra eccellente. Con un milione di conversazioni all’anno, ciò corrisponde a diecimila fallimenti.

Due principi rimangono validi. La validazione dovrebbe essere indipendente dall’agente e dalle piattaforme di modello. Non costruiamo gli agenti noi stessi, ed è per questo che posso affermare chiaramente che nessun fornitore dovrebbe giudicare la propria IA. Lo standard è costituito dalle politiche interne dell’impresa, dagli impegni verso i clienti e dagli obblighi normativi, non da una scheda di valutazione del fornitore.

E ogni guasto in produzione dovrebbe diventare un checkpoint. Non un ticket, non un elemento di backlog. Un test che l’agente deve superare prima che la prossima release venga distribuita. Se un problema si verifica in produzione e non si trasforma in qualcosa che l’agente deve superare, paghi per scoprire lo stesso problema due volte.

Fiducia e governance sono sempre più citate come ostacoli principali alla scalabilità dell’IA agentica. Ritieni che la tecnologia stia avanzando più rapidamente della capacità delle imprese di supervisionarla, e quali rischi ciò comporta?

Penso che sia esattamente quello che sta accadendo, e il divario è strutturale piuttosto che dovuto a una mancanza di impegno. Un’idea può diventare un agente a contatto con il cliente in poche settimane. La disciplina operativa intorno a quell’agente, la proprietà, le prove, la supervisione, richiedono molto più tempo, perché coinvolgono persone e responsabilità, non solo software.

Il rischio è che il divario rimanga invisibile mentre si amplia. Un agente può fornire a un cliente una risposta errata con sicurezza, senza alcun errore, senza transazione fallita e senza alcun avviso. Ogni cruscotto appare verde. Le operazioni tradizionali dipendono dal fatto che i sistemi ti segnalino quando hanno problemi, e gli agenti non lo fanno in modo affidabile.

Non penso che la risposta sia rallentare. Le aziende che vinceranno qui si muoveranno rapidamente. La risposta è costruire le prove e la supervisione che ti consentano di muoverti velocemente con fiducia. Più autonomia riceve un agente, più prove sono necessarie per dimostrare che possa assumersi la responsabilità.

Quando un agente autonomo prende una decisione sbagliata, chi dovrebbe essere in ultima analisi responsabile: lo sviluppatore, l’unità aziendale che lo implementa, il fornitore del modello o il dirigente che ne ha approvato l’uso?

In definitiva, l’azienda che implementa l’agente possiede il risultato. Diverse parti sono coinvolte nella costruzione e nell’operatività del sistema, ma il cliente non ha alcuna relazione con il fornitore del modello. Il cliente ha una relazione con l’azienda il cui nome appare nell’interazione.

Ciò non significa che la responsabilità ricada su una sola persona. Essa scorre lungo la catena decisionale. Lo sviluppatore è responsabile di come è stato costruito il sistema. L’azienda decide cosa l’agente è autorizzato a fare. Il fornitore è responsabile della tecnologia che fornisce. La leadership è responsabile di garantire che l’azienda disponga dei controlli e della supervisione necessari per gestire il rischio in ogni caso.

L’errore è pensare che, poiché il modello ha preso la decisione, il modello ne sia proprietario. Non è così. Se un agente prende un impegno verso un cliente per tuo conto, quell’impegno appartiene al marchio. I clienti lo comprendono istintivamente, così come i regolatori.

Gli agenti IA possono comportarsi in modo imprevedibile quando incontrano situazioni non previste durante i test. Come dovrebbero le imprese testare questi casi limite prima che gli agenti abbiano accesso a clienti, sistemi finanziari o dati sensibili?

Devi presumere che l’agente incontrerà alla fine qualcosa per cui non è stato progettato. La domanda è cosa succede quando ciò avviene.

Quindi valida oltre il percorso previsto. Fornisci all’agente richieste ambigue. Fornisci informazioni contrastanti. Fornisci un contesto incompleto. Mettilo in situazioni in cui la risposta corretta è fermarsi e segnalare piuttosto che continuare. Aggiungi le condizioni del mondo reale, che nella voce includono accenti, rumore, connessioni scadenti e chiamanti che cambiano argomento a metà conversazione. L’obiettivo non è confermare che l’agente funzioni, ma scoprire come si comporta quando le condizioni non sono ottimali.

Il punto più importante è che devi convalidare l’intero percorso, non l’agente isolatamente. Il modello di solito non è il problema. Quando qualcosa va storto, la mia prima domanda è quale contesto ha ricevuto il modello. Potrebbe trattarsi di un articolo di conoscenza obsoleto, di due sistemi con politiche contrastanti, o di un passaggio che ha perso ciò che il cliente aveva già spiegato. Ogni componente può superare il proprio test e il percorso del cliente può comunque fallire nelle interfacce tra di essi.

Quello strato tra i sistemi è quello su cui abbiamo lavorato per anni, in più di 450 imprese e oltre 350 milioni di percorsi cliente all’anno. Agentico o meno, si rompe allo stesso modo. Vediamo anche agenti costruiti su più di 55 tecnologie di fornitori diversi, oltre a tutte le principali piattaforme di contact center, il che dimostra che il modello si mantiene indipendentemente dal modello sottostante.

Prima che un agente ottenga accesso a qualcosa di rilevante, l’impresa dovrebbe disporre di prove su cosa faccia quando le cose vanno bene e quando non vanno.

Come vedi l’evoluzione del testing IA man mano che le aziende passano da software deterministici a sistemi che ragionano, pianificano, comunicano e compiono azioni su più applicazioni?

Il testing deve passare dal chiedersi se un sistema ha prodotto la risposta attesa a chiedersi se ha raggiunto il risultato corretto.

È un cambiamento significativo. Un agente può seguire diversi percorsi per risolvere lo stesso problema del cliente, e tali percorsi possono variare nel tempo man mano che i modelli e le conoscenze alla base cambiano. Non è possibile scrivere uno script per ogni possibile interazione. Devi valutare se l’agente ha compreso l’intento, ha preso decisioni corrette lungo il percorso e ha rispettato i limiti a cui è stato vincolato.

Voglio essere cauto su un aspetto, perché il settore sta iniziando a sbagliare in modo costoso. Il testing pre‑lancio conta di più ora, non di meno. È ciò che determina se un agente è pronto. L’argomento secondo cui si può saltare questo test e osservare la produzione è in realtà un argomento per scoprirlo davanti ai clienti.

Ciò che cambia è che il testing pre‑lancio non è più la fine del processo. La produzione rivela condizioni che un ambiente controllato non può riprodurre completamente, e ciò che la produzione rivela diventa un test che l’agente deve superare prima del prossimo rilascio. Prova prima del lancio, vigilanza in produzione, e ciascuna alimenta l’altra. L’agente in esercizio al sesto mese dovrebbe essere misurabilmente migliore di quello che è stato lanciato.

Guardando al futuro, cosa distinguerà le organizzazioni che costruiscono con successo forze lavoro IA affidabili da quelle che rimangono bloccate in piccoli progetti pilota di IA agentica?

Le organizzazioni che ottengono un ritorno reale dagli agenti sono quelle che hanno costruito un modello operativo basato sull’evidenza. Quelle che si fermano di solito non sono bloccate dalla tecnologia. Sono bloccate perché nessuno può produrre ciò che richiede il livello successivo di approvazione. Il legale pone una domanda ragionevole, o lo fa il comitato dei rischi, e non c’è risposta, quindi il pilota resta un pilota. La tecnologia può essere pronta e l’organizzazione ancora non riesce a giustificare di concederle più autorità.

Questa è la differenza tra un pilota e una forza lavoro operativa. In un pilota, qualcuno osserva sempre. In un modello operativo, ogni agente ha un compito che si può esprimere in una frase. La sua autorità è limitata e scritta. Le sue prestazioni sono valutate da qualcosa di diverso dal team che lo ha creato. I fallimenti di produzione diventano barriere di rilascio. Maggiore autonomia segue la prova.

La seconda differenza è la proprietà. Nelle aziende che crescono, l’agente appartiene alla funzione aziendale che serve, con un proprietario nominato che risponde di ciò che fa. Quando rimane un progetto IA di proprietà di un team IA, rimane piccolo, perché nessun leader aziendale assorbirà il rischio di qualcosa che non controlla.

Niente di tutto ciò è esotico. È vicino a come un’azienda gestisce già le persone di cui si fida con reale responsabilità.

Un pilota può funzionare sulla convinzione di un’organizzazione. La scalata richiede evidenza.

Grazie per la splendida intervista, i lettori che desiderano saperne di più dovrebbero visitare Cyara.