Cómo Evaluar Agentes de IA en Producción: El Sistema de 3 Capas que Usamos en Trazas Reales

Cómo Evaluar Agentes de IA en Producción: El Sistema de 3 Capas que Usamos en Trazas Reales

Evaluar agentes de IA en producción significa puntuar la trayectoria completa de varios pasos del agente, no solo su respuesta final, sobre tráfico real: revisar cada paso de razonamiento, validar que llamó a las herramientas correctas con los argumentos correctos, y monitorizar de forma continua el éxito de la tarea, el coste y la seguridad después del lanzamiento, porque los agentes fallan en silencio y de forma no determinista.

En una ejecución de junio de 2026 de nuestro propio pipeline de contenido de Techsy, el agente entregó un post de blog con aspecto perfecto y la puntuación de salida final lo aprobó. Limpio. Excepto que, tres pasos antes, el brief-creator había llamado a la herramienta de búsqueda de enlaces internos equivocada, así que la mitad de los enlaces del clúster no llevaban a ninguna parte. Saber cómo evaluar agentes de IA en producción significa puntuar todo el camino que recorrió el agente, no solo la respuesta en la que terminó por casualidad.

Puntos clave:

• Puntúa la trayectoria completa, no solo la respuesta final: una respuesta correcta por el camino equivocado sigue siendo un fallo.
• Valida las llamadas a herramientas en tres ejes: herramienta correcta, argumentos correctos, paso correcto.
• Ejecuta las mismas métricas offline y online, sobre trazas de producción reales, en un bucle continuo.
• Bloquea despliegues por vulnerabilidades de seguridad (jailbreak, PII, mal uso de herramientas), no solo por puntuaciones de precisión bajas.

¿Por qué evaluar agentes de IA en producción es diferente de evaluar un LLM?

Evaluar agentes de IA en producción es más difícil que evaluar un modelo porque un agente da varios pasos, llama a herramientas externas y modifica un estado real, y hace todo eso de forma no determinista. La misma entrada puede producir una secuencia de llamadas a herramientas distinta en cada ejecución, así que un solo paso equivocado al principio puede corromper todos los pasos posteriores.

Esta guía asume que ya conoces la evaluación general de LLMs. Si no es así, empieza con nuestra guía completa de evaluación de LLM y luego vuelve para ver qué cambia cuando el modelo se convierte en un agente. (¿Todavía estás construyendo los agentes que vas a evaluar? Nuestro repaso de los mejores frameworks de agentes de IA cubre la capa de debajo.)

Cuatro cosas se rompen en el momento en que tu LLM empieza a actuar por su cuenta:

• Multi-paso. Un agente de soporte puede buscar en una base de conocimiento, llamar a una API de pedidos y luego redactar una respuesta. Si solo puntúas la respuesta, quedas ciego a los dos pasos que la decidieron.
• No determinista. La temperatura, las actualizaciones de pesos del modelo y la latencia de las herramientas hacen que la misma solicitud siga un camino distinto en cada ejecución. Tu evaluación tiene que sobrevivir a un objetivo en movimiento.
• Con estado. Los agentes escriben en bases de datos, envían correos, reembolsan pedidos. Una acción equivocada no es una frase mal escrita, es un efecto secundario que no puedes deshacer.
• Acumulativo. Un paso 2 ligeramente equivocado en una ejecución de 12 pasos envenena todo lo que viene después, y la respuesta final puede seguir pareciendo correcta.

El informe State of Eval Engineering de Galileo de febrero de 2026, que encuestó a más de 500 profesionales, encontró que el 84,9% de los equipos sufrió un incidente de IA en los seis meses posteriores al lanzamiento. El equipo de ingeniería de Anthropic lo expresa sin rodeos en su ensayo sobre evaluación de agentes: los agentes fallan en los pasos, en las herramientas y en la intención, no solo en la salida final.

Un agente que devuelve la respuesta correcta a través de una trayectoria equivocada no ha aprobado. Ha fallado en silencio, y fallará de forma ruidosa la próxima vez que la recuperación afortunada no ocurra.

¿Qué métricas importan de verdad para los agentes de IA en producción?

Las métricas que más importan para los agentes en producción van más allá de la precisión: tasa de éxito de la tarea, coste por tarea exitosa, percentiles de latencia, precisión de las llamadas a herramientas, faithfulness, tasa de intervención humana, deriva y tasa de aprobación de la puerta de seguridad. Juntas, estas métricas de evaluación de agentes de IA detectan los fallos silenciosos y no deterministas que una sola puntuación de salida pasa por alto.

Estas son las ocho métricas que realmente vigilamos en nuestras propias ejecuciones. Fíjate en lo pocas que se preocupan de si la respuesta final suena bien:

La mayoría de estas dependen de un LLM como juez (un modelo que puntúa la salida de otro). Es el truco estándar y escala bien, pero es ruidoso: el juez a menudo comparte los puntos ciegos del agente, así que trata sus puntuaciones como una señal, no como una verdad absoluta. Volvemos a la calibración del juez en la sección siete.

Una métrica merece una mención aparte. El coste por tarea exitosa es la cifra que sobrevive a una revisión de presupuesto. El coste por tarea sin más premia los fallos baratos, porque un agente que se rinde rápido y mal parece eficiente en la hoja de cálculo.

¿Cómo se puntúa la trayectoria de un agente en lugar de su respuesta final?

Para puntuar la trayectoria de un agente, evalúas la traza: el registro ordenado de cada paso de razonamiento, llamada a herramienta y salida intermedia que produjo el agente. La evaluación a nivel de span puntúa cada paso individual (span) para que puedas señalar exactamente cuál falló, en lugar de solo saber que la ejecución en general salió mal.

Piensa en una traza como un stack trace del razonamiento. Cada span es un paso: una recuperación, una llamada a herramienta, un traspaso a un subagente. La observabilidad captura esos spans; la evaluación los puntúa. (¿Todavía no tienes trazado? Nuestra guía de observabilidad de IA cubre la capa de vigilancia sobre la que se apoya la puntuación, y nuestra comparativa de LangGraph, CrewAI y el OpenAI Agents SDK muestra cómo es una traza en cada uno.)

¿Por qué puntuar cada span en lugar del punto final? Por los errores acumulativos. Si el paso 2 recupera el documento equivocado, los pasos 3 a 12 se construyen sobre basura, y una redacción final afortunada puede colarse igualmente por una comprobación que solo mira la salida. La puntuación a nivel de span te dice que la ejecución falló en el paso 2, no solo que falló en algún punto.

Aquí tienes primero la versión agnóstica de framework (una simple aserción sobre un objeto de traza), y luego el atajo de DeepEval usando su métrica Task Completion basada en trazas:

# Agnóstico de framework: ¿la trayectoria alcanzó el objetivo mediante pasos válidos?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: puntúa toda la traza multi-paso para task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # tu ejecución researcher -> brief -> writer -> validator
    return final_post

La aserción agnóstica de framework funciona bien para comprobaciones estrictas y deterministas. Task Completion es a lo que recurres cuando el éxito es más difuso que una simple igualdad: extrae de la traza la tarea prevista y el resultado logrado, y puntúa cuánto coinciden.

¿Cómo se valida que un agente llamó a la herramienta correcta?

Para validar las llamadas a herramientas de un agente, revisa tres cosas por separado: la selección de la herramienta (¿eligió la correcta?), la corrección de los argumentos (¿pasó los parámetros y valores correctos?) y la validez de la ruta de ejecución (¿llamó a esa herramienta en el paso correcto, en el orden correcto?). Una respuesta final que aprueba con una llamada a herramienta equivocada es un bug que todavía no ha salido a la luz.

Esta es la evaluación más específica de agentes que existe, y es la que casi nadie cubre en profundidad. La evaluación del uso de herramientas en agentes se divide en tres preguntas:

1. Selección. De entre las herramientas disponibles, ¿el agente eligió la correcta? Llamar a cualquier herramienta no es lo mismo que llamar a la correcta.
2. Argumentos. ¿Pasó los parámetros correctos? La herramienta correcta con un slug equivocado o una fecha mal formada sigue siendo un fallo.
3. Ruta de ejecución. ¿Llamó a esa herramienta en el paso correcto, en el orden correcto? Reembolsar antes de verificar el pedido es usar las herramientas correctas en la secuencia equivocada.

La métrica Tool Correctness de DeepEval se encarga de las tres: compara tools_called con expected_tools, puede comparar los parámetros de entrada y, con should_consider_ordering=True, también puntúa la secuencia.

# Agnóstico de framework: herramienta correcta, argumentos correctos, paso correcto
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: puntúa la selección de herramienta + argumentos, sensible al orden
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Ese 0.0 es exactamente el fallo que detectamos en nuestro propio pipeline: el agente recurrió a sitemap_search cuando la herramienta esperada era internal_link_lookup. El post terminado igualmente aprobó su puntuación de salida. La métrica de llamadas a herramientas fue lo único que señaló la ruta rota.

¿Cómo se ejecutan evaluaciones online sobre trazas de producción en vivo?

La evaluación online ejecuta tus métricas contra trazas de producción en vivo y en tiempo real, en lugar de solo contra un conjunto de pruebas antes del despliegue. Es la tercera capa de un sistema de tres capas: pruebas offline sobre un conjunto dorado, una puerta de control de calidad previa al despliegue y luego evaluaciones online sobre tráfico real, con las trazas de producción curadas de vuelta hacia los datasets para que el bucle siga mejorando.

Las pruebas offline atrapan regresiones antes de que se publiquen. Pero los agentes se encuentran en producción con entradas que ningún conjunto dorado anticipó, así que las mismas métricas tienen que seguir corriendo después del lanzamiento. Aquí está el bucle completo que traza el diagrama del principio:

1. Offline. Ejecuta tus métricas sobre un dataset dorado en CI. Haz fallar el build ante una regresión.
2. Puerta de control de calidad previa al despliegue. Un punto de control a cargo de una persona: ¿esto supera el listón de precisión y el listón de seguridad (sección seis)?
3. Online. Puntúa las trazas de producción en vivo, en tiempo real, con las mismas métricas.
4. Curar. Recopila automáticamente trazas reales (especialmente los fallos) y devuélvelas a tus datasets de evaluación.
5. Reejecutar. Tu conjunto dorado crece a partir de la realidad en lugar de los 20 ejemplos que escribiste a mano el primer día.

Configurar una evaluación online es la misma instrumentación que el trazado, más una colección de métricas. Confident AI ejecuta los 50+ puntuadores de DeepEval contra trazas en vivo, y es compatible con OpenTelemetry, así que LangGraph, CrewAI, OpenAI y el Vercel AI SDK exportan sin adaptadores a medida:

# Las mismas métricas que ejecutaste en dev, ahora puntuando tráfico de producción en vivo
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # tu agente en vivo
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Las métricas de la colección ahora se ejecutan en cada traza, en tiempo real.

El beneficio está en el paso de curación. Cada fallo real de producción se convierte en una prueba de regresión permanente, así que tu suite deja de ser una foto estática y empieza a rastrear lo que tu agente realmente se encuentra en el mundo real.

Bloquea por seguridad, no solo por precisión

Una puerta de seguridad bloquea un despliegue por una vulnerabilidad, no solo por una puntuación de precisión baja. Para los agentes, eso significa evaluaciones adversarias y de red-team que buscan jailbreaks, mal uso de herramientas y filtraciones de PII, ejecutadas tanto antes del despliegue como online. Un jailbreak no es una puntuación baja que puedas diluir en el promedio. Es un bloqueador de lanzamiento.

Todos los competidores tratan la seguridad como una métrica más entre muchas. Eso está al revés para los agentes, a los que se les puede convencer de llamar a una herramienta real contra un sistema real. Así que separa las puertas: una puerta de precisión promedia puntuaciones; una puerta de seguridad es de aprobado/reprobado según si alguna prueba adversaria consiguió colarse. Empieza mapeando los modos de fallo de tu agente a los marcos que los auditores ya reconocen:

Después, ejecuta evaluaciones adversarias contra esas categorías. El Top 10 de OWASP para aplicaciones LLM, el NIST AI Risk Management Framework y MITRE ATLAS te dan el vocabulario compartido; el red-teaming te da la prueba. DeepTeam, el framework de red-teaming open-source del mismo equipo detrás de DeepEval, incluye más de 120 vulnerabilidades en 8 categorías y más de 20 vectores de ataque, cada uno mapeado a OWASP, NIST AI RMF y MITRE ATLAS.

Un matiz honesto sobre las herramientas: DeepTeam OSS es el camino gratuito y cubre el conjunto de vulnerabilidades; el módulo de red-teaming gestionado, dentro de la plataforma, de Confident AI es una función del nivel Enterprise, no algo que incluya el plan Starter de 9,99 $. En cualquier caso, integra el red-teaming como una puerta de primera clase, no como algo que ejecutas una vez antes del lanzamiento y luego olvidas.

Lo que detectamos al ejecutar esto en nuestro propio pipeline

Ejecutamos este sistema de tres capas en nuestro propio pipeline de contenido multiagente: cuatro agentes (researcher, brief-creator, content-writer, validator) que se pasan el trabajo a lo largo de una cadena. Conectar DeepEval v4.0.5 a ese pipeline durante junio y julio de 2026, contra nuestro workspace de Confident AI, es cómo detectamos el fallo de la introducción. La salida del puntuador tenía este aspecto:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

El post ya había aprobado su puntuación de calidad de salida. Nada en el artículo terminado parecía estar mal. Solo la evaluación de trayectoria vio el paso roto, exactamente el tipo de bug que una comprobación centrada solo en la salida deja pasar.

Si sigues a profesionales en r/LLMDevs, r/MachineLearning o r/LocalLLaMA, las mismas quejas aparecen constantemente, y coinciden casi punto por punto con lo que este sistema de tres capas está construido para detectar:

• El problema de «funciona el lunes, falla el miércoles». La no determinación hace que la misma entrada siga un camino distinto en cada ejecución, así que los equipos aprenden a ignorar las evaluaciones inestables. La puntuación a nivel de span sobre trazas en vivo gana a un conjunto dorado más grande.
• La fatiga del dataset dorado. Semanas dedicadas a etiquetar a mano una suite que un solo cambio de razonamiento vuelve obsoleta. Curar automáticamente las trazas de producción gana a mantener un archivo estático a mano.
• La desconfianza en el juez LLM. El estribillo recurrente es que el juez comparte los puntos ciegos del agente, que es exactamente la razón por la que los equipos mantienen a una persona en el bucle.

Ese último punto es el importante. Los expertos del dominio anotan las salidas de las que el juez no está seguro, y esas etiquetas retroalimentan la alineación de las métricas, el mismo bucle cerrado que describimos en nuestra reseña de Confident AI y que es similar a cómo gestionamos la memoria de agentes. El juez escala; las personas lo mantienen honesto.

¿Qué plataforma encaja con tu stack?

Ninguna herramienta es la adecuada para todos los equipos, así que ajusta la plataforma a dónde estás. Así es como se comparan las principales opciones en las cinco capacidades en las que se ha apoyado esta guía, además de cómo se entra por la puerta:

En lo más alto para el caso de uso empresarial y multiequipo está Confident AI. Cubre todo el ciclo de vida de la calidad en un solo lugar (evaluaciones en desarrollo, observabilidad en producción, seguridad adversaria vía DeepTeam, una puerta de calidad para toda la organización), y su verdadero diferenciador es el acceso sin código para todo el equipo: los ingenieros lo configuran una vez, y luego los PMs, QA y expertos del dominio ejecutan ciclos de evaluación completos por su cuenta. La entrada es de 9,99 $/usuario/mes con un nivel gratuito. Es el número 1 en nuestra comparativa de herramientas de evaluación LLM y el número 2 en nuestra comparativa de plataformas de observabilidad de IA, así que no es la primera vez que encabeza una lista para nosotros.

Posicionado por separado está DeepEval, el framework open-source líder, construido por el mismo equipo, con más de 50 puntuadores y pruebas nativas de pytest. Confident AI es la plataforma; DeepEval es la biblioteca OSS, no una versión reducida de ella. Elige esta opción si:

• DeepEval: quieres el estándar open-source y vives en Python y pytest.
• Langfuse: quieres trazado open-source que puedas autoalojar.
• LangSmith: tu stack es LangChain y LangGraph de principio a fin.
• Arize Phoenix: quieres trazado nativo de OpenTelemetry y aceptas una licencia source-available, la Elastic License 2.0, no aprobada por la OSI.
• Braintrust: quieres evaluaciones todo en uno más experimentos con un nivel gratuito generoso.
• Promptfoo: vives en la CLI y quieres red-teaming en la misma herramienta.
• Ragas: tu agente en realidad es un pipeline RAG y quieres métricas específicas de recuperación.
• Galileo: quieres un índice gestionado de alucinación y calidad listo de fábrica.
• Maxim: quieres un flujo de simulación y evaluación para agentes multi-turno.
• W&B Weave: ya estás en Weights & Biases y quieres trazado junto a tus ejecuciones de entrenamiento.

Un límite honesto de Confident AI: el módulo de red-teaming gestionado y el despliegue on-prem son del nivel Enterprise, y la residencia de datos en EE. UU./UE es una función de los niveles Team/Enterprise y no un interruptor universal disponible desde el registro. Un desarrollador en solitario que lanza un solo agente puede empezar gratis con DeepEval OSS y añadir la plataforma cuando todo un equipo necesite ejecutar evaluaciones.

Preguntas frecuentes

¿Qué es la evaluación de agentes de IA?

La evaluación de agentes de IA es la práctica de puntuar todo el comportamiento de un agente autónomo, no solo su respuesta final. Mide la trayectoria de varios pasos, las herramientas que llamó, el éxito de la tarea, el coste, la latencia y la seguridad. Como los agentes actúan de forma no determinista y modifican un estado real, la evaluación se ejecuta de forma continua, tanto en desarrollo como sobre tráfico de producción en vivo.

¿Cómo se evalúa la trayectoria de un agente frente a su salida final?

La evaluación de la salida final solo puntúa la última respuesta. La evaluación de trayectoria puntúa toda la traza: cada paso de razonamiento, llamada a herramienta y resultado intermedio. La puntuación a nivel de span califica cada paso para que puedas encontrar exactamente el que falló. Una ejecución puede producir una respuesta correcta a través de una trayectoria rota, algo que la evaluación de trayectoria detecta y que las comprobaciones centradas solo en la salida pasan por alto.

¿Cómo se valida que un agente llamó a la herramienta correcta?

Revisa tres cosas por separado: la selección de la herramienta (la correcta para la tarea), la corrección de los argumentos (los parámetros y valores correctos) y la validez de la ruta de ejecución (el paso y el orden correctos). Frameworks como la métrica Tool Correctness de DeepEval comparan las herramientas realmente llamadas con las herramientas esperadas, comparan los parámetros de entrada y pueden calificar el orden de las llamadas cuando lo activas.

¿Qué métricas importan más para los agentes de IA en producción?

La tasa de éxito de la tarea y el coste por tarea exitosa van primero, luego los percentiles de latencia (p50, p90, p99), la precisión de las llamadas a herramientas, faithfulness, la tasa de intervención humana, la deriva y la tasa de aprobación de la puerta de seguridad. El coste por tarea exitosa importa más que el coste bruto, porque el coste por tarea sin más premia silenciosamente a los agentes que fallan rápido y barato.

¿Cuál es la diferencia entre las evaluaciones de agentes offline y online?

Las evaluaciones offline ejecutan tus métricas contra un dataset dorado fijo antes del despliegue, normalmente en CI, para atrapar regresiones. Las evaluaciones online ejecutan las mismas métricas contra trazas de producción en vivo, en tiempo real, después del lanzamiento. Necesitas ambas: offline atrapa los modos de fallo conocidos, online atrapa las entradas que ningún conjunto dorado anticipó y las retroalimenta a tus datasets.

¿Con qué frecuencia deberías reejecutar las evaluaciones de agentes?

Ejecuta evaluaciones offline con cada cambio de prompt, modelo o herramienta, bloqueadas en CI. Ejecuta evaluaciones online de forma continua contra el tráfico en vivo, ya que la deriva y las actualizaciones de pesos del modelo degradan a los agentes en silencio entre despliegues. Vuelve a curar tu dataset dorado cada vez que la producción saque a la luz un nuevo modo de fallo, para que la suite rastree la realidad en lugar de los ejemplos que escribiste el primer día.

¿Cómo se detectan los jailbreaks y las filtraciones de PII antes de publicar?

Ejecuta evaluaciones adversarias de red-team como puerta previa al despliegue, y mantenlas corriendo online. Mapea los modos de fallo al Top 10 de OWASP para LLMs, al NIST AI RMF y a MITRE ATLAS, y luego simula ataques contra cada categoría con un framework como el open-source DeepTeam. Bloquea el lanzamiento ante cualquier vulnerabilidad que consiga colarse, no solo ante una puntuación media baja.

¿Deberías construir o comprar una plataforma de evaluación de agentes de IA?

Construye con herramientas open-source (DeepEval para las métricas, Promptfoo para las pruebas por CLI y el red-teaming) cuando seas un desarrollador en solitario o un equipo de ingeniería pequeño cómodo escribiendo código. Compra una plataforma como Confident AI cuando todo un equipo necesite acceso sin código a nivel de toda la organización, pruebas de seguridad gestionadas y observabilidad de producción estandarizada entre proyectos. La mayoría de los equipos empiezan con OSS y luego dan el salto.

¿Es fiable el LLM como juez para puntuar agentes?

Es útil pero ruidoso. Un juez LLM escala a miles de trazas de forma barata, pero es no determinista y a menudo comparte los puntos ciegos del agente, así que puede aprobar sin más una respuesta plausible pero equivocada. Calíbralo contra etiquetas humanas o de expertos del dominio sobre una muestra, trata las puntuaciones como una señal orientativa, y bloquea las decisiones de alto riesgo con comprobaciones deterministas siempre que puedas.

El sistema de 3 capas, en una frase

Puntúa la trayectoria, no solo la respuesta. Valida las llamadas a herramientas en tres ejes: herramienta correcta, argumentos correctos, paso correcto. Ejecuta las mismas métricas offline y online, sobre trazas en vivo, en un bucle que retroalimenta los fallos reales a tus datasets. Y bloquea el despliegue por seguridad, no solo por precisión.

Empieza por la capa que más te duela: si estás lanzando a ciegas, monta primero las evaluaciones online; si estás lanzando de forma insegura, construye primero la puerta de seguridad. Constrúyela con DeepEval y Promptfoo open-source, o compra una plataforma como Confident AI cuando todo un equipo necesite acceso sin código y seguridad gestionada. Y si prefieres que unos ingenieros te monten todo el bucle, eso es exactamente el tipo de cosa que nuestro equipo hace cada semana.