Un equipo en una empresa de seguros de tamano mediano paso seis meses construyendo su agente de IA. La demo fue impecable. Las pruebas internas pasaron. Lo lanzaron a clientes reales.
En tres dias, tenian un problema: el agente estaba citando con confianza una politica de reembolsos que habia sido actualizada dos meses antes. A los clientes se les decia que podian devolver productos que en realidad no podian devolver. La IA habia aprendido la politica antigua durante el entrenamiento, y nadie habia probado si manejaria la version actualizada correctamente.
El agente paso todas las pruebas que ejecutaron. Pero las pruebas no cubrieron el escenario que importaba.
Esta es la brecha de realidad de produccion, y es donde la mayoria de los proyectos de agentes de IA realmente fallan. No en la demo. No en QA. Sino en la primera semana de trafico real.
La brecha de realidad de produccion
Las pruebas de desarrollo y las pruebas de produccion son problemas fundamentalmente diferentes. Los entornos de desarrollo usan entradas controladas, datos limpios y escenarios que tu equipo penso en escribir. La produccion trae clientes reales con errores de escritura, acentos inusuales, estados emocionales, ruido de fondo y solicitudes que nunca estuvieron en tus datos de entrenamiento.
Esto es lo que las pruebas de desarrollo no detectan:
- El Cliente Impaciente que interrumpe al agente a mitad de oracion para cambiar su solicitud
- El Usuario Confundido que dice "eh, de hecho olvidalo, puedes solo..." a mitad de conversacion
- El Caso Limite de Politicas donde la situacion del cliente esta tecnicamente cubierta pero es practicamente ambigua
- El que Llama a las 3am que ya esta frustrado antes de empezar a hablar
Construir un framework de pruebas que detecte estas brechas antes del lanzamiento no es opcional. Es la diferencia entre un despliegue exitoso y un rollback costoso.
Capa 1: Pruebas unitarias de los componentes de IA
Las pruebas unitarias para agentes de IA son mas matizadas que para software tradicional. Con una API REST, la misma entrada siempre produce la misma salida. Con un agente basado en LLM, estas probando que las salidas caigan dentro de rangos aceptables, no que sean identicas byte por byte.
Que probar a nivel unitario:
Precision de reconocimiento de intenciones
Para cada intencion que tu agente esta disenado para manejar, pruebala con al menos 15-20 formulaciones variadas. "Quiero cancelar mi suscripcion" y "como hago para que dejen de cobrarme?" son la misma intencion. Tu agente necesita reconocer ambas.
Rastrea tu precision de reconocimiento como porcentaje. Cualquier cosa por debajo del 90% para una intencion central es un problema que vale la pena corregir antes de lanzar.
// Example: testing intent recognition across variations
const cancellationPhrases = [
"I want to cancel my subscription",
"how do I stop being charged?",
"I need to end my account",
"cancel everything",
"I don't want this anymore",
"can you stop my payments",
"how do I unsubscribe",
// ... 10+ more
];
for (const phrase of cancellationPhrases) {
const result = await agent.classify(phrase);
expect(result.intent).toBe('cancel_subscription');
expect(result.confidence).toBeGreaterThan(0.85);
}Precision de extraccion de entidades
Si tu agente necesita extraer valores de la entrada del usuario (numeros de cuenta, fechas, montos, nombres), prueba la precision y recall de extraccion con entradas desordenadas del mundo real.
"Mi numero de cuenta es eh, 7-7-4-2... de hecho es 7742-9981" es el tipo de entrada que tus pruebas unitarias deberian manejar, no solo "mi numero de cuenta es 77429981".
Validacion de calidad de respuesta
No solo pruebes que el agente responde. Prueba que responde correctamente. Verifica:
- Precision factual contra tu base de conocimiento
- Tono apropiado para el escenario (empatico para quejas, eficiente para consultas simples)
- Ausencia de contenido fuera de politica (cosas que el agente nunca deberia decir)
- Longitud de respuesta dentro de rangos esperados
La puntuacion automatizada usando un patron de LLM-as-judge funciona bien aqui: que un modelo separado evalue las respuestas de tu agente contra una rubrica. Los scorecards de IA de Chanl automatizan esta evaluacion a escala.
Capa 2: Pruebas de integracion del sistema completo
Las pruebas unitarias pasan en aislamiento. Las pruebas de integracion verifican el sistema completo: tu agente hablando con tus APIs reales, bases de conocimiento, CRM, procesadores de pagos y caminos de escalacion.
Cada punto de integracion es un posible modo de falla.
Lista de verificacion de pruebas de integracion:
Flujos de conversacion de extremo a extremo
Mapea tus 10 recorridos de cliente mas comunes y escribe pruebas de integracion con guion para cada uno. Una consulta de facturacion que se resuelve exitosamente. Una solicitud de devolucion que escala a un humano. Un restablecimiento de contrasena que se completa de extremo a extremo.
Estas pruebas deberian ejecutarse contra infraestructura real (o casi real), no mocks. Los mocks pueden ocultar fallas de integracion que solo se manifiestan en produccion.
Pruebas de dependencias de terceros
Para cada servicio externo que tu agente llama, prueba tanto el camino feliz como los modos de falla:
| Integracion | Camino Feliz | Modo de Falla |
|---|---|---|
| Consulta CRM | Devuelve registro del cliente | Devuelve 404 → agente pide informacion manualmente |
| Base de conocimiento | Devuelve documento relevante | Resultado vacio → agente dice "No estoy seguro, dejame verificar" |
| API de pagos | Confirma transaccion | Timeout → agente dice "dejame reintentar eso" |
| Escalacion | Enruta a humano | Cola llena → agente ofrece callback |
Las fallas silenciosas son el peor tipo. Si tu CRM devuelve un error y el agente simplemente continua proporcionando informacion incorrecta con confianza, eso es un incidente de produccion esperando a ocurrir.
Validacion de caminos de escalacion
Cada escenario de escalacion deberia probarse explicitamente. Cuando transfiere el agente a un humano? Que informacion pasa? Como comunica la transferencia al cliente?
La transferencia en caliente es una de las cosas mas dificiles de hacer bien. "Dejeme transferirlo" seguido de desconexion inmediata es una fuente bien documentada de furia del cliente.
Capa 3: Pruebas de rendimiento bajo carga
Un tiempo de respuesta de 200ms con 10 sesiones concurrentes puede convertirse en 2,000ms con 100 sesiones concurrentes. Las pruebas de rendimiento no son opcionales. Es como estableces los limites de capacidad antes de necesitarlos.
Que medir:
Percentiles de latencia
Siempre prueba latencia p50, p95 y p99, no solo promedios. Los promedios ocultan valores atipicos. Si el 1% de tus conversaciones tarda 8 segundos en responder, esos son clientes reales teniendo una experiencia terrible.
Establece umbrales antes de que comiencen las pruebas. Una linea base razonable para IA de voz: p50 < 400ms, p95 < 800ms, p99 < 1,500ms de tiempo de respuesta de extremo a extremo. Ajusta segun las expectativas reales de tus clientes.
Capacidad de sesiones concurrentes
Ejecuta pruebas de carga que escalen de 1 a tu concurrencia pico esperada gradualmente. Encuentra donde la latencia se degrada, donde empiezan a aparecer errores y donde el sistema colapsa. Eso te da tu limite de operacion seguro.
Documenta este numero y construye alertas alrededor del 70% de la capacidad, no del 100%.
Patrones de degradacion
La pregunta no es solo "cuantas sesiones puede manejar el sistema?" Es "como cambia la calidad a medida que aumenta la carga?" El modelo empieza a cometer mas errores? La coherencia de las respuestas cae? La precision de reconocimiento de intenciones baja?
Si tu agente se vuelve mas tonto bajo carga, necesitas saberlo antes que tus usuarios.
Capa 4: Pruebas de caos, rompiendo cosas deliberadamente
Las pruebas de caos son donde la mayoria de los frameworks de pruebas de IA se quedan cortos. Tambien es donde vienen las fallas de produccion mas costosas.
La premisa es simple: si no pruebas que pasa cuando las cosas salen mal, lo descubriras cuando realmente salgan mal. En produccion, frente a clientes reales.
Escenarios de caos para probar:
Fallas de dependencias
Que pasa cuando:
- La base de conocimiento esta devolviendo 503s?
- La consulta al CRM toma 30 segundos en lugar de 300ms?
- La API del proveedor de LLM se cae a mitad de conversacion?
- La cola de escalacion esta llena?
Para cada escenario, verifica que el agente o se recupera elegantemente o falla elegantemente, no silenciosamente o catastroficamente.
Inestabilidad de red
La IA de voz es especialmente vulnerable a problemas de red. Prueba perdida de paquetes, jitter aumentado y caidas de conexion. Que hace el agente cuando no puede escuchar al cliente claramente? Que pasa si una llamada a una herramienta se cuelga por 10 segundos?
Casos limite de datos
Que pasa cuando:
- El numero de cuenta de un cliente no existe en el sistema?
- Un producto por el que preguntan fue descontinuado la semana pasada?
- Su nombre contiene caracteres que el sistema no fue construido para manejar?
- Estan llamando sobre un pedido que pertenece a una cuenta diferente?
Estos no son hipoteticos. Son exactamente lo que los clientes reales hacen.
Personas de prueba: el arma secreta
La mejor forma de encontrar modos de falla que tus pruebas con guion no detectan es simular usuarios que no se comportan como esperarias.
En Chanl, hemos encontrado cuatro personas que exponen las brechas mas criticas:
El Cliente Impaciente
Interrumpe constantemente. Hace preguntas de seguimiento antes de que el agente termine su respuesta. Tiene un problema y quiere que se resuelva en 30 segundos. Esta persona prueba tu manejo de interrupciones y la capacidad de tu agente para retomar el contexto despues de ser cortado.
El Usuario Confundido
Cambia de tema a mitad de oracion. Proporciona informacion parcial y se frustra cuando le piden mas. Dice "ya sabes, la cosa que pedi la semana pasada, no espera, de hecho fue hace dos semanas" y espera que el agente siga el ritmo. Esto prueba el seguimiento de contexto y la desambiguacion elegante.
El Explorador de Casos Limite
Pregunta sobre politicas para situaciones inusuales. "Puedo devolver un pedido personalizado?" "Que pasa si me pase de la ventana de devolucion por un dia?" "Que cubre realmente su garantia?" Estas conversaciones exponen brechas entre lo que cubren tus datos de entrenamiento y lo que los clientes realmente preguntan.
El Escalador Frustrado
Llega ya molesto. Usa lenguaje emocionalmente cargado. Escala a "quiero hablar con un humano" en el primer intercambio. Esto prueba tus disparadores de escalacion, tus intentos de desescalacion y la calidad de la transferencia cuando no logras desescalar exitosamente.
Ejecuta cada persona contra cada uno de tus flujos de conversacion principales. Las combinaciones sacaran a la luz modos de falla que tus pruebas deterministicas nunca encontraran.
Construyendo tu pipeline de pruebas
No tienes que implementar las cuatro capas de una vez. Aqui hay una secuencia practica:
-
Comienza con pruebas unitarias para tus intenciones de mayor trafico. Si el 40% de tus llamadas son preguntas de facturacion, tu reconocimiento de intencion de facturacion deberia tener cobertura unitaria completa primero.
-
Agrega pruebas de integracion para tus flujos mas criticos. Generalmente: resolucion exitosa, escalacion a humano y manejo de falla en la busqueda de cuenta.
-
Ejecuta pruebas de rendimiento antes de cualquier lanzamiento importante. No solo "funciona", sino "como se comporta a 10x de nuestro pico esperado?"
-
Agrega pruebas de caos incrementalmente. Elige tus tres modos de falla mas probables y escribe pruebas de caos para esos primero. Expande la biblioteca con el tiempo.
Pruebas de regresion en cada merge
Cada vez que cambias tu agente (actualizacion de prompt, nueva herramienta, cambio de version de modelo), estas introduciendo riesgo de regresion. La misma conversacion que funciono la semana pasada podria producir una respuesta sutilmente diferente (peor) hoy.
Las suites de regresion automatizadas que se ejecutan en cada merge detectan estos antes de que lleguen a produccion. No necesitan ser exhaustivas. 50-100 conversaciones representativas cubriendo tus flujos principales suele ser suficiente para detectar regresiones significativas.
Que significa realmente "listo para produccion"
Una heuristica util: tu agente esta listo para produccion cuando puedes responder si a todas estas:
- Maneja tus 10 conversaciones mas comunes correctamente, de forma consistente, con formulaciones variadas?
- Escala apropiadamente cuando deberia, y no escala cuando no deberia?
- Ha sido probado a 2x de tu carga pico esperada sin degradacion de latencia?
- Falla elegantemente cuando cualquier dependencia individual no esta disponible?
- Tienes monitoreo implementado para detectar regresiones de calidad que no anticipaste?
Si alguna de estas es "todavia no", esa es tu hoja de ruta de pruebas.
El objetivo no es un agente perfecto. Es un agente que falla de forma predecible y se recupera elegantemente, con un sistema de monitoreo que te dice cuando esta teniendo dificultades antes de que lo hagan tus clientes.
Para empezar esta semana
Si estas lanzando un agente de IA en los proximos 30 dias y aun no has construido un framework de pruebas sistematico, aqui esta la version minima viable:
- Escribe 10 pruebas de conversacion con guion cubriendo tus flujos mas criticos, caminos felices y los modos de falla mas obvios
- Elige tus 3 intenciones mas importantes y prueba cada una con 15+ formulaciones variadas
- Ejecuta una prueba de carga basica a 2x de tu concurrencia pico esperada
- Prueba tu falla de dependencia mas critica, generalmente el CRM o la base de conocimiento cayendose
Eso no detectara todo. Pero detectara las cosas obvias, y te da una base sobre la cual construir. Los frameworks de pruebas que funcionan en produccion son los que comienzan simples y crecen con el sistema, no los que intentan probar todo antes de que se lance una sola linea de codigo.
Comienza ahi, e itera.
Engineering Lead
Building the platform for AI agents at Chanl — tools, testing, and observability for customer experience.
Aprende IA Agéntica
Una lección por semana: técnicas prácticas para construir, probar y lanzar agentes IA. Desde ingeniería de prompts hasta monitoreo en producción. Aprende haciendo.
