Sushil Kumar, administrerende direktør i Cyara – Intervjuserie

Sushil Kumar, administrerende direktør i Cyara er en erfaren leder innen bedriftsprogramvare og entreprenør med mer enn 25 år i ledelse innen kunstig intelligens, DevOps, skyinfrastruktur, produktstrategi og programvaretesting. Han ble ansatt som administrerende direktør i Cyara i desember 2025, etter sin rolle som medgründer og administrerende direktør i RelicX.ai, hvor han bygde en generativ AI-drevet, intensjonsbasert testautomatiseringsplattform som ble kjøpt opp av Harness. Deretter ledet han integreringen av RelicX sin teknologi i Harness og bidro til å forme deres strategi for AI-testautomatisering. Tidligere i karrieren var Kumar general manager for DevOps i Broadcom, senior vice president for produkter i CA Technologies, og tilbrakte mer enn 16 år i Oracle, hvor han hadde senior produktledelsesroller og hjalp til med å skalere store bedriftsprogramvarevirksomheter. Gjennom disse rollene har han fokusert på å bygge og skalere AI-, sky-, DevOps- og automatiseringsplattformer for store foretak. Hans ansettelse i Cyara er rettet mot å utvide selskapets AI-drevne kundeservicegaranti‑kapasiteter og globale rekkevidde.

Cyara er et selskap for kundeservicegaranti som hjelper foretak med å teste, overvåke og validere kundesamhandlinger på tvers av tale, digitale kanaler, meldinger og konversasjons‑AI. Deres Cyara Agentic Platform er designet for å møte de økende utfordringene som AI‑drevne kundeopplevelser skaper, inkludert testing av ikke‑deterministiske AI‑agenter, oppdagelse av hallusinasjoner og atferdsdrift, validering av samsvar, overvåking av produksjonssystemer og vurdering av ende‑til‑ende kundereiser. Plattformen kombinerer AI‑agenttesting, produksjonsovervåking, tale‑ og telekommunikasjonsgaranti, testing av digitale kanaler og CX‑observabilitet, og støtter mer enn 350 millioner kundereiser årlig på et globalt fotavtrykk som spenner over mer enn 140 land. Etter hvert som foretak distribuerer stadig mer autonome AI‑agenter i kundevendte arbeidsflyter, posisjonerer Cyara sin teknologi som et garantilag for å evaluere om disse systemene oppfører seg pålitelig, trygt og konsistent før og etter utrulling.

Du har tilbrakt mesteparten av karrieren med å bygge og skalere bedriftsprogramvare, fra Oracle og CA/Broadcom til å grunnlegge Relicx og nå lede Cyara. Hvordan har den erfaringen påvirket ditt syn på at AI‑agenter bør styres mindre som tradisjonell programvare og mer som medlemmer av en arbeidsstyrke?

Jeg har tilbrakt mesteparten av karrieren med å bygge og skalere bedriftsprogramvare, og disiplinen vi bygde der var en disiplin rundt deterministiske systemer. Du vet hva programvaren skal gjøre. Du validerer den mot den forventningen. Når den feiler, forteller den deg: en feil, en mislykket transaksjon, en alarm.

AI‑agenter fungerer ikke på den måten. De er ikke‑deterministiske, så samme input kan ta en annen vei. Enda viktigere er at de kan handle på vegne av selskapet. De gjør forpliktelser: refusjoner, retningslinjer, løfter. Og når en av dem er feil, bryter ingenting. Et feil svar høres akkurat ut som et riktig. Transaksjonen lykkes, dashbordet forblir grønt, og kunden går bort med noe selskapet aldri har samtykket til.

Når programvare kan ta beslutninger og forpliktelser, og kan ta feil uten å fortelle deg det, krever den en annen driftsmodell.

Det er her sammenligningen med arbeidsstyrken viser sin verdi. Du styrer ikke en ansatt ved å skripte hver beslutning de skal ta. Du gir dem en rolle, du fastsetter myndigheten som følger med den, og du utvider den myndigheten etter hvert som de fortjener den. En agent oppfører seg på samme måte under samme struktur.

Min oppfatning er at autonomi ikke er en utrullingsbeslutning. Det er en serie av forfremmelser. En agent oppnår hver av dem ved å vise at den kan utføre jobben, holde seg innenfor sin myndighet, og innse når den trenger hjelp.

Hvordan ser en «HR‑lignende» driftsmodell for AI‑agenter egentlig ut i en bedrift, og hvilke elementer bør selskaper implementere først?

Start med jobben. Hver agent bør ha noe som ligner en stillingsbeskrivelse før den tas i bruk i produksjon. Hva skal den oppnå, hvilken informasjon er autoritativ for den, hvilke kundedata kan den bruke, hvilke beslutninger kan den ta på egen hånd, og hvor slutter ansvaret dens. Hvis et selskap ikke kan skrive dette ned i ett avsnitt, er agenten ikke klar for en rolle. Den er klar for en demonstrasjon.

Fire ting følger av den rollen, og rekkefølgen er viktig. Bevis før lansering, som betyr å demonstrere at agenten kan utføre jobben under forhold som ligner den virkelige verden i stedet for en kontrollert test. Tilsyn mens den kjører, slik at du vet hva agenten faktisk gjorde og ikke bare om systemet svarte. Forfremmelsesporter, slik at mer myndighet gis når det foreligger bevis som støtter det og ikke før. Og en eier i virksomheten, ikke i ingeniøravdelingen, som er ansvarlig for hva agenten får lov til å gjøre.

Får du rekkefølgen feil, holder resten ikke. Hvis ansvaret er uklart, er god ytelse umulig å bevise, og det samme gjelder for feil. Rollen kommer først, og bevisene følger.

Hvis en AI‑agent tildeles en spesifikk rolle, hvordan bør organisasjoner definere dens ansvar, tillatelser og grenser før den får lov til å samhandle med kunder eller kritiske systemer?

Rollen sier hva agenten er til for. Tillatelsene sier hva den kan nå. Dette er to forskjellige samtaler, og selskaper har en tendens til å kun ha den første.

Vær tydelig på tre ting. Hvilke systemer og data agenten kan berøre, og i hvilken retning, fordi å lese en kunderekord og å endre en er ikke samme tillatelse. Hva den kan forplikte seg til på egen hånd, hvor pengene og ansvaret ligger: en refusjon, en kreditt, et unntak fra policy. Og hva som tvinger frem en overlevering, både de tilfellene du kan navngi på forhånd og signalet om at agenten har beveget seg utenfor sin kompetanse.

Dette er ikke beslutninger som skal overlates til teknologiteamet. De bestemmer risikoen selskapet tar. Personene som har ansvar for kundeopplevelse og etterlevelsesrisiko trenger å få si sin mening om hvor disse grensene trekkes, og de er vanligvis de siste som blir spurt.

Deretter må du bevise at agenten holder seg innenfor dem. Målet er ikke å eliminere alle mulige feil. Det vil oppstå feil. Spørsmålet er om agenten forstår sine grenser, vet når den skal stoppe, og kan utføre oppgaven den har fått uten å skape konsekvenser andre steder i kundereisen.

Du argumenterer for at større autonomi bør fortjenes i stedet for å gis fra starten. Hva bør en AI‑agent demonstrere før en virksomhet utvider omfanget av handlinger den kan utføre uavhengig?

Det er nå enkelt å bygge en AI‑agent. Den vanskelige delen er å bevise at den fortjener autonomi.

Før man utvider hva en agent kan gjøre på egen hånd, trenger en virksomhet bevis på at den utfører sin tildelte oppgave konsekvent og holder seg innenfor sine grenser. Det innebærer hvordan den håndterer situasjonene du forventer, samt de du ikke hadde forutsett. En agent kan virke sterk under kontrollerte forhold, men oppføre seg annerledes når konteksten eller de omkringliggende systemene endres.

En kunde kan starte med et enkelt faktureringsspørsmål og bli frustrert etter en mislykket betaling. Agenten må gjenkjenne denne endringen mens den skjer og endre kurs, i stedet for å fortsette på den veien den ble validert for.

Tre ting bør være sanne før myndigheten utvides. Agenten utfører jobben under reelle forhold, ikke bare under ideelle. Den kjenner grensene for sin egen kompetanse og stopper der. Og noen kan levere bevisene for begge på forespørsel.

Bevisnivået må tilsvare autonominivået. Små beslutninger, lett bevis. Tilgang til et betalingssystem, eller evnen til å forplikte selskapet til et policy‑unntak, krever et betydelig høyere krav.

Hvordan bør selskaper kontinuerlig evaluere ytelsen til AI‑agenter etter at de er tatt i bruk, spesielt når kvaliteten på beslutningene deres ikke kan fanges opp av tradisjonelle programvaretestingsmålinger alene?

Dette er hvor tradisjonell programvaretenkning svikter. Med deterministisk programvare tester du om noe bestod eller feilet. Med en AI‑agent kan du få et vellykket svar fra systemet og likevel ha en mislykket kundesamtale.

Derfor evaluerer du resultatet, ikke responsen. Forsto agenten hva kunden prøvde å oppnå? Brukte den riktig informasjon? Fullførte den reisen? Holdt den seg innenfor sine grenser og eskalerte når den skulle?

Grunnleggende evalueringer, der svarene scores mot et gullsett, er minimum. Alle selskaper vil ha dette. Dimensjonene som avgjør om en kunde fortsetter å stole på deg, er de underliggende: etterlevelse, skjevhet, misbruk, og hvordan agenten takler ekte samtalepartnere, deres aksenter, bakgrunnsstøy, den billige telefonen, avbrytelsen midt i en setning. I tale betyr dette mer enn folk forventer, fordi hver score er knyttet til et transkript. Hvis talelag misforstår spørsmålet, svarer agenten på et spørsmål ingen stilte.

Aritmetikken er verdt å sette seg inn i. En 99 % score i evaluering høres utmerket ut. Med en million samtaler i året blir det ti tusen mislykkede.

To prinsipper holder stand. Valideringen bør være uavhengig av agenten og modellplattformene. Vi bygger ikke agentene selv, noe som er en del av grunnen til at jeg kan si tydelig at ingen leverandør bør dømme sin egen AI. Standarden er virksomhetens egne retningslinjer, kundeløfter og regulatoriske forpliktelser, ikke en leverandørs poengkort.

Og hver produksjonsfeil bør bli en port. Ikke en sak, ikke et backlog‑element. En test agenten må bestå før neste versjon lanseres. Hvis et problem oppstår i produksjon og det ikke blir noe agenten må bestå, betaler du for å oppdage det samme problemet to ganger.

Tillits‑ og styringsspørsmål blir stadig mer nevnt som store hindringer for å skalere agent‑AI. Tror du at teknologien utvikler seg raskere enn virksomhetenes evne til å overvåke den, og hvilke risikoer skaper det?

Jeg mener det er nettopp det som skjer, og gapet er strukturelt snarere enn et resultat av manglende innsats. En idé kan bli en kundevendt agent på noen uker. Driftsdisiplinen rundt den agenten, eierskapet, bevisene, tilsynet, tar mye lenger tid, fordi det involverer mennesker og ansvarlighet, og ikke bare programvare.

Risikoen er at gapet forblir usynlig mens det vokser. En agent kan gi en kunde et selvsikkert feil svar uten feil, uten mislykket transaksjon og uten varsel. Alle dashbord ser grønne ut. Tradisjonelle operasjoner er avhengige av at systemene forteller deg når de er i trøbbel, og agenter gjør det ikke pålitelig.

Jeg tror ikke svaret er å bremse ned. Selskapene som vinner her, vil bevege seg raskt. Svaret er å bygge bevis og tilsyn som lar deg bevege deg raskt med selvtillit. Jo mer autonomi en agent får, desto mer bevis trenger du for at den kan bære ansvaret.

Når en autonom agent tar en dårlig beslutning, hvem bør i siste instans holdes ansvarlig: utvikleren, forretningsenheten som implementerer den, leverandøren som leverer modellen, eller lederen som godkjente bruken?

I siste instans eier selskapet som implementerer agenten resultatet. Flere parter er involvert i å bygge og drifte systemet, men kunden har ingen relasjon til modellleverandøren. Kunden har en relasjon til selskapet som står bak interaksjonen.

Det betyr ikke at ansvaret ligger hos én person. Det går gjennom beslutningskjeden. Utvikleren er ansvarlig for hvordan systemet ble bygget. Forretningen bestemmer hva agenten får lov til å gjøre. Leverandøren er ansvarlig for teknologien den leverer. Ledelsen er ansvarlig for å sikre at selskapet har kontrollene og tilsynet som trengs for å håndtere risikoen.

Feilen er å tro at fordi modellen tok beslutningen, eier modellen den. Det gjør den ikke. Hvis en agent gir en forpliktelse til en kunde på dine vegne, tilhører den forpliktelsen merket. Kunder forstår dette intuitivt, og det gjør regulatorene også.

AI-agenter kan oppføre seg uforutsigbart når de møter situasjoner som ikke ble forutsett under testing. Hvordan bør virksomheter teste disse ekstreme tilfellene før agenter får tilgang til kunder, økonomisystemer eller sensitive data?

Du må anta at agenten etter hvert vil støte på noe den ikke er designet for. Spørsmålet er hva som skjer når det skjer.

Valider derfor utover den forventede banen. Gi agenten tvetydige forespørsler. Gi den motstridende informasjon. Gi den ufullstendig kontekst. Sett den i situasjoner hvor det riktige svaret er å stoppe og eskalere i stedet for å fortsette. Legg til virkelige forhold, som i tale betyr aksenter, støy, dårlige forbindelser og innringere som endrer tema halvveis. Målet er ikke å bekrefte at agenten fungerer, men å finne ut hvordan den oppfører seg når forholdene ikke er optimale.

Det viktigste poenget er at du må validere hele reisen, ikke agenten isolert. Modellen er vanligvis ikke problemet. Når noe går galt, er mitt første spørsmål hvilken kontekst modellen fikk. Det kan ha vært en utdatert kunnskapsartikkel, eller to systemer med motstridende retningslinjer, eller en overlevering som mistet det kunden allerede hadde forklart. Hver komponent kan bestå sin egen test, og kundereisen kan fortsatt svikte i overgangene mellom dem.

Det laget mellom systemene er det vi har brukt år på å instrumentere, på tvers av 450 virksomheter og mer enn 350 millioner kundereiser per år. Enten de er agentbaserte eller ikke, bryter de på samme måte. Vi ser også agenter bygget på teknologi fra mer enn 55 ulike leverandører, i tillegg til alle store kontaktcenterplattformer, noe som viser at mønsteret gjelder uavhengig av hvilken modell som ligger under.

Før en agent får tilgang til noe viktig, bør virksomheten ha bevis på hva den gjør når ting går bra og når de ikke gjør det.

Hvordan ser du AI-testing utvikle seg når selskaper går fra deterministisk programvare til systemer som resonnerer, planlegger, kommuniserer og utfører handlinger på tvers av flere applikasjoner?

Testing må gå fra å spørre om et system leverte det forventede svaret til å spørre om det oppnådde riktig resultat.

Det er et betydelig skifte. En agent kan ta flere ulike veier for å løse det samme kundeproblemet, og disse veiene kan endre seg over tid etter hvert som modellene og kunnskapen bak dem endres. Du kan ikke skrive et skript for hver mulige interaksjon. Du må vurdere om agenten forsto intensjonen, tok fornuftige beslutninger underveis, og holdt seg innenfor de grensene den fikk.

Jeg vil være forsiktig med én ting, fordi bransjen begynner å gjøre det feil på en kostbar måte. Test før lansering er viktigere nå, ikke mindre. Det er det som fastslår om en agent er klar. Argumentet om at du kan hoppe over det og i stedet observere produksjon, er et argument for å finne ut av det foran kundene.

Det som endrer seg er at test før lansering ikke lenger er slutten på prosessen. Produksjon avdekker forhold som et kontrollert miljø ikke kan gjenskape fullt ut, og det produksjonen avdekker blir en test agenten må bestå før neste utgivelse. Bevis før lansering, årvåkenhet i produksjon, og at hver del styrker den andre. Agenten som kjører i sjette måned bør være merkbart bedre enn den som ble lansert.

Når vi ser fremover, hva vil skille organisasjoner som lykkes med å bygge pålitelige AI-arbeidsstyrker fra de som fortsatt sitter fast i små agentbaserte AI-piloter?

De organisasjonene som får reell avkastning fra agenter er de som har bygget en driftsmodell basert på bevis. De som stopper, er vanligvis ikke blokkert av teknologien. De er blokkert fordi ingen kan levere det neste godkjenningsnivået krever. Juridisk stiller et rimelig spørsmål, eller risikokomiteen gjør det, og det finnes ingen svar, så pilotprosjektet forblir en pilot. Teknologien kan være klar, men organisasjonen kan fortsatt ikke rettferdiggjøre å gi den mer myndighet.

Det er forskjellen mellom en pilot og en operativ arbeidsstyrke. I en pilot er noen alltid på vakt. I en operativ modell har hver agent en oppgave du kan formulere i én setning. Dens myndighet er begrenset og nedskrevet. Dens ytelse evalueres av noe annet enn teamet som bygde den. Produksjonsfeil blir utgivelsesporter. Mer autonomi følger bevis.

Den andre forskjellen er eierskap. I selskapene som skalerer, tilhører agenten den forretningsfunksjonen den betjener, med en navngitt eier som er ansvarlig for hva den gjør. Der den forblir et AI-prosjekt eid av et AI-team, forblir den liten, fordi ingen forretningsleder vil påta seg risikoen for noe de ikke kontrollerer.

Ingenting av dette er eksotisk. Det er likt hvordan en bedrift allerede håndterer de menneskene den stoler på med reelt ansvar.

En pilot kan drives på organisasjonens overbevisning. Skalering krever bevis.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Cyara.