QA de Agentes de IA: Cómo Probarlos Antes de que Fallen con un Cliente

Según el reporte State of AI Agents de LangChain, el 57% de las organizaciones ya tiene agentes en producción y el 32% señala la calidad como la principal barrera para desplegarlos. Es la queja número uno de la industria, y tiene una causa concreta: la automatización puso la construcción de agentes al alcance de cualquiera, pero el rigor para probarlos no se democratizó al mismo ritmo.

El resultado se repite: la demo funciona, el cliente aprueba, y al mes tres alguien descubre que el agente lleva semanas dando información equivocada. Este artículo es la batería de pruebas mínima que aplicamos antes de dejar que un agente hable con clientes reales.

Por qué no sirve el QA de software tradicional

En software tradicional, probar es comparar: le das una entrada, esperas una salida exacta, y si no coincide, falla la prueba. Con un agente eso se rompe por dos motivos.

Primero, la misma entrada puede producir salidas distintas. Un modelo es probabilístico por diseño; dos ejecuciones idénticas pueden redactar diferente. Segundo, la entrada no es finita: un usuario puede preguntar lo mismo de cincuenta maneras, incluyendo unas que a nadie se le ocurrieron.

Entonces la pregunta del QA cambia. Ya no es "¿devuelve exactamente esta cadena?" sino "¿el hecho que afirma es correcto, sin importar cómo lo redacte?". Todo lo demás se deriva de ahí.

1. La batería de casos con respuesta conocida

Es la base de todo. Un conjunto de preguntas reales cuya respuesta correcta está verificada por una persona y guardada aparte. Cincuenta es un buen punto de partida para un agente de atención; cien si maneja precios o reglas complejas.

Cada caso guarda tres cosas: la pregunta, el hecho que debe aparecer en la respuesta, y la fuente de la que debe salir. Se ejecuta completa ante cualquier cambio de prompt, de modelo, de herramienta o de datos. Sin excepción — el cambio "inofensivo" de prompt es exactamente el que rompe cosas.

2. La prueba de repetición

Esta es la que casi nadie hace y la que más problemas destapa. Consiste en lanzar la misma pregunta veinte veces seguidas y comparar los datos duros de las veinte respuestas.

Si el precio, la fecha o el porcentaje varían aunque sea una vez, ya sabes algo importante: ese dato no está saliendo de una fuente determinista, lo está produciendo el modelo. Es un diagnóstico, no una estadística. Y es la forma más rápida de detectar el problema que describimos en determinismo vs probabilismo.

3. Los casos límite que sí ocurren

No hace falta imaginar escenarios exóticos. Los que rompen agentes en producción son aburridos y frecuentes:

• Un producto con promoción vigente y otro con promoción que venció ayer.
• Precios con y sin impuesto incluido en el mismo catálogo.
• Un artículo descontinuado que todavía aparece en un PDF viejo.
• Dos productos con nombres casi idénticos.
• Una pregunta que mezcla dos temas: "¿cuánto cuesta y cuándo me lo entregan?"
• El cliente que corrige a media conversación: "no, era el otro modelo".

Cada uno de estos debería estar en la batería con su respuesta correcta documentada. Y si al listarlos descubres que ninguno tiene una fuente clara de la que salga la respuesta, el problema no es de pruebas: revisa primero si el agente es la herramienta correcta para ese caso.

4. Trazabilidad

Para cualquier conversación, deberías poder responder: ¿de qué fuente salió cada dato que el agente afirmó? Si no puedes, no tienes un sistema auditable, tienes una caja negra que a veces acierta.

En la práctica esto significa registrar, junto a cada respuesta, qué herramientas se ejecutaron y qué devolvieron. Cuando algo salga mal —y algo saldrá mal— la diferencia entre corregirlo en una hora o en una semana es exactamente ese registro.

5. Qué hace el agente cuando no sabe

La prueba más reveladora de todas: pregúntale algo que no está en ninguna de sus fuentes. Un producto que no existe, una política que nadie escribió.

La respuesta correcta es reconocer que no tiene el dato y escalar a una persona. La respuesta incorrecta es improvisar algo plausible. Si tu agente improvisa aquí, va a improvisar en producción, con la diferencia de que ahí nadie estará revisando.

6. El QA no termina en el despliegue

Un agente en producción se degrada por motivos que no dependen de él: cambian los precios, se agrega un producto, se actualiza el modelo del proveedor, aparece un tipo de pregunta que no existía. Por eso la batería debe correr de forma programada, no solo antes de desplegar. Muchas de esas degradaciones vienen de lo que entra al contexto del modelo, un tema que tratamos aparte en context engineering.

Un esquema que funciona bien:

• Antes de cada cambio: batería completa, obligatoria.
• Diario, automático: un subconjunto de casos críticos, los que tocan precios y reglas.
• Semanal, humano: revisar una muestra de conversaciones reales. Aquí es donde aparecen los tipos de pregunta que nadie anticipó.
• Continuo: una alerta cuando el agente escala más de lo normal, que suele ser la primera señal de que algo cambió en los datos.

La lista de verificación

Antes de que un agente hable con un cliente real:

• Existe una batería de al menos cincuenta casos con respuesta verificada.
• La prueba de repetición pasa: los datos duros no varían.
• Los casos límite conocidos están cubiertos y documentados.
• Cada dato de la respuesta es trazable hasta su fuente.
• El comportamiento ante falta de datos es escalar, no improvisar.
• Hay una persona responsable de revisar conversaciones cada semana.
• Existe una alerta para cuando el patrón de escalamiento cambia.

Ninguno de estos siete puntos requiere herramientas caras ni un equipo grande. Requieren decidir que el agente no sale hasta que pasen. Esa decisión es, en nuestra experiencia, la única diferencia consistente entre los proyectos que siguen funcionando al año y los que se apagan en silencio a los tres meses.