Sushil Kumar, CEO von Cyara – Interviewreihe

Sushil Kumar, CEO von Cyara ist ein erfahrener Führungskraft im Bereich Unternehmenssoftware und Unternehmer mit mehr als 25 Jahren Leitungserfahrung in Künstlicher Intelligenz, DevOps, Cloud-Infrastruktur, Produktstrategie und Softwaretests. Er trat Cyara im Dezember 2025 als CEO bei, nachdem er als Mitgründer und CEO von RelicX.ai tätig war, wo er eine generative KI‑gestützte, intent‑basierte Testautomatisierungsplattform aufgebaut hatte, die von Harness übernommen wurde. Anschließend leitete er die Integration der RelicX‑Technologie in Harness und half, deren KI‑Testautomatisierungsstrategie zu formen. Zu Beginn seiner Karriere war Kumar General Manager für DevOps bei Broadcom, Senior Vice President of Products bei CA Technologies und verbrachte über 16 Jahre bei Oracle, wo er leitende Produktmanagement‑Positionen innehatte und beim Skalieren großer Unternehmenssoftware‑Geschäfte half. In all diesen Rollen konzentrierte er sich auf den Aufbau und das Skalieren von KI-, Cloud-, DevOps‑ und Automatisierungsplattformen für Großunternehmen. Seine Ernennung bei Cyara zielt darauf ab, die KI‑gestützten Fähigkeiten zur Sicherstellung von Kundenerfahrungen und die globale Reichweite des Unternehmens auszubauen.

Cyara ist ein Unternehmen für Kundenerfahrungs‑Sicherung, das Unternehmen dabei unterstützt, Kundeninteraktionen über Sprache, digitale Kanäle, Messaging und konversationelle KI‑Kanäle zu testen, zu überwachen und zu validieren. Die Cyara Agentic Platform ist darauf ausgelegt, die wachsenden Herausforderungen durch KI‑gesteuerte Kundenerlebnisse zu bewältigen, einschließlich des Testens nicht‑deterministischer KI‑Agenten, der Erkennung von Halluzinationen und Verhaltensdrift, der Validierung von Compliance, der Überwachung von Produktionssystemen und der Bewertung von End‑zu‑End‑Kundenreisen. Die Plattform kombiniert KI‑Agenten‑Testing, Produktions‑Monitoring, Sprach‑ und Telekom‑Sicherung, Tests digitaler Kanäle und CX‑Observability und unterstützt jährlich mehr als 350 Millionen Kundenreisen in über 140 Ländern weltweit. Während Unternehmen zunehmend autonome KI‑Agenten in kundenorientierte Workflows einsetzen, positioniert Cyara seine Technologie als Sicherungsschicht, um zu prüfen, ob diese Systeme vor und nach dem Einsatz zuverlässig, sicher und konsistent funktionieren.

Sie haben den Großteil Ihrer Karriere damit verbracht, Unternehmenssoftware aufzubauen und zu skalieren, von Oracle und CA/Broadcom über die Gründung von Relicx bis hin zur Leitung von Cyara. Wie hat diese Erfahrung Ihre Ansicht geprägt, dass KI‑Agenten weniger wie traditionelle Software und mehr wie Mitglieder einer Belegschaft verwaltet werden sollten?

Ich habe den größten Teil meiner Karriere damit verbracht, Unternehmenssoftware zu bauen und zu skalieren, und die Disziplin, die wir dort etablierten, war eine Disziplin rund um deterministische Systeme. Sie wissen, was die Software leisten soll. Sie validieren sie anhand dieser Erwartung. Wenn sie ausfällt, meldet sie Ihnen: einen Fehler, eine fehlgeschlagene Transaktion, einen Alarm.

KI‑Agenten funktionieren nicht so. Sie sind nicht‑deterministisch, sodass dieselbe Eingabe unterschiedliche Pfade nehmen kann. Noch wichtiger ist, dass sie im Namen des Unternehmens handeln können. Sie geben Zusagen ab: Rückerstattungen, Richtlinien, Versprechen. Und wenn eine davon falsch ist, bricht nichts zusammen. Eine falsche Antwort klingt exakt wie eine richtige. Die Transaktion gelingt, das Dashboard bleibt grün, und der Kunde geht mit etwas davon weg, dem das Unternehmen nie zugestimmt hat.

Sobald Software Entscheidungen und Zusagen treffen kann und dabei Fehler macht, ohne dies mitzuteilen, benötigt sie ein anderes Betriebsmodell.

Hier kommt der Vergleich mit der Belegschaft ins Spiel. Man verwaltet einen Mitarbeitenden nicht, indem man jede seiner Entscheidungen vorschreibt. Man gibt ihm eine Rolle, legt die damit verbundene Autorität fest und erweitert diese Autorität, sobald er sie verdient hat. Ein Agent verhält sich unter derselben Struktur auf dieselbe Weise.

Ich sehe das so: Autonomie ist keine einmalige Deploy‑Entscheidung, sondern eine Reihe von Beförderungen. Ein Agent verdient jede Stufe, indem er zeigt, dass er die Aufgabe erfüllen kann, innerhalb seiner Autorität bleibt und erkennt, wann er Hilfe benötigt.

Wie sieht ein „HR‑ähnliches“ Betriebsmodell für KI‑Agenten in einem Unternehmen tatsächlich aus, und welche Elemente sollten Unternehmen zuerst implementieren?

Beginnen Sie mit der Aufgabe. Jeder Agent sollte eine annähernd klare Stellenbeschreibung haben, bevor er in die Produktion geht. Was soll er erreichen, welche Informationen sind für ihn maßgeblich, welche Kundendaten darf er nutzen, welche Entscheidungen kann er eigenständig treffen und wo endet seine Verantwortung. Wenn ein Unternehmen das nicht in einem Absatz formulieren kann, ist der Agent noch nicht für eine Rolle bereit. Er ist lediglich für eine Demo bereit.

Vier Dinge ergeben sich aus dieser Rolle, und die Reihenfolge ist entscheidend. Evidenz vor dem Start, das bedeutet, zu beweisen, dass der Agent die Aufgabe unter realweltähnlichen Bedingungen und nicht nur in einem kontrollierten Test ausführen kann. Aufsicht während des Betriebs, damit Sie wissen, was der Agent tatsächlich getan hat und nicht nur, ob das System reagiert hat. Beförderungs­schwellen, bei denen mehr Autorität erst gewährt wird, wenn entsprechende Nachweise vorliegen, und nicht vorher. Und ein Eigentümer im Geschäftsbereich, nicht in der Technik, der für das, was der Agent tun darf, verantwortlich ist.

Wenn die Reihenfolge falsch ist, hält der Rest nicht. Ist die Verantwortung vage, lässt sich gute Leistung nicht nachweisen, ebenso wenig wie ein Versagen. Die Rolle kommt zuerst, die Evidenz folgt.

Wenn einem KI‑Agenten eine bestimmte Rolle zugewiesen wird, wie sollten Unternehmen seine Verantwortlichkeiten, Berechtigungen und Grenzen definieren, bevor er mit Kunden oder kritischen Systemen interagieren darf?

Die Rolle gibt an, wofür der Agent gedacht ist. Die Berechtigungen geben an, worauf er zugreifen kann. Das sind zwei unterschiedliche Gespräche, und Unternehmen haben in der Regel nur das erste.

Seien Sie bei drei Punkten eindeutig. Welche Systeme und Daten der Agent berühren kann und in welche Richtung, denn das Lesen eines Kundendatensatzes und das Ändern desselben sind nicht dieselbe Berechtigung. Was er eigenständig vertraglich festlegen kann, also wo Geld und Haftung liegen: eine Rückerstattung, ein Guthaben, eine Ausnahme von der Richtlinie. Und was einen Übergang auslöst, sowohl die Fälle, die Sie im Voraus benennen können, als auch das Signal, dass der Agent seine Kompetenz überschritten hat.

Dies sind keine Entscheidungen, die dem Technologie‑Team überlassen werden sollten. Sie bestimmen das Risiko, das das Unternehmen eingeht. Die Verantwortlichen für das Kundenerlebnis und die Compliance‑Exposition müssen ein Mitspracherecht bei der Festlegung dieser Grenzen haben, und sie werden in der Regel zuletzt gefragt.

Dann muss man nachweisen, dass der Agent innerhalb dieser Grenzen bleibt. Das Ziel ist nicht, jeden möglichen Fehler zu eliminieren. Es wird Fehler geben. Die Frage ist, ob der Agent seine Grenzen versteht, weiß, wann er stoppen muss, und die ihm zugewiesene Aufgabe erledigen kann, ohne an anderer Stelle in der Customer Journey Konsequenzen zu erzeugen.

Sie argumentieren, dass größere Autonomie verdient und nicht von Anfang an gewährt werden sollte. Was muss ein KI‑Agent nachweisen, bevor ein Unternehmen den Umfang der Aktionen, die er eigenständig ausführen kann, erweitert?

Es ist heute einfach, einen KI‑Agenten zu bauen. Der schwierige Teil ist, zu beweisen, dass er Autonomie verdient.

Bevor ein Unternehmen erweitert, was ein Agent eigenständig tun darf, benötigt es Nachweise, dass er seine zugewiesene Aufgabe konsequent erfüllt und innerhalb seiner Grenzen bleibt. Das bedeutet, wie er die erwarteten Situationen bewältigt und auch die, die Sie nicht vorausgesehen haben. Ein Agent kann unter kontrollierten Bedingungen stark wirken und sich anders verhalten, wenn sich der Kontext oder die umgebenden Systeme ändern.

Ein Kunde kann mit einer einfachen Rechnungsfrage beginnen und nach einer fehlgeschlagenen Zahlung frustriert werden. Der Agent muss diese Veränderung in Echtzeit erkennen und den Kurs ändern, anstatt den Pfad weiterzuverfolgen, für den er validiert wurde.

Drei Dinge sollten wahr sein, bevor die Befugnisse erweitert werden. Der Agent erledigt die Aufgabe unter realen Bedingungen, nicht nur unter idealen. Er kennt die Grenzen seiner eigenen Kompetenz und stoppt dort. Und jemand kann auf Abruf Nachweise für beides erbringen.

Der Nachweisgrad muss dem Autonomiegrad entsprechen. Kleine Entscheidungen, leichter Nachweis. Zugriff auf ein Zahlungssystem oder die Möglichkeit, das Unternehmen zu einer Richtlinienausnahme zu verpflichten, erfordern ein deutlich höheres Niveau.

Wie sollten Unternehmen die Leistung von KI‑Agenten kontinuierlich bewerten, sobald sie im Einsatz sind, insbesondere wenn die Qualität ihrer Entscheidungen nicht allein durch traditionelle Software‑Testmetriken erfasst werden kann?

Hier scheitert das traditionelle Software‑Denken. Bei deterministischer Software testen Sie, ob etwas bestanden oder fehlgeschlagen ist. Bei einem KI‑Agenten kann das System eine erfolgreiche Antwort geben, während die Kundeninteraktion dennoch fehlschlägt.

Daher bewerten Sie das Ergebnis, nicht die Antwort. Hat der Agent verstanden, was der Kunde erreichen wollte? Hat er die richtigen Informationen verwendet? Hat er die Reise abgeschlossen? Ist er innerhalb seiner Grenzen geblieben und hat eskaliert, wenn es nötig war?

Grundlegende Bewertungen, bei denen Antworten gegen ein Gold‑Set bewertet werden, bilden das Minimum. Jedes Unternehmen wird solche haben. Die Dimensionen, die darüber entscheiden, ob ein Kunde Ihnen weiterhin vertraut, liegen darunter: Compliance, Verzerrungen, Missbrauch und wie der Agent mit echten Anrufern, deren Akzenten, Hintergrundgeräuschen, billigen Telefonen und Unterbrechungen mitten im Satz zurechtkommt. Bei Sprache ist das wichtiger, als viele erwarten, weil jede Bewertung auf einem Transkript basiert. Wenn die Spracherkennung die Frage falsch versteht, beantwortet der Agent eine Frage, die niemand gestellt hat.

Die Rechnung lohnt sich, genauer hinzusehen. Ein Bewertungsergebnis von 99 % klingt hervorragend. Bei einer Million Gesprächen pro Jahr sind das zehntausend fehlgeschlagene.

Zwei Grundsätze gelten. Die Validierung sollte unabhängig vom Agenten und den Modellplattformen sein. Wir bauen die Agenten nicht selbst, weshalb ich klar sagen kann, dass kein Anbieter seine eigene KI beurteilen sollte. Maßstab sind die eigenen Richtlinien des Unternehmens, seine Kundenverpflichtungen und regulatorischen Pflichten, nicht das Scorecard eines Anbieters.

Und jeder Produktionsfehler sollte zu einem Gate werden. Nicht zu einem Ticket, nicht zu einem Backlog‑Eintrag. Ein Test, den der Agent vor dem nächsten Release bestehen muss. Wenn ein Problem in der Produktion auftritt und nicht zu einem Test wird, den der Agent bestehen muss, zahlen Sie dafür, dasselbe Problem zweimal zu entdecken.

Vertrauen und Governance werden zunehmend als wesentliche Hindernisse für die Skalierung agentischer KI genannt. Glauben Sie, dass die Technologie schneller voranschreitet als die Fähigkeit von Unternehmen, sie zu überwachen, und welche Risiken entstehen dadurch?

Ich denke, genau das passiert, und die Lücke ist strukturell und nicht das Ergebnis mangelnder Anstrengungen. Eine Idee kann innerhalb von Wochen zu einem kundenorientierten Agenten werden. Die operative Disziplin rund um diesen Agenten, die Verantwortung, die Nachweise, die Aufsicht benötigen jedoch deutlich länger, weil Menschen und Verantwortlichkeit involviert sind und nicht nur Software.

Das Risiko besteht darin, dass die Lücke unsichtbar bleibt, während sie sich vergrößert. Ein Agent kann einem Kunden eine selbstbewusst falsche Antwort geben, ohne Fehler, ohne fehlgeschlagene Transaktion und ohne Alarm. Jeder Dashboard sieht grün aus. Traditionelle Abläufe hängen davon ab, dass Systeme einem mitteilen, wann sie in Schwierigkeiten sind, und Agenten tun das nicht zuverlässig.

Ich glaube nicht, dass die Antwort darin besteht, langsamer zu werden. Die Unternehmen, die hier gewinnen, werden schnell handeln. Die Antwort ist, die Evidenz und Aufsicht aufzubauen, die es Ihnen ermöglichen, schnell und mit Zuversicht zu handeln. Je mehr Autonomie ein Agent erhält, desto mehr Evidenz benötigen Sie, dass er die Verantwortung tragen kann.

Wenn ein autonomer Agent eine schlechte Entscheidung trifft, wer sollte letztlich verantwortlich sein: der Entwickler, die Geschäftseinheit, die ihn einsetzt, der Anbieter des Modells oder die Führungskraft, die seine Nutzung genehmigt hat?

Letztlich gehört das Ergebnis dem Unternehmen, das den Agenten einsetzt. Mehrere Parteien sind am Aufbau und Betrieb des Systems beteiligt, aber der Kunde hat keine Beziehung zum Modellanbieter. Der Kunde hat eine Beziehung zu dem Unternehmen, dessen Name auf der Interaktion steht.

Das bedeutet nicht, dass die Verantwortung bei einer Person liegt. Sie verläuft durch die Entscheidungskette. Der Entwickler ist für den Aufbau des Systems verantwortlich. Das Unternehmen entscheidet, was der Agent tun darf. Der Anbieter ist für die bereitgestellte Technologie verantwortlich. Die Führungsebene ist dafür verantwortlich, dass das Unternehmen die Kontrollen und die Aufsicht hat, um das Risiko insgesamt zu managen.

Der Irrtum besteht darin zu denken, dass das Modell, weil es die Entscheidung getroffen hat, auch dafür verantwortlich ist. Das ist nicht der Fall. Wenn ein Agent im Namen Ihres Unternehmens einem Kunden ein Versprechen gibt, gehört dieses Versprechen zur Marke. Kunden verstehen das intuitiv, und das tun auch die Regulierungsbehörden.

KI‑Agenten können sich unvorhersehbar verhalten, wenn sie auf Situationen stoßen, die während der Tests nicht antizipiert wurden. Wie sollten Unternehmen diese Randfälle testen, bevor Agenten Zugang zu Kunden, Finanzsystemen oder sensiblen Daten erhalten?

Man muss davon ausgehen, dass der Agent irgendwann auf etwas stößt, für das er nicht konzipiert wurde. Die Frage ist, was passiert, wenn das eintritt.

Validieren Sie also über den erwarteten Pfad hinaus. Geben Sie dem Agenten mehrdeutige Anfragen. Geben Sie ihm widersprüchliche Informationen. Geben Sie ihm unvollständigen Kontext. Versetzen Sie ihn in Situationen, in denen die richtige Antwort darin besteht, anzuhalten und zu eskalieren, anstatt weiterzumachen. Fügen Sie die Bedingungen der realen Welt hinzu, was bei Sprache Akzente, Hintergrundgeräusche, schlechte Verbindungen und Anrufer bedeutet, die das Thema mitten im Gespräch wechseln. Das Ziel ist nicht zu bestätigen, dass der Agent funktioniert. Es geht darum herauszufinden, wie er sich verhält, wenn die Bedingungen nicht sauber sind.

Der wichtigere Punkt ist, dass Sie die gesamte Reise validieren müssen, nicht den Agenten isoliert. Das Modell ist in der Regel nicht das Problem. Wenn etwas schiefgeht, ist meine erste Frage, welchen Kontext das Modell erhalten hat. Es könnte ein veralteter Wissensartikel gewesen sein, oder zwei Systeme, die widersprüchliche Richtlinien haben, oder ein Übergang, bei dem das, was der Kunde bereits erklärt hatte, verloren ging. Jede Komponente kann ihren eigenen Test bestehen, und dennoch kann die Kundenreise an den Übergängen zwischen ihnen scheitern.

Diese Schicht zwischen den Systemen ist die, die wir über Jahre hinweg instrumentiert haben, über 450 Unternehmen und mehr als 350 Millionen Kundenreisen pro Jahr hinweg. Agentisch oder nicht, sie bricht auf dieselbe Weise. Wir sehen auch Agenten, die auf mehr als 55 verschiedenen Anbietertechnologien basieren, plus jede große Contact‑Center‑Plattform, was uns zeigt, dass das Muster unabhängig vom zugrunde liegenden Modell gilt.

Bevor ein Agent Zugang zu etwas Wichtigem erhält, sollte das Unternehmen Evidenz darüber haben, was er tut, wenn alles gut läuft, und wenn nicht.

Wie sehen Sie die Entwicklung des KI‑Testens, wenn Unternehmen von deterministischer Software zu Systemen übergehen, die denken, planen, kommunizieren und Aktionen über mehrere Anwendungen hinweg ausführen?

Das Testen muss sich von der Frage, ob ein System die erwartete Antwort liefert, hin zur Frage bewegen, ob es das richtige Ergebnis erzielt.

Das ist ein bedeutender Wandel. Ein Agent kann mehrere verschiedene Wege gehen, um dasselbe Kundenproblem zu lösen, und diese Wege können sich im Laufe der Zeit ändern, wenn sich die Modelle und das dahinterstehende Wissen ändern. Man kann nicht für jede mögliche Interaktion ein Skript schreiben. Man muss bewerten, ob der Agent die Absicht verstanden hat, fundierte Entscheidungen getroffen hat und innerhalb der vorgegebenen Grenzen geblieben ist.

Ich möchte bei einer Sache vorsichtig sein, weil die Branche beginnt, dies auf teure Weise falsch zu machen. Tests vor dem Start sind jetzt wichtiger denn je, nicht weniger. Sie bestimmen, ob ein Agent bereit ist. Das Argument, man könne sie überspringen und stattdessen die Produktion beobachten, ist ein Argument dafür, es erst vor den Kunden herauszufinden.

Was sich ändert, ist, dass Tests vor dem Start nicht mehr das Ende des Prozesses darstellen. Die Produktion deckt Bedingungen auf, die eine kontrollierte Umgebung nicht vollständig reproduzieren kann, und das, was die Produktion aufdeckt, wird zu einem Test, den der Agent vor dem nächsten Release bestehen muss. Nachweis vor dem Start, Wachsamkeit in der Produktion, und beides nährt das andere. Der Agent, der im sechsten Monat läuft, sollte messbar besser sein als der, der beim Start eingesetzt wurde.

Wenn wir in die Zukunft blicken, was wird die Organisationen unterscheiden, die erfolgreich vertrauenswürdige KI‑Belegschaften aufbauen, von denen, die weiterhin kleine agentische KI‑Pilotprojekte betreiben?

Die Unternehmen, die echten Nutzen aus Agenten ziehen, sind diejenigen, die ein Betriebsmodell auf Basis von Evidenz aufgebaut haben. Die, die stagnieren, werden in der Regel nicht durch die Technologie blockiert. Sie werden blockiert, weil niemand das liefern kann, was die nächste Genehmigungsebene verlangt. Die Rechtsabteilung stellt eine berechtigte Frage, oder das Risikokomitee tut es, und es gibt keine Antwort, sodass der Pilot ein Pilot bleibt. Die Technologie mag bereit sein, und das Unternehmen kann dennoch nicht rechtfertigen, ihr mehr Befugnisse zu geben.

Das ist der Unterschied zwischen einem Pilotprojekt und einer operativen Belegschaft. In einem Pilotprojekt beobachtet stets jemand. In einem Betriebsmodell hat jeder Agent eine Aufgabe, die man in einem Satz formulieren kann. Seine Befugnisse sind begrenzt und schriftlich festgelegt. Seine Leistung wird von etwas anderem bewertet als vom Team, das ihn entwickelt hat. Produktionsfehler werden zu Freigabeschranken. Mehr Autonomie folgt dem Nachweis.

Der zweite Unterschied ist das Eigentum. In den Unternehmen, die skalieren, gehört der Agent zu der Geschäfts‑Funktion, die er unterstützt, mit einem benannten Eigentümer, der für seine Tätigkeit verantwortlich ist. Bleibt er ein KI‑Projekt, das einem KI‑Team gehört, bleibt er klein, weil kein Geschäftsleiter das Risiko übernehmen wird, das er nicht kontrolliert.

Nichts davon ist exotisch. Es kommt dem Vorgehen nahe, wie ein Unternehmen bereits die Personen verwaltet, denen es echte Verantwortung anvertraut.

Ein Pilot kann auf der Überzeugung einer Organisation basieren. Skalierung erfordert Evidenz.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten Cyara besuchen.