Сушіл Кумар, генеральний директор Cyara – Серія інтерв’ю

Sushil Kumar, генеральний директор Cyara — досвідчений керівник корпоративного програмного забезпечення та підприємець з більш ніж 25‑річним досвідом лідерства у галузях штучного інтелекту, DevOps, хмарної інфраструктури, продукт‑стратегії та тестування ПЗ. Він приєднався до Cyara на посаді генерального директора у грудні 2025 року після ролі співзасновника та генерального директора RelicX.ai, де створив генеративний AI‑потужний, орієнтований на наміри, платформу автоматизації тестування, яку придбала Harness. Після цього він очолив інтеграцію технології RelicX у Harness і допоміг сформувати її стратегію AI Test Automation. На початку кар’єри Кумар працював генеральним менеджером DevOps у Broadcom, старшим віце‑президентом з продуктів у CA Technologies та понад 16 років у Oracle, де займав старші ролі у керуванні продуктами та допомагав масштабувати великі корпоративні програмні продукти. У всіх цих ролях він зосереджувався на створенні та масштабуванні AI, хмари, DevOps та автоматизаційних платформ для великих підприємств. Його призначення в Cyara спрямоване на розширення можливостей компанії у сфері AI‑потужного забезпечення якості взаємодії з клієнтами та глобального охоплення.

Cyara — компанія з забезпечення якості взаємодії з клієнтами, яка допомагає підприємствам тестувати, моніторити та верифікувати взаємодії з клієнтами через голос, цифрові канали, повідомлення та розмовний AI. Її платформа Cyara Agentic Platform розроблена для вирішення зростаючих викликів, створених AI‑орієнтованими взаємодіями, включаючи тестування недетермінованих AI‑агентів, виявлення галюцинацій та поведінкових відхилень, перевірку відповідності, моніторинг виробничих систем і оцінку сквозних клієнтських шляхів. Платформа поєднує тестування AI‑агентів, моніторинг у продакшн, забезпечення голосу та телекомунікацій, тестування цифрових каналів та спостереження за CX, підтримуючи понад 350 мільйонів клієнтських подорожей щорічно у глобальній мережі, що охоплює більше 140 країн. У міру того, як підприємства впроваджують все більш автономні AI‑агенти у робочі процеси, орієнтовані на клієнтів, Cyara позиціонує свою технологію як шар забезпечення для оцінки, чи працюють ці системи надійно, безпечно та послідовно до та після розгортання.

Ви провели більшу частину кар’єри, створюючи та масштабуючи корпоративне програмне забезпечення, від Oracle і CA/Broadcom до заснування Relicx і тепер очолюючи Cyara. Як цей досвід сформував вашу точку зору щодо того, що AI‑агенти мають керуватись менш як традиційне ПЗ і більше як члени робочої сили?

Більшу частину своєї кар’єри я присвятив створенню та масштабуванню корпоративного програмного забезпечення, і дисципліна, яку ми там сформували, була дисципліною навколо детермінованих систем. Ви знаєте, що має робити програмне забезпечення. Ви перевіряєте його відповідність цьому очікуванню. Коли воно виходить з ладу, воно повідомляє: помилка, невдала транзакція, тривога.

AI‑агенти не працюють так. Вони недетерміновані, тому один і той самий ввід може вести до різних шляхів. Більше того, вони можуть діяти від імені компанії. Вони беруть на себе зобов’язання: повернення коштів, політики, обіцянки. І коли одне з цих зобов’язань помилкове, нічого не ламається. Неправильна відповідь звучить точно так само, як правильна. Транзакція успішна, панель моніторингу залишається зеленою, і клієнт отримує те, на що компанія ніколи не погоджувалась.

Як тільки програмне забезпечення може приймати рішення та зобов’язання, і може помилитися, не повідомляючи вас, йому потрібна інша модель експлуатації.

Саме тут порівняння з робочою силою виправдовує себе. Ви не керуєте працівником, скриптуючи кожне його рішення. Ви надаєте йому роль, встановлюєте повноваження, що з нею пов’язані, і розширюєте ці повноваження, коли він їх заслужить. Агент діє так само в межах такої ж структури.

Я вважаю, що автономність — це не рішення про розгортання. Це серія підвищень. Агент отримує кожне з них, демонструючи, що може виконувати роботу, залишатися в межах своїх повноважень і розпізнавати, коли потрібна допомога.

Як виглядає «HR‑подібна» модель управління AI‑агентами всередині підприємства і які елементи компаніям слід впроваджувати перш за все?

Почніть з ролі. Кожен агент повинен мати щось схоже на опис посадових обов’язків, перш ніж переходити до продакшн. Що він має досягти, яка інформація для нього є авторитетною, які дані клієнтів він може використовувати, які рішення може приймати самостійно і де закінчується його відповідальність. Якщо компанія не може сформулювати це в одному абзаці, агент не готовий до ролі. Він готовий лише до демонстрації.

Від цієї ролі випливають чотири аспекти, і порядок важливий. Докази перед запуском, що означає підтвердження здатності агента виконувати роботу за умов, схожих на реальний світ, а не в контрольованому тесті. Нагляд під час роботи, щоб ви знали, що агент дійсно зробив, а не лише чи система відповіла. Ворота просування, коли більше повноважень надається лише після наявності доказів, а не раніше. І власник у бізнесі, а не в інженерії, який несе відповідальність за те, що агент може робити.

Якщо порядок порушено, решта не працює. Якщо відповідальність нечітка, неможливо довести хорошу продуктивність, так само як і провал. Спочатку визначається роль, а потім збираються докази.

Якщо AI‑агенту призначено конкретну роль, як організації повинні визначати його обов’язки, дозволи та межі перед тим, як дозволити йому взаємодіяти з клієнтами або критичними системами?

Роль вказує, для чого призначений агент. Дозволи визначають, до чого він може отримати доступ. Це два різні діалоги, і компанії, як правило, мають лише перший.

Будьте конкретними щодо трьох речей. Які системи та дані агент може торкатися і в якому напрямку, оскільки читання запису клієнта та його зміна – це не одна й та сама дозвола. Що він може здійснювати самостійно, де знаходяться гроші та відповідальність: повернення коштів, кредит, виняток з політики. І що змушує передати справу, як заздалегідь визначені випадки, так і сигнал, що агент вийшов за межі своєї компетенції.

Це не рішення, які слід залишати технологічній команді. Вони визначають ризик, який бере на себе компанія. Люди, відповідальні за досвід клієнтів та відповідність нормативам, повинні мати слово у визначенні цих меж, і зазвичай їх запитують останніми.

Потім треба довести, що агент дотримується цих меж. Мета не в тому, щоб усунути кожну можливу помилку. Помилки будуть. Питання в тому, чи розуміє агент свої межі, знає, коли зупинитися, і чи може виконувати доручену йому роботу, не створюючи наслідків в іншій частині шляху клієнта.

Ви стверджуєте, що більша автономія має заслужуватись, а не надаватись одразу. Що має продемонструвати AI‑агент, перш ніж підприємство розширить спектр дій, які він може виконувати самостійно?

Зараз легко створити AI‑агента. Складнощі полягають у доведенні, що він заслуговує на автономію.

Перш ніж розширювати те, що агент може робити самостійно, підприємству потрібні докази того, що він виконує свою завдану роботу послідовно і дотримується встановлених меж. Це означає, як він справляється з передбачуваними ситуаціями, а також з тими, які ви не передбачали. Агент може виглядати сильним у контрольованих умовах, а потім поводитися по‑іншому, коли змінюється контекст або оточуючі системи.

Клієнт може розпочати з простого запитання щодо рахунку, а після невдалої оплати роздратуватись. Агент повинен розпізнати цю зміну в процесі та змінити курс, а не продовжувати рухатися по шляху, на якому його верифікували.

Три умови мають бути виконані перед розширенням повноважень. Агент виконує роботу в реальних умовах, а не лише в ідеальних. Він знає межу своєї компетенції і зупиняється на ній. І хтось може надати докази обох цих аспектів за запитом.

Рівень доказів має відповідати рівню автономії. Невеликі рішення – легкі докази. Доступ до платіжної системи або можливість зобов’язати компанію до винятку з політики вимагає значно вищих вимог.

Як компанії мають постійно оцінювати продуктивність AI‑агентів після їх розгортання, особливо коли якість їхніх рішень не можна повністю виміряти традиційними метриками тестування програмного забезпечення?

Саме тут традиційне мислення про програмне забезпечення руйнується. У випадку детермінованого ПЗ ви тестуєте, чи пройшов щось чи ні. У випадку AI‑агента можна отримати успішну відповідь від системи, а взаємодія з клієнтом залишиться невдалою.

Тому ви оцінюєте результат, а не відповідь. Чи зрозумів агент, чого намагався досягти клієнт? Чи використав він правильну інформацію? Чи завершив він шлях? Чи залишався в межах своїх обов’язків і ескалував, коли це було необхідно?

Базові оцінки, які передбачають порівняння відповідей з золотим набором, становлять мінімум. Кожна компанія матиме їх. Параметри, які визначають, чи продовжуватиме клієнт довіряти вам, – це саме вони: відповідність, упередженість, зловживання та те, як агент справляється з реальними абонентами, їхніми акцентами, фоновим шумом, дешевим телефонним апаратом, перериванням посеред речення. У голосовому режимі це важливіше, ніж люди очікують, оскільки кожен бал базується на транскрипції. Якщо мовний шар неправильно розпізнає питання, агент відповідає на питання, яке ніхто не задав.

Варто розібратись у цій арифметиці. Оцінка 99 % звучить відмінно. При мільйоні розмов на рік це означає десять тисяч невдалих.

Два принципи залишаються в силі. Валідність повинна бути незалежною від агентів та платформ моделей. Ми не створюємо агентів самі, і саме тому я можу відкрито сказати, що жоден постачальник не повинен оцінювати власний AI. Стандартом є внутрішні політики підприємства, його зобов’язання перед клієнтами та регуляторні вимоги, а не оцінка постачальника.

Кожна помилка в продакшн має стати бар’єром. Не тикетом, не пунктом беклогу. Тестом, який агент має пройти перед випуском наступної версії. Якщо проблема виникає в продакшн і не перетворюється у тест, який агент повинен пройти, ви платите за подвійне виявлення однієї і тієї ж проблеми.

Довіра та управління все частіше називаються головними перешкодами для масштабування агентного ШІ. Чи вважаєте ви, що технологія розвивається швидше, ніж здатність підприємств її контролювати, і які ризики це створює?

Я вважаю, що саме це й відбувається, і розрив є структурним, а не результатом недбалості. Ідея може стати клієнтським агентом за кілька тижнів. Операційна дисципліна навколо цього агента, його власність, докази, нагляд вимагають значно більше часу, бо вони включають людей і відповідальність, а не лише програмне забезпечення.

Ризик полягає в тому, що розрив залишиться невидимим, одночасно розширюючись. Агент може надати клієнту впевнено неправильну відповідь без помилки, без невдалої транзакції та без сповіщення. Кожна панель інструментів виглядає зеленою. Традиційні операції залежать від систем, які повідомляють вас, коли у них проблеми, а агенти це роблять ненадійно.

Я не вважаю, що відповідь — уповільнитися. Компанії, які тут переможуть, будуть діяти швидко. Відповідь полягає у створенні доказів і контролю, які дозволяють рухатися швидко з упевненістю. Чим більше автономії отримує агент, тим більше доказів потрібно, щоб підтвердити, що він може нести відповідальність.

Коли автономний агент приймає погане рішення, хто повинен нести остаточну відповідальність: розробник, підрозділ, що його впроваджує, постачальник моделі чи керівник, який схвалив її використання?

Зрештою компанія, що впроваджує агента, несе відповідальність за результат. У створенні та експлуатації системи залучено кілька сторін, але у клієнта немає відносин з постачальником моделі. Клієнт має відносини з компанією, назва якої вказана в взаємодії.

Це не означає, що відповідальність лежить на одній особі. Вона проходить через ланцюжок прийняття рішень. Розробник відповідає за те, як була побудована система. Бізнес вирішує, що агент може робити. Постачальник відповідає за надану технологію. Керівництво відповідає за те, щоб у компанії були контролі та нагляд для управління ризиком у цілому.

Помилкою є думка, що оскільки модель прийняла рішення, то модель його володіє. Це не так. Якщо агент робить зобов’язання перед клієнтом від вашого імені, це зобов’язання належить бренду. Клієнти розуміють це інтуїтивно, так само як і регулятори.

AI‑агенти можуть поводитися непередбачувано, коли стикаються з ситуаціями, які не передбачали під час тестування. Як підприємства мають тестувати такі крайні випадки, перш ніж надати агентам доступ до клієнтів, фінансових систем або конфіденційних даних?

Потрібно припускати, що агент зрештою зіткнеться з чимось, для чого його не розробляли. Питання — що станеться, коли це трапиться.

Тому перевіряйте не лише очікуваний шлях. Давайте агенту неоднозначні запити. Давайте йому суперечливу інформацію. Давайте неповний контекст. Ставте його в ситуації, коли правильна відповідь — зупинитися і ескалувати, а не продовжувати. Додавайте умови реального світу, які у голосі означають акценти, шум, поганий зв’язок і абонентів, які змінюють тему посеред розмови. Мета не в тому, щоб підтвердити, що агент працює. Вона полягає у виявленні його поведінки, коли умови не ідеальні.

Більш важливим є те, що потрібно перевіряти весь шлях, а не лише агента окремо. Зазвичай проблема не в моделі. Коли щось іде не так, моє перше запитання — який контекст отримала модель. Це могла бути застаріла стаття знань, або дві системи з протиріччям у політиках, або передача, яка втратила те, що клієнт уже пояснив. Кожен компонент може пройти власний тест, і все ж шлях клієнта може зазнати провалу в місцях їх взаємодії.

Той шар між системами — це те, що ми роками налаштовували, охоплюючи 450 підприємств і понад 350 мільйонів клієнтських шляхів щороку. Незалежно від того, чи є агент автономним, він ламається однаково. Ми також бачимо агентів, створених на базі технологій понад 55 різних постачальників, а також на кожній великій платформі контакт-центру, що дозволяє нам стверджувати, що шаблон зберігається незалежно від того, яка модель використовується під ним.

Перш ніж агент отримає доступ до важливих ресурсів, підприємство має мати докази того, що він робить у випадках успіху та невдачі.

Як ви бачите еволюцію тестування ШІ, коли компанії переходять від детермінованого програмного забезпечення до систем, які розмірковують, планують, спілкуються та здійснюють дії в декількох додатках?

Тестування має перейти від питання, чи система надала очікувану відповідь, до питання, чи вона досягла правильного результату.

Це суттєва зміна. Агент може обирати кілька різних шляхів для вирішення однієї й тієї ж клієнтської проблеми, і ці шляхи можуть змінюватися з часом у міру оновлення моделей та знань, що їх підкріплюють. Ви не можете написати сценарій для кожної можливої взаємодії. Потрібно оцінювати, чи агент зрозумів намір, чи приймав обґрунтовані рішення протягом процесу та чи залишався в межах заданих йому обмежень.

Хочу бути обережним щодо одного, бо галузь починає робити це неправильно і дорого. Тестування перед запуском зараз важливіше, а не менш. Воно визначає, чи готовий агент. Твердження, що можна його пропустити і просто спостерігати за продакшном, — це аргумент, який виявляє проблеми перед клієнтами.

Змінюється те, що тестування перед запуском вже не є кінцем процесу. Продакшн виявляє умови, які контрольоване середовище не може повністю відтворити, і те, що виявляє продакшн, стає тестом, який агент має пройти перед наступним випуском. Докази перед запуском, пильність у продакшні, і взаємне підсилення цих етапів. Агент, який працює у шостому місяці, повинен бути вимірно кращим, ніж той, що був запущений.

Дивлячись у майбутнє, що відрізнятиме організації, які успішно створюють довірені ШІ‑команди, від тих, які залишаються на місці, проводячи лише малі пілотні проєкти агентних ШІ?

Організації, які отримують реальну віддачу від агентів, — це ті, що побудували операційну модель навколо доказів. Ті, що затримуються, зазвичай не блоковані технологією. Їх блокує те, що ніхто не може надати те, що вимагає наступний рівень затвердження. Юридичний відділ ставить розумне питання, або це робить комітет з ризиків, і відповіді немає, тому пілот залишається пілотом. Технологія може бути готова, а організація все ще не може виправдати надання їй більшої влади.

Ось різниця між пілотом і діючою робочою силою. У пілоті хтось завжди спостерігає. В операційній моделі кожен агент має завдання, яке можна сформулювати в одному реченні. Його повноваження обмежені і задокументовані. Його продуктивність оцінюється не тією командою, яка його створила. Помилки у виробництві стають воротами випуску. Більша автономність слідує після доведення.

Друга різниця — це власність. У компаніях, які масштабуются, агент належить бізнес‑функції, якій він служить, і має іменованого власника, який відповідає за його дії. Якщо ж він залишається проєктом ШІ, яким керує команда ШІ, він залишається малим, бо жоден бізнес‑лідер не візьме на себе ризик того, чого він не контролює.

Ніщо з цього не є екзотичним. Це близько до того, як компанія вже керує людьми, яким довіряє реальна відповідальність.

Пілот може працювати на основі переконання організації. Масштабування вимагає доказів.

Дякуємо за чудове інтерв’ю, читачі, які хочуть дізнатися більше, повинні відвідати Cyara.