La conversación empieza siempre por el nombre de una herramienta. Alguien ha visto una demo, alguien ha leído un hilo, y la pregunta que llega a la reunión es si montamos Langfuse o pagamos una plataforma. Es la pregunta equivocada, y se nota tres semanas después: el trazado está puesto, el panel existe, y nadie sabe decir si el agente responde peor que el mes pasado.
La tesis en una frase: la observabilidad de agentes de IA no es una herramienta, son cuatro capas que se deciden por separado, y con piezas abiertas puedes cubrir las cuatro hoy. Lo que se rompe no es la herramienta —las abiertas funcionan— sino las dos cosas que nadie pone en la comparativa: la convención de datos está aún en desarrollo y su documentación se ha mudado de sitio, y «abierto» significa al menos tres licencias que no te permiten lo mismo.
Las herramientas de observabilidad de agentes de IA que puedes alojar tú: cuatro capas, no una
El error de partida es tratar esto como una compra única. «Observabilidad» se usa como si fuera un producto, y en un agente son cuatro trabajos distintos que fallan de formas distintas y que casi nunca hacen falta los cuatro el mismo día. Separarlos es lo que convierte una elección de marca en una decisión de ingeniería.
| Capa | Qué pregunta responde | Qué pasa si no la tienes |
|---|---|---|
| Trazas correladas | ¿Qué hizo el agente, en qué orden, con qué herramientas y con qué entrada en cada paso? | Depuras a ciegas: tienes el resultado final y ninguna forma de saber en qué paso se torció |
| Evaluación antes de producción | ¿Este cambio de prompt o de modelo mejora o empeora respecto a la línea base? | Cada cambio es una apuesta, y la única prueba es esperar a que se queje alguien |
| Atribución de coste | ¿Qué cuesta cada caso, cada agente y cada herramienta, no la factura agregada? | Ves el total del proveedor a fin de mes y no puedes atribuirlo ni cortarlo |
| Detección de deriva | ¿Sigue respondiendo como hace un mes, con el mismo modelo detrás? | La calidad baja despacio, la monitorización clásica lo da todo por verde y lo descubre un cliente |
Las dos primeras las cubre hoy cualquiera de las piezas abiertas serias. La tercera depende de que hayas instrumentado con la granularidad correcta desde el principio —añadirla después es reinstrumentar—. La cuarta no es una función que se activa: es una cadencia que alguien tiene que ejecutar, y es la que más se queda sin dueño. El mecanismo de por qué la deriva no produce un error sino un deslizamiento lo desarrollamos en qué pasa cuando cambia el modelo de IA por debajo de tus automatizaciones; aquí nos interesa qué capa del stack tendría que haberlo cazado.
Lo primero que se rompe no es la herramienta: es la convención
Para que las cuatro capas hablen entre sí hace falta que todas llamen igual a las mismas cosas: qué es una llamada al modelo, qué es una invocación de agente, qué es una ejecución de herramienta. Eso es una convención semántica, y es la pieza del stack que casi nadie mira antes de elegir. También es la que está menos asentada.
Dos hechos concretos, los dos verificables en la fuente primaria. El primero: las convenciones GenAI de OpenTelemetry —los atributos gen_ai.*— siguen marcadas como en desarrollo, no estables. El segundo, y el que de verdad te va a morder: esa documentación ya no vive donde la va a encontrar tu buscador. La página histórica del repositorio de convenciones semánticas ahora solo dice que el contenido se ha trasladado al repositorio de convenciones GenAI y que la antigua ya no se mantiene.
Encima de eso hay una segunda convención en circulación: OpenInference, la capa semántica que mantiene Arize y sobre la que funciona su herramienta abierta. No es un problema en sí —los exportadores traducen— pero sí es la razón por la que dos piezas «compatibles con OpenTelemetry» pueden llegar con árboles de spans que no encajan. Decide una y conviértela en la norma de casa; no dejes que la elija cada equipo que instrumenta.
«Abierto» son tres licencias distintas, y solo una te deja hacer lo que crees
Aquí es donde el stack abierto se parece más de lo que nadie admite al mismo debate que ya existe en automatización. Es exactamente la trampa que desmontamos en herramientas open source de automatización con IA: «0 € de licencia» no es «0 € de coste», y «open source» no siempre es lo que la palabra sugiere. En observabilidad de agentes pasa igual, con un matiz propio.
| Pieza | Qué dice su propia documentación | Qué significa en la práctica |
|---|---|---|
| Langfuse | Es open source y se puede autoalojar con Docker en tu infraestructura; algunas funciones de complemento requieren clave de licencia | Para operar tu propia flota te sirve el núcleo. En su lista de funciones de autoalojamiento hay tres marcadas como empresariales — creadores de organización, API de gestión de instancia y personalización de interfaz |
| Arize Phoenix | Publicado bajo Elastic License 2.0; autoalojarlo en tu infraestructura o tu cuenta de nube es gratuito y está plenamente permitido, y no hay funciones de pago | Si lo usas de puertas adentro, no tienes recortes. La ELv2 no está aprobada por la OSI y su restricción central es ofrecerlo como servicio gestionado a terceros |
| OpenTelemetry | Proyecto de la CNCF; las convenciones GenAI están en desarrollo | La cañería es la parte más sólida y la menos discutible del stack. La inestabilidad está en el vocabulario, no en el transporte |
La lectura operativa: si montas esto para tu propia operación, las tres licencias te dejan hacerlo y la conversación jurídica es corta. Si en algún momento vas a revender el panel a tus clientes como servicio —una agencia, un proveedor de servicios gestionados— la ELv2 es exactamente lo que te lo prohíbe, y conviene saberlo antes de construir el negocio encima, no después.
En qué punto el stack abierto deja de compensar (y no es un número de agentes)
La respuesta que se espera aquí es una cifra: hasta X agentes monta lo abierto, a partir de X compra. Esa cifra no existe, y quien te la dé te está vendiendo el lado que le conviene. El umbral no es de volumen: es de garantías.
Lo dice el propio fabricante en su documentación, y es la frase más honesta de toda la categoría. En la tabla de opciones de despliegue de Langfuse, el arranque por Docker Compose aparece descrito como una única máquina virtual sin alta disponibilidad, sin escalado y sin copias de seguridad, y el autoalojamiento de producción —Kubernetes, AWS, Azure, GCP— aparece con la responsabilidad asignada a una sola columna: tu infraestructura.
Ahí está el umbral real, y no tiene nada que ver con cuántos agentes tengas. El stack abierto deja de compensar el día en que el panel pasa a ser infraestructura crítica: cuando alguien de fuera nota la caída, cuando la traza es la evidencia que necesitas para responder a un cliente o a un auditor, o cuando retener seis meses de trazas se convierte en un requisito y no en una preferencia. Ese día ya no estás eligiendo una herramienta, estás decidiendo quién se levanta a arreglarla. Que es la misma pregunta —planteada para automatizaciones— de quién responde cuando se cae una automatización.
Conviene además leer con distancia las cifras de escala que publica cualquier fabricante. Langfuse afirma en su documentación procesar más de 90.000 millones de observaciones al mes y que 21 de las Fortune 50 lo usan. Son datos del fabricante sobre su propio producto, no una medición independiente ni un resultado nuestro; sirven para saber que la pieza aguanta carga, no como promesa de lo que va a aguantar en tu casa.
Cuándo NO montar el stack abierto
Cuatro situaciones en las que este proyecto es un desvío, no un avance. Las cuatro son reales y las cuatro se presentan disfrazadas de buena idea:
- Tienes un agente y no está instrumentado. No te falta una plataforma de observabilidad: te falta el trazado. Instrumenta primero con la convención fijada y decide dónde lo mandas después; el orden inverso te hace elegir herramienta con cero datos sobre lo que necesitas ver.
- Nadie va a mirar el panel. Un panel sin guardia asignada no es observabilidad, es un gasto de infraestructura con gráficas. Si no hay una persona con nombre y turno, monta primero eso.
- El problema que tienes es de calidad, no de salud. Si la queja es «responde mal», ninguna traza te lo arregla: lo que necesitas es una rúbrica y un banco de casos, que es un trabajo distinto — lo tratamos en evaluar la calidad de los agentes de IA.
- El agente escribe en un sistema de registro y todavía no tiene la matriz de accesos hecha. La observabilidad te dice qué hizo; no te evita que pueda hacerlo. Ese orden está en qué permisos dar a un agente de IA, y va antes.
Qué se mide el primer mes
El indicador de que el stack está montado de verdad no es que el panel cargue. Son cuatro preguntas que antes no podías contestar y ahora contestas en un minuto, con la traza delante:
- De los fallos del mes, cuántos los detectó una alerta y cuántos los detectó una persona de fuera. Es la única métrica que dice si el panel sirve.
- Cuánto costó el caso más caro, y por qué. Si la respuesta es «no se puede desglosar», la capa de atribución no está, aunque tengas el gráfico de tokens.
- Cuánto tardas en reconstruir qué pasó en un caso concreto de hace tres semanas. Si son horas, las trazas están pero la correlación no.
- Cuántos cambios de prompt o de modelo entraron sin pasar por la línea base. Ese número tendría que ser cero, y casi nunca lo es el primer mes.
Nótese que ninguna de las cuatro es una métrica de la herramienta. Son métricas de la operación, y es la razón por la que el stack abierto no se termina el día del despliegue: lo que se monta con Docker es la mitad barata. Cuando ese trabajo continuo no lo puede sostener el equipo, la conversación es monitorizar la IA en producción como función, no como panel.
La frase para la próxima reunión
Cuando alguien vuelva a preguntar qué herramienta de observabilidad de agentes montamos, la respuesta útil no es un nombre. Es: dime qué capa de las cuatro te falta, qué convención vas a fijar y quién se levanta cuando eso se caiga. Con esas tres respuestas la elección de herramienta se hace sola, y casi siempre es la abierta.