Cómo demostrar que un agente de IA funciona antes de ponerlo delante de un cliente
Se demuestra con casos representativos escritos antes de construir, criterios de aceptación definidos para ese contexto y verificación por estado del sistema, no solo por el texto. Si el agente dice que reservó la cita, la prueba es mirar la agenda y comprobar que el estado esperado realmente cambió.
Por Reynier RiveroIngeniero de software
Por qué una demo aislada no basta
Una mañana de lunes, una responsable de soporte mira la conversación: el agente acaba de responder «He abierto tu ticket». En el sistema no aparece ningún ticket nuevo; solo queda el mensaje verde que confirma algo que no ocurrió.
Escena hipotética: este intercambio es un ejemplo compuesto, no un caso real.
Ahí está la tensión: la conversación dice una cosa y el sistema otra. La responsable debe decidir si confía en una confirmación que el agente redactó o en el estado que realmente quedó registrado.
La consecuencia aparece enseguida: si da por cerrado el caso, el cliente espera una respuesta que nadie ha creado y el equipo pierde la oportunidad de corregirlo. Si revisa el sistema, descubre que el agente puede sonar seguro incluso cuando la acción falló.
El problema, entonces, no es solo que el agente se equivoque; es que la demo mide el texto y deja fuera el efecto. La lección es sencilla: la alternativa no es desconfiar, es medir.
Una demo suele enseñar el camino feliz, elegido por quien vende. Si la pregunta la escribió la misma persona que construyó la respuesta, es un ensayo controlado, no una evaluación del comportamiento en situaciones variadas. Ese camino tampoco revela cómo responderá el agente ante variantes, ambigüedades o fallos de herramientas. Medirlo empieza por escribir los casos que ya aparecen en el histórico de tu equipo de soporte.
El conjunto de casos se escribe antes de construir
El conjunto parte de preguntas reales, sacadas de conversaciones que ya ocurrieron, con la respuesta correcta escrita al lado. Hay que escribirlas antes, porque un conjunto de casos redactado después de ver el agente funcionando se parece sospechosamente a lo que el agente ya hace bien.
Las buenas prácticas de evaluación de OpenAI sirven como referencia para convertir tareas reales en casos evaluables y definir de antemano qué cuenta como un resultado correcto. Si el sistema usará herramientas, ese conjunto forma parte del diseño del agentes de IA y chatbots, no de una revisión al final.
Como punto de partida, puede contener las preguntas más frecuentes, tal y como las escriben tus clientes, con sus faltas de ortografía y su jerga.
También conviene incluir casos límite: la pregunta ambigua, la que mezcla dos temas o la que se apoya en algo dicho antes.
Añade los casos que debe rechazar, como lo que está fuera de su alcance, exige un humano o no puede saber.
Incluye, además, casos con trampa: preguntas cuya respuesta cambió recientemente, para detectar si contesta con una política anterior.
Para cada caso, escribe la respuesta correcta y, si el agente ejecuta acciones, el estado que debe quedar en el sistema.
Los criterios se acuerdan por escrito
Un único porcentaje no debería presentarse como garantía: un pequeño grupo de fallos puede concentrar todas las preguntas sobre devoluciones.
Define criterios de aceptación propios del flujo y una lista de fallos inaceptables que pueden frenar el lanzamiento. Inventarse un dato, prometer algo que la política no permite o ejecutar una acción no autorizada pueden formar parte de esa lista.
Que los criterios estén en el contrato ayuda a cambiar la conversación de lanzamiento: deja de discutirse si el agente está listo y se comprueba.
Se verifica el estado del sistema, no solo el texto
Para un agente con herramientas, la guía de OpenAI sobre agent evals orienta a revisar las trazas de las llamadas al modelo y a las herramientas, además de los guardrails y los handoffs.
La guía de Anthropic sobre evaluaciones de agentes ayuda a mantener una distinción clave: la respuesta que entrega el agente no es el estado final del sistema.
Si el agente afirma que abrió un ticket, la prueba correcta consulta el sistema de tickets.
Leer esa afirmación verifica que el modelo puede redactar una confirmación; no demuestra que el efecto haya ocurrido.
Esta distinción evita confundir una evaluación con una hoja de cálculo de capturas de pantalla. También ayuda a detectar el fallo más caro de un agente con acciones: que diga que hizo algo y no lo haya hecho. Esto importa especialmente cuando forma parte de automatizaciones e integraciones con sistemas de negocio.
Para cada acción permitida, una comprobación útil es confirmar que ocurrió, que ocurrió una sola vez y que no ocurrió nada más. Así se detectan los duplicados por reintento y los efectos colaterales.
La cobertura y la variación se reportan
No copies una cantidad de ejecuciones ni un criterio de aceptación de otro agente como si fueran universales. Las buenas prácticas de evaluación de OpenAI y la guía de Anthropic sobre evaluaciones de agentes sugieren, en conjunto, que el protocolo debe registrar qué casos cubre, qué variantes incluye, qué criterio se aplicó, qué errores aparecieron y bajo qué condiciones.
El apartado Measure del NIST AI RMF Playbook propone elegir medidas adecuadas al contexto y documentar cómo se obtuvieron. Por eso, el informe puede describir cobertura, tipos de error, estado esperado y estado observado, sin convertir un resultado aislado en una garantía.
Si tu proveedor te enseña un panel con un número limpio, pregúntale qué casos cubre, qué criterio aplicó y cómo verificó cada resultado. Esas preguntas separan una medición de una presentación.
Qué exigir en el contrato
Como punto de partida, el contrato puede incluir los criterios de aceptación y la lista de fallos inaceptables, con el conjunto de casos anexado.
También debe enumerar, una a una, las acciones que el agente no puede ejecutar sin confirmación humana.
Conviene fijar una ventana de corrección.
El contrato debe indicar cuánto tiempo tiene el proveedor para arreglar un fallo detectado tras el lanzamiento y qué pasa si no lo hace.
El contrato puede dejar clara la propiedad de los prompts, del conjunto de casos y del índice documental.
Si no es tuyo, cambiar de proveedor es reconstruirlo todo.
Por último, debe definir el registro auditable: qué se guarda de cada conversación, cuánto tiempo y quién puede consultarlo.
Qué medir después del lanzamiento
Puedes observar la tasa de contención —qué porcentaje de conversaciones terminó sin intervención humana—, pero no tratarla como resolución por sí sola. Un abandono solo cuenta como conversación contenida si la instrumentación lo incluye en el denominador; repórtalo además como abandono, porque cerrar la ventana no confirma que el usuario obtuviera lo que buscaba.
Por separado, mide la resolución confirmada: conversaciones donde el usuario obtuvo lo que buscaba, medido por el estado del sistema o por una confirmación explícita. Junto a ella, puedes mirar la tasa de derivación a humano —que baje demasiado puede ser mala señal—, la proporción de respuestas sin fuente citada y las nuevas formulaciones de la misma pregunta por el mismo usuario.
Conviene mantener un calendario de revisión de los casos y documentos. Cuando una política cambia y el agente conserva una versión anterior, registrar la fecha de revisión ayuda a distinguir un problema documental de uno del modelo.
El siguiente paso
Si estás evaluando un agente para tu empresa, no empieces por pedir otra demo. Convierte conversaciones reales en casos representativos, define criterios de aceptación y señala qué estado del sistema confirmará cada acción antes de conectarlo a producción.
¿Sabes exactamente qué puede ver y qué puede cambiar tu agente hoy? Si la respuesta no está documentada, el siguiente paso es diseñar permisos, aprobaciones humanas, trazabilidad y comprobaciones de estado. En Prontavel podemos ayudarte a construir esa capa con un enfoque práctico para agentes de IA y chatbots.
Este marco técnico y operativo no sustituye una revisión legal, contractual o de seguridad adaptada a tu caso. Define los controles con el equipo responsable y, cuando corresponda, con asesoramiento especializado.
El servicio del que habla este artículo: Agentes de IA y chatbots que conocen tu empresa