Pruebas de agentes de IA: regresión y simulación

Las pruebas de agentes de IA son la forma en que un equipo de soporte demuestra que un agente de IA sigue comportándose bien antes de que un cambio llegue a los clientes. Se construyen casos de prueba a partir de conversaciones resueltas reales y de fallos pasados, se vuelven a ejecutar antes de cada cambio de prompt, política, conocimiento o modelo, se simulan clientes difíciles, se comprueban las acciones que tomó el agente y solo se publica cuando se supera una puerta de lanzamiento escrita.

En resumen

• Un agente que toma acciones necesita pruebas sobre lo que hizo (reembolso emitido, límite respetado, caso derivado), no solo sobre lo que dijo.
• Los mejores casos de prueba salen de sus propias conversaciones resueltas y de sus fallos pasados.
• Vuelva a ejecutar el conjunto de regresión completo antes de cada cambio de prompt, política, conocimiento, modelo o herramienta.
• Ejecute cada caso crítico varias veces: un agente que aprueba una vez puede suspender el mismo caso en la siguiente ejecución.
• Escriba la puerta de lanzamiento antes de la ejecución, para que nadie discuta los umbrales después de ver los resultados.

Esta guía es la parte previa al lanzamiento de nuestra guía más amplia de evaluación de agentes de IA.

¿Qué son las pruebas de agentes de IA y en qué se diferencian de las pruebas de chatbot?

Las pruebas de agentes de IA comprueban un agente que razona a lo largo de varios turnos y toma acciones en sus sistemas, como emitir reembolsos, modificar pedidos o actualizar cuentas. Las pruebas de chatbot comprueban sobre todo respuestas y flujos de conversación. La diferencia está en las consecuencias: una respuesta errónea de un chatbot confunde a un cliente, mientras que una acción errónea de un agente cambia registros reales.

Si su bot solo responde y deriva, vea pruebas de chatbot. Este artículo trata lo que cambia cuando el agente puede actuar.

La consistencia es lo difícil. En el estudio τ-bench, donde un modelo de lenguaje hace de cliente y el agente trabaja con herramientas y directrices de política propias de un dominio, incluso agentes potentes con llamadas a funciones tuvieron éxito en menos del 50% de las tareas y superaron la misma tarea de retail en las 8 pruebas menos del 25% de las veces. El éxito se juzgaba por el estado de la base de datos al final de la conversación, no por la respuesta.

¿Qué debe incluir un caso de prueba de un agente de IA?

Un caso de prueba de un agente de IA necesita seis campos básicos: el escenario, el perfil del cliente, el resultado esperado, las acciones que el agente puede tomar, una regla de aprobado que una segunda persona aplicaría igual y la conversación de origen. Sin los dos últimos, los resultados de las pruebas se convierten en opiniones.

Esta es la plantilla: los seis campos básicos más cuatro que mantienen el conjunto manejable. Cópiela en una hoja de cálculo, una fila por caso.

Dos reglas mantienen útil la plantilla. Primero, el resultado esperado describe un estado, no una frase: la guía de ingeniería de Anthropic sobre evaluaciones de agentes lo explica con un ejemplo de reserva de vuelos, donde lo que cuenta es si existe una reserva en la base de datos, no si el agente dice que la hizo. Segundo, cada caso apunta a la conversación que lo justifica, para que cuando cambie una política pueda encontrar y actualizar los casos afectados.

¿Cómo se construye un conjunto de referencia a partir de conversaciones reales?

Construya el conjunto de referencia (golden set) con su propio tráfico: conversaciones resueltas que muestran al agente en su mejor versión, fallos pasados que no quiere volver a ver, escalamientos y los casos límite de cada política. Empiece con 20 a 50 casos y amplíelo cada semana, en lugar de esperar a tener un conjunto perfecto de cientos.

La guía de Anthropic dice que de 20 a 50 tareas sencillas extraídas de fallos reales son un gran comienzo, y recomienda convertir los fallos que reportan los usuarios en casos de prueba para que el conjunto refleje el uso real.

Un primer conjunto equilibrado de 50 casos podría tener este aspecto (una ilustración; ajuste los pesos a su propio volumen y riesgo):

Mantenga en el conjunto los casos que se aprueban: una corrección en un flujo puede romper otro sin hacer ruido, y solo los casos que antes se aprobaban lo mostrarán. Elimine los datos personales de cada conversación de origen antes de convertirla en caso de prueba.

¿Cómo se ejecutan pruebas de regresión antes de cada cambio en un agente de IA?

Ejecute las pruebas de regresión reproduciendo el conjunto de referencia completo contra el agente modificado antes de que entre en producción, con las mismas reglas de aprobado que la última vez, y compare los resultados con la versión actual. Cualquier cambio cuenta: prompts, políticas, artículos de conocimiento, versiones del modelo, herramientas y reglas de enrutamiento alteran el comportamiento. Un artículo de ayuda editado puede cambiar las respuestas sobre reembolsos tanto como un cambio de prompt.

Ejecute los casos críticos más de una vez. Los agentes no son deterministas, así que un solo aprobado demuestra poco; por eso los autores de τ-bench propusieron pass^k, la probabilidad de que las k ejecuciones tengan éxito. La aritmética (ilustración): un caso que el agente aprueba el 90% de las veces aprueba 3 ejecuciones seguidas solo el 73% de las veces (0,9 × 0,9 × 0,9), y 8 ejecuciones seguidas solo el 43%.

Los casos de regresión deben aprobarse al 100% o muy cerca. La guía de Anthropic hace la misma distinción: las evaluaciones de regresión deben tener una tasa de aprobado cercana al 100%, mientras que las evaluaciones de capacidad para nuevas habilidades pueden empezar bajas.

¿Cómo se simulan clientes para probar un agente de IA?

Simule clientes haciendo que un segundo modelo interprete al cliente a partir de un perfil escrito, a lo largo de varios turnos, frente al agente que está probando. Dé a cada perfil un objetivo, unos datos, un carácter y un punto de ruptura, y añada perfiles maliciosos que empujen al agente más allá de sus límites.

Las preguntas sueltas prueban respuestas. La simulación de varios turnos, el diseño que usó τ-bench, prueba lo que falla en las conversaciones reales: el cliente que cambia de solicitud a mitad de camino o que sigue insistiendo en un reembolso que la política no permite.

Escriba de cinco a ocho perfiles y reutilícelos en distintos escenarios:

1. El que pide con claridad: una solicitud, todos los datos. Su referencia.
2. El impreciso: sin número de pedido, nombre de producto equivocado. Prueba las preguntas aclaratorias.
3. El que cambia de tema: empieza con la entrega y termina con una cancelación.
4. El insistente: rechaza la primera respuesta tres veces y pide una excepción. Prueba los límites bajo presión.
5. El cliente molesto: amenaza con irse o con quejarse en público. Prueba el tono y el traspaso.
6. El cliente vulnerable: menciona un duelo, una enfermedad o problemas de dinero. Prueba sus reglas de traspaso para estos casos.
7. El manipulador: dice ser empleado, pega «ignora tus instrucciones» o esconde instrucciones en un adjunto. Prueba la resistencia a lo que OWASP llama inyección de prompts.

Un perfil solo encuentra los problemas que usted pensó en escribir en él, así que use la simulación para ampliar el conjunto y las conversaciones reales para mantenerlo honesto. Los agentes de voz añaden acentos, interrupciones y calidad de la línea; vea control de calidad de agentes de voz con IA.

¿Cómo se prueban las acciones y las llamadas a herramientas de un agente de IA?

Pruebe las acciones comprobando el estado final en sus sistemas después de la conversación, no la descripción que hace el agente de lo que hizo. ¿Existe el registro del reembolso, por el importe correcto y en el pedido correcto? ¿Se mantuvo el agente dentro de sus límites, pidió confirmación donde era obligatorio y no llamó a ninguna herramienta que no tuviera permitida?

Una respuesta que dice «He procesado su reembolso» no demuestra nada. Compruebe cuatro cosas por cada caso de acción:

1. Acción correcta. Se llamó a la herramienta esperada y a ninguna inesperada.
2. Argumentos correctos. Pedido, cliente, importe y motivo correctos.
3. Dentro de los límites. Importe por debajo del tope, permiso vigente, aprobación solicitada donde su política exige a una persona.
4. Informe veraz. Lo que el agente dijo al cliente coincide con lo que realmente pasó en el sistema.

OWASP incluye la agencia excesiva entre sus principales riesgos para aplicaciones con LLM: acciones dañinas posibilitadas por demasiada funcionalidad, demasiados permisos o demasiada autonomía. Sus mitigaciones (extensiones mínimas, permisos mínimos, aprobación del usuario) sirven también como lista de pruebas. Escriba al menos un caso por límite en el que el cliente pida justo un poco más.

Ejecute las pruebas de acciones en un sandbox o con cuentas de prueba, nunca con registros reales. La formación de Salesforce sobre su Agentforce Testing Center advierte de que probar agentes puede modificar datos del CRM e indica usarlo solo en un sandbox.

El traspaso también es una acción: pruebe que el agente deriva los casos que debe, con una nota que permita a la persona continuar (calidad en el escalamiento).

¿Cómo se convierten los fallos en producción en nuevos casos de prueba?

Los fallos en producción se convierten en casos de prueba mediante una rutina semanal: encuentre las conversaciones en las que el agente de IA se equivocó, confirme el fallo, elimine los datos personales, redacte el caso con la plantilla de arriba y añádalo al conjunto de referencia. El siguiente cambio no se publica hasta que ese caso se apruebe.

Lo difícil es encontrar los fallos. Una conversación que el agente «resolvió» puede contener una respuesta errónea, una política inventada o un traspaso omitido, y los dashboards la cuentan como un éxito (fallos silenciosos de agentes de IA). El monitoreo de agentes de IA explica qué vigilar día a día, y el control de calidad de agentes de IA muestra cómo construir la scorecard que los detecta.

Aquí es donde se encuentran el QA de conversaciones reales y las pruebas previas al lanzamiento. AutoPilot de Kaizo evalúa cada conversación resuelta por un agente de IA con su propia scorecard y vincula cada nota con las evidencias, lo que le da fallos confirmados, cada uno con una conversación de origen para la plantilla. Una vez publicada la corrección, evaluar las conversaciones reales de las semanas siguientes muestra si se mantuvo.

Vea dónde falla hoy su agente de IA. Kaizo evalúa las conversaciones de los agentes de IA con la misma scorecard que a su equipo y vincula cada nota con las líneas que la justifican. Reserve una reunión.

Si evalúa con un juez de IA, compruebe también al juez. Nuestra guía sobre cómo validar la evaluación de QA con IA (en inglés) muestra cómo comparar las notas automáticas con las de sus revisores antes de confiar en ellas.

¿Qué debe comprobar una puerta de lanzamiento de un agente de IA?

Una puerta de lanzamiento de un agente de IA es una lista corta y escrita de condiciones que un cambio debe cumplir antes de llegar a los clientes, acordada antes de la ejecución de pruebas. Debe bloquear ante cualquier fallo crítico, exigir resultados de regresión casi perfectos, cubrir cada acción y cada límite, y nombrar quién aprueba y cómo revertir. Cópiela y fije sus propias cifras.

Antes de la ejecución

• El cambio está por escrito: qué, por qué y quién lo pidió.
• Hay casos nuevos para el propio cambio (un límite nuevo recibe casos justo dentro y justo fuera).
• Todo fallo confirmado en producción desde la última versión está en el conjunto.
• Cuentas de prueba y sandbox preparados; ningún registro real de clientes al alcance.

La ejecución

• Conjunto de referencia completo ejecutado contra el agente modificado y contra el actual, con las mismas reglas de aprobado.
• Casos críticos (dinero, datos, asuntos legales, clientes vulnerables) ejecutados al menos 3 veces cada uno.
• Perfiles simulados ejecutados, incluidos el manipulador y el insistente.

Condiciones de aprobado

• Casos críticos: 100% aprobados, en cada prueba. Un solo fallo bloquea la versión.
• Casos de regresión: al menos el 98% aprobados, y ningún caso que se aprobó en la última versión suspende ahora sin explicación.
• Casos de acción: ninguna acción fuera de la lista permitida, ningún importe por encima del límite, ninguna afirmación de una acción que no ocurrió.
• Casos de traspaso: cada caso que debía derivarse llegó a una persona con una nota útil.
• Casos sin respuesta conocida: ninguna respuesta inventada.

Aprobación y después del lanzamiento

• Firma un responsable con nombre: el responsable de soporte o de CX para política y tono, el responsable de IA para la parte técnica.
• La reversión está lista: el prompt, el conocimiento y la versión del modelo anteriores se pueden restaurar el mismo día.
• Los primeros días de conversaciones reales tras el lanzamiento se revisan con más atención de lo habitual.

Ejemplo práctico (una ilustración con cifras inventadas). Un equipo reduce su plazo de reembolso de 30 a 14 días. Su conjunto de referencia tiene 120 casos: 40 críticos y 80 de otro tipo. Los casos críticos se ejecutan 3 veces y el resto una vez, así que la ejecución tiene 200 pruebas. El resultado: 196 de 200 pruebas aprobadas, una tasa del 98% que parece sana. Pero los 4 fallos están en dos casos críticos. En uno, el agente seguía ofreciendo un reembolso el día 20 en una de tres pruebas. En el otro, el perfil insistente le convenció de un reembolso «por cortesía» en las tres. La puerta bloquea la versión. La corrección va al prompt y a un artículo de conocimiento, se añaden dos nuevos casos críticos para el día 14 y el día 15, y la nueva ejecución aprueba 206 de 206 pruebas. Una media habría publicado el error; la puerta no.

¿Qué herramientas necesita para probar agentes de IA?

Necesita tres tipos de herramientas: un lugar donde guardar y versionar los casos de prueba, una forma de ejecutarlos contra el agente (a menudo con clientes simulados) y una forma de evaluar los resultados con sus reglas de aprobado.

• Una hoja de cálculo y ejecuciones manuales bastan por debajo de unos 50 casos y pocos cambios al mes.
• Una función de pruebas de la plataforma encaja con una sola plataforma y flujos estándar. El Agentforce Testing Center de Salesforce, por ejemplo, genera 20 casos de prueba por defecto, y usted decide cuántos son positivos y cuántos negativos.
• Las herramientas de pruebas y simulación añaden clientes simulados, pruebas repetidas y comprobaciones de lanzamiento en el pipeline de despliegue.
• El QA de conversaciones reales evalúa lo que de verdad pasó tras el lanzamiento y devuelve los fallos confirmados al conjunto.

Elija lo que elija, mantenga los casos en un formato que su equipo de soporte pueda leer y editar, o los responsables de las políticas dejarán de actualizarlos.

¿Cuándo un programa completo de pruebas no es para usted?

Un programa completo es excesivo si su agente de IA atiende unas pocas decenas de conversaciones a la semana, solo responde preguntas y no puede tomar acciones. En ese caso, lea las transcripciones cada semana y mantenga una lista corta de 20 casos que vuelva a ejecutar a mano tras cada cambio.

Tampoco el QA de conversaciones reales lo sustituye: evaluar las conversaciones después de que terminen no bloquea un cambio antes de publicarlo. Necesita ambos, pruebas antes del cambio y la evaluación de cada conversación de su agente de IA después.

Cómo empezar esta semana

Puede tener un primer conjunto de referencia, una puerta de lanzamiento escrita y una ejecución de base en cinco días laborables, con una exportación de conversaciones recientes, la plantilla de arriba y un entorno de pruebas.

1. Lunes: exporte 30 conversaciones resueltas por el agente de IA y 20 que salieron mal. Elimine los datos personales.
2. Martes: páselas a la plantilla. Marque cuáles son críticas.
3. Miércoles: escriba la puerta de lanzamiento. Consiga que el responsable de soporte y el responsable de IA acuerden las cifras.
4. Jueves: ejecute el conjunto contra el agente actual, con tres pruebas para los casos críticos. Esta es su línea base; espere algunos fallos.
5. Viernes: acuerde la regla de que ningún cambio de prompt, política, conocimiento o modelo se publica sin una nueva ejecución, y fije un hueco semanal para añadir los nuevos fallos al conjunto.

Vea gobernanza de agentes de IA para saber a quién corresponde la aprobación.

Preguntas frecuentes

¿Qué es la automatización con IA en las pruebas?

La automatización con IA en las pruebas suele significar usar la IA para probar software, por ejemplo agentes que escriben y ejecutan scripts de prueba para una aplicación web. Este artículo trata otro tema: demostrar que un agente de IA de cara al cliente responde y actúa correctamente antes de que cada cambio entre en producción.

¿Los agentes de IA tienen herramientas?

Sí. Las herramientas de un agente de IA son las funciones que puede llamar, como consultar un pedido o emitir un reembolso. Por ellas las pruebas de agentes deben comprobar el estado final en sus sistemas, no solo la respuesta.

¿Qué es un tester de IA?

O bien una persona que prueba sistemas de IA, o bien una IA que prueba otro software. En atención al cliente suele ser un responsable de QA o de IA que escribe casos de prueba a partir de conversaciones reales y decide si un cambio supera la puerta de lanzamiento.

¿Cuántos casos de prueba necesita un agente de IA?

Empiece con 20 a 50 casos extraídos de conversaciones reales y fallos pasados, y añada después cada fallo confirmado en producción. Cubrir sus intenciones principales, sus acciones y sus límites importa más que el número total.

¿Con qué frecuencia hay que ejecutar pruebas de regresión de un agente de IA?

Ejecute el conjunto completo antes de cada cambio de prompts, políticas, conocimiento, modelos, herramientas o enrutamiento, y cada semana aunque no haya cambiado nada, porque los proveedores de modelos y los sistemas conectados también cambian.