Sushil Kumar, CEO de Cyara – Serie de entrevistas

Sushil Kumar, CEO de Cyara es un ejecutivo de software empresarial experimentado y emprendedor con más de 25 años de liderazgo en inteligencia artificial, DevOps, infraestructura en la nube, estrategia de producto y pruebas de software. Se unió a Cyara como CEO en diciembre de 2025, después de su papel como cofundador y CEO de RelicX.ai, donde construyó una plataforma de automatización de pruebas basada en intención y potenciada por IA generativa que fue adquirida por Harness. Posteriormente lideró la integración de la tecnología de RelicX en Harness y ayudó a definir su estrategia de Automatización de Pruebas con IA. En etapas anteriores de su carrera, Kumar se desempeñó como Gerente General de DevOps en Broadcom, Vicepresidente Senior de Productos en CA Technologies, y pasó más de 16 años en Oracle, donde ocupó cargos de liderazgo senior de producto y contribuyó a escalar importantes negocios de software empresarial. En todos esos roles, se ha centrado en construir y escalar plataformas de IA, nube, DevOps y automatización para grandes empresas. Su nombramiento en Cyara está enfocado en ampliar las capacidades de garantía de experiencia del cliente impulsadas por IA de la compañía y su alcance global.

Cyara es una empresa de garantía de experiencia del cliente que ayuda a las organizaciones a probar, monitorear y validar las interacciones con clientes a través de canales de voz, digitales, de mensajería y de IA conversacional. Su Cyara Agentic Platform está diseñada para abordar los crecientes desafíos creados por experiencias de cliente impulsadas por IA, incluyendo la prueba de agentes de IA no determinísticos, la detección de alucinaciones y desviaciones de comportamiento, la validación de cumplimiento, el monitoreo de sistemas de producción y la evaluación de recorridos de cliente de extremo a extremo. La plataforma combina pruebas de agentes de IA, monitoreo de producción, garantía de voz y telecomunicaciones, pruebas de canales digitales y observabilidad de CX, respaldando más de 350 millones de recorridos de cliente al año en una presencia global que abarca más de 140 países. A medida que las organizaciones despliegan agentes de IA cada vez más autónomos en flujos de trabajo orientados al cliente, Cyara está posicionando su tecnología como una capa de garantía para evaluar si esos sistemas se comportan de manera fiable, segura y consistente antes y después del despliegue.

Has dedicado gran parte de tu carrera a construir y escalar software empresarial, desde Oracle y CA/Broadcom hasta fundar Relicx y ahora liderar Cyara. ¿Cómo ha influido esa experiencia en tu visión de que los agentes de IA deberían gestionarse menos como software tradicional y más como miembros de una fuerza laboral?

He dedicado la mayor parte de mi carrera a construir y escalar software empresarial, y la disciplina que desarrollamos allí se centró en sistemas determinísticos. Sabes lo que el software debe hacer. Lo validas contra esa expectativa. Cuando falla, te indica: un error, una transacción fallida, una alerta.

Los agentes de IA no funcionan de esa manera. Son no determinísticos, por lo que la misma entrada puede seguir un camino diferente. Más importante aún, pueden actuar en nombre de la empresa. Asumen compromisos: reembolsos, políticas, promesas. Y cuando uno de esos es incorrecto, no se produce una ruptura. Una respuesta errónea suena exactamente como una correcta. La transacción se completa, el panel permanece verde y el cliente se lleva algo que la empresa nunca acordó.

Una vez que el software puede tomar decisiones y compromisos, y puede equivocarse sin avisarte, necesita un modelo operativo diferente.

Ahí es donde la comparación con la fuerza laboral cobra sentido. No gestionas a un empleado programando cada decisión que tomará. Le asignas un rol, estableces la autoridad que conlleva y amplías esa autoridad a medida que la gana. Un agente se comporta de la misma manera bajo la misma estructura.

Mi interpretación es que la autonomía no es una decisión de despliegue. Es una serie de promociones. Un agente gana cada una demostrando que puede realizar el trabajo, mantenerse dentro de su autoridad y reconocer cuándo necesita ayuda.

¿Cómo es realmente un modelo operativo \”similar al de RR.HH.\” para agentes de IA dentro de una empresa, y qué elementos deberían implementar primero las compañías?

Comienza con el puesto. Cada agente debe contar con algo parecido a una descripción de trabajo antes de acercarse a la producción. Qué debe lograr, qué información es autoritativa para él, qué datos de cliente puede usar, qué decisiones puede tomar por sí mismo y dónde termina su responsabilidad. Si una empresa no puede redactar eso en un párrafo, el agente no está listo para un rol. Está listo para una demostración.

Cuatro cosas derivan de ese rol, y el orden es importante. Evidencia antes del lanzamiento, lo que implica demostrar que el agente puede desempeñar el trabajo bajo condiciones que se asemejen al mundo real en lugar de una prueba controlada. Supervisión mientras funciona, para saber lo que el agente realmente hizo y no solo si el sistema respondió. Puertas de promoción, de modo que se otorgue más autoridad cuando exista evidencia que lo respalde y no antes. Y un responsable en el negocio, no en ingeniería, que rinda cuentas de lo que ese agente está autorizado a hacer.

Si el orden se equivoca, el resto no se sostiene. Si la responsabilidad es vaga, es imposible demostrar un buen desempeño, al igual que el fracaso. El rol viene primero y la evidencia sigue.

Si se asigna a un agente de IA un rol específico, ¿cómo deberían las organizaciones definir sus responsabilidades, permisos y límites antes de permitirle interactuar con clientes o sistemas críticos?

El rol indica para qué sirve el agente. Los permisos indican a qué puede acceder. Son dos conversaciones diferentes, y las empresas tienden a tener solo la primera.

Sea explícito acerca de tres cosas. Qué sistemas y datos puede tocar el agente, y en qué dirección, porque leer un registro de cliente y modificarlo no son el mismo permiso. Qué puede comprometer por sí mismo, que es donde se encuentran el dinero y la responsabilidad: un reembolso, un crédito, una excepción a la política. Y qué obliga a una transferencia, tanto los casos que puede nombrar de antemano como la señal de que el agente ha salido de su competencia.

Estas no son decisiones que se deban dejar al equipo de tecnología. Determinan el riesgo que asume la empresa. Las personas responsables de la experiencia del cliente y de la exposición a cumplimiento deben opinar sobre dónde se trazan esas líneas, y suelen ser las últimas a las que se consulta.

Luego hay que demostrar que el agente se mantiene dentro de ellas. El objetivo no es eliminar todo error posible. Habrá errores. La cuestión es si el agente comprende sus límites, sabe cuándo detenerse y puede realizar la tarea asignada sin generar consecuencias en otra parte del recorrido del cliente.

Argumentas que una mayor autonomía debe ganarse en lugar de concederse desde el principio. ¿Qué debe demostrar un agente de IA antes de que una empresa amplíe el alcance de acciones que puede realizar de forma independiente?

Ahora es fácil crear un agente de IA. La parte difícil es demostrar que merece autonomía.

Antes de ampliar lo que un agente puede hacer por sí mismo, una empresa necesita evidencia de que desempeña su tarea asignada de manera constante y se mantiene dentro de sus límites. Eso implica cómo maneja las situaciones que esperas y también las que no anticipaste. Un agente puede parecer sólido bajo condiciones controladas y comportarse de forma distinta cuando el contexto o los sistemas circundantes cambian.

Un cliente puede comenzar con una pregunta sencilla de facturación y frustrarse tras un pago fallido. El agente debe reconocer ese cambio mientras ocurre y cambiar de rumbo, en lugar de continuar por el camino en el que fue validado.

Tres cosas deben ser verdaderas antes de que la autoridad se amplíe. El agente realiza su trabajo bajo condiciones reales, no solo en entornos limpios. Conoce el límite de su propia competencia y se detiene allí. Y alguien puede proporcionar la evidencia de ambos a demanda.

El nivel de prueba debe coincidir con el nivel de autonomía. Decisiones pequeñas, evidencia ligera. El acceso a un sistema de pagos, o la capacidad de comprometer a la empresa con una excepción de política, deben tener un umbral considerablemente más alto.

¿Cómo deberían las empresas evaluar continuamente el rendimiento de los agentes de IA una vez desplegados, especialmente cuando la calidad de sus decisiones no puede capturarse solo con métricas tradicionales de pruebas de software?

Aquí es donde el pensamiento tradicional de software se rompe. Con software determinista se prueba si algo aprobó o falló. Con un agente de IA puedes obtener una respuesta exitosa del sistema y, sin embargo, tener una interacción con el cliente que falla.

Por lo tanto, evalúas el resultado, no la respuesta. ¿Entendió el agente lo que el cliente intentaba lograr? ¿Utilizó la información correcta? ¿Completó el recorrido? ¿Se mantuvo dentro de sus límites y escaló cuando debía?

Las evaluaciones básicas, puntuando respuestas contra un conjunto de referencia, son el punto de partida. Cada empresa tendrá esas. Las dimensiones que determinan si un cliente sigue confiando en ti son las subyacentes: cumplimiento, sesgo, uso indebido y cómo el agente se desempeña con llamantes reales, sus acentos, el ruido de fondo, el teléfono barato, la interrupción a mitad de una frase. En voz, esto importa más de lo que la gente espera, porque cada puntuación se basa en una transcripción. Si la capa de voz interpreta mal la pregunta, el agente responde a una que nadie hizo.

Vale la pena analizar la aritmética. Una puntuación del 99 % en la evaluación suena excelente. Con un millón de conversaciones al año, eso equivale a diez mil fallidas.

Dos principios se mantienen. La validación debe ser independiente del agente y de las plataformas de modelo. No construimos los agentes nosotros mismos, lo que explica por qué puedo afirmar claramente que ningún proveedor debe ser el juez de su propia IA. El estándar son las políticas propias de la empresa, sus compromisos con los clientes y sus obligaciones regulatorias, no la hoja de puntuación de un proveedor.

Y cada falla en producción debe convertirse en una puerta. No en un ticket, no en un elemento del backlog. Una prueba que el agente debe superar antes de que se envíe la siguiente versión. Si un problema ocurre en producción y no se transforma en algo que el agente deba superar, estás pagando por descubrir el mismo problema dos veces.

La confianza y la gobernanza se citan cada vez más como barreras importantes para escalar la IA agente. ¿Crees que la tecnología avanza más rápido que la capacidad de las empresas para supervisarla, y qué riesgos genera eso?

Creo que eso es exactamente lo que está ocurriendo, y la brecha es estructural más que una falta de esfuerzo. Una idea puede convertirse en un agente de cara al cliente en semanas. La disciplina operativa alrededor de ese agente, la propiedad, la evidencia, la supervisión, lleva mucho más tiempo, porque involucra a personas y responsabilidad, no solo al software.

El riesgo es que la brecha permanezca invisible mientras se amplía. Un agente puede dar a un cliente una respuesta errónea con total confianza, sin error, sin transacción fallida y sin alerta. Cada panel muestra todo en verde. Las operaciones tradicionales dependen de que los sistemas avisen cuando están en problemas, y los agentes no lo hacen de manera fiable.

No creo que la respuesta sea reducir la velocidad. Las empresas que ganen aquí se moverán rápido. La respuesta es construir la evidencia y la supervisión que le permitan avanzar con confianza. Cuanta más autonomía recibe un agente, más evidencia se necesita para demostrar que puede asumir la responsabilidad.

Cuando un agente autónomo toma una mala decisión, ¿quién debe ser finalmente responsable: el desarrollador, la unidad de negocio que lo despliega, el proveedor del modelo o el ejecutivo que aprobó su uso?

En última instancia, la empresa que despliega el agente es la responsable del resultado. Varios actores participan en la construcción y operación del sistema, pero el cliente no tiene relación con el proveedor del modelo. El cliente sí tiene relación con la empresa cuyo nombre aparece en la interacción.

Eso no significa que la responsabilidad recaiga en una sola persona. Se extiende a lo largo de la cadena de decisiones. El desarrollador es responsable de cómo se construyó el sistema. La empresa decide qué puede hacer el agente. El proveedor es responsable de la tecnología que brinda. El liderazgo es responsable de asegurar que la compañía cuente con los controles y la supervisión necesarios para gestionar el riesgo en su totalidad.

El error consiste en pensar que, porque el modelo tomó la decisión, el modelo es el dueño de ella. No es así. Si un agente asume un compromiso con un cliente en su nombre, ese compromiso pertenece a la marca. Los clientes lo entienden instintivamente, y los reguladores también.

Los agentes de IA pueden comportarse de manera impredecible cuando se enfrentan a situaciones no previstas durante las pruebas. ¿Cómo deberían las empresas probar estos casos límite antes de que los agentes tengan acceso a clientes, sistemas financieros o datos sensibles?

Debe asumirse que el agente, eventualmente, encontrará algo para lo que no fue diseñado. La cuestión es qué ocurre cuando eso sucede.

Por lo tanto, valide más allá del camino esperado. Dé al agente solicitudes ambiguas. Proporciónele información contradictoria. Déle contexto incompleto. Colóquelo en situaciones donde la respuesta correcta sea detenerse y escalar en lugar de continuar. Añada las condiciones del mundo real, que en la voz implican acentos, ruido, conexiones deficientes y llamantes que cambian de tema a mitad de la conversación. El objetivo no es confirmar que el agente funciona, sino descubrir cómo se comporta cuando las condiciones no son limpias.

El punto más importante es que debe validarse todo el recorrido, no solo el agente de forma aislada. Normalmente, el modelo no es el problema. Cuando algo falla, mi primera pregunta es qué contexto recibió el modelo. Podría haber sido un artículo de conocimiento desactualizado, o dos sistemas con políticas contradictorias, o una transferencia que perdió lo que el cliente ya había explicado. Cada componente puede aprobar su propia prueba y, sin embargo, el recorrido del cliente puede fallar en los puntos de conexión entre ellos.

Esa capa entre los sistemas es la que hemos pasado años instrumentando, en más de 450 empresas y más de 350 millones de recorridos de clientes al año. Sea agente o no, se rompe de la misma manera. También vemos agentes construidos sobre la tecnología de más de 55 proveedores diferentes, además de todas las principales plataformas de centros de contacto, lo que nos permite confirmar que el patrón se mantiene independientemente del modelo subyacente.

Antes de que un agente tenga acceso a algo importante, la empresa debe contar con evidencia de lo que hace cuando las cosas van bien y cuando no.

¿Cómo ve la evolución de las pruebas de IA a medida que las empresas pasan de software determinista a sistemas que razonan, planifican, se comunican y actúan a través de múltiples aplicaciones?

Las pruebas deben pasar de preguntar si un sistema produjo la respuesta esperada a preguntar si logró el resultado correcto.

Ese es un cambio significativo. Un agente puede seguir varios caminos diferentes para resolver el mismo problema del cliente, y esos caminos pueden cambiar con el tiempo a medida que los modelos y el conocimiento que los sustenta evolucionan. No se puede escribir un guion para cada interacción posible. Hay que evaluar si el agente comprendió la intención, tomó decisiones acertadas a lo largo del proceso y se mantuvo dentro de los límites que se le asignaron.

Quiero ser cuidadoso con un aspecto, porque la industria está empezando a equivocarse de manera costosa. Las pruebas previas al lanzamiento son ahora más importantes, no menos. Son lo que determina si un agente está listo. El argumento de que se puede omitir y observar la producción en su lugar es, en realidad, un argumento para descubrir los problemas frente a los clientes.

Lo que cambia es que las pruebas previas al lanzamiento ya no son el final del proceso. La producción revela condiciones que un entorno controlado no puede reproducir completamente, y lo que la producción revela se convierte en una prueba que el agente debe superar antes del próximo lanzamiento. Prueba antes del lanzamiento, vigilancia en producción, y que cada una alimenta a la otra. El agente que opere en el sexto mes debería ser mediblemente mejor que el que se lanzó inicialmente.

Mirando al futuro, ¿qué distinguirá a las organizaciones que construyan con éxito fuerzas de trabajo de IA confiables de aquellas que siguen atrapadas en pequeños pilotos de IA agente?

Las organizaciones que obtienen un retorno real de los agentes son las que construyeron un modelo operativo basado en evidencia. Las que se estancan generalmente no están bloqueadas por la tecnología. Están bloqueadas porque nadie puede producir lo que el siguiente nivel de aprobación requiere. El área legal plantea una pregunta razonable, o lo hace el comité de riesgos, y no hay respuesta, por lo que el piloto sigue siendo un piloto. La tecnología puede estar lista y la organización aún no puede justificar otorgarle más autoridad.

Esa es la diferencia entre un piloto y una fuerza laboral operativa. En un piloto, siempre hay alguien observando. En un modelo operativo, cada agente tiene una tarea que puedes expresar en una oración. Su autoridad es limitada y está documentada. Su desempeño se evalúa por algo distinto al equipo que lo creó. Los fallos de producción se convierten en puertas de liberación. Más autonomía sigue a la prueba.

La segunda diferencia es la propiedad. En las empresas que escalan, el agente pertenece a la función de negocio a la que sirve, con un propietario nombrado que responde por lo que hace. Cuando sigue siendo un proyecto de IA propiedad de un equipo de IA, permanece pequeño, porque ningún líder empresarial absorberá el riesgo de algo que no controla.

Nada de esto es exótico. Es similar a cómo una empresa ya gestiona a las personas en las que confía con verdadera responsabilidad.

Un piloto puede basarse en la convicción de una organización. Escalar requiere evidencia.

Gracias por la excelente entrevista, los lectores que deseen obtener más información deberían visitar Cyara.