Antes de habilitar un agente en un proceso real, pruébalo con tareas representativas, resultados esperados y situaciones que deberían detenerlo. La evaluación previa permite decidir si está listo para un alcance limitado; no reemplaza la supervisión en producción, donde cambian los datos, las personas y las condiciones del trabajo. La meta no es demostrar que el agente nunca se equivoca, sino conocer fallos relevantes y definir de antemano qué hacer si aparecen.
Convierte el proceso en preguntas comprobables
Empieza por describir qué puede hacer el agente, qué herramientas y datos puede tocar, qué salida se considera correcta y qué acciones requieren permiso humano. Evita una meta vaga como “resolver bien las solicitudes”. Para una prueba hipotética en una pequeña posada, por ejemplo, el agente recibe reportes de mantenimiento y prepara una clasificación y un borrador de orden de trabajo, pero no asigna personal ni declara reparado el equipo. No afirmamos que sea una función disponible de Jarvis ni de otra plataforma: es un escenario para diseñar pruebas.
Hecho: OpenAI recomienda definir el objetivo de evaluación, reunir un conjunto de ejemplos, establecer métricas, comparar ejecuciones y evaluar de forma continua; también aconseja incluir casos típicos, límite y adversariales. (OpenAI, “Evaluation best practices”, sin fecha; consultada 2026-10-03: https://developers.openai.com/api/docs/guides/evaluation-best-practices).
Recomendación práctica: convierte cada expectativa en un caso con entrada, contexto disponible, respuesta o acción esperada y condición de aprobación. Un caso rutinario podría ser “la lámpara del pasillo no enciende”: se espera una categoría de baja urgencia, una pregunta si falta ubicación y un borrador sin afirmar que alguien ya reparó el problema. Incluye también entradas que no deben disparar acción: un comentario general sin solicitud o un reporte duplicado.
Prueba lo normal y lo que rompe el flujo
Hecho: Anthropic describe las evaluaciones de agentes como algo más complejo que revisar una respuesta aislada, porque estos sistemas usan herramientas en varios turnos y pueden modificar el estado; su guía recomienda tareas inequívocas, conjuntos equilibrados de comportamientos que sí deben ocurrir y los que no, y un entorno estable para repetir ensayos. (Anthropic, “Demystifying evals for AI agents”, 9 de enero de 2026: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).
Recomendación práctica: diseña una matriz que cubra el recorrido completo. Prueba un reporte claro; uno incompleto que necesite una pregunta; dos reportes duplicados; una urgencia sin datos suficientes; una herramienta desconectada; y una instrucción engañosa dentro del reporte que intente cambiar las reglas. Para cada uno escribe por adelantado qué debe hacer el agente y qué tiene prohibido hacer. En el ejemplo de mantenimiento, una posible emergencia cerca de cableado expuesto debería escalarse y no recibir una clasificación rutinaria por falta de detalles.
Verifica tanto aciertos como abstenciones: ¿detecta lo urgente?, ¿evita inventar datos?, ¿se detiene ante información contradictoria?, ¿no crea dos órdenes por el mismo reporte?, ¿pide ayuda si no puede confirmar un dato? Guarda entradas y salidas con versiones identificables del prompt, configuración y herramientas; si cambias uno de esos elementos, repite las pruebas relevantes.
No midas solo si la respuesta “suena bien”. Revisa si la clasificación corresponde, si el borrador refleja los datos y si no hubo una acción fuera de permiso. Anthropic distingue evaluadores basados en código, modelos y revisión humana, cada uno con ventajas y límites; recomienda usar comprobaciones deterministas cuando sea posible y revisión humana para validar juicios más matizados. (Anthropic, “Demystifying evals for AI agents”, 9 de enero de 2026: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents). La automatización de la calificación también puede equivocarse; por eso una muestra revisada por una persona ayuda a comprobar que la rúbrica mide lo que importa.
Define cuándo no se habilita
Hecho: el NIST AI RMF 1.0 establece que los sistemas de IA deberían probarse antes de su despliegue y regularmente durante su operación; también menciona pruebas rigurosas, monitoreo en tiempo real y la posibilidad de detener, modificar o introducir intervención humana cuando el sistema se desvía de lo esperado. (National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”, enero de 2023: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf).
Recomendación práctica: fija criterios de parada antes de ejecutar los casos. No habilites el flujo si una prueba crítica revela que el agente inventa una reparación, omite una urgencia definida, modifica registros sin autorización o sigue adelante cuando falta una confirmación esencial. Tampoco des por válido un resultado si la tarea es ambigua, el entorno de prueba falla o el evaluador no puede distinguir una respuesta correcta de una incorrecta: primero corrige el caso o la medición y vuelve a correrlo.
No existe en las fuentes citadas un porcentaje universal de aprobación para toda pyme o proceso. Define el umbral según el impacto de un error y decide cuáles fallos son inaceptables aunque sean poco frecuentes. En un proceso de bajo impacto, quizá baste con probar clasificación y borradores en un grupo acotado. Si puede generar daños, compromisos externos o cambios difíciles de revertir, mantén la decisión o ejecución bajo control humano hasta que las pruebas sean suficientes para el riesgo concreto.
La evaluación termina; la supervisión no
Una evaluación previa es una fotografía de casos elegidos y condiciones controladas: permite comparar versiones y buscar fallos conocidos antes de exponer el proceso. No demuestra cómo responderá el agente ante todas las entradas reales, ni cubre cambios en los datos, permisos, instrucciones o herramientas.
Hecho: la documentación de Google separa “Test Case Evaluation” para pruebas de regresión con un conjunto de datos y “Online Monitoring” para seguir continuamente la calidad de un despliegue en producción. (Google Cloud, “Evaluate your agents”, actualizado el 1 de octubre de 2026: https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-agents).
Recomendación práctica: si decides iniciar, limita el alcance y registra qué sugirió el agente, qué acción ocurrió, qué corrigió la persona y por qué se detuvo un caso. Define quién revisa excepciones y quién puede pausar el flujo; vigila patrones como más casos sin resolver, errores de clasificación o intentos de acción no autorizada. Ante una señal crítica, detén el proceso, vuelve a revisión manual, investiga la causa y añade el fallo como caso de regresión antes de reanudar.
La guía de Jarvis sobre aprobación humana explica cómo reservar ciertas decisiones para una persona: https://www.jarvisrd.com.do/blog/aprobacion-humana-ia-no-decide-sola. Como acción concreta, elige un solo flujo acotado esta semana, redacta diez casos entre normales, ambiguos y límite, y acuerda por escrito qué resultado permite avanzar y cuál obliga a parar. Ese pequeño expediente será más útil que habilitar el agente basándose únicamente en una demostración convincente.