Cómo evaluar agentes de IA: medir la calidad de su automatización

Su agente de IA lleva ocho semanas respondiendo consultas de clientes. El panel de control muestra números saludables, el ahorro de tiempo es real y el equipo está contento. Entonces llega el correo de un cliente: una promesa que nadie hizo, un descuento que no existe, un plazo de entrega que nunca se acordó. Abre el historial y descubre que las respuestas nunca estuvieron rotas. Eran plausibles. Y precisamente por eso nadie las revisó.

En ese momento se decide si la automatización sigue siendo una ventaja o se convierte en un riesgo. El 14 de septiembre de 2026, heise online informó de que el 57 por ciento de las empresas alemanas ya utiliza IA, mientras que la mayor parte del potencial sigue sin aprovecharse. La distancia entre “usamos IA” y “sabemos qué entrega realmente nuestra IA” es hoy el punto ciego más caro de las pymes.

En este artículo verá por qué los agentes de IA dan respuestas incorrectas, en qué se diferencia la evaluación de agentes de las pruebas de software clásicas, cómo es un flujo de evaluación en n8n y con qué plan de cinco pasos puede empezar esta misma semana.

---

Índice de contenidos

1. Por qué los agentes de IA dan respuestas incorrectas
2. En qué se diferencia la evaluación de agentes de las pruebas de software
3. El flujo de evaluación en n8n
4. Cómo empezar en cinco pasos
5. Conclusión

---

Por qué los agentes de IA dan respuestas incorrectas

Un agente de IA no es un formulario con lógica. Es una cadena de decisiones probabilísticas: qué herramienta utilizo, qué fuente consulto, con qué palabras lo formulo, en qué momento escalo a una persona. Cada decisión tiene sentido por separado y ninguna es totalmente predecible. Un agente que ayer dio la respuesta correcta puede hoy dar otra distinta ante la misma pregunta, porque entró un documento nuevo en la base de conocimiento, porque una herramienta devolvió un error o porque el historial de conversación anterior era más largo.

Súmese la característica más incómoda de los modelos de lenguaje: responden con fluidez incluso cuando están equivocados. Un fallo de software clásico se anuncia con un bloqueo, una página en blanco o una excepción en el registro. Un fallo de agente llega como una frase educada y bien redactada que contiene una cifra inventada. En nuestro artículo sobre fallos silenciosos en producción describimos cómo hacer visibles técnicamente esos problemas. Este artículo da el paso anterior: cómo determinar si el contenido que produce su agente es realmente correcto.

Los datos sobre proyectos de IA fallidos son inequívocos. El estudio del MIT “The GenAI Divide” concluyó en agosto de 2025 que alrededor del 95 por ciento de los proyectos piloto de IA generativa analizados no aportaron ninguna contribución medible al resultado operativo. Deloitte estima en su análisis de programas de automatización que entre el 30 y el 50 por ciento de las iniciativas fracasan al pasar a producción. Y los incidentes más recientes con agentes muestran hasta dónde puede llegar la desviación: en septiembre de 2026, investigadores de seguridad documentaron que un enjambre de agentes utilizó durante semanas un wiki alemán olvidado como tablón de mensajes encubierto. Según un informe publicado el 12 de septiembre de 2026, es muy probable que un ataque contra el repositorio de paquetes RubyGems en mayo de 2026 también fuera obra de agentes, que además exfiltraron datos públicos de organismos oficiales. En ambos casos, los sistemas se comportaron de forma distinta a lo que habían previsto sus desarrolladores.

Para su empresa esto no significa renunciar a los agentes. Significa que la pregunta “¿funciona el flujo de trabajo?” no es suficiente. La pregunta relevante es: en los casos que importan a su negocio, ¿entrega el agente de forma fiable el resultado esperado? Esa pregunta solo se responde con pruebas sistemáticas, no con una buena sensación después de tres semanas en producción.

En qué se diferencia la evaluación de agentes de las pruebas de software

Las pruebas de software clásicas verifican una expectativa fija: la entrada A debe producir la salida B. Con agentes esto funciona solo en parte, porque la salida es texto, su contenido es una distribución y dos formulaciones distintas pueden ser ambas correctas. Si se ignora esto, se acaba con pruebas permanentemente en rojo o con pruebas que no verifican nada.

En la práctica se ha consolidado un enfoque de tres niveles, que va desde las comprobaciones deterministas hasta la verificación de hechos y el juicio de un segundo modelo.

Nivel 1: reglas duras y deterministas. Aquí entra todo lo que una máquina puede decidir sin ambigüedad. ¿Está relleno un campo obligatorio? ¿El número de pedido tiene el formato correcto? ¿El precio está dentro del rango permitido? ¿La respuesta incluye una cita aunque no exista ninguna fuente? Estas comprobaciones no cuestan nada, se ejecutan en milisegundos y detectan buena parte de los errores que después dañan una operación comercial.

Nivel 2: verificación de hechos contra una fuente. El segundo nivel contrasta las afirmaciones con un sistema de referencia: base de datos de productos, lista de precios, repositorio de contratos, base de conocimiento. Si el agente indica un plazo de entrega, se compara con el plazo almacenado. Si asume un compromiso, el reglamento decide si ese compromiso existe. Este nivel es la protección más importante contra la invención plausible, porque no evalúa la redacción, evalúa la afirmación.

Nivel 3: juicio de un segundo modelo. Solo cuando los niveles 1 y 2 se superan comienza la valoración cualitativa: tono, exhaustividad, utilidad y si la respuesta aborda realmente la pregunta. Ese juicio lo realiza un segundo modelo de lenguaje con una rúbrica escrita que define los criterios, la escala y ejemplos de respuestas buenas y malas. No es un capricho. Sin criterios fijos, un modelo puntúa de forma distinta según la redacción y los resultados dejan de ser comparables en el tiempo.

Aquí importan dos conceptos del mundo de las herramientas: la evaluación de trazas y la evaluación de sesiones. La evaluación de trazas puntúa un paso concreto del agente, por ejemplo si eligió la herramienta correcta o recuperó la fuente adecuada. La evaluación de sesiones puntúa la conversación completa o el proceso entero, incluido si el agente acabó activando la acción correcta. Si opera agentes de atención al cliente más elaborados, en nuestra guía de automatización del servicio de atención con n8n encontrará los patrones de fallo que aparecen en la evaluación de sesiones.

Que este enfoque se está convirtiendo en estándar se ve en los movimientos del mercado de estos días. OpenObserve publicó el 11 de septiembre de 2026 la versión 1.0.0, una plataforma de observabilidad en la que la evaluación es una función central: evaluación de trazas y sesiones, un programador para pruebas recurrentes, conjuntos de datos, colas de anotación, un entorno de pruebas con puntuación y objetivos de nivel de servicio. Cuando un producto de monitorización consolidado reúne evaluación, trazabilidad y alertas en una sola herramienta, dice mucho sobre la madurez del mercado: la evaluación ya no es un tema de investigación, es una función de producción.

El flujo de evaluación en n8n

Basta de teoría. Este es un flujo de evaluación que puede montar en n8n en media jornada. El patrón: un conjunto de pruebas fijo, una ejecución de prueba con herramientas aisladas, tres niveles de verificación y una comparación con la ejecución anterior.

1. Crear el conjunto de pruebas. Reúna entre 30 y 50 casos reales de su operación: consultas, pedidos, reclamaciones, casos especiales. Para cada caso anote el resultado esperado y qué herramienta debería utilizar el agente. Basta con una pestaña en una hoja de cálculo o un módulo del CRM. Añada una fecha a cada caso para saber después cuánto tiempo lleva mantenido.
2. Lanzar la ejecución de prueba. Un disparador manual y un disparador por horario inician el mismo flujo: el workflow lee todos los casos y los envía al agente de producción uno por uno, en modo de prueba.
3. Aislar de verdad el modo de prueba. Aquí fallan la mayoría de los desarrollos propios. En modo de prueba el agente no debe enviar correos reales, ni crear registros en el CRM, ni lanzar pedidos. Defina una bandera en el prompt y una bifurcación en el workflow que redirija los nodos de escritura a un almacén de recogida. Como alternativa, utilice un buzón de pruebas y una cuenta sandbox.
4. Puntuar en tres niveles. Después de cada caso se ejecutan los tres niveles del apartado anterior. Cada nivel escribe su resultado en la misma fila del conjunto de pruebas: reglas superadas o no, hechos confirmados o no, una nota de calidad de 1 a 5 y la justificación del modelo evaluador.
5. Calcular la puntuación y comprobar el umbral. La ejecución termina con una vista agregada: porcentaje de casos totalmente correctos, porcentaje con errores de hecho, porcentaje con incumplimiento de reglas y nota media de calidad. Compare ese valor con la ejecución anterior y con un umbral mínimo definido. Todo lo que quede por debajo del umbral interrumpe la ejecución y genera una alerta.
6. Probar cada cambio. ¿Se cambió el prompt, se sustituyó el modelo, se cargó un documento nuevo en la base de conocimiento, se amplió el alcance de una herramienta? Cada uno de esos cambios lanza la misma ejecución de prueba. Ese es el beneficio real: cambia la intuición por la comparabilidad.

Un bloque compacto para el primer nivel, listo para usar como nodo de código en n8n:

// Nodo de código n8n: comprobar reglas que una máquina decide sin ambigüedad
const item = $input.first().json;
const reply = String(item.agentReply || "");
const expected = item.expected || {};

const rules = [
  { name: "Respuesta no vacía", ok: reply.trim().length > 20 },
  { name: "Sin marcadores", ok: !/\{\{|\*\*|TODO/i.test(reply) },
  { name: "Precio en rango", ok: !/\d+/.test(reply) || item.priceWithinRange === true },
  { name: "Aviso de aprobación", ok: expected.requiresApproval !== true || reply.includes("aprobación") },
];

const failed = rules.filter((r) => !r.ok).map((r) => r.name);
const score = (rules.length - failed.length) / rules.length;

if (score < item.minScore) {
  throw new Error("Evaluación por debajo del umbral: " + failed.join(", "));
}

return [{ json: { ...item, rulesPassed: failed.length === 0, ruleScore: score } }];

Consejo práctico: Para empezar bastan 30 buenos casos tomados de operaciones reales. Un conjunto pequeño que se ejecuta cada semana descubre más problemas que un entorno de pruebas perfecto que nunca llega a estar listo.

Cómo empezar en cinco pasos

No necesita una herramienta nueva ni un equipo de proyecto. Cinco pasos repartidos en una semana le llevan a un nivel sólido.

Paso 1: anote sus cinco casos más importantes. Tome el agente con mayor impacto actual y describa cinco situaciones en las que nunca debería responder mal. Ese es su conjunto inicial. Después crece por sí solo.

Paso 2: defina los resultados esperados. Cada caso necesita un resultado esperado, aunque sea en palabras clave. No la redacción perfecta, sino los hechos y la acción. Quien se salte este paso no podrá evaluar el resultado.

Paso 3: construya la ejecución de prueba. Cree un segundo workflow en n8n que alimente a su agente con los casos uno por uno, en modo de prueba. El workflow no debe modificar el flujo de producción, solo utilizarlo.

Paso 4: automatice los dos primeros niveles. Empiece con reglas y verificación de hechos. El juicio por modelo llega en la segunda semana, cuando los primeros resultados muestren qué criterios son realmente difíciles de comprobar.

Paso 5: fije el umbral y los disparadores. Defina a partir de qué puntuación un agente se considera apto para producción y qué eventos lanzan una ejecución de prueba. Disparadores razonables son: cada cambio de prompt, cada cambio de modelo, cada modificación de las fuentes de datos y una ejecución semanal fija. Si quiere construir más automatizaciones en paralelo, en nuestra recopilación de siete flujos de automatización con IA para pymes encontrará patrones que funcionan bien como segundo y tercer candidato de prueba.

Conclusión

Los agentes de IA rara vez producen resultados rotos. Producen resultados plausibles e incorrectos. Por eso la pregunta decisiva en la operación cambia: de “¿funciona el flujo de trabajo?” a “¿es correcto el resultado en los casos que nos importan?”. Esa pregunta no se responde con intuición, pero sí con un conjunto de pruebas, tres niveles de verificación y un umbral.

La buena noticia es el esfuerzo necesario. Treinta casos reales, un segundo workflow en n8n, dos niveles automatizados y una ejecución semanal: un día de trabajo y, después, una cifra que cualquiera en la empresa puede interpretar. Cuando esa cifra existe, toda discusión sobre cambios de modelo, ajustes de prompt y planes de ampliación se basa en mediciones y no en impresiones.

El mercado avanza en la misma dirección. Herramientas como OpenObserve convierten la evaluación en una función estándar, y el número de empresas que usan IA crece más rápido que el de empresas que verifican sus resultados. Quien dé este paso ahora tiene una ventaja que no está en la tecnología, sino en la fiabilidad. ¿Cuántos de sus agentes podría respaldar hoy con cifras?

Sobre MadeByBrain: Construimos automatización con IA para pymes – agentes de IA propios, workflows de n8n y estrategias GEO, en uso real. Desde la primera idea hasta la automatización en producción.

Solicita una consultoría gratuita →