{"id":6535,"date":"2026-09-29T08:57:00","date_gmt":"2026-09-29T06:57:00","guid":{"rendered":"https:\/\/blog-david.moreno-morales.com\/?p=6535"},"modified":"2026-09-27T20:59:56","modified_gmt":"2026-09-27T18:59:56","slug":"observabilidad-aplicaciones-ia","status":"publish","type":"post","link":"https:\/\/blog-david.moreno-morales.com\/index.php\/2026\/09\/29\/observabilidad-aplicaciones-ia\/","title":{"rendered":"Observabilidad para aplicaciones con IA: qu\u00e9 medir m\u00e1s all\u00e1 de logs y errores"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Cuando una aplicaci\u00f3n tradicional empieza a comportarse mal, solemos buscar se\u00f1ales conocidas: errores HTTP, excepciones, consumo de CPU, memoria, consultas lentas o mensajes en los logs.<\/p>

Con una aplicaci\u00f3n basada en inteligencia artificial, esas se\u00f1ales siguen siendo necesarias. El problema es que ya no son suficientes.<\/p>

Imagina que un agente tarda 35 segundos en responder. La petici\u00f3n termina correctamente, no aparece ninguna excepci\u00f3n y la infraestructura funciona con normalidad. Desde el punto de vista de la observabilidad tradicional, quiz\u00e1 no haya ning\u00fan incidente.<\/p>

Pero quedan muchas preguntas abiertas. \u00bfEl modelo tard\u00f3 demasiado? \u00bfSe realizaron m\u00e1s llamadas de las previstas? \u00bfUna herramienta respondi\u00f3 lentamente? \u00bfEl agente entr\u00f3 en un bucle? \u00bfSe enviaron demasiados tokens? \u00bfHubo reintentos? \u00bfEl retrieval recuper\u00f3 informaci\u00f3n irrelevante? \u00bfLa respuesta fue t\u00e9cnicamente correcta pero innecesariamente cara?<\/p>

La observabilidad de aplicaciones con IA necesita responder a todas esas preguntas. Y para conseguirlo debemos dejar de pensar \u00fanicamente en logs y empezar a observar la ejecuci\u00f3n completa.<\/p>

De observar servicios a observar ejecuciones<\/h2>

En una aplicaci\u00f3n web convencional podemos imaginar una petici\u00f3n relativamente sencilla:<\/p>

Usuario \u2192 API \u2192 Base de datos \u2192 Respuesta<\/p>

Una aplicaci\u00f3n con IA puede ejecutar algo mucho m\u00e1s parecido a esto:<\/p>

\u00a0 \u00a0 \u00a0 \u00a0 Usuario \u2192 Aplicaci\u00f3n \u2192 LLM \u2192 Tool call \u2192 API externa \u2192 LLM \u2192 Retrieval \u2192 LLM \u2192 Respuesta<\/p>

Adem\u00e1s, cualquiera de esos pasos puede repetirse. Un agente puede decidir utilizar una herramienta, analizar su resultado, llamar a otra, volver al modelo y repetir el proceso hasta obtener una respuesta final.<\/p>

Por eso el elemento fundamental de observabilidad deja de ser \u00fanicamente la petici\u00f3n HTTP. Necesitamos observar el workflow completo.<\/p>

Una buena traza deber\u00eda permitir reconstruir la ejecuci\u00f3n desde que entra la petici\u00f3n del usuario hasta que se genera la respuesta final.<\/p>

Las trazas se convierten en la pieza central<\/h2>

OpenTelemetry lleva a\u00f1os proporcionando un est\u00e1ndar abierto para trabajar con trazas, m\u00e9tricas y logs en sistemas distribuidos.<\/p>

La llegada de la IA generativa ha a\u00f1adido nuevas necesidades. Actualmente existen convenciones sem\u00e1nticas espec\u00edficas para GenAI que contemplan operaciones como inferencia, retrieval, memoria y ejecuci\u00f3n de herramientas.<\/p>

La idea es sencilla: representar las operaciones de IA mediante spans dentro de una traza distribuida.<\/p>

Una ejecuci\u00f3n podr\u00eda verse as\u00ed:<\/p>

agent.run                        4.82 s\n\u251c\u2500\u2500 model.inference              1.34 s\n\u251c\u2500\u2500 execute_tool                 0.61 s\n\u2502   \u2514\u2500\u2500 database.query           0.48 s\n\u2514\u2500\u2500 model.inference              2.21 s<\/code><\/pre>
De repente, una pregunta como \u201c\u00bfpor qu\u00e9 esta respuesta tard\u00f3 cinco segundos?\u201d resulta mucho m\u00e1s f\u00e1cil de investigar.<\/p>
No vemos simplemente que la petici\u00f3n tard\u00f3 cinco segundos, vemos d\u00f3nde se consumi\u00f3 ese tiempo. Esta diferencia es fundamental para diagnosticar agentes.<\/p>
1. Latencia: medir mucho m\u00e1s que el tiempo total<\/h2>
La primera m\u00e9trica evidente sigue siendo la latencia, pero medir \u00fanicamente el tiempo total de respuesta puede esconder el problema real.<\/p>
Conviene separar al menos:<\/p>
  • latencia total del workflow;<\/p><\/li>
  • latencia de cada llamada al modelo;<\/p><\/li>
  • latencia de cada herramienta;<\/p><\/li>
  • latencia del retrieval;<\/p><\/li>
  • tiempo empleado en reintentos;<\/p><\/li>
  • tiempo hasta comenzar a recibir la respuesta cuando existe streaming.<\/p><\/li><\/ul>
    Adem\u00e1s, las medias pueden resultar enga\u00f1osas. En producci\u00f3n suele ser m\u00e1s \u00fatil observar percentiles como p50, p95 y p99.<\/p>
    Un agente podr\u00eda tener una latencia media perfectamente aceptable mientras un porcentaje peque\u00f1o de ejecuciones tarda varias veces m\u00e1s.<\/p>
    La pregunta interesante no es solamente: \u00bfCu\u00e1nto tarda mi aplicaci\u00f3n?<\/p>
    Sino: \u00bfQu\u00e9 componente est\u00e1 provocando las ejecuciones lentas?<\/p>
    Las trazas permiten responder a la segunda.<\/p>
    2. Tokens: una m\u00e9trica t\u00e9cnica y econ\u00f3mica<\/h2>
    En aplicaciones con LLMs, los tokens son una de las se\u00f1ales m\u00e1s importantes. Conviene registrar, cuando el proveedor lo permita:<\/p>
    input_tokens\noutput_tokens\ncached_tokens\nreasoning_tokens\ntotal_tokens<\/code><\/pre>
    No solo para calcular costes. Un crecimiento inesperado del n\u00famero de tokens puede revelar problemas arquitect\u00f3nicos.<\/p>
    Por ejemplo:<\/p>
    • prompts que acumulan demasiado contexto;<\/p><\/li>
    • historiales de conversaci\u00f3n que crecen indefinidamente;<\/p><\/li>
    • documentos excesivamente grandes enviados al modelo;<\/p><\/li>
    • agentes que realizan m\u00e1s iteraciones de las necesarias;<\/p><\/li>
    • herramientas que devuelven informaci\u00f3n demasiado extensa.<\/p><\/li><\/ul>
      Por eso resulta especialmente \u00fatil observar tokens por ejecuci\u00f3n y no \u00fanicamente\u00a0tokens totales del d\u00eda.<\/p>
      Dos aplicaciones pueden consumir un mill\u00f3n de tokens diarios y comportarse de manera completamente diferente. Una puede atender 10.000 solicitudes eficientes, la otra puede atender 500 workflows extraordinariamente caros.<\/p>
      3. Coste por workflow<\/h2>
      Los tokens permiten construir otra m\u00e9trica operativa muy \u00fatil: coste_por_ejecucion<\/code><\/p>
      Tambi\u00e9n podemos agregarla por:<\/p>
      coste_por_usuario\ncoste_por_agente\ncoste_por_modelo\ncoste_por_funcionalidad\ncoste_por_cliente<\/code><\/pre>
      Esto permite detectar algo que la observabilidad tradicional raramente necesitaba considerar: una aplicaci\u00f3n puede estar t\u00e9cnicamente sana y econ\u00f3micamente degradada.<\/p>
      No hay errores, no hay ca\u00edda del servicio, la latencia incluso puede ser correcta, pero una modificaci\u00f3n en el prompt ha duplicado el consumo de tokens. Desde la perspectiva del negocio, eso tambi\u00e9n es una regresi\u00f3n.<\/p>
      4. Tool calls: observar las decisiones del agente<\/h2>
      Cuando introducimos agentes aparece otra dimensi\u00f3n importante, el modelo ya no se limita a producir texto, puede decidir ejecutar acciones.<\/p>
      Por ejemplo:<\/p>
      buscar_cliente()\nconsultar_pedido()\nbuscar_documentacion()\nejecutar_consulta_sql()\nenviar_email()<\/code><\/pre>
      Por tanto, deber\u00edamos observar qu\u00e9 herramientas utiliza el agente y c\u00f3mo las utiliza.<\/p>
      Algunas m\u00e9tricas interesantes son:<\/p>
      tool_calls_por_ejecucion\ntool_error_rate\ntool_latency\ntool_retry_count<\/code><\/pre>
      Pero tambi\u00e9n conviene conservar la relaci\u00f3n causal, queremos poder reconstruir algo parecido a:<\/p>
      Modelo\n  \u2193\ndecide ejecutar buscar_cliente\n  \u2193\nTool call\n  \u2193\nresultado\n  \u2193\nModelo\n  \u2193\ndecide ejecutar consultar_pedido<\/code><\/pre>
      Esto permite distinguir un problema de infraestructura de un problema de razonamiento u orquestaci\u00f3n. Una API puede responder perfectamente en 100 milisegundos.<\/p>
      Pero si el agente la llama doce veces cuando deber\u00eda llamarla una, el problema est\u00e1 en otro sitio.<\/p>
      5. Reintentos y bucles<\/h2>
      Los retries merecen atenci\u00f3n especial. Un retry puede ser totalmente leg\u00edtimo, diez retries pueden indicar un problema.<\/p>
      En sistemas de agentes interesa observar:<\/p>
      iterations_per_run\nmodel_calls_per_run\ntool_calls_per_run\nretry_count<\/code><\/pre>
      y establecer distribuciones normales para cada workflow. Si normalmente un agente resuelve una tarea utilizando dos llamadas al modelo y repentinamente empieza a necesitar siete, existe una regresi\u00f3n aunque todas las ejecuciones terminen correctamente.<\/p>
      Esta es una caracter\u00edstica importante de los sistemas con IA: el \u00e9xito funcional no implica eficiencia operativa.<\/p>
      6. Errores: HTTP 500 ya no cuenta toda la historia<\/h2>
      Los errores tradicionales contin\u00faan siendo importantes:<\/p>
      • timeouts;<\/p><\/li>
      • errores HTTP;<\/p><\/li>
      • excepciones;<\/p><\/li>
      • rate limits;<\/p><\/li>
      • errores de autenticaci\u00f3n;<\/p><\/li>
      • servicios externos no disponibles.<\/p><\/li><\/ul>
        Pero aparecen otras categor\u00edas.<\/p>
        Por ejemplo:<\/p>
        tool_selection_error\ninvalid_tool_arguments\nmax_iterations_reached\nguardrail_triggered\ncontext_limit\nstructured_output_validation_error<\/code><\/pre>
        Incluso podemos tener ejecuciones t\u00e9cnicamente exitosas pero funcionalmente in\u00fatiles.<\/p>
        El modelo responde, la API devuelve 200, pero la respuesta no satisface la tarea.<\/p>
        Esto introduce una frontera interesante entre observabilidad y evaluaci\u00f3n de calidad.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t\t\"De\t\t\t\t\t\t\t\t\t\t\t
        De un log aislado a una traza end-to-end<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t\t\"Las\t\t\t\t\t\t\t\t\t\t\t
        Las cinco se\u00f1ales que hay que med<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t
        7. Observabilidad y evaluaci\u00f3n no son lo mismo<\/h2>
        Conviene separar ambos conceptos. La observabilidad intenta responder:<\/p>
        \u00bfQu\u00e9 ocurri\u00f3 durante esta ejecuci\u00f3n?<\/p><\/blockquote>
        La evaluaci\u00f3n intenta responder:<\/p>
        \u00bfFue buena la respuesta?<\/p><\/blockquote>
        Son problemas diferentes, aunque deber\u00edan conectarse. Podemos imaginar una traza con atributos como:<\/p>
        trace_id\nmodel\ninput_tokens\noutput_tokens\nlatency\ntool_calls\nretry_count<\/code><\/pre>
        y asociarle posteriormente una evaluaci\u00f3n:<\/p>
        correctness_score\nrelevance_score\ngroundedness\nuser_feedback<\/code><\/pre>
        Esta combinaci\u00f3n es extremadamente \u00fatil. Por ejemplo, podr\u00edamos descubrir que las respuestas con peor evaluaci\u00f3n aparecen cuando:<\/p>
        • se utiliza determinado modelo;<\/p><\/li>
        • el retrieval devuelve pocos documentos;<\/p><\/li>
        • el agente supera determinado n\u00famero de iteraciones;<\/p><\/li>
        • una herramienta concreta falla;<\/p><\/li>
        • el contexto supera cierto tama\u00f1o.<\/p><\/li><\/ul>
          Ah\u00ed es donde observabilidad y evaluaci\u00f3n empiezan a convertirse en una herramienta real de ingenier\u00eda.<\/p>
          8. El modelo tambi\u00e9n debe formar parte de la telemetr\u00eda<\/h2>
          En sistemas tradicionales solemos registrar la versi\u00f3n del servicio desplegado. Con IA debemos hacer algo parecido con los modelos.<\/p>
          Resulta \u00fatil registrar informaci\u00f3n como:<\/p>
          model\nprovider\nworkflow_version\nprompt_version\nagent_version<\/code><\/pre>
          Esto permite comparar comportamiento entre versiones. Si cambiamos un modelo podemos preguntar:<\/p>
          • \u00bfha cambiado la latencia?<\/p><\/li>
          • \u00bfha cambiado el consumo de tokens?<\/p><\/li>
          • \u00bfutiliza m\u00e1s herramientas?<\/p><\/li>
          • \u00bfha aumentado el coste?<\/p><\/li>
          • \u00bfhan mejorado las evaluaciones?<\/p><\/li><\/ul>
            Sin esta informaci\u00f3n, investigar una regresi\u00f3n despu\u00e9s de cambiar de modelo puede convertirse en un ejercicio de arqueolog\u00eda.<\/p>
            9. El prompt tambi\u00e9n necesita versionado<\/h2>
            Un cambio de prompt puede modificar radicalmente el comportamiento de una aplicaci\u00f3n sin cambiar una sola l\u00ednea de c\u00f3digo. Por eso los prompts deber\u00edan tratarse como artefactos versionados.<\/p>
            En lugar de depender \u00fanicamente del contenido completo del prompt, podemos registrar:<\/p>
            prompt_name\nprompt_version<\/code><\/pre>
            Por ejemplo:<\/p>
            customer_support_agent\nv17<\/code><\/pre>
            As\u00ed podemos comparar:<\/p>
            latencia v16 vs v17\ntokens v16 vs v17\ntool calls v16 vs v17\nevaluaciones v16 vs v17<\/code><\/pre>
            Esto convierte cambios aparentemente subjetivos en cambios observables.<\/p>
            10. Cuidado con registrar prompts completos<\/h2>
            Aqu\u00ed aparece uno de los principales riesgos. Guardar prompts y respuestas completas facilita enormemente el debugging.<\/p>
            Pero tambi\u00e9n puede introducir:<\/p>
            • datos personales;<\/p><\/li>
            • informaci\u00f3n confidencial;<\/p><\/li>
            • credenciales;<\/p><\/li>
            • c\u00f3digo privado;<\/p><\/li>
            • documentos internos;<\/p><\/li>
            • informaci\u00f3n empresarial sensible.<\/p><\/li><\/ul>
              Por tanto, \u201cregistrarlo todo\u201d no deber\u00eda ser la estrategia predeterminada. Una arquitectura madura deber\u00eda decidir expl\u00edcitamente: qu\u00e9 contenido se captura, durante cu\u00e1nto tiempo y qui\u00e9n puede consultarlo.<\/p>
              Podemos utilizar t\u00e9cnicas como:<\/p>
              • redacci\u00f3n de informaci\u00f3n sensible;<\/p><\/li>
              • allowlists de atributos;<\/p><\/li>
              • sampling;<\/p><\/li>
              • almacenamiento separado;<\/p><\/li>
              • controles de acceso;<\/p><\/li>
              • periodos de retenci\u00f3n diferentes.<\/p><\/li><\/ul>
                En muchos casos ser\u00e1 posible obtener observabilidad suficiente registrando metadatos y capturando contenido \u00fanicamente en determinadas ejecuciones.<\/p>
                11. Sampling: no todas las trazas tienen el mismo valor<\/h2>
                Guardar cada detalle de cada ejecuci\u00f3n puede resultar caro, por eso el sampling tambi\u00e9n es importante. Una estrategia sencilla podr\u00eda conservar:<\/p>
                100 % de errores\n100 % de ejecuciones anormalmente lentas\n100 % de workflows excesivamente caros\n5 % de ejecuciones normales<\/code><\/pre>
                As\u00ed obtenemos informaci\u00f3n detallada precisamente sobre los casos m\u00e1s interesantes sin multiplicar innecesariamente el volumen de telemetr\u00eda.<\/p>
                En aplicaciones con IA, adem\u00e1s, el sampling puede depender de se\u00f1ales espec\u00edficas:<\/p>
                token_count > l\u00edmite\ntool_calls > l\u00edmite\nlatency > l\u00edmite\nretry_count > l\u00edmite\nevaluation_score < l\u00edmite<\/code><\/pre>
                12. M\u00e9tricas agregadas para detectar problemas<\/h2>
                Las trazas sirven para investigar ejecuciones concretas, las m\u00e9tricas permiten descubrir tendencias. Un dashboard b\u00e1sico de una aplicaci\u00f3n con IA podr\u00eda incluir:<\/p>
                Requests\/min\nLatencia p50 \/ p95 \/ p99\nModel calls\/run\nTool calls\/run\nTool error rate\nInput tokens\/run\nOutput tokens\/run\nCost\/run\nRetry rate<\/code><\/pre>
                Si existe evaluaci\u00f3n autom\u00e1tica o feedback del usuario, podemos a\u00f1adir se\u00f1ales de calidad. La combinaci\u00f3n es especialmente potente.<\/p>
                Por ejemplo:<\/p>
                Latencia \u2191\nTokens \u2191\nTool calls \u2191\nCalidad =<\/code><\/pre>
                podr\u00eda indicar que el agente se ha vuelto menos eficiente sin aportar mejores resultados.<\/p>
                13. OpenTelemetry empieza a proporcionar un lenguaje com\u00fan<\/h2>
                Uno de los avances m\u00e1s interesantes es que esta telemetr\u00eda empieza a normalizarse. Las convenciones de OpenTelemetry para IA generativa definen atributos y operaciones espec\u00edficas para representar interacciones con modelos y otros componentes de sistemas GenAI.<\/p>
                Entre ellas aparecen conceptos relacionados con:<\/p>
                • inferencia;<\/p><\/li>
                • agentes;<\/p><\/li>
                • ejecuci\u00f3n de herramientas;<\/p><\/li>
                • retrieval;<\/p><\/li>
                • memoria;<\/p><\/li>
                • tokens;<\/p><\/li>
                • modelos;<\/p><\/li>
                • latencia.<\/p><\/li><\/ul>
                  Esto es importante porque evita que cada organizaci\u00f3n invente desde cero su propio esquema. Aun as\u00ed, es un terreno en evoluci\u00f3n. En 2026 siguen existiendo discusiones sobre c\u00f3mo representar mejor workflows duraderos, checkpoints, reanudaciones, delegaciones, efectos externos y otras caracter\u00edsticas propias de agentes complejos.<\/p>
                  Por eso conviene adoptar est\u00e1ndares, pero evitando acoplar toda la arquitectura a campos experimentales sin una capa propia de abstracci\u00f3n.<\/p>
                  14. Los SDK de agentes ya incorporan tracing<\/h2>
                  La observabilidad tampoco tiene que construirse completamente desde cero, frameworks y SDK modernos empiezan a incorporar tracing directamente. Por ejemplo, el Agents SDK de OpenAI registra eventos relacionados con generaciones del modelo, llamadas a herramientas, handoffs, guardrails y otros elementos de una ejecuci\u00f3n. Tambi\u00e9n permite obtener informaci\u00f3n agregada sobre uso de tokens durante un run. Esto reduce considerablemente el esfuerzo necesario para empezar.<\/p>
                  Pero disponer de tracing autom\u00e1tico no elimina la necesidad de dise\u00f1ar una estrategia de observabilidad.<\/p>
                  Seguimos teniendo que decidir:<\/p>
                  • qu\u00e9 m\u00e9tricas importan;<\/p><\/li>
                  • qu\u00e9 atributos necesitamos;<\/p><\/li>
                  • qu\u00e9 alertas tienen sentido;<\/p><\/li>
                  • qu\u00e9 datos podemos almacenar;<\/p><\/li>
                  • c\u00f3mo relacionamos telemetr\u00eda t\u00e9cnica con resultados de negocio.<\/p><\/li><\/ul>
                    15. Un modelo pr\u00e1ctico de observabilidad para IA<\/h2>
                    Una forma sencilla de empezar consiste en dividir las se\u00f1ales en cinco grupos.<\/p>
                    Rendimiento<\/h3>
                    latency\ntime_to_first_token\nmodel_latency\ntool_latency\nretrieval_latency<\/code><\/pre>
                    Consumo<\/h3>
                    input_tokens\noutput_tokens\ncached_tokens\nmodel_calls\ncost<\/code><\/pre>
                    Comportamiento del agente<\/h3>
                    iterations\ntool_calls\nhandoffs\nretries<\/code><\/pre>
                    Fiabilidad<\/h3>
                    errors\ntimeouts\ntool_errors\nrate_limits\nvalidation_errors<\/code><\/pre>
                    Calidad<\/h3>
                    evaluations\nuser_feedback\ntask_success<\/code><\/pre>
                    No todas las aplicaciones necesitan todas las m\u00e9tricas.<\/p>
                    La pregunta debe ser: \u00bfQu\u00e9 informaci\u00f3n necesitar\u00edamos ma\u00f1ana para explicar una ejecuci\u00f3n incorrecta, lenta o demasiado cara?<\/p>
                    La respuesta define buena parte de la telemetr\u00eda que deber\u00edamos implementar hoy.<\/p>
                    De \u201c\u00bfhay errores?\u201d a \u201c\u00bfqu\u00e9 ocurri\u00f3 realmente?\u201d<\/h2>
                    Ese es probablemente el cambio conceptual m\u00e1s importante. La observabilidad tradicional suele empezar preguntando:<\/p>
                    \u00bfEst\u00e1 funcionando el sistema?<\/p><\/blockquote>
                    En aplicaciones con IA necesitamos preguntas adicionales:<\/p>
                    \u00bfQu\u00e9 hizo exactamente?<\/p><\/blockquote>
                    \u00bfPor qu\u00e9 tard\u00f3 tanto?<\/p><\/blockquote>
                    \u00bfQu\u00e9 herramientas utiliz\u00f3?<\/p><\/blockquote>
                    \u00bfCu\u00e1ntos tokens consumi\u00f3?<\/p><\/blockquote>
                    \u00bfCu\u00e1nto cost\u00f3?<\/p><\/blockquote>
                    \u00bfCu\u00e1ntas veces lo intent\u00f3?<\/p><\/blockquote>
                    \u00bfQu\u00e9 versi\u00f3n del modelo y del prompt utiliz\u00f3?<\/p><\/blockquote>
                    \u00bfY el resultado fue realmente \u00fatil?<\/p><\/blockquote>
                    Los logs contin\u00faan siendo necesarios, las m\u00e9tricas contin\u00faan siendo necesarias, las trazas contin\u00faan siendo necesarias, pero la unidad que necesitamos comprender ha cambiado. Ya no observamos \u00fanicamente servicios.<\/p>
                    Observamos ejecuciones inteligentes compuestas por decisiones, modelos, herramientas y datos.<\/p>
                    Y cuanto m\u00e1s aut\u00f3nomos sean nuestros agentes, m\u00e1s importante ser\u00e1 poder reconstruir exactamente qu\u00e9 hicieron. Porque cuando un agente falle en producci\u00f3n, saber que la API devolvi\u00f3 200 OK<\/code> probablemente ser\u00e1 la parte menos interesante del incidente.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t\t
                    \n\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t\t
                    REFERENCIAS\n<\/h4>\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t
                    • OpenTelemetry \u2014 Inside the LLM Call: GenAI Observability with OpenTelemetry (2026): https:\/\/opentelemetry.io\/blog\/2026\/genai-observability\/<\/li>
                    • OpenTelemetry \u2014 Semantic conventions for generative client AI spans: https:\/\/github.com\/open-telemetry\/semantic-conventions-genai\/blob\/main\/docs\/gen-ai\/gen-ai-spans.md<\/li>
                    • OpenTelemetry \u2014 Semantic Conventions 1.44.0: https:\/\/opentelemetry.io\/docs\/specs\/semconv\/<\/li>
                    • OpenAI Agents SDK \u2014 Tracing: https:\/\/openai.github.io\/openai-agents-python\/tracing\/<\/li>
                    • OpenAI Agents SDK \u2014 Usage: https:\/\/openai.github.io\/openai-agents-python\/usage\/<\/li>
                    • OpenTelemetry GenAI \u2014 Proposal: observability semantics for durable agentic runtime execution (Issue #462, 2026): https:\/\/github.com\/open-telemetry\/semantic-conventions-genai\/issues\/462<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"
                      Trazar llamadas al modelo, herramientas, tokens, latencia y errores; c\u00f3mo usar telemetr\u00eda para diagnosticar agentes y aplicaciones con IA.<\/p>\n","protected":false},"author":1,"featured_media":6538,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[38],"tags":[71,47,49,52,70,48],"class_list":["post-6535","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-aplicaciones","tag-desarrollo","tag-ia","tag-inteligenciaartificial","tag-observabilidad","tag-software"],"_links":{"self":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6535","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/comments?post=6535"}],"version-history":[{"count":3,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6535\/revisions"}],"predecessor-version":[{"id":6541,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6535\/revisions\/6541"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media\/6538"}],"wp:attachment":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media?parent=6535"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/categories?post=6535"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/tags?post=6535"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}