Jeff Champagne, Field CTO en Cribl – Serie de entrevistas

Jeff Champagne, Field CTO en Cribl, aporta una profunda experiencia en observabilidad, datos empresariales, estrategia de productos y arquitectura técnica. Antes de unirse a Cribl, se desempeñó como Director de Gestión de Productos en Databricks y pasó más de siete años en Splunk en roles de arquitectura de productos, ingeniería de sistemas globales y arquitectura de campo. Su experiencia también incluye liderazgo en arquitectura de sistemas en BNY ConvergEx, trabajo de ingeniería senior en Premier Technology Solutions y liderazgo en ingeniería temprana en Assist-2-Sell, lo que le da una perspectiva amplia sobre cómo las empresas recopilan, gestionan, analizan y actúan sobre datos operativos a gran escala.

Cribl es una empresa de telemetría empresarial que se centra en ayudar a los equipos de TI, seguridad, SRE y DevOps a recopilar, procesar, enrutar, almacenar y analizar datos de observabilidad y seguridad sin quedar atrapados en un solo proveedor. La empresa se posiciona como la “Plataforma de Inteligencia Artificial para Telemetría”, con productos como Cribl Stream para la recopilación, reducción, enriquecimiento y enrutamiento de telemetría en tiempo real; Cribl Edge para la recopilación de telemetría de puntos finales de proveedores neutrales; Cribl Search para la búsqueda de datos en su lugar; y Cribl Lake para el almacenamiento. Su misión más amplia es dar a las empresas más control, flexibilidad y eficiencia a medida que crecen los volúmenes de telemetría y se requieren operaciones impulsadas por inteligencia artificial con datos más limpios y accesibles.

Ha trabajado en Splunk, Databricks y ahora en Cribl, lo que le da una visión única sobre los datos empresariales, la observabilidad y la infraestructura a lo largo de múltiples ciclos tecnológicos. Desde esa perspectiva, ¿qué es lo que realmente diferencia el desafío de la observabilidad creado por la inteligencia artificial autónoma?

En la observabilidad de aplicaciones, siempre hemos lidiado con rutas de ejecución complejas y ramificadas, rastreando solicitudes a través de microservicios y correlacionando registros en sistemas distribuidos. En las operaciones de seguridad, hemos abordado fuentes de datos de alto volumen y dispares para detectar amenazas en sistemas que, aunque complejos, aún se comportan de manera predecible. La inteligencia artificial autónoma no reinventa ninguno de esos problemas; los hace explotar simultáneamente.

Los agentes encadenan decisiones, invocan herramientas externas y generan subagentes de manera dinámica de formas que no se predeterminan en el momento de la escritura. El gráfico de ejecución no solo es complejo, sino que puede ser enormemente diferente cada vez, y el volumen de telemetría necesario para reconstruir lo que realmente sucedió crece exponencialmente con cada salto. Recopilar toda la telemetría necesaria para hacer que los sistemas autónomos sean observables tiene que ser fácil de instrumentar y rentable de operar a gran escala. De lo contrario, las empresas harán el mismo intercambio que siempre han hecho y reducirán la visibilidad para controlar los costos — exactamente en el momento equivocado para quedarse ciegos.

¿Dónde están las brechas de visibilidad más grandes entre lo que se le pide a un agente que haga y lo que realmente sucede en los sistemas subyacentes cuando las empresas incorporan agentes autónomos en los flujos de trabajo?

Los agentes completan flujos de trabajo que parecen exitosos en la superficie mientras hacen llamadas a herramientas malas, alucinan parámetros o se desvían del objetivo original. Las consecuencias a menudo se manifiestan horas más tarde en otro sistema.

La desconexión generalmente comienza en la interpretación: una ligera ambigüedad en la instrucción original se resuelve de manera diferente dependiendo de lo que el agente recupera de la memoria, qué herramientas están disponibles en ese momento o cómo un paso anterior en la cadena dio forma a su contexto. También debes instrumentar los sistemas downstream que depende el agente, porque un agente puede hacer una llamada a la base de datos perfectamente bien formada y aún así devolver una respuesta incorrecta si la tabla subyacente nunca se actualizó porque un trabajo de ETL falló silenciosamente upstream.

El agente hizo exactamente lo que se le dijo; los datos en los que confiaba simplemente estaban desactualizados.

¿Por qué las herramientas de observabilidad tradicionales a menudo son insuficientes para monitorear sistemas de inteligencia artificial autónomos?

Primero, se construyeron alrededor de esquemas rígidos y propietarios y formas de datos predecibles. Las trazas de los agentes autónomos no se ajustan a esas expectativas — son voluminosas, muy variables en estructura e incluyen tipos de datos como texto de llamada completo, cadenas de razonamiento de modelos y cargas útiles de llamadas a herramientas que las herramientas heredadas no estaban diseñadas para ingerir sin un trabajo de transformación significativo. Estándares abiertos como las convenciones semánticas de OpenTelemetry para GenAI están surgiendo para abordar esto, pero muchas plataformas heredadas no fueron diseñadas para aprovecharlos.

Segundo, la ecuación de escala y costo se rompe rápidamente. Un solo agente que maneja cargas de trabajo de producción puede generar más telemetría en una hora que toda una pila de aplicaciones produjo en un día, y la mayoría de las plataformas tradicionales cobran por volumen ingerido y almacenado. Eso crea un intercambio imposible — o instrumentas todo y enfrentas costos desbordados, o reduces la visibilidad en los sistemas donde más la necesitas.

¿Cuándo un agente de inteligencia artificial falla, cómo pueden las organizaciones determinar si la causa raíz fue el modelo, la capa de recuperación, una dependencia de API, un problema de permisos o un problema de infraestructura downstream?

Aislar la causa raíz en una falla autónoma es un proceso de eliminación a través de capas. Solo funciona si su telemetría abarca todas ellas consistentemente. Señales de latencia y error en las trazas del modelo señalan hacia el propio modelo. Las trazas de recuperación te dicen si el contexto devuelto fue relevante o desactualizado. Las trazas de llamadas a herramientas exponen dependencias de API fallidas o errores de permisos.

Como se mencionó, también necesitas telemetría de los sistemas downstream que depende el agente, porque un agente puede hacer una llamada perfectamente bien formada y aún así producir una respuesta incorrecta si los datos en los que confiaba nunca se actualizaron. Ninguna señal de solo un tipo cuenta toda la historia, por lo que correlacionar a través de todas esas capas en un solo lugar es lo que separa a los equipos que pueden depurar fallas autónomas rápidamente de aquellos que aún están adivinando.

¿Qué tipos de datos de telemetría se vuelven más importantes cuando las empresas intentan comprender el comportamiento de los agentes a gran escala?

La base sigue siendo MELT — métricas, eventos, registros y trazas — pero el peso cambia considerablemente cuando se pasa a sistemas autónomos. Las métricas te dicen que algo está mal y los registros te dan el registro bruto de lo que sucedió, pero ninguno de los dos puede reconstruir la cadena de razonamiento que un agente siguió para llegar a una respuesta incorrecta. Eso es donde las trazas se vuelven la señal de más importancia.

En un sistema distribuido tradicional, una traza te muestra cómo se movió una solicitud a través de los servicios. En un sistema autónomo, te muestra cómo un modelo razonó a través de un problema, qué herramientas llamó, qué contexto recuperó, dónde se ramificó y qué decidió en cada paso. Sin esa traza, estás mirando una salida sin forma de explicar cómo llegaste allí.

Las otras señales de MELT no desaparecen; las métricas sobre el uso de tokens y la latencia importan para el costo y el rendimiento, y los registros de los sistemas downstream siguen siendo esenciales. Pero las trazas son lo que hacen que el comportamiento del agente sea legible a gran escala.

Muchas discusiones sobre inteligencia artificial aún se centran mucho en las alucinaciones. ¿Están las empresas subestimando los fallos operativos como las recuperaciones malas, las integraciones rotas, los picos de latencia o el contexto perdido?

La mayoría de las alucinaciones en producción no son fallos del modelo; son fallos operativos disfrazados. Una recuperación mala devuelve contexto desactualizado o incompleto, y el modelo llena el vacío con algo que suena plausible. Una integración rota significa que el agente nunca obtuvo los datos que necesitaba para razonar correctamente en primer lugar. El contexto perdido de un trabajo de ETL fallido parece una alucinación pero es realmente un problema de infraestructura.

Cuando los equipos no pueden ver la diferencia, recurren a lo que pueden controlar, que generalmente es el modelo en sí. Iteran sobre los prompts del sistema, agregan barandas y refinan los marcos de evaluación, y aunque esas técnicas tienen un valor real, están tratando un síntoma en lugar de la causa. En mi experiencia, la inversión de mayor rendimiento es casi siempre la calidad y la frescura de los datos en la capa de recuperación. Un agente bien fundamentado con datos limpios y actuales superará a uno con un diseño de prompt pesado que trabaja a partir de un contexto desactualizado o incompleto.

A medida que los agentes se vuelven más autónomos, ¿qué deben registrar, trazar o monitorear los equipos empresariales para mantener la rendición de cuentas sin abrumarse con ruido?

La base sigue siendo MELT, pero la rendición de cuentas para los sistemas autónomos requiere capas de un marco de evaluación sobre la telemetría tradicional. Métricas, eventos y registros exponen fallos de infraestructura y integraciones rotas que pueden corromper el comportamiento del agente antes de que el modelo responda; las trazas te dan la cadena de razonamiento para entender por qué llegó a una respuesta particular. Pero ninguno de los dos te dice si la respuesta fue realmente correcta, y eso es donde la evaluación LLM-as-juez llena el vacío. Las mismas capacidades de inteligencia artificial que impulsan a los agentes se pueden utilizar para evaluarlos, puntuando las salidas por precisión, fundamentación y finalización de tareas a una escala que ningún proceso de revisión humano puede igualar.

Antes de la producción, actúa como una puerta de calidad, atrapando regresiones antes de que lleguen a los usuarios. En producción, se convierte en un monitor continuo, muestreando el tráfico en vivo y señalizando respuestas que caen fuera de los umbrales aceptables. La clave para evitar el ruido es reconocer que no todos los flujos de trabajo de los agentes conllevan el mismo riesgo, lo que significa moverse hacia un gobierno de bucle humano, que la industria está empezando a llamar gobernanza de bucle humano. Defines líneas de base de comportamiento y umbrales de confianza de antemano, dejas que los agentes operen y reservas la intervención humana para las excepciones.

¿Qué papel pueden desempeñar las tuberías de telemetría para ayudar a los equipos de seguridad, SRE, datos y inteligencia artificial a trabajar desde una visión compartida del comportamiento del agente?

Los equipos de seguridad, SRE, ingenieros de datos y equipos de inteligencia artificial están mirando diferentes rebanadas del mismo problema a través de diferentes herramientas, y ninguno de ellos tiene la imagen completa por sí solo. La razón por la que las tuberías de telemetría se han vuelto una parte estándar de la arquitectura de datos empresariales moderna es que resuelven exactamente este problema: una tubería única y bien gobernada upstream de todas sus herramientas garantiza que cada equipo trabaje con los mismos datos normalizados y enriquecidos sin agentes y recolectores personalizados desplegados para cada equipo.

Esta flexibilidad importa a dos niveles. El primero es la jerarquía de datos. Una tubería de telemetría bien diseñada te permite emparejar los datos con la estrategia de almacenamiento y análisis adecuada para que no estés pagando precios de análisis de nivel de análisis para datos que solo necesitas para la retención de cumplimiento a largo plazo. El segundo es la opción mientras el paisaje de herramientas de inteligencia artificial sigue evolucionando rápidamente. Las empresas que construyen su estrategia de observabilidad alrededor del ecosistema de un solo proveedor enfrentarán proyectos de migración costosos cada vez que surja una herramienta mejor.

¿Qué errores están cometiendo las empresas cuando intentan adaptar prácticas de monitoreo existentes a las implementaciones de inteligencia artificial autónoma?

El error más común que veo es recurrir a plataformas de observabilidad premium existentes para recopilar trazas de agentes sin pensar en las implicaciones de costo primero. Las trazas de los agentes autónomos son grandes, variables y voluminosas de maneras que la telemetría de aplicaciones tradicional no lo es, y la mayoría de las plataformas premium cobran por ingesta y almacenamiento. La factura puede convertirse en un problema grave antes de que los equipos siquiera se den cuenta de lo que está sucediendo, y la respuesta típica es reducir lo que recopilan. El resultado es lo peor de ambos mundos: alto costo e visibilidad incompleta.

El segundo error es aplicar el modelo mental incorrecto a lo que el monitoreo se supone que debe responder. El monitoreo de infraestructura tradicional pregunta “¿Está el sistema arriba?” y genera alertas cuando no lo está. Esa pregunta es necesaria pero está lejos de ser suficiente para los sistemas autónomos, donde la infraestructura puede estar perfectamente saludable mientras el agente está tomando decisiones pobres, recuperando datos desactualizados o desviándose de su objetivo original. Los equipos que adaptan tableros y umbrales de alerta existentes a los flujos de trabajo de los agentes a menudo se convencen de que tienen cobertura cuando en realidad solo están vigilando la fontanería.

El tercer error es tratar la instrumentación como un después. Las empresas que pilotan agentes rápidamente y pasan a producción sin pensar en la observabilidad terminan en ciclos de remediación costosos, reconstruyendo la arquitectura de recopilación de datos después del primer fallo de producción significativo. Los equipos que escalan las implementaciones de agentes con más éxito instrumentan temprano, establecen líneas de base mientras el tráfico es bajo y el comportamiento es predecible, y construyen su marco de evaluación antes de que lo necesiten en lugar de después de que algo salga mal.

¿Mirando hacia adelante, ¿se convertirá la visibilidad de la infraestructura en un requisito previo para la adopción de inteligencia artificial empresarial de la misma manera que la observabilidad en la nube se volvió esencial para la migración a gran escala en la nube?

La paralela con la nube es extremadamente similar. Lo más importante que les digo a los clientes cuando migran la infraestructura a la nube es que no están levantando y trasladando. Están desplegando una arquitectura completamente nueva con capacidades nuevas. Todo eso necesita ser instrumentado y monitoreado de maneras que las herramientas anteriores probablemente no estaban configuradas para hacer. Las empresas que saltaron ese paso se encontraron con fallos en cascada que no podían diagnosticar, costos en espiral que no podían explicar y cortes de servicio que no podían prevenir. La observabilidad se convirtió en la base de la confianza que hizo posible la escala en la nube, y el mismo patrón se está reproduciendo ahora con la inteligencia artificial autónoma, moviéndose más rápido y con mayores apuestas.

La razón principal por la que los agentes necesitarán este tipo de supervisión de manera indefinida es que están diseñados para ser no deterministas, su comportamiento emerge en tiempo de ejecución y su capacidad efectiva crece cada vez que se conecta una nueva herramienta. La certificación estática pre-despliegue no puede cubrir un sistema cuya superficie de acción cambia con cada integración. Los agentes operarán dentro de límites de confianza definidos, y esos límites se expandirán con el tiempo a medida que maduren la infraestructura de observabilidad, la política y la evaluación. Los límites en sí nunca desaparecerán, y eso no es un estado de falla. Es así como funciona cada sistema autónomo importante en el mundo.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Cribl.