Sushil Kumar, CEO for Cyara – Interviewserie

Sushil Kumar, CEO for Cyara er en erfaren leder inden for enterprise‑software og iværksætter med mere end 25 år af ledelse inden for kunstig intelligens, DevOps, cloud‑infrastruktur, produktstrategi og softwaretest. Han tiltrådte som CEO i Cyara i december 2025 efter sin rolle som medstifter og CEO for RelicX.ai, hvor han byggede en generativ AI‑drevet, intention‑baseret testautomatiseringsplatform, som blev opkøbt af Harness. Han ledte derefter integrationen af RelicX’s teknologi i Harness og hjalp med at forme deres AI Test Automation‑strategi. Tidligere i sin karriere var Kumar General Manager for DevOps hos Broadcom, Senior Vice President for Products hos CA Technologies, og tilbragte mere end 16 år hos Oracle, hvor han havde senior produktledelsesroller og hjalp med at skalere store enterprise‑softwareforretninger. På tværs af disse roller har han fokuseret på at bygge og skalere AI, cloud, DevOps og automatiseringsplatforme for store virksomheder. Hans ansættelse i Cyara fokuserer på at udvide virksomhedens AI‑drevne kundoplevelses‑sikringskapaciteter og globale rækkevidde.

Cyara er en virksomhed inden for sikring af kundeoplevelser, som hjælper virksomheder med at teste, overvåge og validere kundens interaktioner på tværs af stemme, digitale, besked‑ og konverserende AI‑kanaler. Dens Cyara Agentic Platform er designet til at imødekomme de voksende udfordringer, som AI‑drevne kundeoplevelser skaber, herunder test af ikke‑deterministiske AI‑agenter, påvisning af hallucinationer og adfærdsmæssig afvigelse, validering af overholdelse, overvågning af produktionssystemer og vurdering af end‑to‑end‑kunderejser. Platformen kombinerer AI‑agenttest, produktionsovervågning, stemme‑ og telekommunikations‑sikring, digital‑kanal‑test og CX‑observabilitet og understøtter mere end 350 millioner kunderejser årligt på tværs af et globalt fodaftryk, der dækker mere end 140 lande. Efterhånden som virksomheder implementerer stadig mere autonome AI‑agenter i kundevendte arbejdsgange, positionerer Cyara sin teknologi som et sikringslag for at evaluere, om disse systemer opfører sig pålideligt, sikkert og konsistent før og efter implementering.

Du har brugt det meste af din karriere på at bygge og skalere enterprise‑software, fra Oracle og CA/Broadcom til at grundlægge Relicx og nu lede Cyara. Hvordan har den erfaring formet din opfattelse af, at AI‑agenter bør styres mindre som traditionel software og mere som medlemmer af en arbejdsstyrke?

Jeg har tilbragt størstedelen af min karriere med at bygge og skalere enterprise‑software, og den disciplin, vi opbyggede der, var en disciplin omkring deterministiske systemer. Du ved, hvad softwaren skal gøre. Du validerer den i forhold til den forventning. Når den fejler, fortæller den dig: en fejl, en mislykket transaktion, en alarm.

AI‑agenter fungerer ikke på den måde. De er ikke‑deterministiske, så den samme input kan føre til en anden vej. Endnu vigtigere kan de handle på vegne af virksomheden. De indgår forpligtelser: refusioner, politikker, løfter. Og når en af dem er forkert, går der intet i stykker. Et forkert svar lyder præcis som et rigtigt. Transaktionen lykkes, dashboardet forbliver grønt, og kunden går væk med noget, virksomheden aldrig har accepteret.

Når software kan træffe beslutninger og forpligtelser, og kan være forkert uden at give besked, har det brug for en anden driftsmodel.

Det er her sammenligningen med arbejdsstyrken giver mening. Du styrer ikke en medarbejder ved at skripte hver beslutning, de vil træffe. Du giver dem en rolle, du fastlægger den tilhørende autoritet, og du udvider autoriteten, efterhånden som de opnår den. En agent opfører sig på samme måde under den samme struktur.

Min opfattelse er, at autonomi ikke er en implementeringsbeslutning. Det er en række forfremmelser. En agent opnår hver enkelt ved at demonstrere, at den kan udføre jobbet, holde sig inden for sin autoritet og erkende, hvornår den har brug for hjælp.

Hvordan ser en \”HR‑lignende\” driftsmodel for AI‑agenter egentlig ud i en virksomhed, og hvilke elementer bør virksomheder implementere først?

Start med jobbet. Hver agent bør have noget, der svarer til en jobbeskrivelse, inden den kommer tæt på produktion. Hvad skal den opnå, hvilken information er autoritativ for den, hvilke kundedata kan den bruge, hvilke beslutninger kan den træffe selv, og hvor ender dens ansvar. Hvis en virksomhed ikke kan skrive dette ned i et afsnit, er agenten ikke klar til en rolle. Den er klar til en demo.

Fire ting følger af den rolle, og rækkefølgen er vigtig. Evidens før lancering, hvilket betyder at bevise, at agenten kan udføre jobbet under forhold, der ligner den virkelige verden i stedet for en kontrolleret test. Tilsyn mens den kører, så du ved, hvad agenten faktisk har gjort, og ikke kun om systemet har svaret. Forfremmelses‑gateways, så mere autoritet tildeles, når der er evidens til at understøtte det, og ikke før. Og en ejer i forretningen, ikke i ingeniørafdelingen, som er ansvarlig for, hvad agenten må gøre.

Får du rækkefølgen forkert, holder resten ikke. Hvis ansvaret er uklart, er god præstation umulig at bevise, og det samme gælder for fejl. Rollen kommer først, og evidensen følger.

Hvis en AI‑agent tildeles en specifik rolle, hvordan bør organisationer definere dens ansvar, tilladelser og grænser, før den får lov til at interagere med kunder eller kritiske systemer?

Rollen angiver, hvad agenten er til. Tilladelserne angiver, hvad den kan nå. Det er to forskellige samtaler, og virksomheder har typisk kun den første.

Vær eksplicit om tre ting. Hvilke systemer og data agenten kan røre ved, og i hvilken retning, fordi det at læse en kunderecord og at ændre den ikke er den samme tilladelse. Hvad den kan forpligte sig til på egen hånd, hvor pengene og ansvaret ligger: en refundering, en kredit, en undtagelse fra politik. Og hvad der tvinger en overdragelse, både de tilfælde du kan navngive på forhånd og signalet om, at agenten er bevæget sig uden for sin kompetence.

Dette er ikke beslutninger, der skal overlades til teknologiteamet. De bestemmer den risiko, virksomheden påtager sig. De personer, der ejer kundeoplevelsen og compliance‑eksponeringen, skal have indflydelse på, hvor disse grænser trækkes, og de er som regel de sidste, der bliver spurgt.

Derefter skal du bevise, at agenten holder sig inden for dem. Målet er ikke at eliminere enhver mulig fejl. Der vil opstå fejl. Spørgsmålet er, om agenten forstår sine grænser, ved, hvornår den skal stoppe, og kan udføre den tildelte opgave uden at skabe konsekvenser andre steder i kunderejsen.

Du argumenterer for, at større autonomi bør fortjenes frem for at blive tildelt fra starten. Hvad skal en AI‑agent demonstrere, før en virksomhed udvider omfanget af handlinger, den kan udføre selvstændigt?

Det er nu let at bygge en AI‑agent. Den svære del er at bevise, at den fortjener autonomi.

Før man udvider, hvad en agent kan gøre på egen hånd, har en virksomhed brug for beviser på, at den udfører sin tildelte opgave konsekvent og holder sig inden for sine grænser. Det betyder, hvordan den håndterer de situationer, du forventer, men også dem du ikke har forudset. En agent kan fremstå stærk under kontrollerede forhold og opføre sig anderledes, når konteksten eller de omkringliggende systemer ændrer sig.

En kunde kan starte med et enkelt faktureringsspørgsmål og blive frustreret efter en mislykket betaling. Agenten skal genkende dette skift, mens det sker, og ændre kurs i stedet for at fortsætte på den sti, den blev valideret på.

Tre ting skal være sande, før myndigheden udvides. Agenten udfører jobbet under reelle forhold, ikke kun under perfekte. Den kender grænsen for sin egen kompetence og stopper der. Og nogen skal kunne levere beviserne for begge på forespørgsel.

Bevisniveauet skal matche autonominiveauet. Små beslutninger, let bevis. Adgang til et betalingssystem eller evnen til at forpligte virksomheden til en politikundtagelse, kræver et betydeligt højere krav.

Hvordan skal virksomheder løbende evaluere AI‑agenters præstation, når de er i drift, især når kvaliteten af deres beslutninger ikke kan indfanges alene af traditionelle software‑testmålinger?

Her bryder traditionel software‑tænkning sammen. Med deterministisk software tester du, om noget bestod eller fejlede. Med en AI‑agent kan du få et succesfuldt svar fra systemet og stadig have en mislykket kundesamtale.

Så evaluerer du resultatet, ikke svaret. Forstod agenten, hvad kunden prøvede at opnå? Brugte den de rette oplysninger? Fuldførte den rejsen? Holdt den sig inden for sine grænser og eskalerede, når den burde have gjort det?

Grundlæggende evalueringer, hvor svar scores mod et guldstandard‑sæt, er minimum. Alle virksomheder vil have dem. De dimensioner, der afgør, om en kunde fortsat har tillid til dig, er de underliggende: compliance, bias, misbrug, og hvordan agenten klarer sig med rigtige opkald, deres accenter, baggrundsstøj, den billige håndsæt, afbrydelsen midt i en sætning. I stemme betyder dette mere, end folk forventer, fordi hver score er baseret på et transkript. Hvis tale‑laget misforstår spørgsmålet, svarer agenten på et, ingen har stillet.

Aritmetikken er værd at overveje. En 99 % score i evalueringen lyder fremragende. Ved en million samtaler om året svarer det til ti tusinde fejlede.

To principper holder stand. Valideringen skal være uafhængig af agent‑ og modelplatforme. Vi bygger ikke agenterne selv, hvilket er en del af grunden til, at jeg kan sige klart, at ingen leverandør bør dømme sin egen AI. Standarden er virksomhedens egne politikker, dens kundeløfter og regulatoriske forpligtelser, ikke en leverandørs scorekort.

Og hver produktionsfejl skal blive en gate. Ikke en ticket, ikke et backlog‑element. En test, som agenten skal bestå, før den næste version udgives. Hvis et problem opstår i produktion og ikke bliver til noget, agenten skal bestå, betaler du for at opdage det samme problem to gange.

Tillid og styring nævnes i stigende grad som store barrierer for at skalere agent‑AI. Tror du, at teknologien udvikler sig hurtigere end virksomhedernes evne til at overvåge den, og hvilke risici medfører det?

Jeg mener, at det er præcis, hvad der sker, og kløften er strukturel snarere end et resultat af manglende indsats. En idé kan blive til en kunde‑fokuseret agent på få uger. Driftsdisciplinen omkring den agent, ejerskabet, beviserne, tilsynet, tager meget længere, fordi det involverer mennesker og ansvarlighed og ikke kun software.

Risikoen er, at hullet forbliver usynligt, mens det udvider sig. En agent kan give en kunde et selvsikkert forkert svar uden fejl, uden mislykket transaktion og uden alarm. Alle dashboards ser grønne ud. Traditionelle operationer er afhængige af, at systemerne fortæller dig, når de er i problemer, og agenter gør det ikke pålideligt.

Jeg mener ikke, at svaret er at bremse farten. De virksomheder, der vinder her, vil bevæge sig hurtigt. Svaret er at opbygge beviser og tilsyn, der gør det muligt at bevæge sig hurtigt med selvtillid. Jo mere autonomi en agent får, jo flere beviser har du brug for, at den kan bære ansvaret.

Når en autonom agent træffer en dårlig beslutning, hvem bør i sidste ende holdes ansvarlig: udvikleren, forretningsenheden, der implementerer den, leverandøren, der leverer modellen, eller lederen, der godkendte dens brug?

I sidste ende ejer det firma, der implementerer agenten, resultatet. Flere parter er involveret i at bygge og drive systemet, men kunden har ingen relation til modeludbyderen. Kunden har en relation til det firma, hvis navn er på interaktionen.

Det betyder ikke, at ansvaret ligger hos én person. Det løber gennem beslutningskæden. Udvikleren er ansvarlig for, hvordan systemet blev bygget. Virksomheden bestemmer, hvad agenten må gøre. Leverandøren er ansvarlig for den teknologi, den leverer. Ledelsen er ansvarlig for at sikre, at virksomheden har de nødvendige kontroller og tilsyn til at håndtere risikoen.

Fejlen er at tro, at fordi modellen traf beslutningen, så ejer modellen den. Det gør den ikke. Hvis en agent indgår en forpligtelse over for en kunde på dine vegne, tilhører den forpligtelse mærket. Kunder forstår dette intuitivt, og det gør regulatorerne også.

AI‑agenter kan opføre sig uforudsigeligt, når de støder på situationer, der ikke var forudset under test. Hvordan bør virksomheder teste disse edge‑cases, før agenter får adgang til kunder, finansielle systemer eller følsomme data?

Du er nødt til at antage, at agenten på et tidspunkt vil støde på noget, den ikke er designet til. Spørgsmålet er, hvad der sker, når det sker.

Så valider ud over den forventede sti. Giv agenten tvetydige forespørgsler. Giv den modstridende information. Giv den ufuldstændig kontekst. Sæt den i situationer, hvor det rette svar er at stoppe og eskalere i stedet for at fortsætte. Tilføj de virkelige verdens betingelser, som i tale betyder accenter, støj, dårlige forbindelser og opkaldere, der skifter emne halvvejs gennem samtalen. Målet er ikke at bekræfte, at agenten fungerer. Det er at finde ud af, hvordan den opfører sig, når betingelserne ikke er optimale.

Det vigtigste punkt er, at du skal validere hele rejsen, ikke kun agenten isoleret. Modellen er normalt ikke problemet. Når noget går galt, er mit første spørgsmål, hvilken kontekst modellen modtog. Det kan have været en forældet vidensartikel, eller to systemer med modstridende politikker, eller en overdragelse, der tabte det, kunden allerede havde forklaret. Hver komponent kan bestå sin egen test, og kunderejsen kan stadig fejle i overgangen mellem dem.

Det lag mellem systemerne er det, vi har brugt år på at instrumentere, på tværs af 450 virksomheder og mere end 350 millioner kunderejser om året. Agentisk eller ej, det fejler på samme måde. Vi ser også agenter bygget på mere end 55 forskellige leverandørers teknologi, plus alle større kontaktcenterplatforme, hvilket viser, at mønsteret gælder uanset hvilken model der ligger til grund.

Før en agent får adgang til noget vigtigt, bør virksomheden have beviser for, hvad den gør, når tingene går godt, og når de ikke gør.

Hvordan ser du AI-testning udvikle sig, når virksomheder bevæger sig fra deterministisk software til systemer, der ræsonnerer, planlægger, kommunikerer og handler på tværs af flere applikationer?

Testning skal gå fra at spørge, om et system leverede det forventede svar, til at spørge, om det opnåede det rette resultat.

Det er en betydelig ændring. En agent kan tage flere forskellige veje for at løse det samme kundeproblem, og disse veje kan ændre sig over tid, efterhånden som modellerne og den bagvedliggende viden ændres. Du kan ikke skrive et script for hver mulig interaktion. Du skal vurdere, om agenten forstod intentionen, traf fornuftige beslutninger undervejs, og holdt sig inden for de grænser, den blev givet.

Jeg vil være omhyggelig med én ting, fordi branchen begynder at gøre det forkert på en dyr måde. Testning før lancering betyder mere nu, ikke mindre. Det er det, der fastslår, om en agent er klar. Argumentet om, at man kan springe det over og i stedet observere produktionen, er et argument for at finde ud af det foran kunderne.

Hvad der ændrer sig, er, at testning før lancering ikke længere er slutningen på processen. Produktion afslører betingelser, som et kontrolleret miljø ikke kan reproducere fuldstændigt, og hvad produktionen afslører, bliver en test, som agenten skal bestå før den næste udgivelse. Bevis før lancering, årvågenhed i produktion, og at hver del fodrer den anden. Agenten, der kører i den sjette måned, bør målbart være bedre end den, der blev lanceret.

Hvad vil i fremtiden adskille organisationer, der med succes opbygger pålidelige AI‑arbejdsstyrker, fra dem, der forbliver fastlåst i små agent‑AI‑piloter?

De organisationer, der får reel gevinst fra agenter, er dem, der har bygget en driftsmodel omkring evidens. De, der går i stå, er som regel ikke blokeret af teknologien. De er blokeret, fordi ingen kan levere, hvad næste godkendelsesniveau kræver. Juridisk stiller et rimeligt spørgsmål, eller risikokomitéen gør, og der er intet svar, så pilotprojektet forbliver et pilotprojekt. Teknologien kan være klar, men organisationen kan stadig ikke retfærdiggøre at give den mere myndighed.

Det er forskellen mellem et pilotprojekt og en driftsstyrke. I et pilotprojekt er der altid nogen, der holder øje. I en driftsmodel har hver agent et job, du kan beskrive i en sætning. Dens myndighed er begrænset og nedskrevet. Dens præstation evalueres af noget andet end det team, der har bygget den. Produktionsfejl bliver til frigivelsesgate. Mere autonomi følger beviset.

Den anden forskel er ejerskab. I de virksomheder, der skalerer, tilhører agenten den forretningsfunktion, den betjener, med en navngivet ejer, der svarer for, hvad den gør. Hvor den forbliver et AI-projekt ejet af et AI-team, forbliver den lille, fordi ingen forretningsleder vil påtage sig risikoen for noget, de ikke kontrollerer.

Intet af dette er eksotisk. Det ligger tæt på, hvordan en virksomhed allerede håndterer de personer, den har tillid til med reelt ansvar.

Et pilotprojekt kan køre på en organisations overbevisning. Skalering kræver evidens.

Tak for det gode interview, læsere der ønsker at lære mere, bør besøge Cyara.