#Prólogo
El Model Context Protocol les dio tools a los agents. El agent payment stack — AP2, ACP, x402, MPP — les dio dinero. Ninguno respondió la pregunta que determina si algo de esto sobrevive a los primeros mil turnos de producción: ¿cómo sabes que tus agents siguen siendo confiables después de los primeros mil turnos de producción?
Este documento es la respuesta del canon perea a esa pregunta. La arquitectura canónica de 2026 es un pipeline de seis etapas — instrument → trace → dataset → evaluator → score → CI gate — y los equipos de ingeniería que ya lo han implementado reportan mejoras en la economía unitaria que hacen viable el resto del agent stack. Los equipos que aún no lo han implementado reportan lo contrario: demos en etapa piloto que se lanzan, regresan silenciosamente y consumen presupuesto durante dos trimestres antes de que alguien pregunte por qué la factura de LLM sigue duplicándose mientras el puntaje de satisfacción del usuario sigue bajando. El 2025 State of AI in Business de MIT NANDA es directo con la estadística poblacional: el 95 % de las iniciativas empresariales de GenAI no generaron ningún retorno comercial, y la causa más citada fue la ausencia de bucles de integración y aprendizaje, que es precisamente la función que realiza el stack de observabilidad + evaluación.
El documento sintetiza 97 fuentes primarias de las plataformas (Langfuse, LangSmith, Phoenix, Braintrust, Helicone, AgentOps, Latitude, Curate-Me), los estándares (OpenTelemetry GenAI Semantic Conventions que se estabilizan en 2026), los modos de falla (sesgo del judge, explosión de cardinalidad de traces, drift silencioso), los patrones de despliegue (canary, shadow mode, SLO rollback) y la evidencia de ROI empresarial (Slack con ahorros superiores a $20 M, Marsh McLennan con aproximadamente 1 M de horas ahorradas). Cierra el hilo operativo que abrieron los documentos MCP Server Playbook y Agent Payment Stack 2026. Está pensado para que cada líder de ingeniería lo lea una vez, completo, antes de aprobar la inversión del próximo trimestre en la plataforma de agents.
#Resumen ejecutivo
El hallazgo principal es estructural. El stack de observabilidad de agents en producción de 2026 converge en un pipeline de seis etapas que valida cada cambio. Agent Evaluation Stack in 2026 de CallSphere (6 de mayo de 2026) lo enmarca como instrument → trace → dataset → evaluator → score → CI gate. El orden de construcción recomendado es el mismo en todos los equipos que lo han lanzado: primero tracing, luego un dataset de 200 ejemplos curado a partir de traces reales de producción, luego un heurístico más un LLM judge, luego la vista de experiment-diff, luego el CI gate y finalmente las evaluaciones en línea. Saltarse una etapa implica lanzar regresiones; reordenarlas significa optimizar la señal equivocada.
La consolidación de plataformas ya ocurrió. ClickHouse adquirió Langfuse el 16 de enero de 2026, junto con una Serie D de $400 M a una valoración de $15 000 M. Las raíces de código abierto de Langfuse permanecen — licencia MIT, self-host de primera clase —, pero la capa de datos es ahora una plataforma de analítica de nivel uno, y el modelado de tablas anchas de Langfuse v3 reduce la memoria en 3× y acelera las consultas analíticas en 20×. La adquisición llegó con métricas de volumen reveladoras: más de 26 M de instalaciones de SDK por mes, más de 6 M de pulls de Docker, 19 de las Fortune 50 y 63 de las Fortune 500. Helicone fue adquirida por Mintlify en marzo de 2026 e ingresó en modo de mantenimiento, dejando a 16 000 organizaciones planeando migraciones. LiteLLM sufrió un ataque a la cadena de suministro que afectó las versiones 1.82.7-1.82.8 (malware robador de credenciales), lo que cambió permanentemente el cálculo de confianza para la adopción de gateways self-hosted. LangSmith lanzó más de 30 plantillas reutilizables de evaluadores el 16 de abril de 2026. arize-phoenix-otel 0.15.0 de Arize llegó a PyPI el 2 de marzo de 2026. El nivel gratuito de Braintrust — 1 M de spans/mes, usuarios ilimitados, 10 K evals — sigue siendo el más generoso de la comparación.
Las OpenTelemetry GenAI Semantic Conventions se estabilizan en 2026 (Issue #3330 en el repositorio semantic-conventions, 25 de enero de 2026). Datadog, New Relic, Honeycomb y Dynatrace admiten v1.37+ de forma nativa, lo que significa que el código de agents instrumentado con OpenTelemetry ahora envía a esos backends sin ningún cambio en el SDK. El registro de instrumentación OpenInference — Python, JavaScript, TypeScript, Java — cubre OpenAI, LangChain, LlamaIndex, Anthropic, AWS Bedrock, DSPy, el Claude Agent SDK, Agno y una docena más de frameworks. Los frameworks nativos que emiten spans OTel por sí mismos incluyen LangChain, CrewAI, AutoGen y AG2.
El sesgo del LLM-as-judge es el modo de falla silencioso de 2026. El sesgo de posición por sí solo hace que el 20-40 % de los veredictos pairwise se inviertan cuando se intercambian las posiciones de las opciones (Tianpan, 27 de abril de 2026). La mitigación es innegociable: ejecutar A-luego-B + B-luego-A, contar solo los veredictos donde ambas ordenaciones coinciden y tratar la tasa de desacuerdo como el piso. El drift lo agrava — gpt-4o-2024-08-06 y gpt-4o-2024-11-20 producen puntuaciones diferentes en el mismo conjunto de evaluación con el mismo prompt. El patrón consolidado es un panel congelado de 200-500 ejemplos calificados manualmente más una línea de tendencia de tasa de acuerdo como métrica de salud del judge, más un muestreo del 5-10 % de producción para recalificación humana. Para las evaluaciones de gate de lanzamiento, los ensembles de múltiples judges de distintas familias de modelos (Claude + GPT-4 + Gemini con voto mayoritario) neutralizan el sesgo estilístico de una sola familia con un costo de judge aproximadamente 3× mayor.
La economía de calibración ya se comprende bien. arXiv 2604.13717 demuestra que el ensemble scoring + la inyección de criterios específicos de la tarea (esta última casi gratuita) alcanza un 85,8 % de precisión en RewardBench 2 — una mejora de +13,5 puntos respecto al baseline—, y los modelos pequeños se benefician de forma desproporcionada. Apilar calibración sobre el ensembling no aporta — un ensemble con k=8 ya absorbe el ruido. Causal Judge Evaluation (CJE, arXiv 2512.11150) calibra puntuaciones baratas de LLM-judge contra un 5 % de etiquetas oracle y logra un 99 % de precisión en el ranking con un costo 14× menor en 4961 prompts de Arena; los intervalos de confianza ingenuos sobre puntuaciones sin calibrar tienen un 0 % de cobertura, mientras que los de CJE están en torno al 95 %. CalibraEval (ACL 2025) proporciona un algoritmo no paramétrico sin etiquetas para mitigar el sesgo de selección.
El tail sampling es el único muestreo que funciona para agents. Los traces de agents tienen un volumen de spans 10-50× mayor y un tamaño de span 10-50× mayor que los endpoints REST tradicionales (Tianpan, 16 de abril de 2026). La política madura de tail sampling es 100 % de errores + 100 % de anomalías de costo + 100 % de outliers de latencia + slice estratificado + 1-5 % probabilístico de healthy con rate limit, con decision_wait configurado en 2-3× la latencia p99 del trace (30-90 segundos para cargas de trabajo de agents). OpenObserve reporta una reducción de costos del 60-95 % sin perder visibilidad cuando la política se implementa correctamente en el tier del gateway. Tres palancas adicionales — un límite de 2 KB en los atributos del span, payloads movidos a logs/events, payloads movidos a S3/R2 con URLs de objetos — suelen eliminar otro 60-80 % del gasto de almacenamiento de spans.
La evidencia de ROI empresarial es ahora sustancial. La charla de Slack en AWS re:Invent 2025 (Jean Ting, Austin Bell, Sharya Kath Reddy) reporta una reducción de más del 90 % en costos de infraestructura (ahorros superiores a $20 M), una reducción del 90 % en el cost-to-serve por usuario activo mensual, un aumento de escala de 5× y mejoras del 15-30 % en satisfacción del usuario en las principales funcionalidades tras migrar de SageMaker a Bedrock y pasar de un LLM en producción a más de quince. Marsh McLennan reporta que el 87 % de sus 90 000 empleados utiliza su asistente LLM, con 25 M de solicitudes al año y un ahorro conservador de aproximadamente 1 M de horas anuales, con fine-tunes LoRA de Predibase que enrutan aproximadamente 500 K solicitudes por semana a ciclos de entrenamiento de alrededor de $20 cada uno. OptyxStack documenta el playbook de rescate “apágalo → ROI positivo” a través de la economía unitaria: costo por outcome exitoso / adopción / tasa de deflection / narrativa de payback.
La disciplina de despliegue converge en un único patrón. Progresión canary de 1 % → 5 % → 25 % → 50 % → 100 % con gates de significancia estadística (TuringPulse, prueba z de dos proporciones sobre la tasa de éxito, Mann-Whitney U sobre calidad continua), shadow mode para cambios de alto riesgo con un umbral de promoción meanCosine ≥ 0,85 y una banda de histéresis de rollback < 0,80 (Antigravity, 30 de abril de 2026), ventanas Fast SLO de 60 s + Slow SLO de 15 m con rollback idempotente (Claude Lab, 22 de abril de 2026), rollback atómico por lotes para cambios de infraestructura sugeridos por IA (postmortem de Amazon). El monitor interno de agents de codificación de Anthropic (GPT-5.4 Thinking con esfuerzo máximo de razonamiento) revisa las interacciones en un plazo de 30 minutos tras su finalización y avanza hacia el bloqueo síncrono previo a la ejecución. El Operator Card de OpenAI reporta un monitor de prompt injection con un 99 % de recall y un 90 % de precisión en un conjunto de evaluación de 77 intentos, con el recall mejorado del 79 % al 99 % en un solo día después del red-team.
El avance en la economía de costos se esconde a plena vista. El benchmark de Distil Labs del 6 de marzo de 2026 en 8 datasets y 10 LLMs frontier: los modelos pequeños fine-tuned de 0,6 B-8 B ocupan en promedio el puesto 3,2 frente a Claude Opus en el 4,6, a $3 por 1 M de solicitudes frente a $6241 — aproximadamente 2080× más barato. El competidor de ranking más cercano (Gemini 2.5 Flash, puesto 3,5) cuesta $313 por 1 M de solicitudes, lo que sigue siendo aproximadamente 100× más caro que la alternativa fine-tuned para una calidad esencialmente equivalente. LoRA Land mostró 25 variantes LoRA sirviendo simultáneamente en una sola A100 de 80 GB. El cálculo de punto de equilibrio de Akshay Ghalme (27 de abril de 2026) sitúa el self-hosting en números positivos en aproximadamente 50-100 M de tokens/día con una utilización de GPU del 50 % o superior, con un aumento del 30-50 % en TCO sobre los costos de GPU declarados.
Los ocho hallazgos que siguen son: (I) el pipeline de seis etapas; (II) el panorama de plataformas post-consolidación; (III) la estandarización OpenTelemetry GenAI; (IV) el sesgo y la calibración del judge; (V) la disciplina de despliegue; (VI) el tail sampling y los tiers de almacenamiento; (VII) el avance en la economía de los modelos pequeños; (VIII) la evidencia de ROI empresarial. El playbook de 90 días (Parte IX) y el pronóstico 2027-2028 (Parte X) cierran el documento.
#Parte I — El pipeline de seis etapas
El pipeline es ingeniería mecánica, no metodología de investigación. El marco de CallSphere ha sido adoptado suficientes veces en producción como para que el orden sea ahora estructural: cada etapa produce un artefacto que consume la siguiente, y saltarse cualquier etapa obliga a un backfill posterior a un múltiplo del costo original.
#Etapa 1 — Instrument
Cada agent emite spans compatibles con OpenTelemetry. El mínimo indispensable es OpenInference (pip install openinference-instrumentation-openai más el paquete específico del framework), con un SDK de OTel registrado contra cualquier backend compatible con OTel. El registro OpenInference cubre el Python SDK y el Agents SDK de OpenAI, el Claude Agent SDK, LangChain (Python y JS), LlamaIndex, DSPy, Anthropic, AWS Bedrock, MistralAI, VertexAI, Groq, Agno, BeeAI, LiteLLM (y LiteLLM Proxy para tráfico enrutado) y una docena más. La auto-instrumentación lee los paquetes instalados en tiempo de importación y los instrumenta sin cambios de código; register(auto_instrument=True) es una línea. Para los frameworks que emiten OTel directamente (LangChain, CrewAI, AutoGen, AG2), no se requiere una biblioteca de instrumentación separada: los spans fluyen al collector sin cambios. Los usuarios de Java obtienen tracing manual basado en anotaciones a través de los decoradores @LLM, @LLMSpan y @AgentSpan (respaldados por ByteBuddy).
La disciplina en esta etapa es la propagación. El contexto de trace debe propagarse a través de límites de proceso (headers W3C Trace Context), límites de colas (reemitir contexto al desencolar) y handoffs en sistemas multi-agent. El patrón de tracing consciente de agents que converge en producción es un árbol jerárquico de spans que refleja el flujo de control real del agent, no una lista plana de spans — agent → LLM → tool, con INTERNAL para spans en proceso e CLIENT para servicios remotos.
#Etapa 2 — Trace
Un trace es más que un log. Es un objeto estructurado que las etapas posteriores reproducirán, puntuarán, editarán y clonarán. El patrón que funciona consiste en capturar cinco campos en cada parent run: la entrada orientada al usuario, la salida final, el historial completo de mensajes (cada llamada intermedia a LLM), todas las E/S de tools y metadatos (user_id, session_id, model_version, feature flags). Los metadatos son los que permiten a la etapa de dataset segmentar el corpus posteriormente — muéstrame todos los traces de usuarios con el nuevo prompt donde tool_calls > 3 y la latencia final > 4 segundos.
Las convenciones semánticas de OpenTelemetry GenAI codifican los nombres de campos y las estructuras de spans para que los traces sigan siendo portátiles entre proveedores. El atributo requerido es gen_ai.operation.name (uno de: chat, text_completion, generate_content, embeddings, execute_tool, invoke_agent, create_agent, invoke_workflow, rerank); los atributos condicionalmente requeridos son gen_ai.request.model y error.type; el conjunto recomendado incluye server.address, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens y atributos específicos del proveedor (anthropic.*, aws.bedrock.*, openai.*).
#Etapa 3 — Dataset
El tráfico de producción es una manguera de incendios. Un dataset es un subconjunto curado que representa la distribución que vale la pena medir. El error más frecuente en equipos en etapa temprana es volcar 50 000 traces aleatorios en un “dataset”: eso es un backup, no un dataset. Un dataset de evaluación real está equilibrado, etiquetado y es lo suficientemente pequeño como para volver a ejecutarse en menos de diez minutos. El objetivo de lanzamiento es 200-800 ejemplos, que crecen hasta 2-5 K en sistemas maduros.
El dataset es también un artefacto vivo, no una pieza estática. El patrón que funciona en todos los equipos que han lanzado es un cron diario que extrae los traces de las últimas 24 horas, muestrea por slice estratificado (tipo de intención, tier de usuario, bucket de latencia), envía la muestra a una cola de anotación para etiquetado humano y fusiona los ejemplos aprobados en el dataset. Confident AI, Datadog Annotation Queues, Arize AX Labeling Queues y Langfuse Annotation Queues admiten este bucle. Las Automation Rules de Datadog eliminan la selección manual de traces: enruta traces por filtro + tasa de muestreo (por ejemplo, el 10 % de los fallos de evaluación se encolan automáticamente) para que la cola se alimente continuamente sin curación humana.
#Etapa 4 — Evaluator
El evaluador de trabajo es el LLM-as-judge. La biblioteca de más de 30 plantillas de LangSmith (16 de abril de 2026) cubre las categorías que importan: seguridad (prompt injection, PII, sesgo, toxicidad), safety (moderación de contenido), calidad (corrección, utilidad, tono), conversación, trayectoria (¿el agent tomó los pasos correctos?) e imagen y voz multimodal. Cada plantilla incluye un prompt ajustado y evaluadores de código basados en reglas cuando corresponde, y todas se ejecutan tanto en modo online (producción) como offline (experimento). La pestaña Evaluators es a nivel de workspace, no de proyecto: se construye un evaluator una vez, se adjunta a todos los proyectos de tracing de producción desde un solo lugar y las actualizaciones se propagan.
Los heurísticos baratos complementan al judge. Afirmaciones simples y regex se ejecutan en cada solicitud en CI/CD sin dudarlo: ¿la respuesta contiene un número de teléfono cuando no debería, comienza con el saludo esperado, es parseable como JSON? Estos son determinísticos, rápidos, nunca producen falsos positivos por sensibilidad al prompt y detectan una fracción significativa de regresiones de forma gratuita. Los clasificadores fine-tuned de 7 B llenan el intermedio: se entrenan con ejemplos etiquetados, logran gran parte del valor del judge y se ejecutan en cada commit a una fracción del costo.
#Etapa 5 — Score
El scoring es donde el sesgo deja de ser teórico. La comparación pairwise es más estable que la calificación pointwise por la misma razón por la que los humanos son mejores en juicios relativos que absolutos: las puntuaciones pointwise varían entre ejecuciones y son sensibles al anclaje del texto. El patrón consolidado es ejecutar pairwise contra un baseline fuerte y reportar una tasa de victorias, no una escala Likert. Los controles de sesgo son obligatorios: ejecutar cada prompt dos veces (A-luego-B, B-luego-A), contar solo los veredictos donde ambas ordenaciones coinciden y tratar la tasa de desacuerdo como el piso del sesgo de posición. En pares de candidatos muy cercanos, la fracción descartada suele alcanzar el 20-40 %.
#Etapa 6 — CI Gate
El gate es lo que convierte la observabilidad en disciplina de ingeniería. El patrón: cada PR que toque prompts, tools, elecciones de modelo o orquestación de agents ejecuta automáticamente el conjunto de evaluación; el experimento se publica como comentario en el PR con deltas; la fusión se bloquea si alguna métrica de bloqueo de regresión cae por debajo del baseline previo. El LLM-as-Judge Production Eval Pipeline de Chanl (2 de abril de 2026) envía umbrales concretos: accuracy ≥ 3,8/5, taskCompletion ≥ 4,0/5, safety ≥ 4,8/5, ninguna dimensión baja más de 0,2 puntos respecto al baseline, con fallo duro si cualquier puntuación de safety está por debajo de 3. La variante de AI Workflow Lab añade --ignore-errors de DeepEval para evitar que fallos transitorios de la API aborten el conjunto, y triggers selectivos para que el pipeline solo se ejecute en cambios a prompts, código fuente de LLM, tests de evaluación o datasets golden.
La transición entre offline (CI) y online (producción) es la disciplina que cierra el bucle. Las evaluaciones offline son rápidas, deterministas y a pequeña escala. Las evaluaciones online se ejecutan en el 5-10 % del tráfico de producción — heurísticos más ligeros, judges LLM muestreados — y detectan el distribution shift que el dataset offline no puede capturar. La arquitectura de evaluación de dos niveles de Tianpan es la articulación más limpia: aserciones y judges fine-tuned más pequeños en CI; LLM-as-judge con modelos frontier reservados para barridos nocturnos y candidatos de lanzamiento.
#Parte II — El panorama de plataformas (post-consolidación)
El mercado de plataformas se consolidó más rápido a principios de 2026 que el resto del agent stack, y la consolidación fue desigual. Tres eventos de remodelación definen el panorama actual: ClickHouse + Langfuse, Helicone + Mintlify y el incidente de cadena de suministro de LiteLLM.
#Langfuse + ClickHouse — 16 de enero de 2026
ClickHouse cerró una Serie D de $400 M a una valoración de $15 000 M y adquirió Langfuse el mismo día. El acuerdo se cerró con la lógica estratégica de que Langfuse ya había migrado su capa de datos principal a ClickHouse en v3, por lo que la integración técnica era un hecho consumado; lo que cambió fue el compromiso institucional. Métricas de Langfuse en el momento de la adquisición: 20 470 estrellas en GitHub a finales de 2025, más de 26 M de instalaciones de SDK por mes, más de 6 M de pulls de Docker, 19 de las Fortune 50 y 63 de las Fortune 500 clientes. La adquisición preserva la licencia MIT de Langfuse para las funciones principales, mantiene Langfuse Cloud como servicio independiente y retiene explícitamente el self-hosting como ruta de despliegue de primera clase.
El impacto técnico llega en el modelado de tablas anchas de v3, que el equipo integrado está implementando: una reducción del 3× en el uso de memoria y una aceleración de 20× en las consultas analíticas. La arquitectura es el SDK + un endpoint OpenTelemetry que alimenta eventos a colas de Redis y S3, con workers asíncronos que procesan eventos hacia ClickHouse como núcleo analítico. Marc Klingen (CEO de Langfuse) enmarcó el acuerdo con precisión: “La observabilidad y evaluación de LLM es fundamentalmente un problema de datos”. La adquisición significa un producto más integrado de extremo a extremo, ingesta más rápida, evaluación más profunda y un camino más corto desde un problema de producción hasta una mejora medible.
#LangSmith — 16 de abril de 2026
El lanzamiento de evaluadores reutilizables de LangSmith lo convirtió en el integrador más profundo con los stacks de LangChain y LangGraph. Las más de 30 plantillas de evaluadores se distribuyen en seis categorías (seguridad, safety, calidad, conversación, trayectoria, imagen y voz multimodal), con una pestaña Evaluators a nivel de workspace para que un único evaluator se adjunte a múltiples proyectos de tracing y datasets. openevals v0.2.0 se lanzó el mismo día con soporte multimodal para evaluar salidas de voz e imagen. El trade-off es el lock-in de plataforma: LangSmith es solo en la nube, sin despliegue self-hosted. Para stacks con mucho LangChain, la integración nativa es inigualable. Para todos los demás, el lock-in es el costo.
#Arize Phoenix — 2 de marzo de 2026
arize-phoenix-otel 0.15.0 (Apache-2.0) es la opción de código abierto más limpia y nativa de OpenTelemetry. El paquete es un wrapper ligero alrededor de primitivas de OpenTelemetry con valores predeterminados orientados a Phoenix: un register(auto_instrument=True, batch=True, project_name="my-app") de una sola línea activa la auto-instrumentación en LlamaIndex, LangChain, DSPy, Mastra y el Vercel AI SDK; la auto-instrumentación de proveedores cubre OpenAI, AWS Bedrock y Anthropic; los lenguajes soportados son Python, TypeScript y Java. Phoenix y Arize AX son productos deliberadamente separados con APIs diferentes: Phoenix es la superficie de código abierto, Arize AX es la plataforma en la nube con autenticación ARIZE_SPACE_ID + ARIZE_API_KEY.
#Braintrust, Helicone, AgentOps, Latitude, Curate-Me
El nivel restante se diferencia por su postura. Braintrust es la plataforma orientada a evaluación — el nivel gratuito más generoso de la comparación (1 M de spans/mes, usuarios ilimitados, 10 K evals), el flujo de trabajo de despliegue con gate de evaluación más sólido en CI/CD, Serie B de $80 M respaldada por a16z, Pro a $249/mes. Helicone está en modo de mantenimiento tras la adquisición por Mintlify (marzo de 2026); la historia de confiabilidad del AI Gateway basado en Rust (~10 K rps, limitación de tasa GCRA, chequeos de salud de 5 segundos, failover automático cuando la tasa de errores supera el 10 %) sobrevive, pero la velocidad de nuevas funciones se detuvo y 16 000 organizaciones cliente ahora planean migraciones. AgentOps envía más de 400 integraciones de frameworks y depuración con time-travel en un paquete SDK-first de Python; más de 5400 estrellas en GitHub; clientes de producción incluyen Microsoft, Google, Meta, Samsung, Deloitte y Fidelity Investments. Latitude es la plataforma de ciclo de vida de incidencias — su GEPA (Generative Eval from Production Annotations) genera automáticamente evaluaciones a partir de fallos anotados en producción, y los estados de ciclo de vida (activo → en progreso → resuelto → regresado) son únicos en la comparación. Curate-Me es la capa de enforcement — una cadena de gobernanza de cinco pasos (límites de tasa, topes de costo, escaneo de PII, listas de modelos permitidos, aprobaciones human-in-the-loop) más runners sandbox gestionados para la ejecución autónoma de agents, la única plataforma que bloquea activamente solicitudes en lugar de solo registrarlas.
#LiteLLM y el reinicio de la cadena de suministro
El incidente de LiteLLM en marzo de 2026 (versiones 1.82.7-1.82.8 comprometidas con malware robador de credenciales) redefinió el cálculo de confianza para la adopción de gateways self-hosted. LiteLLM sigue ampliamente desplegado en producción — Midas Engineering en The Atlantic (febrero de 2026) documenta un despliegue multi-entorno con autenticación por virtual-key y autoscaling basado en KEDA impulsado por métricas de Prometheus en lugar de CPU —, pero cada equipo que ejecuta LiteLLM ahora presupuesta controles explícitos de cadena de suministro (versiones fijadas, firma de imágenes de contenedor, revisión de dependencias). La respuesta del mercado incluye alternativas que enfatizan la postura de confianza: el gateway construido en Rust de Helicone, el lock de cumplimiento empresarial de Portkey, la combinación Model Cascading + Shadow Engine de NeuralRouting, y guías del patrón gateway que recomiendan siempre pasar por endpoints compatibles con OpenAI con cadenas de fallback explícitas.
El resultado neto de la consolidación: ya no hay una única plataforma correcta; hay una plataforma por postura de equipo. Para equipos con requisitos de residencia de datos: Langfuse self-hosted en Kubernetes, con la arquitectura (Web + Worker + Postgres + ClickHouse + Redis/Valkey + almacenamiento de blobs S3) ahora estable, bien documentada y ejecutándose con componentes bloqueados en UTC. Para equipos nativos de LangChain: LangSmith, con reutilización de evaluadores a nivel de workspace y simplicidad gestionada en la nube. Para equipos nativos de OTel: Phoenix, con el registro OpenInference realizando todo el trabajo de instrumentación de frameworks. Para equipos orientados a evaluación: Braintrust, generoso en el nivel gratuito y sólido en el gate de CI. Para equipos orientados a gobernanza: Curate-Me, donde la capa de enforcement es el producto. Para equipos de gateway empresarial: Portkey (gestionado) o LiteLLM (self-hosted con salvedades). La matriz de decisión está en el playbook de 90 días (Parte IX); la siguiente sección pasa al estándar que los une.
#Parte III — La estandarización OpenTelemetry GenAI
El OpenTelemetry Generative AI Observability SIG comenzó su trabajo en abril de 2024 y publica una versión estable de las convenciones semánticas GenAI en 2026. La hoja de ruta de estabilización es pública — Issue #3330 en el repositorio open-telemetry/semantic-conventions (25 de enero de 2026) — y el efecto práctico ya es visible en el soporte de proveedores: Datadog, New Relic, Honeycomb y Dynatrace admiten v1.37+ de forma nativa, lo que significa que el código de agents instrumentado con OpenTelemetry ahora envía traces de LLM directamente a esos backends sin cambios de SDK específicos del proveedor.
Las convenciones cubren cuatro familias de señales — events, exceptions, metrics y spans — más extensiones específicas de tecnología para Anthropic, Azure AI Inference, AWS Bedrock, OpenAI y el propio Model Context Protocol. El vocabulario de spans es la pieza estructural. El formato del nombre del span es {gen_ai.operation.name} {gen_ai.request.model} (o overrides específicos del framework como invoke_agent {gen_ai.agent.name} e invoke_workflow {gen_ai.workflow.name}). El kind del span es CLIENT para servicios remotos e INTERNAL para en proceso. El atributo requerido es gen_ai.operation.name; condicionalmente requeridos son gen_ai.request.model y error.type (este último establecido con el código de error devuelto por el proveedor, el nombre canónico de la excepción u otro identificador de baja cardinalidad). Los atributos recomendados incluyen server.address, server.port, gen_ai.usage.input_tokens y gen_ai.usage.output_tokens.
El atributo gen_ai.provider.name sirve como discriminador que identifica el sabor del formato de telemetría. Los valores bien conocidos son anthropic, aws.bedrock, openai, mistral, perplexity, google_generative_ai. El patrón de discriminador significa que los spans, métricas y eventos GenAI relacionados con AWS Bedrock deben establecer gen_ai.provider.name = "aws.bedrock" e incluir atributos aws.bedrock.* — y no deben incluir atributos openai.*. El mismo trace puede llevar spans de múltiples proveedores, pero cada span mantiene su propio espacio de nombres de atributos específico del proveedor.
Las métricas estándar son: gen_ai.client.token.usage (Histogram, etiquetado por modelo y sistema), gen_ai.client.operation.duration (segundos), gen_ai.server.request.duration (latencia del lado del servidor para instrumentación de gateway/proxy) y gen_ai.server.time_per_output_token (time-to-first-token y latencia entre tokens). El vocabulario de métricas es el sustrato que permite a los motores de SLO agregar entre proveedores y frameworks; el equipo que ejecuta un gateway frente a tres proveedores de modelos obtiene un Histogram por métrica, no tres.
La estrategia de transición es explícita: las instrumentaciones existentes que usan v1.36.0 o anterior no deben cambiar las versiones de convenciones emitidas por defecto, pero deben introducir una variable de entorno OTEL_SEMCONV_STABILITY_OPT_IN con gen_ai_latest_experimental como valor, para que los usuarios puedan optar por las convenciones más recientes por categoría. La guía de instrumentación de Datadog detalla el caso de producción textualmente: establecer OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental garantiza que frameworks como strands-agents (que ahora admiten v1.37+ pero antes emitían versiones anteriores) emitan las convenciones actuales, que Datadog LLM Observability luego ingiere y enruta a través de su esquema de spans nativo.
Del lado de los proveedores, el mapeo de atributos ya está estandarizado. Datadog mapea gen_ai.operation.name → meta.span.kind (con la tabla: chat, text_completion, generate_content, completion → llm; embeddings → embedding; execute_tool → tool; invoke_agent, create_agent → agent; rerank → workflow); gen_ai.provider.name → meta.model_provider; gen_ai.response.model → meta.model_name (con gen_ai.request.model como fallback si response.model está ausente); todos los parámetros gen_ai.request.* → meta.metadata.* con el prefijo eliminado; todos los gen_ai.usage.* → campos de uso de tokens. El mapeo bidireccional significa que dd_llmobs_enabled=false en cualquier span lo mantiene solo en APM y fuera de LLM Observability — enrutamiento explícito por trace.
El registro de instrumentación OpenInference es el compañero compatible con OTel de las convenciones y el toolkit cross-language más completo disponible. Los paquetes de Python, JavaScript/TypeScript (@arizeai/openinference-*) y Java cubren el SDK y Agents SDK de OpenAI, el Claude Agent SDK, LangChain (Python y JS), LlamaIndex, DSPy, el SDK de Anthropic, AWS Bedrock (y Bedrock Agent Runtime), MistralAI, VertexAI, Groq, Agno, BeeAI, LiteLLM (y LiteLLM Proxy para tráfico enrutado), @arizeai/openinference-mcp, @arizeai/openinference-vercel para el Vercel AI SDK y @arizeai/openinference-genai para las convenciones GenAI. Los usuarios de Java obtienen paquetes de Maven Central: openinference-instrumentation-langchain4j, openinference-instrumentation-springAI y un tracer manual basado en anotaciones que usa ByteBuddy para respaldar los decoradores @LLM, @LLMSpan y @AgentSpan. Los ejemplos cubren los casos de uso intermedios que importan: LangServe con metadatos personalizados por solicitud, DSPy RAG con FastAPI/Weaviate/Cohere, Haystack QA RAG, OpenAI Agents con handoffs, Microsoft Autogen AssistantAgent + TeamChat, PydanticAI y Pipecat.
El resultado neto de la estandarización es la observabilidad portátil. Un agent instrumentado con OpenInference + OpenTelemetry envía a Phoenix, Langfuse, Datadog, Honeycomb o cualquier backend compatible con OTel sin rutas de código específicas del proveedor. La decisión del proveedor se convierte en una decisión de backend, no de instrumentación — y el backend puede intercambiarse sin tocar el código del agent. Esa es la propiedad que la generación anterior de plataformas de observabilidad de LLM específicamente no tenía, y es la propiedad que hace que el resto de la arquitectura sea portátil entre los eventos de consolidación de 2026.
#Parte IV — El problema del sesgo del judge
El modo de falla más subestimado en la observabilidad de agents en producción es el sesgo del judge. La configuración ingenua — apuntar un LLM a una respuesta candidata, pedirle que puntúe 1-5 y registrar el resultado — produce un número que parece una medición pero que en realidad está dominado por artefactos estructurales del proceso de juicio. Tres sesgos recurren en la literatura, cada uno con una mitigación conocida, y cada uno no opcional para cualquier puntuación que valide un despliegue.
El sesgo de posición es el artefacto dominante. En comparaciones pairwise (A versus B), el veredicto del judge depende de la posición del candidato en el prompt. Algunos judges favorecen la primera opción, otros la segunda, y la intensidad del sesgo depende del modelo y la tarea. La señal limpia es la asimetría de orden: ejecutar A-luego-B, luego B-luego-A, y contar solo los veredictos donde ambas ordenaciones coinciden. La tasa de desacuerdo es el piso del sesgo de posición. En pares de candidatos muy cercanos, el 20-40 % de los veredictos se invierten cuando se intercambian las posiciones, lo que significa que hasta el 40 % de las “victorias” en una evaluación pairwise de una sola dirección son artefactos de ordenación, no señal. El playbook de auditoría de sesgo de Tianpan (27