Sushil Kumar, CEO společnosti Cyara – Série rozhovorů

Sushil Kumar, CEO společnosti Cyara, je zkušený výkonný ředitel a podnikatel v oblasti podnikového softwaru s více než 25 lety vedení napříč umělou inteligencí, DevOps, cloudovou infrastrukturou, produktovou strategií a testováním softwaru. Do Cyary nastoupil jako CEO v prosinci 2025 po své roli spoluzakladatele a CEO společnosti RelicX.ai, kde vybudoval platformu pro generativní AI‑poháněnou, na záměrech založenou automatizaci testování, která byla odkoupena společností Harness. Následně vedl integraci technologie RelicX do Harness a pomohl formovat její strategii AI Test Automation. Dříve ve své kariéře Kumar působil jako generální manažer DevOps ve společnosti Broadcom, jako senior viceprezident produktů ve společnosti CA Technologies a strávil více než 16 let ve společnosti Oracle, kde zastával vedoucí produktové pozice a pomáhal rozšiřovat významné podnikové softwarové podniky. V těchto rolích se soustředil na budování a škálování AI, cloudu, DevOps a automatizačních platforem pro velké podniky. Jeho jmenování v Cyara je zaměřeno na rozšíření schopností společnosti v oblasti AI‑poháněného zajištění zákaznické zkušenosti a na globální dosah.

Cyara je společnost zaměřená na zajištění zákaznické zkušenosti, která pomáhá podnikům testovat, monitorovat a ověřovat interakce se zákazníky napříč hlasem, digitálními kanály, zprávami a konverzačními AI kanály. Její Cyara Agentic Platform je navržena tak, aby řešila rostoucí výzvy vznikající díky AI‑poháněným zákaznickým zkušenostem, včetně testování nedeterministických AI agentů, detekce halucinací a behaviorálního posunu, ověřování souladu, monitorování produkčních systémů a hodnocení end‑to‑end zákaznických cest. Platforma kombinuje testování AI agentů, monitorování produkce, zajištění hlasu a telekomunikací, testování digitálních kanálů a pozorovatelnost CX, podporuje více než 350 milionů zákaznických cest ročně v globálním rozsahu přes více než 140 zemí. Jak podniky nasazují stále autonomnější AI agenty do workflow směřujících k zákazníkům, Cyara svou technologii umisťuje jako vrstvu zajištění pro hodnocení, zda tyto systémy fungují spolehlivě, bezpečně a konzistentně před i po nasazení.

Většinu své kariéry jste věnoval budování a škálování podnikového softwaru, od Oracle a CA/Broadcom po založení Relicx a nyní vedení Cyary. Jak tato zkušenost formovala váš názor, že AI agenti by měli být řízeni spíše jako členové pracovní síly než jako tradiční software?

Cela většinu své kariéry jsem věnoval budování a škálování podnikového softwaru a disciplína, kterou jsme tam vytvořili, byla disciplínou zaměřenou na deterministické systémy. Víte, co má software dělat. Ověřujete jej podle tohoto očekávání. Když selže, oznámí vám to: chyba, neúspěšná transakce, výstraha.

AI agenti takto nefungují. Jsou nedeterminističtí, takže stejný vstup může vést různou cestou. Co je ještě důležitější, mohou jednat jménem společnosti. Přijímají závazky: refundace, politiky, sliby. A když je některý z nich špatný, nic se nezhroutí. Špatná odpověď zní naprosto stejně jako správná. Transakce proběhne úspěšně, dashboard zůstane zelený a zákazník odejde s něčím, na co společnost nikdy nesouhlasila.

Až software může činit rozhodnutí a závazky a může se mýlit, aniž by vás o tom informoval, potřebuje odlišný provozní model.

Právě zde se srovnání s pracovní silou ospravedlňuje. Zaměstnance neřídíte skriptováním každého jeho rozhodnutí. Přidělíte mu roli, stanovíte s ní spojenou pravomoc a tuto pravomoc rozšiřujete, jakmile si ji zaslouží. Agent se chová stejně pod stejnou strukturou.

Podle mého názoru autonomie není rozhodnutím o nasazení. Jedná se o sérii povýšení. Agent si každé povýšení zaslouží tím, že prokáže, že dokáže práci vykonat, zůstane v rámci své pravomoci a rozpozná, kdy potřebuje pomoc.

Jak vypadá „HR‑podobný“ provozní model pro AI agenty uvnitř podniku a které prvky by měly společnosti zřídit jako první?

Začněte u role. Každý agent by měl mít něco blízkého popisu práce, než se dostane k produkci. Co má dosáhnout, jaké informace jsou pro něj autoritativní, jaká zákaznická data může využívat, jaká rozhodnutí může samostatně učinit a kde končí jeho odpovědnost. Pokud společnost nedokáže toto shrnout v odstavci, agent není připraven na roli. Je připraven jen na demonstraci.

Z této role vyplývají čtyři věci a pořadí je důležité. Důkazy před spuštěním, což znamená prokázat, že agent dokáže práci vykonat za podmínek podobných reálnému světu, nikoli jen v kontrolovaném testu. Dohled během provozu, abyste věděli, co agent skutečně udělal, a ne jen, zda systém odpověděl. Přípustné brány pro povýšení, aby byla vyšší pravomoc udělena až po předložení důkazů a ne dříve. A vlastník v podnikové oblasti, nikoli v inženýrství, který je zodpovědný za to, co agent smí dělat.

Špatně zvolené pořadí podkopává celý přístup. Pokud je odpovědnost nejasná, nelze prokázat ani dobrý výkon, ani selhání. Role je první a důkazy následují.

Pokud je AI agentu přiřazena konkrétní role, jak by měly organizace definovat jeho odpovědnosti, oprávnění a hranice, než mu umožní interagovat se zákazníky nebo kritickými systémy?

Role říká, k čemu je agent určen. Oprávnění říkají, k čemu má přístup. Jedná se o dva odlišné rozhovory a firmy mají obvykle jen ten první.

Buďte explicitní ohledně tří věcí. Jaké systémy a data může agent dotýkat a v jakém směru, protože čtení záznamu zákazníka a jeho změna nejsou stejné oprávnění. Co může sám závazně učinit, což je místo, kde leží peníze a odpovědnost: vrácení peněz, kredit, výjimka z politiky. A co nutí předání, jak případy, které můžete předem pojmenovat, tak signál, že agent opustil svou kompetenci.

Nejsou to rozhodnutí, která by měla zůstávat na technickém týmu. Určují riziko, které firma podstupuje. Lidé zodpovědní za zákaznickou zkušenost a za soulad s předpisy potřebují mít slovo v tom, kde se tyto hranice vymezují, a obvykle jsou to poslední, kdo je dotázán.

Pak musíte prokázat, že se agent v nich drží. Cílem není eliminovat každou možnou chybu. Chyby se vyskytnou. Otázkou je, zda agent rozumí svým hranicím, ví, kdy má přestat, a dokáže vykonat svěřenou práci, aniž by vytvořil důsledky jinde v zákaznické cestě.

Tvrdíte, že větší autonomie by měla být získána, nikoli udělena od samého začátku. Co by měl AI agent prokázat, než podnik rozšíří rozsah akcí, které může vykonávat samostatně?

Vytvořit AI agenta je nyní snadné. Těžké je prokázat, že si autonomii zaslouží.

Než rozšíříte, co může agent dělat sám, podnik potřebuje důkazy, že vykonává svěřenou práci konzistentně a zůstává v rámci svých hranic. To zahrnuje, jak řeší situace, které očekáváte, i ty, které jste nepředvídali. Agent může vypadat silně za kontrolovaných podmínek a chovat se jinak, když se změní kontext nebo okolní systémy.

Zákazník může začít s jednoduchou otázkou ohledně fakturace a po neúspěšné platbě se rozčílí. Agent musí tuto změnu rozpoznat v průběhu a změnit směr, místo aby pokračoval po cestě, na které byl ověřen.

Před rozšířením pravomocí by měly platit tři věci. Agent vykonává práci za reálných podmínek, ne jen v čistých. Zná hranice své kompetence a zastaví se na nich. A někdo může na požádání předložit důkazy pro obojí.

Úroveň důkazu musí odpovídat úrovni autonomie. Malá rozhodnutí, lehké důkazy. Přístup k platebnímu systému nebo schopnost zavázat společnost k výjimce z politiky by měl mít podstatně vyšší práh.

Jak by měly společnosti průběžně vyhodnocovat výkon AI agentů po jejich nasazení, zejména když kvalitu jejich rozhodnutí nelze zachytit pouze tradičními metrikami testování softwaru?

Zde selhává tradiční myšlení o softwaru. U deterministického softwaru testujete, zda něco prošlo nebo selhalo. U AI agenta můžete získat úspěšnou odpověď systému a přesto mít neúspěšnou interakci se zákazníkem.

Proto hodnotíte výsledek, ne odpověď. Rozuměl agent tomu, co zákazník chtěl dosáhnout? Použil správné informace? Dokončil cestu? Zůstal v rámci svých hranic a eskaloval, když měl?

Základní hodnocení, skórování odpovědí vůči zlatému souboru, je základ. Každá společnost je bude mít. Rozměry, které rozhodují o tom, zda si zákazník udržuje důvěru, jsou pod nimi: soulad, zaujatost, zneužití a to, jak se agent vypořádá s reálnými volajícími, jejich přízvuky, šumem v pozadí, levným telefonem, přerušením uprostřed věty. Ve hlasové komunikaci to má větší význam, než lidé očekávají, protože každé skóre je podloženo přepisem. Pokud řečová vrstva špatně uslyší otázku, agent odpoví na otázku, kterou nikdo nezeptal.

Výpočet stojí za to si projít. Skóre 99 % v hodnocení zní vynikajícím způsobem. Při milionu konverzací ročně to představuje deset tisíc neúspěšných.

Platí dva principy. Validace by měla být nezávislá na agentovi a platformách modelu. Agenty nejsou naším vlastním vývojem, což je část důvodu, proč mohu jasně říci, že žádný dodavatel by neměl soudcem své vlastní AI. Standardem jsou interní politiky podniku, jeho závazky vůči zákazníkům a regulační povinnosti, nikoli skórovací karta dodavatele.

A každé selhání v produkci by mělo být bránou. Ne ticket, ne položka backlogu. Test, který musí agent projít před vydáním další verze. Pokud se problém objeví v produkci a nepřetvoří se v něco, co musí agent projít, platíte za to, že stejný problém objevíte podruhé.

Důvěra a správa jsou stále častěji uváděny jako hlavní překážky pro škálování agentní AI. Věříte, že technologie postupuje rychleji než schopnost podniků ji dohlížet, a jaká rizika to vytváří?

Myslím, že se přesně to děje, a mezera je spíše strukturovaná než selhání úsilí. Nápad se může během několika týdnů proměnit v agenta, který komunikuje se zákazníky. Provozní disciplína kolem tohoto agenta, vlastnictví, důkazy, dohled trvají mnohem déle, protože zahrnují lidi a odpovědnost, a nejen software.

Riziko spočívá v tom, že mezera zůstane neviditelná, zatímco se rozšiřuje. Agent může zákazníkovi dát sebejistě špatnou odpověď bez chyby, bez neúspěšné transakce a bez upozornění. Každý dashboard vypadá zeleně. Tradiční provoz se spoléhá na systémy, které vám řeknou, kdy jsou v potížích, a agenti to spolehlivě nedělají.

Nemyslím si, že odpovědí je zpomalit. Firmy, které zde zvítězí, budou jednat rychle. Odpovědí je vybudovat důkazy a dohled, který vám umožní rychle jednat s jistotou. Čím více autonomie agent získá, tím více důkazů potřebujete, že dokáže nést odpovědnost.

Když autonomní agent učiní špatné rozhodnutí, kdo by měl být nakonec zodpovědný: vývojář, obchodní jednotka, která jej nasazuje, dodavatel poskytující model, nebo výkonný ředitel, který jeho použití schválil?

Nakonec společnost, která agenta nasazuje, vlastní výsledek. Na vývoji a provozu systému se podílí několik stran, ale zákazník nemá vztah s poskytovatelem modelu. Zákazník má vztah se společností, jejíž název je uveden v interakci.

To neznamená, že odpovědnost spočívá v jedné osobě. Prochází rozhodovacím řetězcem. Vývojář je zodpovědný za to, jak byl systém postaven. Podnik rozhoduje, co agent smí dělat. Dodavatel je zodpovědný za poskytovanou technologii. Vedení je zodpovědné za to, aby společnost měla kontrolní mechanismy a dohled k řízení rizika.

Chyba spočívá v tom, že protože model učinil rozhodnutí, model jej vlastní. To není pravda. Pokud agent učiní závazek zákazníkovi vaším jménem, tento závazek patří značce. Zákazníci to chápou intuitivně a tak i regulátoři.

AI agenti se mohou chovat nepředvídatelně, když narazí na situace, které nebyly během testování předvídány. Jak by měly podniky testovat tyto okrajové případy, než budou agenti mít přístup k zákazníkům, finančním systémům nebo citlivým údajům?

Musíte předpokládat, že agent nakonec narazí na něco, na co nebyl navržen. Otázkou je, co se stane, když k tomu dojde.

Proto ověřujte i mimo očekávanou cestu. Dejte agentovi nejednoznačné požadavky. Poskytněte mu protichůdné informace. Dejte mu neúplný kontext. Umístěte ho do situací, kdy je správná odpověď zastavit se a eskalovat místo pokračování. Přidejte podmínky reálného světa, což ve hlasové komunikaci znamená přízvuky, šum, špatná připojení a volající, kteří během hovoru mění téma. Cílem není jen potvrdit, že agent funguje, ale zjistit, jak se chová, když podmínky nejsou čisté.

Důležitější je, že musíte ověřovat celý zákaznický proces, ne jen agenta izolovaně. Model obvykle není problém. Když se něco pokazí, první otázkou je, jaký kontext model obdržel. Může se jednat o zastaralý článek v databázi znalostí, nebo o dva systémy s protichůdnými zásadami, či o předání, při kterém se ztratily informace, které zákazník již vysvětlil. Každá komponenta může projít svým vlastním testem a přesto může cesta zákazníka selhat v mezích mezi nimi.

Tato vrstva mezi systémy je ta, kterou jsme roky instrumentovali, napříč 450 podniky a více než 350 miliony zákaznických cest ročně. Ať už jsou agentní, nebo ne, selhává stejným způsobem. Také vidíme agenty postavené na technologiích více než 55 různých dodavatelů, plus na každé hlavní platformě kontaktního centra, což nám ukazuje, že vzorec platí bez ohledu na to, který model je pod ním.

Než agent získá přístup k něčemu důležitému, měla by firma mít důkazy o tom, co dělá, když vše funguje správně, a co když ne.

Jak vidíte vývoj testování AI, když se společnosti přesouvají od deterministického softwaru k systémům, které uvažují, plánují, komunikují a provádějí akce napříč více aplikacemi?

Testování se musí posunout od otázky, zda systém poskytl očekávanou odpověď, k otázce, zda dosáhl správného výsledku.

Jedná se o významný posun. Agent může zvolit několik různých cest k vyřešení stejného zákaznického problému a tyto cesty se mohou v čase měnit, jak se mění modely a znalosti, na nichž jsou postaveny. Nemůžete napsat skript pro každou možnou interakci. Musíte posoudit, zda agent pochopil záměr, učinil rozumná rozhodnutí během procesu a zůstal v rámci stanovených hranic.

Chci být opatrný ohledně jedné věci, protože odvětví začíná tuto oblast draze pošlapávat. Testování před uvedením na trh je nyní důležitější, ne méně. Určuje, zda je agent připraven. Argument, že jej můžete přeskočit a místo toho sledovat produkci, je argumentem pro zjištění problémů přímo před zákazníky.

Co se mění, je to, že testování před uvedením na trh již není koncem procesu. Produkce odhaluje podmínky, které kontrolované prostředí nedokáže zcela reprodukovat, a to, co produkce odhalí, se stává testem, který musí agent splnit před dalším vydáním. Důkaz před spuštěním, bdělost v produkci a vzájemná podpora. Agent běžící v šestém měsíci by měl být měřitelně lepší než ten, který byl uveden.

Do budoucna, co odliší organizace, které úspěšně budují důvěryhodnou AI pracovní sílu, od těch, které zůstávají uvězněny v malých agentních AI pilotech?

Organizace, které získávají skutečný výnos z agentů, jsou ty, které vybudovaly provozní model založený na důkazech. Ty, které se zdržují, nejsou obvykle blokovány technologií. Jsou blokovány, protože nikdo nedokáže dodat to, co další úroveň schválení vyžaduje. Právní oddělení klade rozumnou otázku, nebo to dělá výbor pro rizika, a neexistuje odpověď, takže pilot zůstává pilotem. Technologie může být připravena, ale organizace stále nedokáže ospravedlnit poskytnutí větší pravomoci.

To je rozdíl mezi pilotem a provozní pracovní silou. V pilotu někdo neustále sleduje. V provozním modelu má každý agent úkol, který lze vyjádřit jednou větou. Jeho pravomoc je omezená a písemně stanovena. Jeho výkon je hodnocen něčím jiným než týmem, který jej vytvořil. Selhání ve výrobě se stávají bránami pro vydání. Více autonomie následuje po důkazu.

Druhý rozdíl je vlastnictví. Ve firmách, které škálují, patří agent k obchodní funkci, kterou obsluhuje, s pojmenovaným vlastníkem, který odpovídá za to, co dělá. Když zůstane AI projektem vlastněným AI týmem, zůstane malý, protože žádný obchodní lídr nepřijme riziko něčeho, co neovládá.

Nic z toho není exotické. Je to blízké tomu, jak společnost již řídí lidi, kterým důvěřuje s reálnou odpovědností.

Pilot může běžet na přesvědčení organizace. Škálování vyžaduje důkazy.

Děkujeme za skvělý rozhovor, čtenáři, kteří se chtějí dozvědět více, by měli navštívit Cyara.