Un equipo que construye sobre Azure tiene las piezas delante —Azure AI Foundry, Semantic Kernel, modelos de Azure OpenAI— y un agente que funciona y hace lo correcto en la demo. Lo que decide si sobrevive al contacto con producción no es qué modelo eligieron. Es si, cuando tres agentes coordinan y el output está silenciosamente mal, alguien puede abrir el trace y ver por qué. En el stack de Microsoft la respuesta es buena, siempre que lo cablees a conciencia. Así encajan las piezas.
Este es el complemento específico de Azure al argumento general de que OpenTelemetry es el contrato de tracing. Los mismos instintos valen en Google —lo escribimos aparte—, y todo el sentido de apoyarse en OTel es que ambos sigan siendo comparables.
La forma del stack
Cuatro capas, y conviene mantenerlas separadas:
- Plataforma — Azure AI Foundry (el antiguo Azure AI Studio), incluido su servicio de agentes, es donde los agentes se construyen, se despliegan y se ejecutan. Foundry trae tracing y evaluación de primera clase; trátalos como la puerta de entrada, no como la casa entera.
- Framework — Semantic Kernel y AutoGen, ahora convergiendo en el Microsoft Agent Framework, es donde vive la lógica de orquestación. Esta capa es la que decide qué se convierte en un span.
- Modelos — Azure OpenAI (las series GPT y o) más el catálogo de modelos. El modelo es un componente: lo elige el eval y lo vigila el trace.
- Backend de telemetría — Azure Monitor y Application Insights, donde aterrizan traces, métricas y logs, y donde de verdad los consultas.
Haz que hable OpenTelemetry, no solo Azure
La única decisión que mantiene sano a este stack es instrumentar en OpenTelemetry con las convenciones semánticas GenAI y dejar que Application Insights sea el backend y no el formato. Semantic Kernel y el Agent Framework emiten OTel; Azure Monitor lo ingiere de forma nativa. Así te queda la experiencia nativa de Azure completa —el tracing de Foundry, las consultas de App Insights, las herramientas de evaluación integradas— mientras los spans siguen siendo telemetría estándar y portable.
¿Por qué insistir si «ya estás en Azure de todos modos»? Porque el cliente regulado que quiere la telemetría en su propio almacén, la plataforma de evaluación donde quieres correr LLM como juez y el futuro multinube con el que aún no te has comprometido salen baratos si el trace es OTel y carísimos si es un blob con forma de Application Insights. Exprime el backend de Azure; solo no dejes que acabe siendo lo único capaz de leer tus traces.
Qué capturar en el span
Las herramientas de Azure registrarán encantadas las llamadas al modelo y la latencia. Los spans que de verdad salvan al ingeniero de guardia llevan más cosas:
- Fronteras de agente y razonamiento — qué agente actuó, por qué eligió esa tool y con cuánta confianza. El servicio de agentes de Foundry te da las fronteras; el contexto semántico lo pones tú.
- Versiones — prompt, config de tool y revisión de agente en cada span, para que el drift de un agente adaptativo sea atribuible.
- Atributos de token y costo —
gen_ai.usage.*en cada generación, porque en un agente de diez pasos el costo se acumula y Azure te factura cada token recomputado.
El Collector y Purview se ocupan de la gobernanza
Para trabajo regulado —y muchos entornos Azure lo son— pon un Collector de OTel entre los agentes y Application Insights, y haz ahí la redacción de PII, una sola vez, antes de que la telemetría salga del perímetro. Combínalo con Microsoft Purview para la gobernanza y el linaje que van a pedirte los auditores. El patrón importa más que los nombres de producto: redacta en el Collector, gobierna en la plataforma, y el texto del prompt y los argumentos de tools llegarán limpios al backend.
La evaluación honesta
El stack de Microsoft es un buen sitio para ejecutar agentes con observabilidad de verdad, y el camino integrado de Foundry más App Insights es genuinamente cómodo. Su principal riesgo es exactamente esa comodidad: es fácil acabar con forma de Azure de arriba abajo, traces incluidos, y descubrir el lock-in justo cuando quieres salir. Apóyate en la integración para la experiencia del operador y mantén los spans en OTel, para que esa experiencia sea una elección y no una jaula. Si lo haces, te llevas lo mejor del stack —el tracing de Foundry, la potencia de consulta de App Insights, los evals integrados— sobre telemetría que todavía puedes recoger y llevarte.
En Azure, el modelo es la decisión fácil; el trace es la que decide si puedes operar el sistema. Foundry, Semantic Kernel y Application Insights te dan observabilidad real de fábrica: tómala, y mantén los spans en OpenTelemetry para que siga siendo tuya. Exprime el stack de Microsoft. Solo asegúrate de que tus traces podrían abandonarlo.