Sushil Kumar, CEO al Cyara – Seria de interviuri

Sushil Kumar, CEO al Cyara este un executiv experimentat în software pentru întreprinderi și antreprenor, cu peste 25 de ani de conducere în domeniul inteligenței artificiale, DevOps, infrastructurii cloud, strategiei de produs și testării software. S-a alăturat Cyara ca CEO în decembrie 2025, după ce a ocupat funcția de co-fondator și CEO la RelicX.ai, unde a construit o platformă de automatizare a testelor bazată pe inteligență artificială generativă și orientată pe intenții, care a fost achiziționată de Harness. Ulterior a condus integrarea tehnologiei RelicX în Harness și a contribuit la definirea strategiei de AI Test Automation. În perioada timpurie a carierei sale, Kumar a fost General Manager pentru DevOps la Broadcom, Vicepreședinte Senior de Produse la CA Technologies și a petrecut peste 16 ani la Oracle, unde a deținut funcții de conducere senioră de produs și a ajutat la scalarea unor mari afaceri de software pentru întreprinderi. În toate aceste roluri, s-a concentrat pe construirea și scalarea platformelor de AI, cloud, DevOps și automatizare pentru mari companii. Numirea sa la Cyara vizează extinderea capabilităților de asigurare a experienței clienților, bazate pe AI, și a prezenței globale ale companiei.

Cyara este o companie de asigurare a experienței clienților care ajută întreprinderile să testeze, monitorizeze și valideze interacțiunile cu clienții pe canalele de voce, digitale, mesagerie și AI conversațional. Platforma sa Cyara Agentic este concepută pentru a răspunde provocărilor tot mai mari generate de experiențele clienților bazate pe AI, inclusiv testarea agenților AI nedeterministici, detectarea halucinațiilor și a devierilor comportamentale, validarea conformității, monitorizarea sistemelor de producție și evaluarea călătoriilor clienților de la cap la cap. Platforma combină testarea agenților AI, monitorizarea producției, asigurarea vocilor și a telecomunicațiilor, testarea canalelor digitale și observabilitatea CX, susținând anual peste 350 de milioane de călătorii ale clienților, pe o prezență globală în peste 140 de țări. Pe măsură ce întreprinderile implementează agenți AI din ce în ce mai autonomi în fluxurile de lucru orientate spre clienți, Cyara poziționează tehnologia sa ca un strat de asigurare pentru evaluarea dacă aceste sisteme se comportă în mod fiabil, sigur și consecvent înainte și după lansare.

Ai petrecut cea mai mare parte a carierei tale construind și scalând software pentru întreprinderi, de la Oracle și CA/Broadcom la fondarea Relicx și acum conducând Cyara. Cum a modelat această experiență opinia ta că agenții AI ar trebui gestionați mai puțin ca software tradițional și mai mult ca membri ai forței de muncă?

Am petrecut cea mai mare parte a carierei mele construind și scalând software pentru întreprinderi, iar disciplina pe care am creat-o acolo era una axată pe sisteme deterministe. Știi ce ar trebui să facă software-ul. Îl validezi în raport cu această așteptare. Când se defectează, îți spune: o eroare, o tranzacție eșuată, o alertă.

Agenții AI nu funcționează în acest fel. Sunt nedeterministi, astfel încât aceeași intrare poate urma un traseu diferit. Mai mult, pot acționa în numele companiei. Fac angajamente: rambursări, politici, promisiuni. Și când unul dintre acestea este greșit, nu se produce nicio defecțiune. Un răspuns greșit sună exact ca unul corect. Tranzacția reușește, tabloul de bord rămâne verde, iar clientul pleacă cu ceva la care compania nu a consimțit niciodată.

Odată ce software-ul poate lua decizii și angajamente și poate greși fără să te avertizeze, are nevoie de un model operațional diferit.

Aici compararea cu forța de muncă își găsește justificarea. Nu gestionezi un angajat prin programarea fiecărei decizii pe care o va lua. Îi atribui un rol, stabilești autoritatea aferentă și extinzi acea autoritate pe măsură ce o câștigă. Un agent se comportă în același mod în cadrul aceleiași structuri.

Interpretarea mea este că autonomia nu este o decizie de implementare. Este o serie de promovări. Un agent câștigă fiecare dintre ele demonstrând că poate îndeplini sarcina, rămâne în limitele autorității sale și recunoaște când are nevoie de ajutor.

Ce arată, în practică, un model operațional „similar cu HR” pentru agenții AI într-o întreprindere și care elemente ar trebui companiile să implementeze mai întâi?

Începe cu rolul. Fiecare agent ar trebui să aibă ceva asemănător cu o descriere de post înainte de a fi apropriat de producție. Ce trebuie să realizeze, ce informații sunt autoritare pentru el, ce date ale clienților poate utiliza, ce decizii poate lua de unul singur și unde se încheie responsabilitatea sa. Dacă o companie nu poate scrie acest lucru într-un paragraf, agentul nu este pregătit pentru un rol. Este pregătit pentru o demonstrație.

Patru aspecte decurg din acel rol, iar ordinea contează. Dovezi înainte de lansare, ceea ce înseamnă să demonstrezi că agentul poate îndeplini sarcina în condiții ce seamănă cu lumea reală, nu cu un test controlat. Supraveghere în timpul funcționării, pentru a ști ce a făcut efectiv agentul și nu doar dacă sistemul a răspuns. Porți de promovare, astfel încât autoritatea suplimentară să fie acordată când există dovezi care să o susțină și nu înainte. Și un responsabil în business, nu în inginerie, care este răspunzător pentru ceea ce agentul are voie să facă.

Greșești ordinea și restul nu se susține. Dacă responsabilitatea este vagă, performanța bună devine imposibil de demonstrat, la fel și eșecul. Rolul vine primul, iar dovezile îl urmează.

Dacă unui agent AI i se atribuie un rol specific, cum ar trebui organizațiile să definească responsabilitățile, permisiunile și limitele sale înainte de a-i permite să interacționeze cu clienții sau cu sistemele critice?

Rolul spune pentru ce este agentul. Permisiunile spun la ce poate ajunge. Acestea sunt două conversații diferite, iar companiile tind să aibă doar prima.

Fiți explicit în privința a trei aspecte. Ce sisteme și date poate atinge agentul și în ce direcție, deoarece citirea unui dosar al clientului și modificarea acestuia nu reprezintă aceeași permisiune. Ce poate angaja pe cont propriu, unde se află banii și răspunderea: o rambursare, un credit, o excepție de politică. Și ce forțează o transferare, atât cazurile pe care le puteți numi în prealabil, cât și semnalul că agentul a ieșit din competența sa.

Acestea nu sunt decizii pe care să le lăsați echipei de tehnologie. Ele determină riscul pe care îl asumă compania. Persoanele responsabile de experiența clienților și de expunerea la conformitate trebuie să aibă un cuvânt de spus în stabilirea acestor limite, iar de obicei sunt ultimele la care se apelează.

Apoi trebuie să demonstrați că agentul rămâne în interiorul lor. Scopul nu este să elimine fiecare greșeală posibilă. Vor exista greșeli. Întrebarea este dacă agentul înțelege limitele sale, știe când să se oprească și poate îndeplini sarcina primită fără să creeze consecințe în altă parte a parcursului clientului.

Susțineți că o autonomie mai mare ar trebui câștigată, nu acordată de la început. Ce ar trebui să demonstreze un agent AI înainte ca o companie să extindă domeniul acțiunilor pe care le poate întreprinde independent?

Acum este ușor să construiești un agent AI. Partea dificilă este să demonstrezi că merită autonomia.

Înainte de a extinde ceea ce poate face un agent pe cont propriu, o companie are nevoie de dovezi că își îndeplinește sarcina atribuită în mod constant și rămâne în limitele sale. Aceasta înseamnă cum gestionează situațiile pe care le așteptați, precum și pe cele pe care nu le-ați anticipat. Un agent poate părea puternic în condiții controlate și să se comporte diferit când contextul sau sistemele înconjurătoare se schimbă.

Un client poate începe cu o întrebare simplă despre facturare și să devină frustrat după o plată eșuată. Agentul trebuie să recunoască această schimbare în timp real și să schimbe direcția, în loc să continue pe calea pe care a fost validat.

Trei aspecte ar trebui să fie adevărate înainte ca autoritatea să se extindă. Agentul își îndeplinește sarcina în condiții reale, nu doar în cele ideale. Cunoaște limita competenței sale și se oprește acolo. Și cineva poate furniza dovezile pentru ambele la cerere.

Nivelul de probă trebuie să corespundă nivelului de autonomie. Decizii mici, dovezi ușoare. Accesul la un sistem de plată sau capacitatea de a angaja compania într-o excepție de politică necesită un standard considerabil mai ridicat.

Cum ar trebui companiile să evalueze continuu performanța agenților AI odată ce sunt implementați, în special când calitatea deciziilor lor nu poate fi captată doar prin metrici tradiționale de testare a software-ului?

Aici gândirea tradițională a software-ului se prăbușește. În cazul software-ului determinist testați dacă ceva a trecut sau a eșuat. În cazul unui agent AI puteți primi un răspuns de succes de la sistem și totuși să aveți o interacțiune eșuată cu clientul.

Așadar evaluați rezultatul, nu răspunsul. A înțeles agentul ce încerca să realizeze clientul? A folosit informațiile corecte? A finalizat parcursul? A rămas în limitele sale și a escaladat când ar fi trebuit?

Evaluările de bază, scorarea răspunsurilor față de un set de referință, reprezintă nivelul minim. Fiecare companie le va avea. Dimensiunile care decid dacă un client continuă să aibă încredere în tine sunt cele de dedesubt: conformitatea, părtinirea, utilizarea abuzivă și modul în care agentul se descurcă cu apelanții reali, accentele lor, zgomotul de fundal, telefonul ieftin, întreruperea la jumătatea unei fraze. În voce, acest aspect contează mai mult decât se crede, deoarece fiecare scor se bazează pe o transcriere. Dacă stratul vocal înțelege greșit întrebarea, agentul răspunde la una pe care nimeni nu a pus-o.

Aritmetica merită analizată. Un scor de 99 % la evaluare pare excelent. La un milion de conversații pe an, asta înseamnă zece mii de cazuri eșuate.

Două principii rezistă. Validarea ar trebui să fie independentă de platformele agentului și ale modelului. Nu construim noi agenții, ceea ce explică de ce pot spune clar că niciun furnizor nu ar trebui să fie judecătorul propriei AI. Standardul este reprezentat de politicile interne ale companiei, angajamentele față de clienți și obligațiile sale de reglementare, nu de foaia de scor a unui furnizor.

Și fiecare eșec în producție ar trebui să devină o poartă. Nu un tichet, nu un element din backlog. Un test pe care agentul trebuie să-l treacă înainte ca următoarea versiune să fie lansată. Dacă o problemă apare în producție și nu se transformă într-un test pe care agentul trebuie să-l depășească, plătiți pentru a descoperi aceeași problemă de două ori.

Încrederea și guvernanța sunt tot mai des invocate ca bariere majore în scalarea AI-ului agentic. Credeți că tehnologia avansează mai repede decât capacitatea companiilor de a o supraveghea și ce riscuri generează acest lucru?

Cred că exact asta se întâmplă, iar decalajul este structural, nu rezultă dintr-un eșec de efort. O idee poate deveni un agent orientat către client în câteva săptămâni. Disciplina operațională în jurul acelui agent, deținerea, dovezile, supravegherea, durează mult mai mult, deoarece implică oameni și responsabilitate, nu doar software.

Riscul este că diferența rămâne invizibilă în timp ce se lărgește. Un agent poate oferi unui client un răspuns greșit cu încredere, fără eroare, fără tranzacție eșuată și fără alertă. Fiecare tablou de bord arată verde. Operațiunile tradiționale depind de sistemele care îți spun când au probleme, iar agenții nu fac acest lucru în mod fiabil.

Nu cred că răspunsul este să încetinești. Companiile care vor câștiga aici vor acționa rapid. Răspunsul este să construiești dovezile și supravegherea care îți permit să te miști rapid cu încredere. Cu cât un agent primește mai multă autonomie, cu atât ai nevoie de mai multe dovezi că poate suporta responsabilitatea.

Când un agent autonom ia o decizie proastă, cine ar trebui să fie în cele din urmă responsabil: dezvoltatorul, unitatea de afaceri care îl implementează, furnizorul care oferă modelul sau executivul care a aprobat utilizarea acestuia?

În final, compania care implementează agentul deține rezultatul. Mai multe părți sunt implicate în construirea și operarea sistemului, dar clientul nu are nicio relație cu furnizorul modelului. Clientul are o relație cu compania al cărei nume apare în interacțiune.

Acest lucru nu înseamnă că responsabilitatea revine unei singure persoane. Ea se propagă prin lanțul decizional. Dezvoltatorul este responsabil pentru modul în care a fost construit sistemul. Afacerea decide ce este permis agentului să facă. Furnizorul este responsabil pentru tehnologia pe care o furnizează. Conducerea este responsabilă să se asigure că compania are controalele și supravegherea necesare pentru a gestiona riscul în totalitate.

Greșeala este să crezi că, pentru că modelul a luat decizia, modelul deține responsabilitatea. Nu este așa. Dacă un agent face un angajament față de un client în numele tău, acel angajament aparține mărcii. Clienții înțeleg acest lucru instinctiv, la fel și autoritățile de reglementare.

Agenții AI pot reacționa imprevizibil când întâlnesc situații neanticipate în timpul testării. Cum ar trebui întreprinderile să testeze aceste cazuri limită înainte ca agenții să aibă acces la clienți, sisteme financiare sau date sensibile?

Trebuie să presupui că agentul va întâlni în cele din urmă ceva pentru care nu a fost conceput. Întrebarea este ce se întâmplă atunci când se întâmplă.

Așadar, validează dincolo de calea așteptată. Oferă agentului cereri ambigue. Oferă-i informații contradictorii. Oferă-i un context incomplet. Pune-l în situații în care răspunsul corect este să se oprească și să escaladeze, în loc să continue. Adaugă condițiile lumii reale, care în voce înseamnă accente, zgomot, conexiuni slabe și apelanți care schimbă subiectul pe parcurs. Scopul nu este să confirmi că agentul funcționează. Este să afli cum se comportă când condițiile nu sunt ideale.

Punctul mai important este că trebuie să validezi întreaga călătorie, nu agentul izolat. Modelul de obicei nu este problema. Când ceva nu merge bine, prima mea întrebare este ce context a primit modelul. Poate fi vorba de un articol de cunoștințe învechit, sau de două sisteme cu politici contradictorii, sau de o predare care a pierdut informațiile pe care clientul le-a explicat deja. Fiecare componentă își poate trece propriul test, iar călătoria clientului poate eșua în intersecțiile dintre ele.

Acest strat dintre sisteme este cel pe care l-am instrumentat de ani de zile, în peste 450 de întreprinderi și mai mult de 350 de milioane de călătorii ale clienților pe an. Indiferent dacă este agentic sau nu, se defectează în același mod. De asemenea, vedem agenți construiți pe tehnologia a peste 55 de furnizori diferiți, plus fiecare platformă majoră de centre de contact, ceea ce ne permite să știm că modelul se menține indiferent de modelul de bază.

Înainte ca un agent să aibă acces la ceva important, întreprinderea ar trebui să aibă dovezi despre ce face atunci când lucrurile merg bine și când nu.

Cum vezi evoluția testării AI pe măsură ce companiile trec de la software determinist la sisteme care raționează, planifică, comunică și acționează în multiple aplicații?

Testarea trebuie să treacă de la întrebarea dacă un sistem a produs răspunsul așteptat la întrebarea dacă a atins rezultatul corect.

Este o schimbare semnificativă. Un agent poate urma mai multe căi diferite pentru a rezolva aceeași problemă a clientului, iar aceste căi pot evolua în timp pe măsură ce modelele și cunoștințele din spatele lor se schimbă. Nu poți scrie un script pentru fiecare interacțiune posibilă. Trebuie să evaluezi dacă agentul a înțeles intenția, a luat decizii solide pe parcurs și a rămas în limitele stabilite.

Vreau să fiu atent la un aspect, deoarece industria începe să greșească în mod costisitor. Testarea pre-lansare contează mai mult acum, nu mai puțin. Ea stabilește dacă un agent este pregătit. Argumentul că poți sări peste ea și să urmărești producția în schimb este, de fapt, un argument pentru a descoperi problemele în fața clienților.

Ceea ce se schimbă este că testarea pre-lansare nu mai reprezintă sfârșitul procesului. Producția dezvăluie condiții pe care un mediu controlat nu le poate reproduce complet, iar ceea ce producția dezvăluie devine un test pe care agentul trebuie să-l treacă înainte de următoarea lansare. Dovada înainte de lansare, vigilența în producție și fiecare alimentându-l pe celălalt. Agentul care rulează în a șasea lună ar trebui să fie măsurabil mai bun decât cel care a fost lansat.

Privind spre viitor, ce va diferenția organizațiile care construiesc cu succes forțe de muncă AI de încredere de cele care rămân blocate în pilotarea mică a AI-ului agentic?

Organizațiile care obțin un randament real de la agenți sunt cele care au construit un model operațional bazat pe dovezi. Cele care stagnează de obicei nu sunt blocate de tehnologie. Sunt blocate pentru că nimeni nu poate produce ceea ce nivelul următor de aprobare solicită. Departamentul juridic pune o întrebare rezonabilă, sau comitetul de risc o face, și nu există răspuns, astfel încât pilotul rămâne un pilot. Tehnologia poate fi pregătită, iar organizația tot nu poate justifica acordarea unei autorități suplimentare.

Aceasta este diferența dintre un pilot și o forță de muncă operațională. Într-un pilot, cineva monitorizează mereu. Într-un model operațional, fiecare agent are o sarcină pe care o poți exprima într-o propoziție. Autoritatea lui este limitată și documentată. Performanța lui este evaluată de ceva diferit de echipa care l-a creat. Defectele de producție devin porți de lansare. Mai multă autonomie urmează dovada.

A doua diferență este proprietatea. În companiile care scalează, agentul aparține funcției de business pe care o deservește, având un proprietar numit care răspunde pentru ceea ce face. În cazul în care rămâne un proiect AI deținut de o echipă AI, rămâne mic, deoarece niciun lider de business nu va prelua riscul unui lucru pe care nu îl controlează.

Nimic din acestea nu este exotic. Este apropiat de modul în care o companie gestionează deja oamenii în care are încredere, cu responsabilitate reală.

Un pilot poate funcționa pe baza convingerii unei organizații. Scalarea necesită dovezi.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze Cyara.