Sushil Kumar, CEO of Cyara — серия интервью

Sushil Kumar, CEO компании Cyara — опытный руководитель в сфере корпоративного программного обеспечения и предприниматель с более чем 25-летним опытом лидерства в области искусственного интеллекта, DevOps, облачной инфраструктуры, продуктовой стратегии и тестирования программного обеспечения. Он присоединился к Cyara в качестве CEO в декабре 2025 года, после того как был соучредителем и CEO 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‑агенты могут вести себя непредсказуемо, когда сталкиваются с ситуациями, не предусмотренными в тестировании. Как предприятия должны проверять такие граничные случаи, прежде чем агенты получат доступ к клиентам, финансовым системам или конфиденциальным данным?

Нужно предполагать, что агент в конечном итоге столкнётся с чем‑то, для чего он не был разработан. Вопрос в том, что произойдёт, когда это случится.

Поэтому проверяйте не только ожидаемый путь. Давайте агенту неоднозначные запросы. Давайте ему противоречивую информацию. Давайте неполный контекст. Помещайте его в ситуации, когда правильный ответ — остановиться и эскалировать, а не продолжать. Добавляйте условия реального мира, а в голосе это означает акценты, шум, плохие соединения и звонящих, меняющих тему посередине разговора. Цель не подтвердить, что агент работает, а выяснить, как он ведёт себя при нечистых условиях.

Самое важное — проверять весь путь, а не только агента в изоляции. Обычно проблема не в модели. Когда что‑то идёт не так, мой первый вопрос: какой контекст получил модель. Это мог быть устаревший справочный материал, два системы с противоречивыми политиками или передача, в которой упущено то, что клиент уже объяснил. Каждый компонент может пройти свой тест, но путь клиента всё равно может провалиться в стыках между ними.

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

Прежде чем агент получит доступ к чему‑то важному, предприятие должно иметь доказательства того, как он работает, когда всё идёт правильно, и когда нет.

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

Тестирование должно перейти от вопроса, дал ли система ожидаемый ответ, к вопросу, достиг ли она правильного результата.

Это значительный сдвиг. Агент может использовать несколько разных путей для решения одной и той же клиентской проблемы, и эти пути могут изменяться со временем по мере изменения моделей и знаний, лежащих в их основе. Нельзя написать сценарий для каждой возможной интеракции. Нужно оценивать, понял ли агент намерение, принимал ли он обоснованные решения и оставался ли в рамках заданных ограничений.

Я хочу предостеречь от одной вещи, потому что отрасль начинает ошибаться в этом дорого. Предзапусковое тестирование сейчас важнее, а не менее важно. Оно определяет, готов ли агент. Аргумент, что можно его пропустить и наблюдать в продакшене, — это аргумент в пользу того, чтобы узнать об ошибках до того, как они коснутся клиентов.

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

Смотря в будущее, что будет отличать организации, успешно создающие надёжные AI‑рабочие силы, от тех, кто остаётся застрявшим в небольших пилотных проектах агентного ИИ?

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

Это разница между пилотом и работающей силой. В пилоте кто‑то постоянно наблюдает. В операционной модели каждый агент имеет задачу, которую можно сформулировать в одном предложении. Его полномочия ограничены и зафиксированы. Его эффективность оценивается не той командой, которая его создала. Ошибки в производстве становятся контрольными точками выпуска. Больше автономии следует после подтверждения.

Вторая разница — владение. В компаниях, которые масштабируются, агент принадлежит бизнес‑функции, которой он служит, и у него есть именованный владелец, отвечающий за его действия. Когда агент остаётся AI‑проектом, принадлежащим AI‑команде, он остаётся небольшим, потому что ни один бизнес‑руководитель не возьмёт на себя риск того, что он не контролирует.

Ничего из этого не является экзотикой. Это близко к тому, как компания уже управляет людьми, которым доверяет реальную ответственность.

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

Спасибо за отличное интервью, читатели, желающие узнать больше, должны посетить Cyara.