Sobhan Daliry, CPO & Líder de Estrategia de IA en Pipefy – Serie de Entrevistas

Sobhan Daliry, CPO & Líder de Estrategia de IA en Pipefy, es un ejecutivo experimentado en producto y tecnología que ha liderado la estrategia de IA de la empresa desde 2023, ayudando a transformar los flujos de trabajo empresariales tradicionales en procesos cada vez más inteligentes y autónomos. A lo largo de su carrera, Daliry ha combinado la estrategia de producto, la transformación organizacional y el liderazgo tecnológico en startups y empresas consolidadas. Antes de unirse a Pipefy, fundó y se desempeñó como CEO de Polen.me y pasó más de cinco años como CEO/CPO de NZN, donde dirigió la reestructuración de la compañía y su estrategia de producto. Sus cargos anteriores incluyen Director de Gestión de Producto en PSafe, Gerente de Producto en Peixe Urbano, y puestos que abarcan servicios digitales, telecomunicaciones, consultoría y desarrollo de negocios en Oi/Telemar, Claro, AIRCOM International y Planeta Tecnologia.

Pipefy es una plataforma global de gestión de procesos e IA diseñada para ayudar a las organizaciones a automatizar y orquestar flujos de trabajo empresariales. Fundada en 2015, la compañía ha evolucionado de una plataforma de automatización de procesos sin código a un entorno de orquestación centrado en IA que reúne Agentes de IA, flujos de trabajo, formularios, portales, aplicaciones, datos, analítica, mensajería e integraciones. Su plataforma permite a los equipos crear y gestionar Agentes de IA usando lenguaje natural y herramientas sin código, al tiempo que mantiene la gobernanza empresarial, la seguridad y la visibilidad. Las capacidades de IA de Pipefy incluyen agentes que pueden interpretar documentos, ejecutar tareas de flujo de trabajo, apoyar la toma de decisiones, interactuar con sistemas externos y orquestar procesos en áreas como finanzas, recursos humanos, adquisiciones, operaciones de cliente y cumplimiento.

Tu carrera te ha llevado desde la ingeniería de telecomunicaciones en empresas como Claro y Oi hasta el liderazgo de producto en Peixe Urbano y PSafe, desempeñándote como CEO/CPO en NZN, fundando Polen.me y ahora liderando la estrategia de producto e IA en Pipefy. ¿Cómo ha influido esa trayectoria en la forma en que piensas sobre la creación de productos de IA que resuelvan problemas operacionales reales en lugar de simplemente exhibir nueva tecnología?

Las telecomunicaciones me enseñaron que la infraestructura debe funcionar en todo momento, a gran escala, sin margen para “funciona en su mayoría”. Una llamada caída no es un fallo de demostración, es un cliente que se marcha. Esa mentalidad —fiabilidad sobre novedad— nunca me abandonó. En Peixe Urbano y PSafe aprendí la lección contraria: la rapidez con la que los productos de consumo viven o mueren depende de si resuelven un problema real y percibido hoy, no uno teórico. Dirigir NZN como CEO/CPO me obligó a mantener ambas verdades a la vez —no puedes superar en ejecución una tesis deficiente, y no puedes superar en tesis una ejecución deficiente. Fundar Polen.me me enseñó la lección más costosa de todas: el capital y el tiempo son finitos, por lo que cada característica que construyes es una característica que no construiste, y el costo de perseguir una demo impresionante en lugar de un flujo de trabajo real se manifiesta meses después, no en el escenario. Cuando llegué a Pipefy, la pregunta que hago sobre cada característica de IA es la misma que haría sobre una torre de telefonía: ¿resiste esto en producción, bajo carga real, cuando nadie está observando? Si un agente de IA solo funciona en un entorno de demo curado, no es un producto — es un tráiler de uno.

Has liderado la formulación e implementación de la estrategia de IA de Pipefy desde 2023. ¿Qué suposiciones sobre la IA empresarial tenías al principio que han cambiado más a medida que la IA generativa y los agentes de IA han madurado?

La mayor suposición que tuve que eliminar fue que el modelo sería el cuello de botella. En 2023, todos —incluyéndome a mí— estaban optimizando para “qué LLM es el más inteligente”. Lo que realmente resultó ser el cuello de botella fue el contexto: ¿sabe el agente cuál es el proceso, cuáles son las limitaciones, cómo se ve “finalizado” para la versión específica del cliente de cuentas por pagar? La calidad del modelo siguió mejorando en una curva que todos podían prever; el contexto del proceso no mejoró por sí solo, porque nadie lo había estructurado. La segunda suposición que cambió fue la relacionada con la autonomía. Asumí que el mercado quería agentes que actuaran completamente de forma independiente lo más rápido posible. Lo que las empresas realmente querían —y aún quieren— es autonomía limitada: agentes que tomen decisiones reales dentro de reglas que no pueden romper, con un rastro que lo demuestre después. La autonomía total sin gobernanza no es ambición, es simplemente riesgo con una mejor interfaz. El mercado maduró más rápido en requisitos de confianza que en requisitos de capacidad bruta, y esa reordenación es lo que más me equivoqué al principio.

Pipefy diferencia entre la automatización de IA relativamente simple y los agentes de IA que pueden razonar en situaciones ambiguas, planificar múltiples pasos y ejecutar acciones a lo largo de un flujo de trabajo. ¿Cómo deben las empresas determinar cuándo una tarea realmente requiere un agente de IA versus cuándo la automatización determinista sigue siendo la mejor solución?

La prueba que utilizo es simple: si puedes escribir la regla, escribe la regla. La automatización determinista sigue siendo la respuesta correcta para cualquier cosa donde el árbol de decisiones se conozca de antemano y no cambie — dirige esta factura a este aprobador si está por debajo de esta cantidad. Eso no es una tarea para un agente, y pretender lo contrario solo añade latencia e imprevisibilidad a algo que ya estaba resuelto. Un agente gana su lugar en el momento en que la situación tiene ambigüedad que una regla fija no puede resolver — la factura no coincide exactamente con la orden de compra, falta un campo, la solicitud del cliente no encaja en ninguna de tus categorías existentes. Ahí es donde el razonamiento tiene valor real: decidir qué hacer a continuación cuando “lo siguiente” no está ya escrito. El error que veo que las empresas cometen constantemente es construir un agente para el 80 % de los casos que ya eran deterministas, porque es más llamativo, y dejar el 20 % ambiguo — la parte realmente difícil — para que un humano lo desentrañe manualmente. Invierte esa proporción y habrás creado algo real.

Hay un cambio creciente de copilotos independientes hacia la “orquestación agente”, donde la IA puede coordinar procesos que abarcan múltiples sistemas. ¿Qué separa la verdadera orquestación agente de simplemente añadir un modelo de lenguaje grande a una plataforma de automatización existente?

Insertar un nodo LLM en un flujo de automatización existente te brinda un paso único más inteligente. La orquestación genuina significa que la IA tiene una visión persistente y estructurada de todo el proceso — no solo de esta tarea, sino de dónde se sitúa dentro de la secuencia, qué ha ocurrido previamente, qué debe ser verdadero downstream para que se considere completado. La diferencia está en si la inteligencia tiene memoria del proceso o solo memoria del prompt. Un copiloto responde a la pregunta que le haces. La orquestación coordina acciones entre sistemas que no se comunican de forma nativa — tu ERP, tu CRM, la API de un socio — mientras hereda las mismas reglas, permisos y rastro de auditoría con los que ya opera el resto del proceso. Si tienes que construir una capa de gobernanza separada alrededor de tu función de IA porque la plataforma de automatización subyacente no la tiene, no tienes orquestación agente — tienes un chatbot con acceso a API, y esos no comparten el mismo perfil de riesgo.

Los agentes de IA sin código pueden permitir que los equipos de negocio automaticen procesos cada vez más complejos sin esperar recursos de ingeniería. ¿Cómo democratizar esa capacidad sin crear una nueva generación de IA sombra, agentes mal diseñados o riesgos de seguridad?

No obtienes una democratización segura pidiendo a los usuarios de negocio que sean más cuidadosos — la obtienes

haciendo que las barreras de seguridad formen parte del pavimento, no una vía separada que la gente tenga que elegir para conducir. Cada agente que construye un usuario de negocio hereda el mismo acceso basado en roles, el mismo rastro de auditoría y las mismas reglas de negocio que ya gobiernan el proceso dentro del cual se crea — no son configuraciones opcionales, son estructurales. Esa es la respuesta real a la IA sombra: no es un problema de política, es un problema de arquitectura. La IA sombra ocurre cuando la herramienta autorizada es más difícil de usar que la no autorizada, de modo que la gente crea su agente en una cuenta personal de ChatGPT o en una herramienta de automatización aleatoria sin visibilidad para TI. Si la experiencia sin código es realmente rápida y la gobernanza es invisible porque es automática, no hay razón para que un equipo de negocio la evite. En el momento en que conviertes la gobernanza en un paso manual que alguien debe recordar, ya la has perdido.

A medida que los agentes de IA adquieren la capacidad de tomar decisiones y ejecutar acciones en lugar de solo recomendarlas, ¿cómo deben las organizaciones decidir dónde es apropiada la autonomía total y dónde los humanos deben permanecer en el bucle?

El eje que utilizo no es “qué tan inteligente es el agente”, sino la reversibilidad y el radio de explosión. Si una decisión errónea es barata de detectar y barata de deshacer — enrutamiento, categorización, redacción — permite que el agente actúe y revisa en conjunto. Si una decisión errónea es costosa, difícil de revertir o afecta directamente dinero, cumplimiento o una relación con el cliente, mantén a un humano en el bucle para ese paso específico, incluso si el agente ha acertado los últimos mil decisiones. El error está en tratar la autonomía como un único dial que se sube para todo el flujo de trabajo. Los procesos reales son una secuencia de pasos con perfiles de riesgo muy diferentes, y el diseño correcto coloca al humano exactamente en el paso donde un error es costoso — no en todas partes y no en ninguna. Eso también explica por qué el humano en el bucle, bien implementado, no es un impuesto a la velocidad — es la forma de construir la confianza para eventualmente eliminarlo de los pasos de bajo riesgo, porque tienes la evidencia que demuestra qué decisiones el agente acierta consistentemente.

Pipefy enfatiza la gobernanza mediante mecanismos como rastros de auditoría, controles de acceso basados en roles, reglas de negocio y trazabilidad dentro del propio flujo de trabajo. ¿Se está volviendo esencial incrustar la gobernanza directamente en la capa de orquestación a medida que las empresas trasladan los agentes de IA de experimentos a producción?

No se está volviendo esencial — ya lo es, y las empresas que lo descubren de la manera difícil son las que enviaron agentes a producción primero y ahora están construyendo el registro de auditoría después del hecho. Eso es al revés, y es costoso de corregir retroactivamente. Si los registros de auditoría, el control de acceso basado en roles y la trazabilidad no son nativos de la capa de orquestación, cada nuevo agente que despliegas es un nuevo punto donde la gobernanza puede fallar silenciosamente — y no lo sabrás hasta que un auditor, un regulador o un incidente plantee la cuestión. Incorporar la gobernanza en la capa de orquestación significa que cada acción que realiza un agente hereda automáticamente las mismas reglas y deja la misma evidencia que una acción humana, sin que nadie tenga que recordar configurarla por separado. Las empresas que pasan de experimentos de IA a IA en producción están descubriendo que los criterios de éxito del piloto y los criterios de éxito de la producción son diferentes: un piloto tiene que funcionar, la producción tiene que ser defendible. La gobernanza es la diferencia entre esas dos barreras.

Muchas empresas pueden demostrar un piloto de IA impresionante, pero les cuesta traducirlo en valor comercial medible. ¿En qué métricas deben centrarse los líderes al determinar si una iniciativa de automatización de IA está realmente generando ROI, y cuáles son las razones más comunes por las que los pilotos prometedores no escalan?

Desconfío de cualquier conversación sobre ROI de IA que empiece con “horas ahorradas”, porque ¿horas ahorradas por quién, verificadas cómo? Las métricas que realmente resisten el escrutinio del CFO son aquellas que los auditores pueden confirmar de forma independiente: tiempo de ciclo en un proceso específico, antes y después; tasa de error o retrabajo; el porcentaje de un flujo de trabajo que ahora se completa sin intervención humana; y la cobertura de la línea de auditoría — ¿puedes mostrar, para cada decisión agente, por qué se tomó? Si no puedes producir ese rastro, no tienes un número de ROI, tienes una anécdota. Los pilotos casi siempre fallan al escalar por la misma razón: fueron construidos para demostrar que el modelo funciona, no para demostrar que el proceso funciona de extremo a extremo, en producción, integrado con los sistemas de los que el resto de la empresa ya depende. Un piloto que vive en un sandbox, desconectado del sistema real de registro, siempre parecerá mejor de lo que rinde una vez que se conecta a todo lo demás que ya está en funcionamiento. Escalar es un problema de integración de sistemas disfrazado de IA.

También has liderado iniciativas de cambio organizacional en Pipefy mientras introducías nuevas capacidades de IA. Desde tu experiencia, ¿cuánto de la adopción exitosa de IA empresarial es realmente un desafío tecnológico frente a un desafío de procesos, cultura y gestión del cambio?

Si soy honesto, la adopción exitosa de IA empresarial es 20 % tecnología y 80 % todo lo demás. La tecnología funciona mayormente ahora — eso no es lo que me quita el sueño. Lo que realmente determina si una iniciativa de IA se mantiene es si las personas cuyo trabajo cambia confían lo suficiente en el sistema como para abandonar la verificación manual que han estado haciendo durante diez años, y si el liderazgo está dispuesto a rediseñar el proceso en lugar de simplemente pegar IA encima del antiguo. Pasamos por esto internamente construyendo nuestras propias herramientas de ingeniería — la tecnología para automatizar partes de cómo construimos software existía mucho antes de que el equipo realmente confiara lo suficiente como para dejar de revisar todo manualmente. El desbloqueo no fue un modelo mejor, fue una prueba visible, repetida suficientes veces, de que el juicio del sistema coincidía con el de ellos. La gestión del cambio para IA no es un ejercicio de comunicación, es un ejercicio de acumulación de evidencia — ganas confianza en pequeños lotes verificables, no lo declaras en una asamblea general.

Mirando al futuro, ¿esperas que el software tradicional de flujos de trabajo y procesos de negocio evolucione hacia capas de orquestación donde humanos, agentes de IA y sistemas empresariales colaboren continuamente? De ser así, ¿qué cambiará fundamentalmente en la forma en que las empresas diseñan y gestionan sus operaciones?

Sí, y creo que el cambio es más grande de lo que la mayoría de la gente está valorando. El software de flujos de trabajo solía ser donde documentabas cómo debería ocurrir el trabajo. Ahora se está convirtiendo en donde el trabajo ocurre realmente — un tiempo de ejecución en vivo donde humanos, agentes y sistemas empresariales actúan dentro del mismo proceso gobernado al mismo tiempo, en lugar de un humano usando el software como un registro pasivo después del hecho. Lo que cambia fundamentalmente es dónde vive el “sistema de registro”. Antes, el registro era una base de datos que se actualizaba una vez que algo ya había sucedido fuera de ella. En una capa de orquestación, el registro y la ejecución son lo mismo — el proceso mismo se vuelve la interfaz, accesible no solo a través de una pantalla sino mediante una API, un servidor MCP, una CLI, de modo que cualquier agente, interno o de un socio, pueda actuar dentro de él bajo las mismas reglas que un humano. Las empresas que traten este cambio como “añadir IA a mis herramientas existentes” seguirán topándose con el techo que describí antes. Las que consideren su capa de proceso como el producto real — lo que vale la pena invertir en estructurar adecuadamente — serán las que acumulen una ventaja que nadie podrá copiar simplemente comprando el mismo modelo de IA.

Gracias por la gran entrevista, los lectores que deseen saber más deberían visitar Pipefy.