Sushil Kumar, CEO da Cyara – Série de Entrevistas

Sushil Kumar, CEO da Cyara é um executivo experiente de software empresarial e empreendedor com mais de 25 anos de liderança em inteligência artificial, DevOps, infraestrutura de nuvem, estratégia de produto e teste de software. Ele ingressou na Cyara como CEO em dezembro de 2025, após atuar como cofundador e CEO da RelicX.ai, onde construiu uma plataforma de automação de testes baseada em intenção e alimentada por IA generativa que foi adquirida pela Harness. Em seguida, liderou a integração da tecnologia da RelicX na Harness e ajudou a moldar sua estratégia de Automação de Testes com IA. No início de sua carreira, Kumar atuou como Gerente Geral de DevOps na Broadcom, Vice‑Presidente Sênior de Produtos na CA Technologies, e passou mais de 16 anos na Oracle, onde ocupou cargos de liderança de produto e ajudou a escalar grandes negócios de software empresarial. Em todas essas funções, ele se concentrou em construir e escalar plataformas de IA, nuvem, DevOps e automação para grandes empresas. Sua nomeação na Cyara tem como foco expandir as capacidades de garantia de experiência do cliente alimentadas por IA da empresa e seu alcance global.

Cyara é uma empresa de garantia de experiência do cliente que ajuda empresas a testar, monitorar e validar interações com clientes em canais de voz, digitais, de mensagens e de IA conversacional. Sua Cyara Agentic Platform foi projetada para enfrentar os desafios crescentes criados por experiências de cliente impulsionadas por IA, incluindo teste de agentes de IA não determinísticos, detecção de alucinações e deriva comportamental, validação de conformidade, monitoramento de sistemas de produção e avaliação de jornadas de cliente de ponta a ponta. A plataforma combina teste de agentes de IA, monitoramento de produção, garantia de voz e telecomunicações, teste de canais digitais e observabilidade de CX, suportando mais de 350 milhões de jornadas de cliente anualmente em uma presença global que abrange mais de 140 países. À medida que as empresas implantam agentes de IA cada vez mais autônomos em fluxos de trabalho voltados ao cliente, a Cyara está posicionando sua tecnologia como uma camada de garantia para avaliar se esses sistemas se comportam de forma confiável, segura e consistente antes e depois da implantação.

Você passou a maior parte da sua carreira construindo e escalando software empresarial, da Oracle e CA/Broadcom à fundação da Relicx e agora liderando a Cyara. Como essa experiência moldou sua visão de que os agentes de IA devem ser gerenciados menos como software tradicional e mais como membros de uma força de trabalho?

Passei a maior parte da minha carreira construindo e escalando software empresarial, e a disciplina que desenvolvemos lá era uma disciplina voltada a sistemas determinísticos. Você sabe o que o software deve fazer. Você o valida contra essa expectativa. Quando ele falha, ele informa: um erro, uma transação falhada, um alerta.

Os agentes de IA não funcionam dessa forma. Eles são não determinísticos, portanto a mesma entrada pode seguir caminhos diferentes. Mais importante ainda, eles podem agir em nome da empresa. Eles assumem compromissos: reembolsos, políticas, promessas. E quando um desses está errado, nada quebra. Uma resposta errada soa exatamente como uma correta. A transação tem sucesso, o painel permanece verde e o cliente sai com algo que a empresa nunca concordou.

Quando o software pode tomar decisões e assumir compromissos, e pode estar errado sem avisar, ele necessita de um modelo operacional diferente.

É aí que a comparação com a força de trabalho justifica seu valor. Você não gerencia um funcionário roteirizando cada decisão que ele tomará. Você lhe atribui um cargo, estabelece a autoridade que o acompanha e expande essa autoridade à medida que ele a conquista. Um agente se comporta da mesma forma sob a mesma estrutura.

Na minha visão, a autonomia não é uma decisão de implantação. É uma série de promoções. Um agente conquista cada uma demonstrando que pode executar a tarefa, permanecer dentro de sua autoridade e reconhecer quando precisa de ajuda.

Como realmente se parece um modelo operacional “semelhante ao RH” para agentes de IA dentro de uma empresa, e quais elementos as empresas devem implementar primeiro?

Comece pelo cargo. Cada agente deve ter algo próximo a uma descrição de cargo antes de ser colocado perto da produção. O que ele deve alcançar, quais informações são autoritativas para ele, quais dados de cliente pode usar, quais decisões pode tomar por conta própria e onde termina sua responsabilidade. Se uma empresa não conseguir escrever isso em um parágrafo, o agente não está pronto para um cargo. Está pronto apenas para uma demonstração.

Quatro coisas decorrem desse cargo, e a ordem é importante. Evidência antes do lançamento, o que significa comprovar que o agente pode executar o cargo em condições que se assemelham ao mundo real, em vez de um teste controlado. Supervisão durante a operação, para que você saiba o que o agente realmente fez e não apenas se o sistema respondeu. Portões de promoção, para que mais autoridade seja concedida quando houver evidências que a sustentem e não antes. E um responsável no negócio, não na engenharia, que seja responsável pelo que esse agente tem permissão para fazer.

Se a ordem estiver errada, o resto não se sustenta. Se a responsabilidade for vaga, é impossível provar um bom desempenho, assim como a falha. O cargo vem primeiro, e a evidência segue.

Se um agente de IA for atribuído a um cargo específico, como as organizações devem definir suas responsabilidades, permissões e limites antes de permitir que ele interaja com clientes ou sistemas críticos?

O papel indica para que o agente serve. As permissões indicam o que ele pode alcançar. São duas conversas diferentes, e as empresas tendem a ter apenas a primeira.

Seja explícito sobre três coisas. Quais sistemas e dados o agente pode acessar, e em que direção, pois ler um registro de cliente e alterá-lo não são a mesma permissão. O que ele pode comprometer por conta própria, que é onde o dinheiro e a responsabilidade se encontram: um reembolso, um crédito, uma exceção à política. E o que força uma transferência, tanto os casos que você pode nomear antecipadamente quanto o sinal de que o agente saiu da sua competência.

Essas não são decisões que devem ser deixadas para a equipe de tecnologia. Elas determinam o risco que a empresa está assumindo. As pessoas responsáveis pela experiência do cliente e pela exposição à conformidade precisam ter voz sobre onde essas linhas são traçadas, e geralmente são as últimas a serem consultadas.

Então é preciso provar que o agente permanece dentro delas. O objetivo não é eliminar todo erro possível. Haverá erros. A questão é se o agente entende seus limites, sabe quando parar e pode executar a tarefa que lhe foi atribuída sem gerar consequências em outra parte da jornada do cliente.

Você argumenta que maior autonomia deve ser conquistada em vez de concedida desde o início. O que um agente de IA deve demonstrar antes que uma empresa amplie o escopo de ações que ele pode executar de forma independente?

Agora é fácil construir um agente de IA. A parte difícil é provar que ele merece autonomia.

Antes de ampliar o que um agente pode fazer por conta própria, uma empresa precisa de evidências de que ele executa a tarefa atribuída de forma consistente e permanece dentro de seus limites. Isso inclui como ele lida com as situações que você espera e também com as que não antecipou. Um agente pode parecer sólido em condições controladas e comportar‑se de maneira diferente quando o contexto ou os sistemas ao redor mudam.

Um cliente pode começar com uma simples pergunta sobre faturamento e ficar frustrado após um pagamento falhado. O agente precisa reconhecer essa mudança enquanto ocorre e mudar de direção, em vez de continuar no caminho em que foi validado.

Três coisas devem ser verdadeiras antes que a autoridade seja ampliada. O agente realiza a tarefa em condições reais, não apenas em cenários limpos. Ele conhece o limite da sua própria competência e para lá. E alguém pode produzir as evidências de ambos sob demanda.

O nível de comprovação deve corresponder ao nível de autonomia. Decisões pequenas, evidência leve. Acesso a um sistema de pagamento ou a capacidade de comprometer a empresa a uma exceção de política exigem um patamar consideravelmente mais alto.

Como as empresas devem avaliar continuamente o desempenho de agentes de IA após sua implantação, especialmente quando a qualidade de suas decisões não pode ser capturada apenas por métricas tradicionais de teste de software?

É aqui que o pensamento tradicional de software falha. Com software determinístico você testa se algo passou ou falhou. Com um agente de IA você pode obter uma resposta bem‑sucedida do sistema e ainda assim ter uma interação com o cliente que falhou.

Portanto, você avalia o resultado, não a resposta. O agente entendeu o que o cliente estava tentando alcançar? Utilizou as informações corretas? Concluiu a jornada? Manteve‑se dentro dos seus limites e escalou quando deveria?

Avaliações básicas, pontuando respostas contra um conjunto de referência, são o ponto de partida. Toda empresa terá essas avaliações. As dimensões que determinam se um cliente continua confiando em você são as subjacentes: conformidade, viés, uso indevido e como o agente se sai com chamadas reais, seus sotaques, o ruído de fundo, o telefone barato, a interrupção no meio de uma frase. Na voz isso importa mais do que as pessoas esperam, porque cada pontuação está baseada em uma transcrição. Se a camada de fala interpreta mal a pergunta, o agente responde a algo que ninguém perguntou.

A conta vale a pena analisar. Uma pontuação de 99 % na avaliação parece excelente. Em um milhão de conversas por ano, isso corresponde a dez mil falhas.

Dois princípios permanecem válidos. A validação deve ser independente do agente e das plataformas de modelo. Não construímos os agentes nós mesmos, o que explica por que posso afirmar claramente que nenhum fornecedor deve ser o juiz da sua própria IA. O padrão são as políticas da própria empresa, seus compromissos com o cliente e suas obrigações regulatórias, não o placar de um fornecedor.

E cada falha em produção deve se tornar um ponto de controle. Não um ticket, não um item de backlog. Um teste que o agente precisa superar antes que a próxima versão seja lançada. Se um problema ocorre em produção e não se transforma em algo que o agente deve passar, você está pagando para descobrir o mesmo problema duas vezes.

A confiança e a governança são cada vez mais citadas como grandes barreiras à escalabilidade da IA agente. Você acredita que a tecnologia está avançando mais rápido do que a capacidade das empresas de supervisioná‑la, e que riscos isso cria?

Acho que isso é exatamente o que está acontecendo, e a lacuna é estrutural, não uma falha de esforço. Uma ideia pode se tornar um agente voltado ao cliente em semanas. A disciplina operacional em torno desse agente, a propriedade, as evidências, a supervisão, levam muito mais tempo, porque envolvem pessoas e responsabilidade, e não apenas software.

O risco é que a lacuna permaneça invisível enquanto se amplia. Um agente pode dar ao cliente uma resposta errada com confiança, sem erro, sem transação falhada e sem alerta. Todos os painéis aparecem verdes. As operações tradicionais dependem de sistemas que avisam quando há problemas, e os agentes não fazem isso de forma confiável.

Não acho que a resposta seja desacelerar. As empresas que vencerão aqui vão se mover rápido. A resposta é construir as evidências e a supervisão que permitem avançar rapidamente com confiança. Quanto mais autonomia um agente recebe, mais evidências você precisa de que ele pode assumir a responsabilidade.

Quando um agente autônomo toma uma decisão ruim, quem deve ser responsabilizado em última instância: o desenvolvedor, a unidade de negócios que o implementa, o fornecedor que fornece o modelo ou o executivo que aprovou seu uso?

Em última análise, a empresa que implanta o agente detém o resultado. Várias partes estão envolvidas na construção e operação do sistema, mas o cliente não tem relação com o provedor do modelo. O cliente tem relação com a empresa cujo nome está na interação.

Isso não significa que a responsabilidade fique com uma única pessoa. Ela percorre a cadeia de decisão. O desenvolvedor é responsável por como o sistema foi construído. A empresa decide o que o agente tem permissão para fazer. O fornecedor é responsável pela tecnologia que fornece. A liderança é responsável por garantir que a empresa tenha os controles e a supervisão necessários para gerir o risco.

O erro está em pensar que, porque o modelo tomou a decisão, ele a possui. Não é assim. Se um agente assume um compromisso com um cliente em seu nome, esse compromisso pertence à marca. Os clientes compreendem isso instintivamente, e os reguladores também.

Agentes de IA podem se comportar de forma imprevisível quando encontram situações não antecipadas durante os testes. Como as empresas devem testar esses casos extremos antes que os agentes tenham acesso a clientes, sistemas financeiros ou dados sensíveis?

É preciso assumir que o agente eventualmente encontrará algo para o qual não foi projetado. A questão é o que acontece quando isso ocorre.

Portanto, valide além do caminho esperado. Dê ao agente solicitações ambíguas. Forneça informações conflitantes. Dê um contexto incompleto. Coloque-o em situações em que a resposta correta é parar e escalar, em vez de continuar. Adicione as condições do mundo real, que na voz incluem sotaques, ruído, conexões ruins e interlocutores que mudam de assunto pela metade. O objetivo não é confirmar que o agente funciona, mas descobrir como ele se comporta quando as condições não são ideais.

O ponto mais importante é que você deve validar toda a jornada, não apenas o agente isoladamente. O modelo geralmente não é o problema. Quando algo dá errado, minha primeira pergunta é qual contexto o modelo recebeu. Pode ter sido um artigo de conhecimento desatualizado, ou dois sistemas com políticas conflitantes, ou uma transferência que perdeu o que o cliente já havia explicado. Cada componente pode passar em seu próprio teste e a jornada do cliente ainda pode falhar nas lacunas entre eles.

Essa camada entre os sistemas é a que temos instrumentado há anos, em mais de 450 empresas e mais de 350 milhões de jornadas de clientes por ano. Seja agente ou não, ela falha da mesma forma. Também vemos agentes construídos sobre a tecnologia de mais de 55 fornecedores diferentes, além de todas as principais plataformas de contact center, o que nos permite saber que o padrão se mantém independentemente do modelo subjacente.

Antes que um agente tenha acesso a algo importante, a empresa deve possuir evidências do que ele faz quando tudo ocorre bem e quando não ocorre.

Como você vê a evolução dos testes de IA à medida que as empresas passam de software determinístico para sistemas que raciocinam, planejam, se comunicam e executam ações em múltiplas aplicações?

Os testes precisam mudar de perguntar se um sistema produziu a resposta esperada para perguntar se ele alcançou o resultado correto.

Essa é uma mudança significativa. Um agente pode seguir vários caminhos diferentes para resolver o mesmo problema do cliente, e esses caminhos podem mudar ao longo do tempo à medida que os modelos e o conhecimento por trás deles evoluem. Não é possível escrever um script para todas as interações possíveis. É necessário avaliar se o agente compreendeu a intenção, tomou decisões sensatas ao longo do processo e permaneceu dentro dos limites estabelecidos.

Quero ser cuidadoso com um ponto, pois a indústria está começando a errar de forma custosa. Os testes pré-lançamento são mais importantes agora, não menos. Eles determinam se um agente está pronto. O argumento de que você pode pular essa fase e observar a produção, na verdade, é um argumento para descobrir os problemas diante dos clientes.

O que muda é que os testes pré-lançamento não são mais o fim do processo. A produção revela condições que um ambiente controlado não consegue reproduzir completamente, e o que a produção revela torna-se um teste que o agente deve superar antes da próxima versão. Prova antes do lançamento, vigilância na produção, e cada um alimentando o outro. O agente em operação no sexto mês deve ser mensuravelmente melhor que o que foi lançado.

Olhando para o futuro, o que distinguirá as organizações que constroem com sucesso forças de trabalho de IA confiáveis daquelas que permanecem presas a pequenos pilotos de IA agente?

As organizações que obtêm retorno real dos agentes são as que construíram um modelo operacional baseado em evidências. As que ficam estagnadas geralmente não são bloqueadas pela tecnologia. Elas são bloqueadas porque ninguém pode produzir o que o próximo nível de aprovação exige. O jurídico faz uma pergunta razoável, ou o comitê de risco faz, e não há resposta, então o piloto continua sendo um piloto. A tecnologia pode estar pronta e a organização ainda não consegue justificar conceder-lhe mais autoridade.

Essa é a diferença entre um piloto e uma força de trabalho operacional. Em um piloto, alguém está sempre observando. Em um modelo operacional, cada agente tem uma tarefa que pode ser descrita em uma frase. Sua autoridade é limitada e documentada. Seu desempenho é avaliado por algo diferente da equipe que o criou. Falhas de produção se tornam portões de liberação. Mais autonomia segue a comprovação.

A segunda diferença é a propriedade. Nas empresas que escalam, o agente pertence à função de negócios que atende, com um proprietário nomeado que responde pelo que ele faz. Quando permanece um projeto de IA de propriedade de uma equipe de IA, ele permanece pequeno, porque nenhum líder de negócios assumirá o risco de algo que não controla.

Nada disso é exótico. É próximo de como uma empresa já gerencia as pessoas em quem confia com responsabilidade real.

Um piloto pode ser conduzido com base na convicção da organização. Escalar requer evidências.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar Cyara.