Una automatización puede parecer impecable durante varios días y fallar precisamente cuando encuentra un caso poco habitual: una página que tarda en cargar, un enlace que cambia de destino, una instrucción contradictoria o una tarea que se ejecuta dos veces. Por eso, cuando un agente de inteligencia artificial empieza a trabajar para un negocio, no basta con contar las acciones completadas. Hay que medir si hizo lo correcto, con las herramientas apropiadas y sin provocar efectos secundarios.
La evaluación sistemática de agentes permite convertir la impresión de «parece que funciona» en resultados comparables. También facilita descubrir errores antes de que afecten a clientes o contenidos públicos. El objetivo no es producir una puntuación vistosa, sino obtener pruebas útiles para mejorar decisiones concretas.
Qué significa evaluar un agente de inteligencia artificial
Evaluar consiste en presentar al sistema tareas con criterios conocidos, observar su comportamiento y contrastarlo con el resultado esperado. En un chatbot sencillo quizá interese principalmente la respuesta final. En un agente con herramientas también importa el recorrido: qué datos consultó, qué operación realizó, si necesitó permisos adicionales y si comprobó el resultado.
La documentación oficial de evaluación de flujos de agentes de OpenAI describe el uso de trazas, evaluadores, conjuntos de casos y ejecuciones de prueba para observar el comportamiento extremo a extremo. Estas herramientas ayudan a identificar regresiones tras cambiar un modelo, una instrucción o una integración.
1. Definir el éxito antes de empezar a probar
Una orden como «publica un artículo» parece concreta, pero admite interpretaciones muy diferentes. ¿Debe tener enlaces internos? ¿Qué ocurre si ya existe una entrada para esa franja? ¿Es obligatorio subir imagen? ¿Se considera completo si WordPress responde correctamente pero la URL pública falla?
La evaluación debe resolver esas dudas por adelantado. Un ejemplo de criterio verificable sería: «existe una única entrada publicada con el título esperado, una URL pública accesible, imagen destacada, contenido íntegro y exactamente cuatro enlaces internos válidos». Otro podría ser: «si ya existe una publicación válida, no crear duplicados».
Cuanto más observable sea el criterio, menos espacio habrá para conclusiones optimistas que no se correspondan con la realidad.
2. Separar calidad del resultado y calidad del proceso
Una respuesta final puede ser correcta por casualidad mientras el proceso empleó datos equivocados. También puede ocurrir lo contrario: el agente ejecutó correctamente varias comprobaciones y se encontró con un bloqueo de autenticación que exige intervención humana.
Conviene evaluar, como dimensiones distintas, exactitud, utilidad, seguridad, cumplimiento de instrucciones, uso de herramientas, recursos consumidos y capacidad para recuperarse de fallos.
Si un agente afirma «publicación completada» pero no puede entregar una URL real, la ejecución no debería considerarse terminada. Si una red social comunica ERROR mientras devuelve una dirección pública y explica que falló solo la miniatura, la pieza principal puede estar publicada con una incidencia accesoria. Las etiquetas deben reflejar esa diferencia.
3. Guardar trazas: qué sucedió en cada paso
Una traza es la secuencia observable de operaciones de una ejecución. Puede incluir solicitudes al modelo, respuestas, llamadas a herramientas, comprobaciones de seguridad y cambios entre componentes. Resulta especialmente útil cuando los fallos aparecen después de varios pasos y no se reproducen con facilidad.
Por ejemplo, un agente que revisa un producto afiliado podría dejar constancia de la ficha consultada, el enlace recuperado, el borrador elegido, la respuesta de WordPress y la verificación pública posterior. No debería guardar contraseñas, cookies de sesión ni claves secretas.
La traza de la automatización tampoco equivale necesariamente al historial completo del proveedor. Para investigar cambios de estado en una plataforma hacen falta, cuando estén disponibles, datos de auditoría independientes que indiquen quién modificó la configuración.
4. Preparar conjuntos de pruebas representativos
Las pruebas no deben incluir únicamente ejemplos fáciles. Si el agente se dedica a publicar contenidos, conviene mezclar artículos nuevos, borradores interrumpidos, entradas ya publicadas, imágenes que no se pueden descargar y respuestas ambiguas después de un tiempo de espera.
En un agente comercial podrían incluirse enlaces correctos, productos de nombre parecido, condiciones que han cambiado y páginas de compra inaccesibles. La respuesta apropiada ante una limitación puede ser «no verificable», no una afirmación de disponibilidad o cierre.
OpenAI describe la creación de conjuntos de datos para evaluar instrucciones y respuestas. La utilidad de estos ejemplos está en repetirlos de forma comparable cuando se modifica el sistema.
5. Medir fallos por gravedad, no solo por cantidad
No tiene el mismo impacto un error tipográfico en una descripción que publicar dos veces el mismo vídeo o enviar información a un destinatario equivocado. Por eso, además de contar errores, conviene clasificarlos por gravedad y reversibilidad.
Una posible escala práctica distingue incidentes cosméticos, problemas de contenido, fallos de publicación y riesgos de seguridad o pago. Los primeros pueden corregirse de forma no destructiva; los últimos deben detener la acción afectada y solicitar autorización cuando corresponda.
La clasificación no debe convertirse en un pretexto para ocultar errores: una miniatura fallida puede ser secundaria para la publicación, pero sigue mereciendo un registro fiel.
6. Medir la recuperación tras interrupciones
Muchas automatizaciones no fallan durante la redacción, sino al guardar, subir archivos o consultar un servicio externo. Un buen diseño conserva identificadores y puntos de control para retomar sin repetir costes o generar objetos duplicados.
Imagina que se crea un borrador, se sube su imagen y el último cambio de estado devuelve un error de conexión. Antes de repetir la publicación, el agente debe leer la entrada original: quizá el cambio ya se aplicó. Si lo vuelve a intentar creando otra entrada, un error temporal acaba convirtiéndose en un problema editorial.
Los criterios de recuperación deberían especificar siempre qué se puede reintentar, qué objeto debe conservarse, cuántos intentos se permiten y cómo verificar el estado final.
7. Evaluar los costes y la intervención necesaria
Un agente que completa una tarea consumiendo tres veces más créditos de los previstos puede ser técnicamente eficaz y económicamente poco conveniente. En un negocio pequeño interesa medir coste por pieza correctamente publicada, tiempo hasta la entrega y cuántas veces hay que intervenir manualmente.
Para vídeos generados con inteligencia artificial, separar generación, locución, montaje, subida y distribución ayuda a encontrar el cuello de botella. Si falla la subida, lo normal es recuperar el archivo existente, no volver a pagar por producir el vídeo.
Para quienes estén valorando formación comercial, puede servir como referencia nuestra reseña del Sistema AMD de marketing digital y el análisis de Inteligencia Artificial para Todos. Antes de pagar conviene definir qué habilidades concretas se desean obtener y cómo se comprobará que se han aprendido. Son artículos de análisis comercial, no certificaciones de resultados.
8. Incluir pruebas adversarias y de permisos
Una ejecución puede recibir instrucciones válidas del propietario y también texto externo manipulador. Los casos de prueba deben comprobar si el agente mantiene separadas ambas clases de contenido, incluso cuando los documentos externos parecen contener órdenes urgentes.
El artículo sobre inyección de instrucciones y sus siete controles explica los principios de seguridad de esa frontera. También resulta útil entender cómo la recuperación RAG puede aportar documentos relevantes sin convertir automáticamente esos documentos en instrucciones autorizadas.
Qué métricas merece la pena seguir
Para un sistema de publicaciones, las métricas de control pueden dividirse en cuatro grupos:
- Cobertura: porcentaje de piezas previstas con publicación pública real y su URL.
- Calidad: artículos completos, enlaces válidos, originalidad y presencia de imagen; vídeos con audio y formato adecuados.
- Robustez: reintentos que no producen duplicados, recuperación de borradores, continuidad de los horarios y registro de incidencias.
- Negocio: visitas cualificadas, clics en enlaces afiliados, contactos interesados y ventas verdaderamente verificadas.
La cuarta categoría es especialmente importante. Publicar más no implica vender más. Un sistema puede alcanzar el cien por cien de sus entregas y seguir sin convertir tráfico en ingresos. Por eso la evaluación técnica y la evaluación comercial deben convivir sin mezclarse.
Cómo introducir evaluaciones sin construir una plataforma compleja
Una pequeña empresa puede empezar con una hoja de cálculo o un documento de control. Se registran veinte ejemplos representativos, los resultados esperados, la fecha de ejecución, los fallos y una clasificación de gravedad. Cada cambio relevante del sistema se compara con esos mismos ejemplos.
Cuando exista suficiente volumen, las trazas automáticas y los evaluadores permiten ampliar la cobertura. Antes de invertir en herramientas avanzadas merece la pena preguntarse si las pruebas actuales detectan realmente los errores que afectan a usuarios y clientes.
La repetición es la clave: un caso difícil que se resolvió una vez debe incorporarse a la batería de pruebas para comprobar que futuras modificaciones no recuperan el mismo defecto.
Conclusión: evaluar es comprobar, no confiar
La automatización aporta valor cuando sus resultados se pueden verificar. Una buena evaluación distingue entre trabajo completado, ejecución bloqueada, publicación degradada y acción no autorizada; conserva la evidencia y convierte los fallos en mejoras reproducibles.
El mejor sistema no es el que nunca informa de errores, sino el que detecta lo que ocurrió, evita agravar el problema y demuestra con pruebas cuándo lo ha resuelto. Esa disciplina es la que permite aumentar la autonomía sin perder control.
Fuentes primarias: documentación oficial de OpenAI «Evaluate agent workflows» y «Getting started with datasets», consultadas en octubre de 2026. Los ejemplos operativos son ilustrativos; no representan una auditoría de ningún proveedor.