Sushil Kumar, CEO Cyara – Seria wywiadów

Sushil Kumar, CEO Cyara jest doświadczonym menedżerem oprogramowania korporacyjnego i przedsiębiorcą z ponad 25‑letnim doświadczeniem przywódczym w dziedzinie sztucznej inteligencji, DevOps, infrastruktury chmurowej, strategii produktu i testowania oprogramowania. Dołączył do Cyara jako CEO w grudniu 2025 r., po pełnieniu funkcji współzałożyciela i CEO RelicX.ai, gdzie stworzył generatywną platformę automatyzacji testów opartą na sztucznej inteligencji i intencjach, którą przejęła firma Harness. Następnie poprowadził integrację technologii RelicX z Harness i pomógł ukształtować jej strategię AI Test Automation. Wcześniej w swojej karierze Kumar pełnił funkcję General Manager DevOps w Broadcom, Senior Vice President of Products w CA Technologies oraz spędził ponad 16 lat w Oracle, gdzie zajmował wysokie stanowiska kierownicze w obszarze produktów i pomagał rozwijać duże przedsiębiorstwa oprogramowania korporacyjnego. W tych rolach koncentrował się na budowaniu i skalowaniu platform AI, chmury, DevOps i automatyzacji dla dużych przedsiębiorstw. Jego powołanie w Cyara ma na celu rozszerzenie możliwości zapewniania doświadczeń klienta opartego na AI oraz zwiększenie zasięgu globalnego firmy.

Cyara jest firmą zapewniającą jakość doświadczeń klienta, pomagającą przedsiębiorstwom testować, monitorować i weryfikować interakcje z klientami w kanałach głosowych, cyfrowych, wiadomości oraz konwersacyjnej AI. Jej platforma Cyara Agentic Platform została zaprojektowana, aby sprostać rosnącym wyzwaniom wynikającym z doświadczeń klienta napędzanych przez AI, w tym testowaniu niedeterministycznych agentów AI, wykrywaniu halucynacji i dryfu zachowań, weryfikacji zgodności, monitorowaniu systemów produkcyjnych oraz ocenie kompleksowych ścieżek klienta. Platforma łączy testowanie agentów AI, monitorowanie produkcji, zapewnianie jakości głosu i telekomunikacji, testowanie kanałów cyfrowych oraz obserwowalność CX, obsługując ponad 350 milionów podróży klientów rocznie w globalnym zasięgu obejmującym ponad 140 krajów. W miarę jak przedsiębiorstwa wdrażają coraz bardziej autonomiczne agenty AI w procesach obsługi klienta, Cyara pozycjonuje swoją technologię jako warstwę zapewniającą wiarygodną, bezpieczną i spójną ocenę działania tych systemów przed i po wdrożeniu.

Spędziłeś dużą część swojej kariery budując i skalując oprogramowanie korporacyjne, od Oracle i CA/Broadcom po założenie Relicx i obecne prowadzenie Cyara. Jak to doświadczenie ukształtowało Twoje przekonanie, że agenty AI powinny być zarządzane mniej jak tradycyjne oprogramowanie, a bardziej jak członkowie siły roboczej?

Większość mojej kariery poświęciłem na budowanie i skalowanie oprogramowania korporacyjnego, a dyscyplina, którą tam wprowadziliśmy, opierała się na systemach deterministycznych. Wiesz, co oprogramowanie ma robić. Weryfikujesz je względem tych oczekiwań. Gdy się zawiedzie, informuje cię: błąd, nieudana transakcja, alert.

Agenci AI nie działają w ten sposób. Są niedeterministyczni, więc to samo wejście może prowadzić do innej ścieżki. Co ważniejsze, mogą działać w imieniu firmy. Składają zobowiązania: zwroty, polityki, obietnice. A gdy któreś z nich jest błędne, nic się nie psuje. Błędna odpowiedź brzmi dokładnie jak prawidłowa. Transakcja się udaje, pulpit pozostaje zielony, a klient odchodzi z czymś, na co firma nigdy się nie zgodziła.

Gdy oprogramowanie może podejmować decyzje i zobowiązania oraz może się mylić, nie informując cię, potrzebuje innego modelu operacyjnego.

Właśnie tu porównanie do siły roboczej nabiera sensu. Nie zarządzasz pracownikiem, pisząc skrypt dla każdej decyzji, jaką podejmie. Przydzielasz mu rolę, określasz przysługujące jej uprawnienia i rozszerzasz te uprawnienia w miarę ich zdobywania. Agent zachowuje się tak samo w tej samej strukturze.

Moim zdaniem autonomię nie decyduje się przy wdrożeniu. To seria awansów. Agent zdobywa każdy z nich, wykazując, że potrafi wykonać zadanie, pozostaje w granicach swoich uprawnień i rozpoznaje, kiedy potrzebuje pomocy.

Jak wygląda w praktyce model operacyjny dla agentów AI przypominający HR w przedsiębiorstwie i które elementy firmy powinny wprowadzić w pierwszej kolejności?

Zacznij od roli. Każdy agent powinien mieć coś w rodzaju opisu stanowiska, zanim trafi do produkcji. Co ma osiągnąć, jakie informacje są dla niego autorytatywne, jakie dane klienta może wykorzystywać, jakie decyzje może podejmować samodzielnie i gdzie kończy się jego odpowiedzialność. Jeśli firma nie potrafi tego zapisać w jednym akapicie, agent nie jest gotowy na rolę. Jest gotowy na demonstrację.

Cztery elementy wynikają z tej roli i kolejność ma znaczenie. Dowody przed uruchomieniem, czyli udowodnienie, że agent potrafi wykonać zadanie w warunkach przypominających rzeczywistość, a nie jedynie w kontrolowanym teście. Nadzór w trakcie działania, aby wiedzieć, co agent faktycznie zrobił, a nie tylko, czy system odpowiedział. Bramy awansowe, które przyznają większe uprawnienia, gdy istnieją dowody je potwierdzające, a nie wcześniej. I właściciel w dziale biznesowym, nie w inżynierii, odpowiedzialny za to, co agent może robić.

Jeśli kolejność zostanie pomieszana, reszta traci sens. Gdy odpowiedzialność jest niejasna, nie da się udowodnić dobrego wyniku, tak samo jak niepowodzenia. Najpierw definiuje się rolę, a dopiero potem gromadzi się dowody.

Jeśli agentowi AI przydzielona zostanie konkretna rola, w jaki sposób organizacje powinny określić jego odpowiedzialności, uprawnienia i granice przed zezwoleniem na interakcję z klientami lub krytycznymi systemami?

Rola określa, do czego agent jest przeznaczony. Uprawnienia określają, do czego może mieć dostęp. To dwie różne rozmowy, a firmy zazwyczaj mają tylko pierwszą.

Bądź konkretny w kwestii trzech rzeczy. Jakie systemy i dane agent może dotknąć i w jakim kierunku, ponieważ odczytanie rekordu klienta i jego zmiana to nie to samo uprawnienie. Co może samodzielnie zobowiązać się zrobić, czyli gdzie leżą pieniądze i odpowiedzialność: zwrot, kredyt, wyjątek od polityki. I co wymusza przekazanie, zarówno przypadki, które możesz wymienić z góry, jak i sygnał, że agent wykracza poza swoją kompetencję.

Nie są to decyzje, które należy pozostawić zespołowi technologicznemu. To oni określają ryzyko, jakie firma podejmuje. Osoby odpowiedzialne za doświadczenie klienta i ekspozycję na zgodność muszą mieć wpływ na wyznaczanie tych granic i zazwyczaj są ostatnimi, do których się zwraca.

Następnie musisz udowodnić, że agent pozostaje w ich granicach. Celem nie jest wyeliminowanie każdego możliwego błędu. Błędy będą się zdarzać. Pytanie brzmi, czy agent rozumie swoje granice, wie, kiedy się zatrzymać, i potrafi wykonać powierzone zadanie, nie wywołując konsekwencji w innym miejscu podróży klienta.

Twierdzisz, że większa autonomia powinna być zdobyta, a nie przyznana od samego początku. Co powinien wykazać agent AI, zanim przedsiębiorstwo rozszerzy zakres działań, które może podejmować samodzielnie?

Obecnie łatwo jest zbudować agenta AI. Trudną częścią jest udowodnienie, że zasługuje na autonomię.

Zanim przedsiębiorstwo rozszerzy, co agent może robić samodzielnie, potrzebne są dowody, że wykonuje przydzielone zadanie konsekwentnie i pozostaje w swoich granicach. Oznacza to, jak radzi sobie w sytuacjach, które przewidujesz, a także w tych, których się nie spodziewałeś. Agent może wydawać się solidny w warunkach kontrolowanych, a zachowywać się inaczej, gdy zmieni się kontekst lub otaczające systemy.

Klient może rozpocząć od prostego pytania o fakturę, a po nieudanej płatności stać się sfrustrowany. Agent musi rozpoznać tę zmianę w trakcie jej trwania i zmienić kurs, zamiast kontynuować ścieżkę, na której został zweryfikowany.

Trzy rzeczy powinny być spełnione, zanim władza zostanie rozszerzona. Agent wykonuje zadanie w rzeczywistych warunkach, nie tylko w czystych. Zna granice swojej kompetencji i zatrzymuje się na nich. I ktoś może na żądanie przedstawić dowody na oba te aspekty.

Poziom dowodu musi odpowiadać poziomowi autonomii. Małe decyzje, lekkie dowody. Dostęp do systemu płatności lub możliwość zobowiązania firmy do wyjątku od polityki powinny wymagać znacznie wyższego progu.

Jak firmy powinny stale oceniać wydajność agentów AI po ich wdrożeniu, szczególnie gdy jakość ich decyzji nie może być uchwycona wyłącznie przez tradycyjne metryki testowania oprogramowania?

Tutaj tradycyjne myślenie o oprogramowaniu się rozpada. W przypadku deterministycznego oprogramowania testujesz, czy coś przeszło, czy nie. W przypadku agenta AI możesz otrzymać pomyślną odpowiedź od systemu, a mimo to mieć nieudaną interakcję z klientem.

Dlatego oceniasz rezultat, a nie odpowiedź. Czy agent zrozumiał, co klient chciał osiągnąć? Czy użył właściwych informacji? Czy zakończył proces? Czy pozostał w swoich granicach i eskalował, gdy powinien był to zrobić?

Podstawowe oceny, punktowanie odpowiedzi w stosunku do zestawu wzorcowego, to minimum. Każda firma będzie je posiadać. Wymiary, które decydują o tym, czy klient nadal Ci ufa, leżą pod spodem: zgodność, uprzedzenia, nadużycia oraz to, jak agent radzi sobie z prawdziwymi rozmówcami, ich akcentami, hałasem w tle, tanim słuchawką, przerywaniem w połowie zdania. W przypadku głosu ma to większe znaczenie niż ludzie się spodziewają, ponieważ każdy wynik opiera się na transkrypcji. Jeśli warstwa mowy błędnie zrozumie pytanie, agent odpowiada na pytanie, którego nikt nie zadał.

Warto poświęcić czas na przeliczenia. Wynik 99% w ocenie brzmi doskonale. Przy milionie rozmów rocznie oznacza to dziesięć tysięcy nieudanych.

Dwie zasady się utrzymują. Walidacja powinna być niezależna od platformy agenta i modelu. Nie budujemy agentów sami, co częściowo tłumaczy, dlaczego mogę otwarcie stwierdzić, że żaden dostawca nie powinien oceniać własnej AI. Standardem są własne polityki przedsiębiorstwa, jego zobowiązania wobec klientów oraz obowiązki regulacyjne, a nie karta wyników dostawcy.

Każda awaria w produkcji powinna stać się bramą. Nie zgłoszeniem, nie elementem backlogu. Testem, który agent musi zaliczyć przed wypuszczeniem kolejnej wersji. Jeśli problem wystąpi w produkcji i nie przekształci się w coś, co agent musi przejść, płacisz podwójnie za odkrycie tego samego problemu.

Zaufanie i zarządzanie są coraz częściej wymieniane jako główne bariery w skalowaniu AI agentowego. Czy uważasz, że technologia rozwija się szybciej niż zdolność przedsiębiorstw do jej nadzorowania, i jakie ryzyka to stwarza?

Uważam, że dokładnie tak się dzieje, a luka ma charakter strukturalny, a nie wynika z braku wysiłku. Pomysł może stać się agentem obsługującym klientów w ciągu kilku tygodni. Dyscyplina operacyjna wokół tego agenta, własność, dowody, nadzór wymagają znacznie więcej czasu, ponieważ angażują ludzi i odpowiedzialność, a nie tylko oprogramowanie.

Ryzyko polega na tym, że luka pozostaje niewidoczna, jednocześnie się poszerzając. Agent może udzielić klientowi pewnej, ale błędnej odpowiedzi bez żadnego błędu, nieudanej transakcji i bez alertu. Każdy pulpit wygląda na zielono. Tradycyjne operacje zależą od systemów informujących, kiedy mają problemy, a agenty nie robią tego niezawodnie.

Nie sądzę, że odpowiedzią jest zwolnienie tempa. Firmy, które tutaj wygrają, będą działać szybko. Odpowiedzią jest zbudowanie dowodów i nadzoru, które pozwolą Ci poruszać się szybko z pewnością. Im większą autonomię otrzymuje agent, tym więcej dowodów potrzebujesz, aby mógł ponosić odpowiedzialność.

Kiedy autonomiczny agent podejmuje złą decyzję, kto ostatecznie powinien ponosić odpowiedzialność: deweloper, jednostka biznesowa wdrażająca go, dostawca modelu czy dyrektor, który zatwierdził jego użycie?

Ostatecznie firma wdrażająca agenta ponosi odpowiedzialność za wynik. W budowie i eksploatacji systemu uczestniczy kilka podmiotów, ale klient nie ma relacji z dostawcą modelu. Klient ma relację z firmą, której nazwa widnieje w interakcji.

To nie oznacza, że odpowiedzialność spoczywa na jednej osobie. Przechodzi ona przez łańcuch decyzyjny. Deweloper jest odpowiedzialny za to, jak system został zbudowany. Biznes decyduje, co agent może robić. Dostawca jest odpowiedzialny za technologię, którą dostarcza. Kierownictwo jest odpowiedzialne za zapewnienie, że firma posiada kontrolę i nadzór niezbędny do zarządzania ryzykiem.

Błędem jest myślenie, że ponieważ model podjął decyzję, to model ją posiada. To nieprawda. Jeśli agent zobowiązuje się wobec klienta w Twoim imieniu, to zobowiązanie należy do marki. Klienci rozumieją to intuicyjnie, podobnie jak regulatorzy.

Agenty AI mogą zachowywać się nieprzewidywalnie, gdy napotykają sytuacje nieprzewidziane podczas testów. Jak przedsiębiorstwa powinny testować takie przypadki brzegowe, zanim agenty uzyskają dostęp do klientów, systemów finansowych lub wrażliwych danych?

Musisz założyć, że agent ostatecznie napotka coś, do czego nie został zaprojektowany. Pytanie brzmi, co się stanie, gdy tak się stanie.

Dlatego weryfikuj poza przewidywaną ścieżką. Daj agentowi niejednoznaczne żądania. Dostarcz mu sprzeczne informacje. Zapewnij niepełny kontekst. Umieść go w sytuacjach, w których właściwą odpowiedzią jest zatrzymanie się i eskalacja, a nie kontynuowanie. Dodaj warunki rzeczywistego świata, co w przypadku głosu oznacza akcenty, szumy, słabe połączenia i rozmówców, którzy zmieniają temat w połowie rozmowy. Celem nie jest potwierdzenie, że agent działa, lecz dowiedzenie się, jak zachowuje się, gdy warunki nie są czyste.

Bardziej istotną kwestią jest to, że musisz weryfikować całą podróż, a nie agenta w izolacji. Model zazwyczaj nie jest problemem. Gdy coś idzie nie tak, pierwsze pytanie brzmi, jaki kontekst otrzymał model. Może to być przestarzały artykuł wiedzy, dwa systemy z sprzecznymi politykami lub przekaz, w którym utracono to, co klient już wyjaśnił. Każdy komponent może przejść własny test, a podróż klienta nadal może zawieść w miejscach ich połączenia.

Ta warstwa pomiędzy systemami to ta, którą przez lata instrumentowaliśmy, obsługując 450 przedsiębiorstw i ponad 350 milionów podróży klientów rocznie. Niezależnie od tego, czy jest agentowa, czy nie, psuje się w ten sam sposób. Widzimy także agenty oparte na technologii ponad 55 różnych dostawców, a także na każdej głównej platformie centrum kontaktowego, co pozwala nam stwierdzić, że wzorzec utrzymuje się niezależnie od tego, jaki model leży u podstaw.

Zanim agent uzyska dostęp do istotnych zasobów, przedsiębiorstwo powinno mieć dowody na to, co robi, gdy wszystko przebiega pomyślnie, oraz gdy nie.

Jak widzisz ewolucję testowania AI, gdy firmy przechodzą od deterministycznego oprogramowania do systemów, które rozumują, planują, komunikują się i podejmują działania w wielu aplikacjach?

Testowanie musi przejść od pytania, czy system wyprodukował oczekiwaną odpowiedź, do pytania, czy osiągnął właściwy rezultat.

To znacząca zmiana. Agent może podjąć kilka różnych ścieżek, aby rozwiązać ten sam problem klienta, a ścieżki te mogą zmieniać się w czasie, gdy modele i wiedza za nimi stojąca ewoluują. Nie można napisać skryptu na każdą możliwą interakcję. Należy ocenić, czy agent zrozumiał intencję, podejmował rozsądne decyzje po drodze i pozostawał w wyznaczonych granicach.

Chcę zwrócić uwagę na jedną kwestię, ponieważ branża zaczyna popełniać kosztowne błędy. Testy przed uruchomieniem mają teraz większe znaczenie, a nie mniejsze. To one określają, czy agent jest gotowy. Argument, że można je pominąć i obserwować produkcję, jest argumentem za odkryciem problemów przed klientami.

Zmiana polega na tym, że testy przed uruchomieniem nie są już końcem procesu. Produkcja ujawnia warunki, których kontrolowane środowisko nie może w pełni odtworzyć, a to, co produkcja ujawnia, staje się testem, który agent musi zaliczyć przed kolejną wersją. Dowód przed uruchomieniem, czujność w produkcji i wzajemne wzmacnianie się tych elementów. Agent działający w szóstym miesiącu powinien być wyraźnie lepszy niż ten, który został uruchomiony.

Patrząc w przyszłość, co odróżni organizacje, które skutecznie budują zaufane zespoły AI, od tych, które wciąż utknęły przy małych pilotach agentowych AI?

Organizacje, które uzyskują rzeczywisty zwrot z agentów, to te, które zbudowały model operacyjny oparty na dowodach. Te, które się zaciągają, zazwyczaj nie są zablokowane przez technologię. Są blokowane, ponieważ nikt nie może dostarczyć tego, czego wymaga kolejny poziom zatwierdzenia. Dział prawny zadaje uzasadnione pytanie, podobnie robi to komitet ds. ryzyka, i nie ma odpowiedzi, więc pilotaż pozostaje pilotażem. Technologia może być gotowa, a organizacja wciąż nie może uzasadnić przyznania jej większych uprawnień.

To jest różnica między pilotażem a operacyjną siłą roboczą. W pilotażu ktoś zawsze obserwuje. W modelu operacyjnym każdy agent ma zadanie, które można sformułować w jednym zdaniu. Jego uprawnienia są ograniczone i zapisane. Jego wydajność jest oceniana przez coś innego niż zespół, który go stworzył. Niepowodzenia w produkcji stają się barierami wydania. Większa autonomia następuje po udowodnieniu.

Drugą różnicą jest własność. W firmach, które skalują, agent należy do funkcji biznesowej, którą obsługuje, i ma wyznaczonego właściciela, który odpowiada za jego działania. Tam, gdzie pozostaje projektem AI będącym własnością zespołu AI, pozostaje mały, ponieważ żaden lider biznesowy nie przejmie ryzyka czegoś, nad czym nie ma kontroli.

Nic z tego nie jest egzotyczne. To jest zbliżone do tego, jak firma już zarządza ludźmi, którym powierza rzeczywistą odpowiedzialność.

Pilotaż może opierać się na przekonaniu organizacji. Skalowanie wymaga dowodów.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Cyara.