Sushil Kumar, CEO van Cyara – Interviewreeks

Sushil Kumar, CEO van Cyara is een ervaren leidinggevende in enterprise‑software en ondernemer met meer dan 25 jaar leiderschap op het gebied van kunstmatige intelligentie, DevOps, cloudinfrastructuur, productstrategie en software‑testen. Hij trad in december 2025 toe tot Cyara als CEO, na zijn functie als mede‑oprichter en CEO van RelicX.ai, waar hij een generatieve AI‑aangedreven, intentie‑gebaseerd testautomatiseringsplatform bouwde dat werd overgenomen door Harness. Vervolgens leidde hij de integratie van de technologie van RelicX in Harness en hielp hij de AI Test Automation‑strategie vormgeven. Eerder in zijn carrière was Kumar General Manager DevOps bij Broadcom, Senior Vice President Products bij CA Technologies, en bracht hij meer dan 16 jaar door bij Oracle, waar hij senior productleiderschapsrollen bekleedde en hielp grote enterprise‑softwarebedrijven op te schalen. In al deze rollen richtte hij zich op het bouwen en opschalen van AI-, cloud‑, DevOps‑ en automatiseringsplatformen voor grote ondernemingen. Zijn benoeming bij Cyara is gericht op het uitbreiden van de AI‑aangedreven klantbelevings‑garantiecapaciteiten van het bedrijf en de wereldwijde reikwijdte.

Cyara is een bedrijf voor klantbelevingsgarantie dat ondernemingen helpt bij het testen, monitoren en valideren van klantinteracties via spraak, digitaal, messaging en conversationele AI‑kanalen. Het Cyara Agentic Platform is ontworpen om de groeiende uitdagingen van AI‑gedreven klantbelevingen aan te pakken, waaronder het testen van niet‑deterministische AI‑agents, het detecteren van hallucinaties en gedragsdrift, het valideren van naleving, het monitoren van productiesystemen en het beoordelen van end‑to‑end klantreizen. Het platform combineert AI‑agent testing, productie‑monitoring, spraak‑ en telecomgarantie, digitale‑kanaal testing en CX‑observability, en ondersteunt meer dan 350 miljoen klantreizen per jaar over een wereldwijde aanwezigheid in meer dan 140 landen. Naarmate ondernemingen steeds autonomere AI‑agents in klantgerichte workflows inzetten, positioneert Cyara zijn technologie als een garantielaag om te evalueren of die systemen betrouwbaar, veilig en consistent functioneren vóór en na de uitrol.

U heeft het grootste deel van uw carrière besteed aan het bouwen en opschalen van enterprise‑software, van Oracle en CA/Broadcom tot het oprichten van Relicx en nu het leiden van Cyara. Hoe heeft die ervaring uw visie gevormd dat AI‑agents minder als traditionele software en meer als leden van een personeelsbestand moeten worden beheerd?

Ik heb het grootste deel van mijn carrière besteed aan het bouwen en opschalen van enterprise‑software, en de discipline die we daar ontwikkelden was een discipline rond deterministische systemen. U weet wat de software zou moeten doen. U valideert deze ten opzichte van die verwachting. Wanneer het faalt, meldt het: een fout, een mislukte transactie, een waarschuwing.

AI‑agents werken niet op die manier. Ze zijn niet‑deterministisch, waardoor dezelfde invoer een ander pad kan volgen. Belangrijker nog, ze kunnen handelen namens het bedrijf. Ze doen toezeggingen: terugbetalingen, beleidsregels, beloften. En wanneer een van die toezeggingen onjuist is, breekt er niets. Een fout antwoord klinkt precies als een juist antwoord. De transactie slaagt, het dashboard blijft groen, en de klant vertrekt met iets waar het bedrijf nooit mee akkoord is gegaan.

Zodra software beslissingen en toezeggingen kan nemen en fout kan gaan zonder het u te melden, heeft het een ander operationeel model nodig.

Daar komt de vergelijking met de arbeidskracht van pas. U beheert een werknemer niet door elke beslissing die hij zal nemen te scripten. U geeft hem een rol, stelt de bijbehorende autoriteit vast, en breidt die autoriteit uit naarmate hij die verdient. Een agent gedraagt zich op dezelfde manier binnen dezelfde structuur.

Mijn interpretatie is dat autonomie geen implementatie‑beslissing is. Het is een reeks promoties. Een agent verdient elke promotie door te laten zien dat hij de taak kan uitvoeren, binnen zijn autoriteit blijft en herkent wanneer hij hulp nodig heeft.

Hoe ziet een “HR‑achtig” operationeel model voor AI‑agents er in de praktijk uit binnen een onderneming, en welke elementen moeten bedrijven eerst implementeren?

Begin met de functie. Elke agent moet iets hebben dat dicht bij een functiebeschrijving ligt voordat hij in productie gaat. Wat moet hij bereiken, welke informatie is voor hem gezaghebbend, welke klantgegevens mag hij gebruiken, welke beslissingen kan hij zelfstandig nemen, en waar eindigt zijn verantwoordelijkheid. Als een bedrijf dat niet in één alinea kan vastleggen, is de agent nog niet klaar voor een rol. Hij is klaar voor een demo.

Vier zaken volgen uit die functie, en de volgorde is belangrijk. Bewijs vóór de lancering, wat betekent dat u aantoont dat de agent de taak kan uitvoeren onder omstandigheden die lijken op de echte wereld in plaats van een gecontroleerde test. Toezicht tijdens de uitvoering, zodat u weet wat de agent daadwerkelijk heeft gedaan en niet alleen of het systeem heeft gereageerd. Promotiegaten, zodat meer autoriteit wordt toegekend wanneer er bewijs is dat dit ondersteunt en niet eerder. En een eigenaar in de business, niet in de engineering, die verantwoordelijk is voor wat die agent mag doen.

Als de volgorde verkeerd is, houdt de rest niet stand. Als verantwoordelijkheid vaag is, is goede prestatie onbewijsbaar, net als falen. De rol komt eerst, en het bewijs volgt.

Als een AI‑agent een specifieke rol krijgt toegewezen, hoe moeten organisaties dan haar verantwoordelijkheden, permissies en grenzen definiëren voordat ze mag interageren met klanten of kritieke systemen?

De rol geeft aan waarvoor de agent bedoeld is. De machtigingen geven aan wat hij kan bereiken. Het zijn twee verschillende gesprekken, en bedrijven hebben meestal alleen de eerste.

Wees duidelijk over drie zaken. Welke systemen en gegevens de agent kan aanraken, en in welke richting, omdat het lezen van een klantrecord en het wijzigen ervan niet dezelfde permissie is. Waar hij zelfstandig toe kan verplichten, hetgeen de financiële en aansprakelijkheidsaspecten omvat: een terugbetaling, een krediet, een uitzondering op beleid. En wat een overdracht afdwingt, zowel de gevallen die u van tevoren kunt benoemen als het signaal dat de agent buiten zijn competentie is getreden.

Dit zijn geen beslissingen die aan het technische team kunnen worden overgelaten. Zij bepalen het risico dat het bedrijf neemt. De mensen die verantwoordelijk zijn voor klantbeleving en de compliance‑risico’s moeten inspraak hebben in waar die grenzen worden getrokken, en zij worden meestal als laatste geraadpleegd.

Daarna moet u aantonen dat de agent zich eraan houdt. Het doel is niet om elke mogelijke fout te elimineren. Er zullen fouten optreden. De vraag is of de agent zijn grenzen begrijpt, weet wanneer hij moet stoppen, en het toegewezen werk kan uitvoeren zonder ergens anders in de klantreis consequenties te veroorzaken.

Je stelt dat meer autonomie verdiend moet worden in plaats van vanaf het begin toegekend. Wat moet een AI‑agent aantonen voordat een onderneming de reikwijdte van acties die hij zelfstandig kan ondernemen uitbreidt?

Het is nu eenvoudig om een AI‑agent te bouwen. Het moeilijke deel is aantonen dat hij autonomie verdient.

Voordat een onderneming de zelfstandige mogelijkheden van een agent uitbreidt, heeft ze bewijs nodig dat hij zijn toegewezen taak consequent uitvoert en binnen zijn grenzen blijft. Dat betekent hoe hij omgaat met de situaties die u verwacht, en ook met die u niet had voorzien. Een agent kan sterk lijken onder gecontroleerde omstandigheden, maar zich anders gedragen wanneer de context of de omringende systemen veranderen.

Een klant kan beginnen met een eenvoudige factureringsvraag en gefrustreerd raken na een mislukte betaling. De agent moet die verschuiving herkennen terwijl deze zich voordoet en van koers veranderen, in plaats van door te gaan op het pad waarop hij is gevalideerd.

Drie zaken moeten waar zijn voordat de autoriteit wordt uitgebreid. De agent voert de taak uit onder reële omstandigheden, niet alleen onder ideale. Hij kent de grenzen van zijn eigen competentie en stopt daar. En iemand moet op verzoek het bewijs voor beide kunnen leveren.

Het bewijsniveau moet overeenkomen met het niveau van autonomie. Kleine beslissingen, licht bewijs. Toegang tot een betalingssysteem, of de mogelijkheid om het bedrijf te binden aan een beleidsuitzondering, vereist een aanzienlijk hoger criterium.

Hoe moeten bedrijven de prestaties van AI‑agents continu evalueren nadat ze zijn ingezet, vooral wanneer de kwaliteit van hun beslissingen niet alleen door traditionele software‑test‑metriek kan worden vastgelegd?

Hier breekt het traditionele software‑denken af. Bij deterministische software test je of iets geslaagd of mislukt is. Bij een AI‑agent kun je een succesvol antwoord van het systeem krijgen, terwijl de klantinteractie toch mislukt.

Dus evalueer je het resultaat, niet de respons. Begriep de agent wat de klant probeerde te bereiken? Maakte hij gebruik van de juiste informatie? Voltooide hij de reis? Bleef hij binnen zijn grenzen en escaleerde hij wanneer dat nodig was?

Basis‑evaluaties, waarbij antwoorden worden gescoord ten opzichte van een gouden set, vormen de ondergrond. Elke onderneming zal die hebben. De dimensies die bepalen of een klant u blijft vertrouwen, liggen eronder: compliance, bias, misbruik, en hoe de agent presteert met echte bellers, hun accenten, achtergrondgeluid, de goedkope handset, de onderbreking halverwege een zin. Bij spraak is dit belangrijker dan men verwacht, omdat elke score op een transcript is gebaseerd. Als de spraaklaag de vraag verkeerd hoort, beantwoordt de agent een vraag die niemand stelde.

De wiskunde is het waard om bij stil te staan. Een score van 99 % in een evaluatie klinkt uitstekend. Bij een miljoen gesprekken per jaar betekent dat tienduizend mislukte gesprekken.

Twee principes blijven staan. De validatie moet onafhankelijk zijn van de agent‑ en modelplatformen. We bouwen de agents zelf niet, wat mede de reden is dat ik duidelijk kan stellen dat geen enkele leverancier zijn eigen AI moet beoordelen. De norm is het eigen beleid van de onderneming, haar klantbeloften en haar wettelijke verplichtingen, niet de scorekaart van een leverancier.

En elke productiefout moet een poort worden. Geen ticket, geen backlog‑item. Een test die de agent moet doorstaan voordat de volgende release wordt uitgerold. Als een probleem zich in productie voordoet en het niet wordt omgezet in een test die de agent moet doorstaan, betaalt u dubbel voor het ontdekken van hetzelfde probleem.

Vertrouwen en governance worden steeds vaker genoemd als belangrijke barrières voor het opschalen van agent‑AI. Gelooft u dat de technologie sneller vooruitgaat dan de mogelijkheid van ondernemingen om deze te superviseren, en welke risico’s creëert dat?

Ik denk dat dat precies gebeurt, en de kloof is structureel in plaats van een tekortkoming in inspanning. Een idee kan binnen enkele weken een klantgerichte agent worden. De operationele discipline rond die agent, het eigenaarschap, het bewijs, de toezicht, vergt veel meer tijd, omdat het mensen en verantwoordelijkheid betreft en niet alleen software.

Het risico is dat de kloof onzichtbaar blijft terwijl deze groter wordt. Een agent kan een klant een vol vertrouwen fout antwoord geven zonder fout, zonder mislukte transactie en zonder waarschuwing. Elk dashboard ziet er groen uit. Traditionele operaties zijn afhankelijk van systemen die je vertellen wanneer ze in de problemen zitten, en agents doen dat niet betrouwbaar.

Ik denk niet dat het antwoord is om te vertragen. De bedrijven die hier winnen, zullen snel bewegen. Het antwoord is om het bewijs en de controle op te bouwen die je in staat stellen snel te bewegen met vertrouwen. Hoe meer autonomie een agent krijgt, hoe meer bewijs je nodig hebt dat hij de verantwoordelijkheid kan dragen.

Wanneer een autonome agent een slechte beslissing maakt, wie moet er uiteindelijk verantwoordelijk worden gehouden: de ontwikkelaar, de business unit die hem inzet, de leverancier die het model levert, of de leidinggevende die het gebruik heeft goedgekeurd?

Uiteindelijk is het bedrijf dat de agent inzet eigenaar van het resultaat. Verschillende partijen zijn betrokken bij het bouwen en exploiteren van het systeem, maar de klant heeft geen relatie met de modelprovider. De klant heeft wel een relatie met het bedrijf wiens naam op de interactie staat.

Dat betekent niet dat de verantwoordelijkheid bij één persoon ligt. Het loopt door de besluitvormingsketen. De ontwikkelaar is verantwoordelijk voor hoe het systeem is gebouwd. Het bedrijf bepaalt wat de agent mag doen. De leverancier is verantwoordelijk voor de technologie die hij levert. Het leiderschap is verantwoordelijk ervoor dat het bedrijf de controles en het toezicht heeft om het risico volledig te beheren.

De fout is te denken dat omdat het model de beslissing heeft genomen, het model er eigenaar van is. Dat is niet zo. Als een agent namens jou een toezegging aan een klant doet, behoort die toezegging tot het merk. Klanten begrijpen dit instinctief, en dat doen regelgevers ook.

AI‑agents kunnen zich onvoorspelbaar gedragen wanneer ze situaties tegenkomen die niet waren voorzien tijdens het testen. Hoe moeten bedrijven deze randgevallen testen voordat agents toegang krijgen tot klanten, financiële systemen of gevoelige data?

Je moet ervan uitgaan dat de agent uiteindelijk iets tegenkomt waarvoor hij niet is ontworpen. De vraag is wat er gebeurt wanneer dat gebeurt.

Valideer dus verder dan het verwachte pad. Geef de agent vage verzoeken. Geef hem tegenstrijdige informatie. Geef hem onvolledige context. Plaats hem in situaties waarin het juiste antwoord is om te stoppen en te escaleren in plaats van door te gaan. Voeg de omstandigheden van de echte wereld toe, wat bij spraak betekent accenten, ruis, slechte verbindingen en bellers die halverwege van onderwerp veranderen. Het doel is niet om te bevestigen dat de agent werkt. Het is om te ontdekken hoe hij zich gedraagt wanneer de omstandigheden niet schoon zijn.

Het belangrijkere punt is dat je de hele reis moet valideren, niet de agent op zichzelf. Het model is meestal niet het probleem. Wanneer er iets misgaat, is mijn eerste vraag welke context het model heeft ontvangen. Het kan een verouderd kennisartikel zijn, of twee systemen met tegenstrijdige beleidsregels, of een overdracht die liet vallen wat de klant al had uitgelegd. Elk onderdeel kan zijn eigen test doorstaan en toch kan de klantreis falen op de overgangen ertussen.

Die laag tussen de systemen is er één waarop we al jaren instrumentatie toepassen, bij 450 ondernemingen en meer dan 350 miljoen klantreizen per jaar. Agentisch of niet, hij breekt op dezelfde manier. We zien ook agents gebouwd op meer dan 55 verschillende leveranciers‑technologieën, plus elk groot contactcenterplatform, waardoor we weten dat het patroon geldt ongeacht welk model eronder zit.

Voordat een agent toegang krijgt tot iets belangrijks, moet de onderneming bewijs hebben van wat hij doet wanneer alles goed gaat en wanneer dat niet het geval is.

Hoe zie je AI‑testen evolueren nu bedrijven overstappen van deterministische software naar systemen die redeneren, plannen, communiceren en acties ondernemen over meerdere applicaties heen?

Testen moeten verschuiven van de vraag of een systeem het verwachte antwoord gaf naar de vraag of het de juiste uitkomst heeft bereikt.

Dat is een aanzienlijke verschuiving. Een agent kan verschillende paden nemen om hetzelfde klantprobleem op te lossen, en die paden kunnen in de loop van de tijd veranderen naarmate de modellen en de kennis erachter evolueren. Je kunt geen script schrijven voor elke mogelijke interactie. Je moet beoordelen of de agent de intentie begreep, verstandige beslissingen nam gedurende het proces, en binnen de grenzen bleef die hem zijn opgelegd.

Ik wil voorzichtig zijn met één punt, omdat de industrie het nu op een dure manier fout maakt. Pre‑launch testen zijn nu belangrijker, niet minder. Het is wat bepaalt of een agent klaar is. Het argument dat je het kunt overslaan en in plaats daarvan de productie kunt observeren, is een argument om het voor de klant te ontdekken.

Wat verandert is dat pre‑launch testen niet langer het einde van het proces zijn. Productie onthult omstandigheden die een gecontroleerde omgeving niet volledig kan reproduceren, en wat productie onthult wordt een test die de agent moet doorstaan vóór de volgende release. Bewijs vóór de lancering, waakzaamheid in productie, en elk onderdeel voedt het andere. De agent die in maand zes draait, moet meetbaar beter zijn dan degene die werd gelanceerd.

Vooruitkijkend, wat zal organisaties onderscheiden die met succes een vertrouwde AI‑werkforce opbouwen van degenen die blijven hangen in kleine agent‑AI‑pilots?

De organisaties die echt rendement halen uit agents zijn degenen die een operationeel model rond bewijs hebben opgebouwd. De organisaties die stagneren, worden meestal niet door de technologie geblokkeerd. Ze worden geblokkeerd omdat niemand kan leveren wat het volgende goedkeuringsniveau vereist. Legal stelt een redelijke vraag, of het risicocomité doet dat, en er is geen antwoord, dus blijft de pilot een pilot. De technologie kan klaar zijn, maar de organisatie kan nog steeds niet rechtvaardigen dat ze meer autoriteit krijgt.

Dat is het verschil tussen een pilot en een operationele workforce. In een pilot kijkt iemand altijd mee. In een operationeel model heeft elke agent een taak die je in één zin kunt beschrijven. Zijn autoriteit is beperkt en vastgelegd. Zijn prestaties worden geëvalueerd door iets anders dan het team dat hem heeft gebouwd. Productiefouten worden release‑poorten. Meer autonomie volgt na bewijs.

Het tweede verschil is eigendom. In de bedrijven die opschalen, behoort de agent tot de bedrijfsfunctie die hij bedient, met een benoemde eigenaar die verantwoording aflegt voor wat hij doet. Waar het een AI‑project blijft dat eigendom is van een AI‑team, blijft het klein, omdat geen bedrijfsleider het risico wil dragen van iets dat hij niet controleert.

Dit is niets exotisch. Het ligt dicht bij hoe een bedrijf al omgaat met de mensen die het vertrouwt met echte verantwoordelijkheid.

Een pilot kan draaien op de overtuiging van een organisatie. Opschalen vereist bewijs.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen Cyara bezoeken.