Sushil Kumar, Cyara-yrityksen toimitusjohtaja – Haastattelusarja

Sushil Kumar, Cyara:n toimitusjohtaja on kokenut yritysohjelmistojen johtaja ja yrittäjä, jolla on yli 25 vuoden kokemus johtamisesta tekoälyn, DevOpsin, pilvi-infrastruktuurin, tuotestrategian ja ohjelmistotestauksen aloilla. Hän liittyi Cyaraan toimitusjohtajana joulukuussa 2025, sen jälkeen kun hän toimi RelicX.ai:n perustajana ja toimitusjohtajana, jossa hän rakensi generatiiviseen tekoälyyn perustuvan, tarkoitukseen kohdistuvan testiautomaatiopalvelun, jonka Harness osti. Hän johti myöhemmin RelicX:n teknologian integrointia Harnessiin ja auttoi muokkaamaan sen AI Test Automation -strategiaa. Aikaisemmin urallaan Kumar toimi Broadcomilla DevOpsin yleisjohtajana, CA Technologiesilla tuotteiden varatoimitusjohtajana ja vietti yli 16 vuotta Oraclella, jossa hänellä oli seniorituotejohtamisen tehtäviä ja hän auttoi skaalaamaan suuria yritysohjelmistoyrityksiä. Näissä rooleissa hän on keskittynyt AI-, pilvi-, DevOps- ja automaatioalustojen rakentamiseen ja skaalaamiseen suurille yrityksille. Hänen nimityksensä Cyaraan keskittyy laajentamaan yrityksen tekoälypohjaisia asiakaskokemuksen varmistuskykyjä ja globaalia kattavuutta.

Cyara on asiakaskokemuksen varmistusyritys, joka auttaa yrityksiä testaamaan, valvomaan ja varmistamaan asiakasvuorovaikutuksia ääni-, digitaalinen-, viestintä- ja keskusteleva tekoäly -kanavilla. Sen Cyara Agentic Platform on suunniteltu vastaamaan tekoälyohjattujen asiakaskokemusten luomiin kasvaviin haasteisiin, mukaan lukien epädeterminististen AI-agenttien testaus, harhauttavien vastausten ja käyttäytymisen poikkeamien havaitseminen, vaatimustenmukaisuuden tarkistaminen, tuotantojärjestelmien valvonta sekä loppuun asti kulkevien asiakaspolkujen arviointi. Alusta yhdistää AI-agenttien testauksen, tuotannon valvonnan, ääni- ja telekommunikaation varmistuksen, digitaalikanavien testauksen ja CX‑havainnoinnin, tukien yli 350 miljoonaa asiakaspolkua vuosittain yli 140 maassa toimivan globaalin verkoston kautta. Kun yritykset ottavat käyttöön yhä autonomisempia AI-agentteja asiakaspalveluprosesseissa, Cyara asemoituu tarjoamaan varmistuskerroksen, jonka avulla voidaan arvioida, toimiiko järjestelmä luotettavasti, turvallisesti ja johdonmukaisesti ennen ja jälkeen käyttöönoton.

Olet viettänyt suuren osan urastasi yritysohjelmistojen rakentamiseen ja skaalaamiseen, Oraclesta ja CA/Broadcomista Relicx:n perustamiseen ja nyt Cyaran johtamiseen. Miten tämä kokemus on muokannut näkemystäsi siitä, että AI-agentteja tulisi hallita vähemmän perinteisen ohjelmiston tavoin ja enemmän työntekijöiden kaltaisina?

Olen käyttänyt suurimman osan urastani yritysohjelmistojen rakentamiseen ja skaalaamiseen, ja siellä kehittämämme kurinalaisuus perustui deterministisiin järjestelmiin. Tiedät, mitä ohjelmiston pitäisi tehdä. Vahvistat sen tätä odotusta vastaan. Kun se pettää, se kertoo sinulle: virheen, epäonnistuneen tapahtuman tai hälytyksen.

AI-agentit eivät toimi näin. Ne ovat epädeterministisiä, joten sama syöte voi johtaa eri polkuun. Vielä tärkeämpää on, että ne voivat toimia yrityksen puolesta. Ne tekevät sitoumuksia: palautuksia, politiikkoja, lupauksia. Ja kun jokin näistä on virheellinen, mitään ei rikkoudu. Väärä vastaus kuulostaa täsmälleen oikealta. Tapahtuma onnistuu, hallintapaneeli pysyy vihreänä, ja asiakas lähtee pois saadakseen jotain, johon yritys ei ole koskaan suostunut.

Kun ohjelmisto voi tehdä päätöksiä ja sitoumuksia, ja voi olla väärässä kertomatta siitä, se tarvitsee erilaisen toimintamallin.

Tässä kohtaa työntekijävertailu osoittaa arvonsa. Et hallinnoi työntekijää skriptittämällä jokaisen päätöksen, jonka hän tekee. Annetaan hänelle rooli, määritellään siihen liittyvä valtuutus ja laajennetaan valtuutusta sitä ansaitessa. Agentti käyttäytyy samalla tavalla saman rakenteen alla.

Minun näkemykseni on, että autonomia ei ole käyttöönottopäätös. Se on sarja ylennyksiä. Agentti ansaitsee jokaisen niistä osoittamalla, että se pystyy hoitamaan tehtävän, pysyy valtuutuksensa rajoissa ja tunnistaa, milloin se tarvitsee apua.

Miltä AI-agenteille \”HR-tyylinen\” toimintamalli oikeastaan näyttää yrityksen sisällä, ja mitkä elementit yritysten tulisi ottaa käyttöön ensin?

Aloita työstä. Jokaisella agentilla tulisi olla lähes työtehtäväkuvaus ennen kuin se lähestyy tuotantoa. Mikä on sen tehtävä, mikä tieto on sille auktoriteettia, mitä asiakastietoja se voi käyttää, mitä päätöksiä se voi tehdä itsenäisesti, ja missä sen vastuu päättyy. Jos yritys ei pysty kirjoittamaan tätä yhteen kappaleeseen, agentti ei ole valmis rooliin. Se on valmis demoon.

Tuosta roolista seuraa neljä asiaa, ja järjestyksellä on merkitystä. Todisteet ennen käyttöönottoa, mikä tarkoittaa agentin kyvyn todistamista suorittaa tehtävä todellista maailmaa muistuttavissa olosuhteissa, ei kontrolloidussa testissä. Valvonta sen toiminnan aikana, jotta tiedät, mitä agentti todella teki, eikä pelkästään, vastasiko järjestelmä. Edistymiskynnykset, jolloin lisää valtuutusta myönnetään, kun on todisteita sen tukemiseksi, eikä ennen sitä. Ja omistaja liiketoiminnassa, ei tekniikassa, joka on vastuussa siitä, mitä agentille on sallittu tehdä.

Jos järjestys on väärä, kaikki muu ei pidä paikkaansa. Jos vastuu on epäselvä, hyvän suorituskyvyn todistaminen on mahdotonta, samoin kuin epäonnistumisen. Rooli tulee ensin, ja todisteet seuraavat.

Jos AI-agentille annetaan tietty rooli, miten organisaatioiden tulisi määritellä sen vastuut, oikeudet ja rajat ennen kuin se saa olla vuorovaikutuksessa asiakkaiden tai kriittisten järjestelmien kanssa?

Rooli kertoo, mihin agentti on tarkoitettu. Oikeudet kertovat, mihin se voi päästä. Nämä ovat kaksi erillistä keskustelua, ja yritykset yleensä keskittyvät vain ensimmäiseen.

Ole täsmällinen kolmessa asiassa. Mitkä järjestelmät ja tiedot agentti voi käsitellä ja missä suunnassa, koska asiakastietueen lukeminen ja sen muuttaminen eivät ole sama oikeus. Mitä se voi sitoutua tekemään itsenäisesti, missä rahallinen vastuu ja velvoitteet asettuvat: palautus, hyvitys, poikkeus politiikasta. Ja mikä pakottaa siirron, sekä etukäteen määritellyt tapaukset että signaali siitä, että agentti on siirtynyt oman osaamisalueensa ulkopuolelle.

Nämä eivät ole päätöksiä, jotka jätetään teknologia‑tiimin tehtäväksi. He määrittelevät yrityksen ottaman riskin. Asiakaskokemuksesta ja sääntelyaltistuksesta vastaavien henkilöiden on saatava sanansa siihen, missä linjat vedetään, ja heitä kysytään yleensä viimeisenä.

Sitten on osoitettava, että agentti pysyy niiden sisällä. Tavoitteena ei ole poistaa kaikkia mahdollisia virheitä. Virheitä tulee. Kysymys on, ymmärtääkö agentti omat rajansa, tietääkö se, milloin lopettaa, ja pystyykö se suorittamaan sille annetun tehtävän aiheuttamatta seurauksia jossain muualla asiakaspolussa.

Sinä väität, että suurempi autonomia tulisi ansaita eikä myöntää alusta alkaen. Mitä AI‑agentin on osoitettava, ennen kuin yritys laajentaa sen itsenäisesti suorittamien toimien laajuutta?

AI‑agentin rakentaminen on nyt helppoa. Vaikeaa on osoittaa, että se ansaitsee autonomian.

Ennen kuin laajennetaan, mitä agentti voi tehdä itsenäisesti, yrityksen on saatava näyttöä siitä, että se suorittaa sille annettavan tehtävän johdonmukaisesti ja pysyy rajoissaan. Tämä tarkoittaa sitä, miten se käsittelee odotetut tilanteet sekä ne, joita ei ole ennakoitu. Agentti voi vaikuttaa vahvalta hallituissa olosuhteissa, mutta käyttäytyä eri tavalla, kun konteksti tai ympäröivät järjestelmät muuttuvat.

Asiakas saattaa aloittaa yksinkertaisella laskutuskysymyksellä ja turhautua epäonnistuneen maksun jälkeen. Agentin on tunnistettava tämä muutos tapahtumisen aikana ja muutettava suuntaa sen sijaan, että se jatkaisi vahvistetulla polulla.

Ennen kuin valtuuksia laajennetaan, kolmen asian on oltava totta. Agentti suorittaa tehtävän todellisissa olosuhteissa, ei vain puhtaissa. Se tuntee oman osaamisalueensa rajan ja pysähtyy siihen. Ja joku pystyy toimittamaan todisteet molemmista pyynnöstä.

Todistustason on vastattava autonomian tasoa. Pienet päätökset, kevyet todisteet. Pääsy maksujärjestelmään tai kyky sitoa yritys politiikka‑poikkeukseen, ja vaatimustason on oltava huomattavasti korkeampi.

Miten yritysten tulisi jatkuvasti arvioida AI‑agenttien suorituskykyä niiden käyttöönoton jälkeen, erityisesti kun päätösten laatua ei voida mitata pelkästään perinteisillä ohjelmistotestauksen mittareilla?

Tässä perinteinen ohjelmistologiikka hajoaa. Deterministisessa ohjelmistossa testaat, onko jokin läpäissyt vai epäonnistunut. AI‑agentin kanssa voit saada järjestelmältä onnistuneen vastauksen, mutta asiakaskohtaaminen voi silti epäonnistua.

Siksi arvioit tulosta, ei vastausta. Ymmärsiiko agentti, mitä asiakas yritti saavuttaa? Käytettiinkö oikeita tietoja? Saavuttiinko matka päätökseen? Pysyikö se rajoissaan ja eskaloiiko silloin, kun sen olisi pitänyt?

Perusarvioinnit, joissa vastauksia pisteytetään kultaisen joukon perusteella, ovat peruslähtökohta. Jokaisella yrityksellä on ne. Ne ulottuvuudet, jotka päättävät, säilyykö asiakkaan luottamus, ovat juuri nämä: sääntöjen noudattaminen, vinouma, väärinkäyttö ja se, miten agentti kestää todelliset puhelijat, heidän aksenttinsa, taustamelun, halvan puhelimen, kesken lauseen tapahtuvan keskeytyksen. Ääniympäristössä tämä on tärkeämpää kuin ihmiset odottavat, koska jokainen pisteytys perustuu transkriptioon. Jos puhekerros kuuntelee kysymyksen väärin, agentti vastaa kysymykseen, jota kukaan ei esittänyt.

Laskutoimitus kannattaa käydä läpi. 99 % pisteytys arvioinnissa kuulostaa erinomaiselta. Miljoonaa keskustelua vuodessa tarkoittaa kymmentä tuhatta epäonnistunutta.

Kaksi periaatetta pitää paikkansa. Vahvistuksen tulee olla riippumaton agentista ja mallialustoista. Emme itse rakenna agenteja, mikä on osa syytä, miksi voin suoraan sanoa, ettei mikään toimittaja saisi toimia oman AI‑teknologiansa tuomarina. Standardi on yrityksen omat käytännöt, sen asiakaslupaukset ja sääntelyvelvoitteet, ei toimittajan pistetaulukko.

Jokaisen tuotantovirheen tulisi muuttua portiksi. Ei tikettinä, ei backlog‑kohteena. Testinä, jonka agentin on suoritettava ennen seuraavan julkaisun lähettämistä. Jos ongelma ilmenee tuotannossa eikä siitä tule asiaa, jonka agentin on läpäistävä, maksat saman ongelman havaitsemisesta kahdesti.

Luottamusta ja hallintoa pidetään yhä useammin merkittävinä esteinä agenttipohjaisen tekoälyn skaalaamiselle. Uskotko, että teknologia kehittyy nopeammin kuin yritysten valvontakyky, ja millaisia riskejä se aiheuttaa?

Mielestäni juuri näin tapahtuu, ja kuilu on rakenteellinen eikä johtunut puutteellisesta ponnistelusta. Idea voi muuttua asiakaskeskeiseksi agentiksi viikkojen sisällä. Sen agentin operatiivinen kurinalaisuus, omistajuus, todisteet ja valvonta vievät paljon pidempään, koska ne koskevat ihmisiä ja vastuullisuutta, eivät pelkästään ohjelmistoja.

Riskinä on, että kuilu pysyy näkymättömänä samalla kun se laajenee. Agentti voi antaa asiakkaalle itsevarman väärän vastauksen ilman virhettä, epäonnistunutta tapahtumaa eikä hälytystä. Kaikki kojelaudat näyttävät vihreiltä. Perinteiset toiminnot riippuvat järjestelmistä, jotka kertovat, milloin ne ovat pulassa, eikä agentit luotettavasti tee niin.

En usko, että vastaus on hidastaa. Tässä menestyvät yritykset tulevat toimimaan nopeasti. Vastaus on rakentaa todisteet ja valvonta, jotka mahdollistavat nopean toiminnan luottamuksella. Mitä enemmän autonomisuutta agentti saa, sitä enemmän todisteita tarvitaan sen vastuullisuuden varmistamiseksi.

Kun autonominen agentti tekee huonon päätöksen, kuka on lopulta vastuussa: kehittäjä, sen käyttöönotosta vastaava liiketoimintayksikkö, mallin tarjoaja vai johtaja, joka on hyväksynyt sen käytön?

Lopulta agentin käyttöönotosta vastaava yritys omistaa tuloksen. Useat osapuolet osallistuvat järjestelmän rakentamiseen ja ylläpitoon, mutta asiakkaalla ei ole suhdetta mallin tarjoajaan. Asiakkaalla on suhde siihen yritykseen, jonka nimi on vuorovaikutuksessa.

Tämä ei tarkoita, että vastuu asettuisi yhden henkilön harteille. Se kulkee päätösketjun läpi. Kehittäjä on vastuussa siitä, miten järjestelmä on rakennettu. Liiketoiminta päättää, mitä agentti saa tehdä. Toimittaja on vastuussa tarjoamastaan teknologiasta. Johto on vastuussa siitä, että yrityksellä on hallintamekanismit ja valvonta riskin hallitsemiseksi kokonaisuudessaan.

Virhe on ajatella, että koska malli teki päätöksen, malli omistaa sen. Se ei ole niin. Jos agentti tekee asiakkaalle sitoumuksen puolestasi, tuo sitoumus kuuluu brändille. Asiakkaat ymmärtävät tämän vaistomaisesti, samoin kuin sääntelijät.

AI-agentit voivat käyttäytyä ennakoimattomasti, kun ne kohtaavat tilanteita, joita ei ole testattu. Miten yritysten tulisi testata näitä reunatapauksia ennen kuin agenteille annetaan pääsy asiakkaisiin, talousjärjestelmiin tai arkaluontoisiin tietoihin?

On oletettava, että agentti kohtaa lopulta jotain, mihin sitä ei ole suunniteltu. Kysymys on, mitä tapahtuu, kun näin tapahtuu.

Siksi on validoitava odotettua polkua laajemmin. Anna agentille epäselviä pyyntöjä. Anna sille ristiriitaista tietoa. Anna sille puutteellista kontekstia. Aseta se tilanteisiin, joissa oikea vastaus on pysähtyä ja eskaloida sen sijaan, että jatketaan. Lisää todellisen maailman olosuhteita, mikä äänessä tarkoittaa aksentteja, melua, huonoja yhteyksiä ja puhelijoita, jotka vaihtavat aihetta puolivälissä. Tavoitteena ei ole varmistaa, että agentti toimii, vaan selvittää, miten se käyttäytyy, kun olosuhteet eivät ole puhtaat.

Tärkeämpi pointti on, että koko asiakasmatka on validoitava, ei pelkkä agentti erillisenä. Malli ei yleensä ole ongelma. Kun jokin menee pieleen, ensimmäinen kysymykseni on, mitä kontekstia malli sai. Se saattoi olla vanhentunut tietämyspääte, kaksi järjestelmää, joilla on ristiriitaiset käytännöt, tai siirto, jossa asiakkaan jo selostama asia jäi puuttumaan. Jokainen komponentti voi läpäistä oman testinsä, mutta asiakasmatka voi silti epäonnistua niiden välisten saumojen takia.

Se kerros järjestelmien välillä on se, jonka instrumentointiin olemme käyttäneet vuosia, yli 450 yrityksessä ja yli 350 miljoonan asiakasmatkan vuodessa. Olipa kyseessä agenttipohjainen tai ei, se hajoaa samalla tavalla. Näemme myös agenteja, jotka on rakennettu yli 55 eri toimittajan teknologialla, sekä jokaisella merkittävällä kontaktikeskusalustalla, mikä osoittaa, että malli pätee riippumatta siitä, mikä malli on taustalla.

Ennen kuin agentti saa pääsyn merkittävään kohteeseen, yrityksellä tulisi olla todisteita siitä, mitä se tekee, kun asiat menevät hyvin ja kun ne eivät mene.

Miten näet AI-testauksen kehittyvän, kun yritykset siirtyvät deterministisestä ohjelmistosta järjestelmiin, jotka pystyvät järkeilemään, suunnittelemaan, kommunikoimaan ja toimimaan useiden sovellusten välillä?

Testauksen on siirryttävä kysymästä, onko järjestelmä tuottanut odotetun vastauksen, kysymykseen, onko se saavuttanut oikean lopputuloksen.

Se on merkittävä muutos. Agentti saattaa käyttää useita eri polkuja ratkaistakseen saman asiakasongelman, ja nämä polut voivat muuttua ajan myötä mallien ja niiden taustalla olevan tiedon kehittyessä. Et voi kirjoittaa skriptiä jokaiselle mahdolliselle vuorovaikutukselle. Sinun on arvioitava, ymmärsikö agentti tarkoituksen, tekikö se järkeviä päätöksiä matkan varrella ja pysyikö se sille asetettujen rajojen sisällä.

Haluan olla varovainen yhden asian suhteen, koska ala alkaa tehdä virheitä kalliilla tavalla. Ennen lanseerausta tehtävä testaus on nyt tärkeämpää kuin koskaan, ei vähemmän. Se määrittää, onko agentti valmis. Väite, että sen voi ohittaa ja seurata tuotantoa sen sijaan, on itse asiassa argumentti siitä, että oppii virheitä suoraan asiakkaiden edessä.

Mitä muuttuu, on se, että ennen lanseerausta tehtävä testaus ei ole enää prosessin loppu. Tuotanto paljastaa olosuhteita, joita hallittu ympäristö ei pysty täysin toistamaan, ja tuotannon paljastamat asiat muuttuvat testiksi, jonka agentin on suoritettava ennen seuraavaa julkaisua. Todiste ennen lanseerausta, valppaus tuotannossa, ja kummankin ruokkima toisiaan. Kuukausi kuudessa toimiva agentti tulisi olla mitattavissa parempi kuin alun perin lanseerattu.

Kun katsomme tulevaisuuteen, mikä erottaa organisaatiot, jotka onnistuvat rakentamaan luotettavan AI-työvoiman, niistä, jotka jäävät jumiin pieniin agenttipohjaisiin AI-pilotteihin?

Organisaatiot, jotka saavat todellista tuottoa agenteista, ovat niitä, jotka ovat rakentaneet toimintamallin todisteiden ympärille. Ne, jotka viivästyvät, eivät yleensä ole teknologian estämässä. Heitä estää se, että kukaan ei pysty tuottamaan sitä, mitä seuraavan tason hyväksyntä vaatii. Lakiosasto esittää kohtuullisen kysymyksen, tai riskikomitea tekee sen, eikä vastausta ole, joten pilotti pysyy pilotina. Teknologia saattaa olla valmis, mutta organisaatio ei silti pysty perustelemaan sen antamista suuremmalla valtuutuksella.

Tämä on ero pilotin ja toimivan työvoiman välillä. Pilotissa joku tarkkailee jatkuvasti. Toimintamallissa jokaisella agentilla on tehtävä, jonka voi kuvata yhdellä lauseella. Sen valtuutus on rajoitettu ja kirjattu. Sen suorituskykyä arvioi jokin muu kuin sen rakentanut tiimi. Tuotantovirheet muuttuvat julkaisukäytäviksi. Lisää autonomiaa seuraa todisteiden perusteella.

Toinen ero on omistajuus. Yrityksissä, jotka laajentuvat, agentti kuuluu siihen liiketoimintafunktioon, jota se palvelee, ja sillä on nimetty omistaja, joka vastaa sen toiminnasta. Jos se pysyy tekoälyprojektina, jonka omistaa tekoälytiimi, se pysyy pienikokoisena, koska kukaan liiketoimintajohtaja ei halua ottaa riskiä jostakin, mitä hän ei hallitse.

Tämä ei ole lainkaan eksoottista. Se on lähellä sitä, miten yritys jo hallinnoi ihmisiä, joihin se luottaa todellisella vastuulla.

Pilotti voi toimia organisaation vakaumuksen varassa. Skaalaus vaatii todisteita.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, tulisi käydä osoitteessa Cyara.