Cómo Mido si un Agente de IA Realmente Está Funcionando

Tabla de contenidos

Actualizado mayo 2026.

TL;DR: La mayoría de los operadores omiten las evaluaciones por completo y simplemente asumen que sus agentes funcionan. Mi framework: construir un golden set de 5–10 inputs conocidos con outputs esperados, definir criterios de pase/fallo en lenguaje natural, y revisar los logs semanalmente. No construyas un sistema de evaluación elaborado antes de tener 10 ejecuciones reales — esa es la trampa que mata el impulso.

[Lectura del operador] Ejecuto más de 30 agentes de IA en producción en mi marca de consultoría y en Pickleland, una instalación de pádel americano en Pflugerville, TX. En algún momento me di cuenta de que pasaba más tiempo preocupándome por si los agentes estaban derivando que usándolos realmente. Este es el framework de evaluación al que llegué — sin doctorado, sin plataforma de evaluación personalizada, sin Python.

El problema del que nadie habla: los agentes derivan silenciosamente

Cuando un empleado humano empieza a hacer su trabajo mal, normalmente te das cuenta. Cuando un agente de IA empieza a producir basura, sigue produciendo basura — en silencio, a escala, hasta que algo falla lo suficientemente mal como para que un humano finalmente lo vea.

He tenido un agente de contenido que empezó a añadir descargos de responsabilidad “Como modelo de lenguaje de IA” después de una actualización del modelo. He tenido un agente promotor de eventos que dejó de incluir enlaces de entradas porque cambió el nombre de una variable en el prompt. Ninguno falló ruidosamente. Ambos simplemente se degradaron.

La solución no es construir un sistema de monitoreo de nivel NASA. Es tener una verificación simple y repetible que detecte la deriva antes de que se acumule.

Qué es realmente una evaluación (para operadores)

Los ingenieros usan la palabra “eval” para referirse a ejecutar un benchmark en un modelo. Para los operadores, me refiero a algo más simple: una prueba repetible que te dice si tu agente sigue haciendo lo que construiste que hiciera.

Tres componentes:

1. Golden set — 5–10 inputs reales que ya has visto, con outputs esperados que ya sabes que son buenos
2. Criterios de pase/fallo — reglas en lenguaje natural que definen qué cuenta como pasar
3. Una verificación programada — tú o tu asistente realmente ejecuta la prueba con cierta cadencia

Eso es todo. No necesitas un framework. Necesitas disciplina.

Construyendo tu golden set

Extrae de tus logs de producción. Encuentra 5–10 inputs reales donde ya sabes cómo se ve un buen output. Estos son tu verdad de base.

Para mi agente de pipeline de contenido, el golden set son 5 posts publicados que pasaron mi checklist de voz cuando los escribí manualmente. Para mi promotor de eventos de Pickleland, son 5 posts pasados de Facebook que tuvieron un engagement superior al promedio (comentarios + compartidos, no solo likes).

Reglas para un buen golden set:

• Inputs reales, no hipotéticos que inventaste
• Incluye al menos un caso límite (un input complicado, uno corto, uno con formato inusual)
• Mantén los outputs esperados documentados — una captura de pantalla, un archivo de texto, una fila en una hoja de cálculo
• Nunca elimines del golden set; solo agrega

Cuando el agente fue confirmado por última vez que funcionaba, escribe exactamente cómo se veía “bueno”. Eso se convierte en tu output esperado.

Definiendo criterios de pase/fallo

Los criterios vagos son inútiles. “El output debería ser bueno” pasará siempre porque lo racionalizarás.

Escribe tus criterios como ítems de checklist que un no-experto podría evaluar. Aquí están los criterios reales que uso para mi agente de pipeline de contenido:

Checklist de pase/fallo del agente de contenido:

• El post tiene un TL;DR en las primeras 100 palabras
• Sin frases como “en el vertiginoso mundo actual” o “Como IA”
• Al menos un número concreto o estadística
• El número de palabras está entre 800 y 2000
• Todos los enlaces internos resuelven (sin errores 404)

Para el promotor de eventos de Pickleland:

Checklist de pase/fallo del promotor de eventos:

• El nombre del evento coincide con el calendario fuente
• La fecha y hora son correctas
• El enlace de entradas está presente y no está roto
• El copy tiene menos de 280 palabras
• El post no usa frases genéricas de relleno (“¡Ven a unirte a nosotros para pasar un buen rato!”)

Si 4 de 5 ítems de la checklist pasan, la ejecución es un pase. Si 3 o menos pasan, es un fallo e investigo antes de la próxima ejecución.

Usando Claude como juez

Para agentes donde los outputs son largos o complejos, uso Claude Sonnet como juez automatizado. Esto es más rápido que la revisión manual y detecta cosas que yo pasaría por alto.

Aquí está el prompt de juez que uso para el agente de contenido:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

Ejecuto esto como un Cloudflare Worker que extrae el último borrador, lanza este prompt y escribe el resultado en una Google Sheet. Todo el proceso toma 8 segundos y cuesta aproximadamente $0.003 por ejecución.

Para el promotor de eventos, el prompt del juez es más simple:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

Dónde buscar: logs de Cloudflare Worker

Si ejecutas agentes en Cloudflare Workers (lo cual hago para la mayoría de mis agentes ligeros), el log tail incorporado es tu mejor amigo. No necesitas un servicio de logging de terceros para empezar.

Qué reviso en las revisiones semanales puntuales:

• Errores y excepciones — cualquier cosa que se bloqueó o agotó el tiempo
• Recuentos de tokens — si una ejecución repentinamente usa 3 veces los tokens normales, algo cambió
• Picos de latencia — una ralentización repentina generalmente significa que el prompt se alargó o el modelo está teniendo problemas
• Deriva en la longitud del output — si el promedio de output pasó de 600 palabras a 200 palabras, el agente cambió de comportamiento

Paso 15 minutos cada lunes por la mañana en esto. Tengo una checklist simple en Notion: abrir logs para cada agente, anotar cualquier anomalía, comparar el uso de tokens con la línea base de la semana pasada. Ese es todo el proceso.

La evaluación en hoja de cálculo: fea pero funciona

Antes de tener cualquier automatización, ejecutaba evaluaciones en una Google Sheet. Todavía la uso para agentes nuevos en las primeras 4 semanas.

Estructura:

Cinco filas por semana. Toma 10 minutos. Si tienes dos fallos seguidos, detienes el agente y corriges el prompt antes de continuar.

Esto es vergonzosamente de baja tecnología. También es así como detecté tres regresiones de prompt antes de que llegaran a producción.

Qué NO hacer

No construyas el sistema de evaluación antes de tener 10 ejecuciones reales. He visto a fundadores pasar dos semanas construyendo un pipeline de evaluación sofisticado para un agente que solo han ejecutado dos veces. No sabes suficiente sobre cómo se ve “bueno” hasta que tienes datos reales de producción.

No evalúes con inputs sintéticos que inventaste. Los casos de prueba sintéticos se pierden los casos límite extraños que la producción te lanza. Siempre empieza con logs reales.

No evalúes todo. Elige los 3–5 agentes donde el fallo realmente dolería — outputs dirigidos a clientes, cualquier cosa que publique públicamente, cualquier cosa que active un pago. Omite los agentes utilitarios internos hasta que tengas espacio mental.

No automatices demasiado pronto. Una hoja de cálculo que realmente uses supera a un dashboard de Datadog que olvidas revisar. Empieza manual, automatiza después de haber ejecutado la verificación 10 veces y saber qué estás buscando realmente.

La conclusión del operador

Las evaluaciones no tienen que ser de nivel ingeniería para ser útiles. Un golden set de 5–10 inputs reales, una checklist de criterios de pase/fallo, y 15 minutos de revisión de logs cada lunes detectarán el 80% de la deriva de agentes antes de que se acumule. Empieza ahí. Si todavía estás ejecutando agentes sin ninguna evaluación, vuelas a ciegas — y eventualmente algo fallará lo suficientemente públicamente como para que desearas haber dedicado los 20 minutos.