Sushil Kumar, Cyara CEO’su – Röportaj Serisi

Sushil Kumar, Cyara CEO’su, yapay zeka, DevOps, bulut altyapısı, ürün stratejisi ve yazılım testinde 25 yıldan fazla liderlik deneyimine sahip deneyimli bir kurumsal yazılım yöneticisi ve girişimcidir. Aralık 2025’te Cyara’ya CEO olarak katıldı; daha önce RelicX.ai’nin kurucu ortağı ve CEO’su olarak görev yaptı ve burada Harness tarafından satın alınan, üretken AI destekli, niyet tabanlı bir test otomasyon platformu oluşturdu. Ardından RelicX’in teknolojisinin Harness’e entegrasyonunu yönetti ve AI Test Otomasyonu stratejisinin şekillenmesine yardımcı oldu. Kariyerinin erken dönemlerinde Kumar, Broadcom’da DevOps Genel Müdürü, CA Technologies’de Ürünler Kıdemli Başkan Yardımcısı olarak görev yaptı ve Oracle’da 16 yıldan fazla süreyle kıdemli ürün liderliği rollerinde bulunarak büyük kurumsal yazılım işlerini ölçeklendirmeye katkıda bulundu. Bu görevlerde AI, bulut, DevOps ve otomasyon platformlarını büyük işletmeler için inşa etmeye ve ölçeklendirmeye odaklandı. Cyara’daki atanması, şirketin AI destekli müşteri deneyimi güvence yeteneklerini ve küresel erişimini genişletmeye yöneliktir.

Cyara, işletmelerin ses, dijital, mesajlaşma ve konuşma AI kanallarında müşteri etkileşimlerini test etmelerine, izlemelerine ve doğrulamalarına yardımcı olan bir müşteri deneyimi güvence şirketidir. Cyara Agentic Platformu, AI tarafından yönlendirilen müşteri deneyimlerinin yarattığı artan zorlukları ele almak üzere tasarlanmıştır; bunlar arasında deterministik olmayan AI ajanlarının test edilmesi, halüsinasyon ve davranış kaymalarının tespiti, uyumluluğun doğrulanması, üretim sistemlerinin izlenmesi ve uçtan uca müşteri yolculuklarının değerlendirilmesi yer alır. Platform, AI ajan testini, üretim izlemeyi, ses ve telekom güvenceyi, dijital kanal testini ve CX gözlemlenebilirliğini birleştirerek, 140’tan fazla ülkede yıllık 350 milyondan fazla müşteri yolculuğunu destekler. İşletmeler, müşteriyle doğrudan etkileşime giren giderek otonom AI ajanlarını devreye aldıkça, Cyara teknolojisini bu sistemlerin dağıtıma öncesi ve sonrası güvenilir, güvenli ve tutarlı bir şekilde davranıp davranmadığını değerlendiren bir güvence katmanı olarak konumlandırmaktadır.

Kariyerinizin büyük bir kısmını Oracle ve CA/Broadcom’dan Relicx’i kurmaya ve şimdi Cyara’yı yönetmeye kadar kurumsal yazılım inşa edip ölçeklendirmekle geçirdiniz. Bu deneyim, AI ajanlarının geleneksel yazılımlara benzer şekilde değil, bir iş gücünün üyeleri gibi yönetilmesi gerektiği görüşünüzü nasıl şekillendirdi?

Kariyerimin büyük bir bölümünü kurumsal yazılım inşa edip ölçeklendirmeye harcadım ve burada geliştirdiğimiz disiplin deterministik sistemler üzerine kuruluydu. Yazılımın ne yapması gerektiğini biliyorsunuz. Bu beklentiye göre doğruluyorsunuz. Kırıldığında size bir hata, başarısız bir işlem veya bir uyarı bildirir.

AI ajanları bu şekilde çalışmaz. Deterministik olmadıkları için aynı girdi farklı bir yol izleyebilir. Daha da önemlisi, şirket adına hareket edebilirler. İade, politika, vaat gibi taahhütlerde bulunurlar. Bu taahhütlerden biri yanlış olduğunda hiçbir şey kırılmaz. Yanlış bir yanıt, doğru bir yanıt gibi duyulur. İşlem başarılı olur, gösterge paneli yeşil kalır ve müşteri, şirketin asla onaylamadığı bir şeyle ayrılır.

Yazılım kararlar alıp taahhütlerde bulunabiliyor ve sizi bilgilendirmeden hatalı olabiliyorsa, farklı bir işletim modeli gerekir.

İşte bu noktada iş gücü karşılaştırması anlam kazanır. Bir çalışanı, alacağı her kararı betimleyerek yönetmezsiniz. Ona bir rol verirsiniz, bu rolün getirdiği yetkiyi belirler ve çalışan bu yetkiyi kazandıkça genişletirsiniz. Bir ajan da aynı yapıda aynı şekilde davranır.

Benim yorumum, özerkliğin bir dağıtım kararı olmadığı; bir dizi terfi olduğudur. Bir ajan, işi yapabildiğini, yetki sınırları içinde kaldığını ve yardıma ihtiyaç duyduğunda bunu fark ettiğini göstererek her birini kazanır.

AI ajanları için \”İK-benzeri\” bir işletim modeli bir işletme içinde gerçekte nasıl görünür ve şirketlerin önce hangi unsurları hayata geçirmesi gerekir?

İş tanımıyla başlayın. Her ajan, üretime girmeden önce bir iş tanımına yakın bir belgeye sahip olmalıdır. Ne başarması gerekiyor, hangi bilgi onun için otoriter, hangi müşteri verilerini kullanabilir, hangi kararları kendi başına alabilir ve sorumluluğu nerede sona erer? Bir şirket bunu bir paragrafta yazamıyorsa, ajan bir role hazır değildir; bir demo için hazırdır.

O rolün ardından dört unsur gelir ve sıralama önemlidir. Başlatmadan önce kanıt, yani ajanın işi gerçek dünyaya benzer koşullarda, kontrollü bir testten ziyade, yapabildiğini kanıtlamak. Çalışırken denetim, böylece ajanın gerçekten ne yaptığını ve sadece sistemin yanıt verip vermediğini bilirsiniz. Terfi kapıları, böylece kanıt olduğunda daha fazla yetki verilir, önceden değil. Ve mühendislikte değil, iş biriminde bir sorumlu, bu ajanın ne yapmasına izin verildiğinden sorumlu olan kişi.

Sıralamayı yanlış yaparsanız diğer şeyler geçerli olmaz. Sorumluluk belirsizse, iyi performans kanıtlanamaz ve başarısızlık da aynı şekilde kanıtlanamaz. Rol önce gelir, kanıt ardından gelir.

Bir AI ajanına belirli bir rol atandığında, organizasyonlar onun sorumluluklarını, izinlerini ve sınırlarını müşterilerle veya kritik sistemlerle etkileşime girmesine izin vermeden önce nasıl tanımlamalıdır?

Rol, ajanın ne amaçla olduğunu söyler. İzinler ise neye ulaşabileceğini belirtir. Bunlar iki farklı konuşmadır ve şirketler genellikle sadece birincisini uygular.

Üç şeye açıkça değinin. Ajentin dokunabileceği sistemler ve veriler ve hangi yönde, çünkü bir müşteri kaydını okumak ve bir kaydı değiştirmek aynı izin değildir. Kendi başına neye taahhüt edebileceği, yani paranın ve sorumluluğun bulunduğu yer: bir iade, bir kredi, politika istisnası. Ve bir devretmeyi zorlayan şey, hem önceden adlandırabileceğiniz durumlar hem de ajentin yetkinliğinin dışına çıktığını gösteren sinyal.

Bunlar teknoloji ekibine bırakılacak kararlar değildir. Şirketin üstlendiği riski belirlerler. Müşteri deneyiminden ve uyumluluk riskinden sorumlu olan kişiler, bu sınırların nerede çizileceği konusunda söz sahibi olmalı ve genellikle en son sorulan kişilerdir.

Ardından, ajentin bu sınırlar içinde kaldığını kanıtlamanız gerekir. Amaç, her olası hatayı ortadan kaldırmak değildir. Hatalar olacaktır. Soru, ajentin sınırlarını anlayıp anlamadığı, ne zaman durması gerektiğini bilip bilmediği ve müşterinin yolculuğunun başka bir yerinde sonuçlar doğurmadan kendisine verilen işi yapıp yapamayacağıdır.

Daha büyük özerkliğin baştan verilmek yerine kazanılması gerektiğini savunuyorsunuz. Bir AI ajanının, bir işletmenin bağımsız olarak gerçekleştirebileceği eylem kapsamını genişletmeden önce neyi kanıtlaması gerekir?

Artık bir AI ajanı oluşturmak kolay. Zor kısmı, özerkliği hak ettiğini kanıtlamaktır.

Bir ajentin kendi başına neler yapabileceğini genişletmeden önce, bir işletmenin ajanın atanan görevini tutarlı bir şekilde yerine getirdiğine ve sınırları içinde kaldığına dair kanıta ihtiyacı vardır. Bu, beklediğiniz durumları nasıl yönettiği ve aynı zamanda öngörmediğiniz durumları da kapsar. Bir ajan kontrollü koşullarda güçlü görünebilir, ancak bağlam veya çevre sistemler değiştiğinde farklı davranabilir.

Bir müşteri basit bir fatura sorusuyla başlayabilir ve başarısız bir ödeme sonrası hayal kırıklığına uğrayabilir. Ajent, bu değişikliği gerçekleşirken fark etmeli ve doğrulandığı yolda devam etmek yerine yön değiştirmelidir.

Yetki genişlemeden önce üç şey doğru olmalıdır. Ajan, sadece temiz koşullarda değil, gerçek koşullarda da işi yapar. Kendi yetkinliğinin sınırını bilir ve orada durur. Ve istek üzerine her ikisi için de kanıt sunabilecek birisi bulunur.

Kanıt seviyesi, özerklik seviyesine uygun olmalıdır. Küçük kararlar, hafif kanıtlar. Bir ödeme sistemine erişim veya şirketi bir politika istisnasına bağlama yetkisi gibi durumlarda ise çubuk çok daha yüksek olmalıdır.

Şirketler, AI ajanları dağıtıldıktan sonra performanslarını nasıl sürekli değerlendirmelidir, özellikle kararlarının kalitesi yalnızca geleneksel yazılım test metrikleriyle yakalanamadığında?

Burada geleneksel yazılım düşüncesi çöküyor. Deterministik yazılımlarda bir şeyin geçip geçmediğini test edersiniz. Bir AI ajanıyla ise sistemden başarılı bir yanıt alabilirsiniz, ancak müşteri etkileşimi başarısız olabilir.

Dolayısıyla yanıtı değil, sonucu değerlendirirsiniz. Ajan, müşterinin ne başarmaya çalıştığını anladı mı? Doğru bilgiyi kullandı mı? Yolculuğu tamamladı mı? Sınırları içinde kaldı mı ve gerektiğinde yükseltme yaptı mı?

Temel değerlendirmeler, yanıtları altın bir küme ile puanlamak, asgari düzeyi oluşturur. Her şirketin bunları olacaktır. Bir müşterinin size güvenini sürdürüp sürdürmeyeceğini belirleyen boyutlar şunlardır: uyumluluk, önyargı, kötüye kullanım ve ajanın gerçek arayanlarla, onların aksanlarıyla, arka plan gürültüsüyle, ucuz kulaklıkla, cümlenin ortasında kesintilerle nasıl başa çıktığı. Sesli iletişimde bu, insanların beklediğinden daha çok önem taşır, çünkü her puan bir transkript üzerine oturur. Konuşma katmanı soruyu yanlış anlar ise, ajan kimsenin sormadığı bir soruya yanıt verir.

Matematiği göz önünde bulundurmak gerekir. Değerlendirmede %99 puan mükemmel gibi görünür. Yılda bir milyon konuşma olduğunda bu, on bin başarısız konuşma demektir.

İki ilke geçerlidir. Doğrulama, ajandan ve model platformlarından bağımsız olmalıdır. Ajanları kendimiz inşa etmiyoruz, bu da açıkça söyleyebildiğim bir neden: hiçbir satıcı kendi AI’sını yargılamamalıdır. Standart, işletmenin kendi politikaları, müşteri taahhütleri ve düzenleyici yükümlülükleridir, bir satıcının puan kartı değil.

Ve her üretim hatası bir engel haline gelmelidir. Bir bilet ya da bir birikmiş iş öğesi değil. Bir sonraki sürüm yayınlanmadan önce ajanın geçmesi gereken bir test. Üretimde bir sorun ortaya çıkar ve bu, ajanın geçmesi gereken bir şeye dönüşmezse, aynı problemi iki kez keşfetmek için ödeme yapıyorsunuz.

Güven ve yönetişim, ajan temelli AI’nın ölçeklendirilmesindeki başlıca engeller olarak giderek daha fazla belirtiliyor. Teknolojinin, işletmelerin denetleme kapasitesinden daha hızlı ilerlediğine inanıyor musunuz ve bu ne tür riskler yaratıyor?

Bunun tam da şu anda gerçekleştiğini düşünüyorum ve boşluk çaba eksikliğinden ziyade yapısal. Bir fikir haftalar içinde müşteriyle yüzleşen bir ajan haline gelebilir. O ajanın etrafındaki işletme disiplini, sahiplik, kanıt, denetim çok daha uzun sürer, çünkü sadece yazılım değil, insan ve sorumluluk da içerir.

Risk, boşluğun genişlerken görünmez kalmasıdır. Bir ajan, müşteriye hatasız, başarısız işlem olmadan ve uyarı vermeden kendinden emin bir şekilde yanlış bir yanıt verebilir. Her gösterge paneli yeşil görünür. Geleneksel operasyonlar, sistemlerin sorun yaşadıklarını size bildirmesine dayanır ve ajanlar bunu güvenilir bir şekilde yapmaz.

Yavaşlamanın cevap olduğunu düşünmüyorum. Burada kazanacak şirketler hızlı hareket edecekler. Cevap, hızlı ve güvenle hareket etmenizi sağlayacak kanıt ve denetimi inşa etmektir. Bir ajana ne kadar fazla özerklik verilirse, sorumluluğu taşıyabileceğine dair o kadar çok kanıt gerekir.

Otonom bir ajan kötü bir karar verdiğinde, nihai sorumluluk kime ait olmalı: geliştiriciye, onu dağıtan iş birimine, modeli sağlayan satıcıya, yoksa kullanımını onaylayan yönetime?

Sonuçta, ajanı dağıtan şirket sonuca sahiptir. Sistemi inşa edip işletmede çeşitli taraflar yer alır, ancak müşterinin model sağlayıcısıyla bir ilişkisi yoktur. Müşterinin, etkileşimin üzerinde adı geçen şirketle bir ilişkisi vardır.

Bu, sorumluluğun tek bir kişide olduğu anlamına gelmez. Sorumluluk karar zinciri boyunca ilerler. Geliştirici, sistemin nasıl inşa edildiğinden sorumludur. İş birimi, ajanın ne yapmasına izin verileceğini belirler. Satıcı, sağladığı teknoloji için sorumludur. Liderlik, şirketin riski yönetmek için gerekli kontrolleri ve denetimi sağladığından sorumludur.

Yanlış, karar modeli verdiği için kararın modele ait olduğunu düşünmektir. Bu doğru değildir. Bir ajan sizin adınıza müşteriye bir taahhüt verdiğinde, bu taahhüt marka adına aittir. Müşteriler bunu içgüdüsel olarak anlar, düzenleyiciler de aynı şekilde.

AI ajanları, test sırasında öngörülmeyen durumlarla karşılaştıklarında öngörülemez davranabilirler. Şirketler, ajanlara müşterilere, finansal sistemlere veya hassas verilere erişim vermeden önce bu uç durumları nasıl test etmelidir?

Ajana, sonunda tasarlanmadığı bir şeyle karşılaşacağını varsaymak gerekir. Soru, bu gerçekleştiğinde ne olacağıdır.

Bu yüzden beklenen yolun ötesinde doğrulama yapın. Ajanı belirsiz isteklerle test edin. Çelişkili bilgiler verin. Eksik bağlam sağlayın. Doğru cevabın durup yükseltmek olduğu, devam etmek yerine, durumları yaratın. Gerçek dünyanın koşullarını ekleyin; sesli iletişimde bu aksanlar, gürültü, kötü bağlantılar ve konuşmanın ortasında konuyu değiştiren arayanlar anlamına gelir. Amaç, ajanın çalıştığını teyit etmek değil, koşullar temiz olmadığında nasıl davrandığını öğrenmektir.

Daha önemli nokta, ajanın yalnız başına değil, tüm yolculuğun doğrulanması gerektiğidir. Model genellikle sorun değildir. Bir şeyler ters gittiğinde, ilk sorum modelin hangi bağlamı aldığıdır. Bu, güncel olmayan bir bilgi makalesi, çelişkili politikalar taşıyan iki sistem veya müşterinin zaten açıkladığını kaybeden bir devretme olabilir. Her bileşen kendi testini geçebilir, ancak müşteri yolculuğu bileşenler arasındaki boşluklarda hâlâ başarısız olabilir.

Sistemler arasındaki bu katman, 450 işletme ve yılda 350 milyondan fazla müşteri yolculuğu boyunca yıllarca ölçüm yaptığımız katmandır. Ajan olsun ya da olmasın, aynı şekilde kırılır. Ayrıca 55’ten fazla farklı satıcının teknolojisi ve tüm büyük iletişim merkezi platformları üzerine inşa edilmiş ajanlar görüyoruz; bu da modelin ne olduğuna bakılmaksızın desenin geçerli olduğunu gösteriyor.

Bir ajanın önemli bir şeye erişim sağlamadan önce, işletmenin her şey yolunda gittiğinde ve gitmediğinde ne yaptığını gösteren kanıtlara sahip olması gerekir.

Şirketler deterministik yazılımlardan, akıl yürüten, plan yapan, iletişim kuran ve birden çok uygulama üzerinde eylem gerçekleştiren sistemlere geçerken AI testinin nasıl evrileceğini nasıl görüyorsunuz?

Test, bir sistemin beklenen yanıtı verip vermediğini sormaktan, doğru sonuca ulaşıp ulaşmadığını sormaya kaymalıdır.

Bu önemli bir kaymadır. Bir ajan aynı müşteri sorununu çözmek için birkaç farklı yol izleyebilir ve bu yollar, modeller ve bunların arkasındaki bilgi zamanla değiştikçe değişebilir. Her olası etkileşim için bir betik yazamazsınız. Ajanın niyeti anlayıp anlamadığını, yol boyunca sağlam kararlar verip vermediğini ve kendisine verilen sınırlar içinde kalıp kalmadığını değerlendirmeniz gerekir.

Bir konuya dikkat etmek istiyorum, çünkü sektör bunu pahalı bir şekilde yanlış yapmaya başladı. Ön lansman testleri artık daha da önemli, az değil. Bu, bir ajanın hazır olup olmadığını belirler. Onu atlayıp üretimi izleyebileceğiniz argümanı, müşterilerin önünde öğrenmek için bir argümandır.

Değişen şey, ön lansman testinin artık sürecin sonu olmamasıdır. Üretim, kontrollü bir ortamın tamamen yeniden üretemediği koşulları ortaya çıkarır ve üretimin ortaya koyduğu durumlar, ajanın bir sonraki sürümden önce geçmesi gereken bir test haline gelir. Lansmandan önce kanıt, üretimde gözetim ve her birinin diğerini beslemesi. Altıncı ayda çalışan ajan, başlatılan ajandan ölçülebilir şekilde daha iyi olmalıdır.

İleriye baktığımızda, güvenilir AI işgücünü başarıyla inşa eden organizasyonları, küçük ajanlı AI pilotlarıyla takılı kalanlardan ayıracak olan nedir?

Gerçek getiri sağlayan organizasyonlar, kanıta dayalı bir işletim modeli inşa edenlerdir. Geri kalanlar genellikle teknoloji tarafından engellenmez. Engellenmelerinin nedeni, bir sonraki onay seviyesinin gerektirdiğini kimsenin üretememesidir. Hukuk makul bir soru sorar ya da risk komitesi sorar ve yanıt yoktur, bu yüzden pilot bir pilot olarak kalır. Teknoloji hazır olabilir ve organizasyon hâlâ ona daha fazla yetki vermeyi haklı çıkaramaz.

Bu, bir pilot ile işletim gücü arasındaki farktır. Bir pilotta, birisi her zaman izler. Bir işletim modelinde, her ajan bir cümleyle ifade edilebilecek bir işe sahiptir. Yetkisi sınırlıdır ve yazılıdır. Performansı, onu geliştiren ekip dışındaki bir şey tarafından değerlendirilir. Üretim hataları sürüm kapıları haline gelir. Daha fazla özerklik kanıtla takip eder.

İkinci fark sahiplenmedir. Ölçeklenen şirketlerde, ajan hizmet verdiği iş fonksiyonuna aittir ve ne yaptığından sorumlu olan adlandırılmış bir sahibi vardır. Bir AI ekibi tarafından sahiplenilen bir AI projesi olarak kalırsa, küçük kalır, çünkü hiçbir iş lideri kontrol etmedikleri bir şeyin riskini üstlenmez.

Bunların hiçbiri egzotik değil. Bir şirketin zaten gerçek sorumlulukla güvendiği insanları nasıl yönettiğine çok benziyor.

Bir pilot, bir organizasyonun inancına dayanarak yürütülebilir. Ölçeklendirme kanıt gerektirir.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Cyara adresini ziyaret etmelidir.