Testing de features con IA generativa
Cuando “funciona” ya no significa siempre lo mismo
El otro día, hablando con un cliente sobre nuevos desarrollos con IA generativa, me trasladó una preocupación muy razonable:
“Todo esto suena muy bien, pero ¿cómo puedo confiar en que la calidad está controlada?”
La pregunta me pareció especialmente relevante porque toca uno de los cambios más importantes cuando incorporamos IA generativa a un producto.
En una funcionalidad tradicional, normalmente tenemos bastante claro qué queremos testear:
Input conocido → output esperado → test pasa o falla.
Un botón debe ejecutar una acción
Una API debe devolver un código concreto
Un cálculo debe producir un resultado exacto
Para eso, el testing automatizado tradicional funciona muy bien:
Unit tests: validan que una función concreta haga exactamente lo esperado
Integration tests: comprueban que varios componentes funcionen correctamente juntos
Regression tests: aseguran que un cambio nuevo no rompa algo que ya funcionaba
🤦🏻♀️ Pero, ¿qué pasa cuando incorporamos una feature basada en IA generativa?
Por ejemplo:
Un asistente que responde preguntas de clientes
Una funcionalidad que resume documentos
Un agente que clasifica solicitudes y propone una acción
Un copiloto que redacta emails
Un buscador conversacional sobre información de negocio
En estos casos, el output ya no es necesariamente idéntico cada vez.
Ante una misma petición, la IA puede responder:
“Puedes solicitar el reembolso desde tu área personal.”
O:
“Para tramitar el reembolso, accede a tu cuenta y selecciona la opción correspondiente.”
Ambas respuestas pueden ser válidas.
Y ahí aparece uno de los grandes cambios: ya no siempre testeamos si la respuesta es exactamente igual, sino si cumple unos criterios de calidad, seguridad y utilidad.
El testing tradicional sigue siendo imprescindible
Que una feature incluya IA generativa no significa que todo el testing anterior desaparezca.
Seguimos necesitando comprobar que:
La API del modelo responde correctamente
El usuario autenticado tiene acceso solo a la información permitida
Los documentos se cargan bien
La conversación se guarda correctamente
El botón de enviar funciona
Los errores, timeouts o caídas del proveedor están controlados
La feature no rompe otros flujos existentes
Es decir: los unit tests, integration tests y regression tests siguen validando la parte determinista del sistema.
La diferencia es que ahora hay una capa nueva: la calidad del comportamiento generado por la IA, la parte no determinista.
Antes: “¿devuelve exactamente este resultado?”
En una funcionalidad tradicional, un test podría ser algo así:
Si el usuario introduce un importe de 100 € y un descuento del 10 %, el resultado debe ser 90 €.
Es un resultado binario:
✅ Devuelve 90 €.
❌ Devuelve cualquier otra cosa.
Incluso en una integración, podemos comprobar que:
Si el usuario cancela una suscripción, el sistema actualiza su estado, envía un email y registra la acción.
Todo está previamente definido.
Ahora: “¿responde de forma suficientemente buena?”
Imaginemos un asistente de atención al cliente basado en IA generativa.
El usuario pregunta:
“Me han cobrado dos veces la cuota de este mes. ¿Qué hago?”
No queremos comprobar que el sistema devuelva exactamente una frase concreta.
Queremos validar cosas como:
¿Identifica correctamente que se trata de un posible cobro duplicado?
¿Da instrucciones correctas?
¿Evita inventarse políticas o plazos?
¿Mantiene un tono adecuado?
¿Deriva el caso a una persona cuando corresponde?
¿No expone datos sensibles?
¿No ejecuta una acción irreversible sin confirmación?
Aquí el test deja de ser únicamente “correcto/incorrecto” y empieza a incluir criterios, umbrales y casos representativos.
A esto se le suele llamar evaluation o evals: pruebas estructuradas para medir cómo se comporta una aplicación basada en modelos generativos, aunque sus respuestas puedan variar.
OpenAI y Anthropic recomiendan partir de criterios de éxito claros y construir conjuntos de casos reales para evaluar la calidad del sistema de forma recurrente.
Cómo cambia cada tipo de testing
1. Unit tests: siguen validando lógica concreta
Los unit tests continúan siendo útiles para validar piezas deterministas:
Que el prompt se construye con las variables correctas.
Que no se incluyen datos personales innecesarios.
Que el sistema limita la longitud del contexto.
Que una respuesta estructurada cumple el formato requerido.
Que una clasificación válida dispara la lógica adecuada.
Por ejemplo:
Si el modelo devuelve
categoria = "cancelacion", el sistema debe mostrar el flujo de cancelación correspondiente.
Aquí no estamos testeando todavía si la IA “razona bien”, sino que nuestra aplicación procese correctamente sus outputs.
2. Integration tests: ahora incluyen modelo, contexto y herramientas
En una feature con IA, no basta con probar el prompt de forma aislada.
La respuesta puede depender de:
El modelo utilizado.
El prompt del sistema.
Los documentos recuperados.
La conversación previa.
Las herramientas disponibles.
Los permisos del usuario.
La lógica que decide cuándo ejecutar una acción.
Por eso, los integration tests adquieren una nueva dimensión.
Por ejemplo, en un asistente de atención al cliente:
Dado un usuario con una factura duplicada, el sistema debe recuperar la política correcta, responder de forma coherente y ofrecer la acción adecuada, sin ejecutar un reembolso automáticamente.
El objetivo ya no es solo comprobar que los sistemas están conectados, sino que la combinación de modelo + contexto + reglas + acciones produce un comportamiento correcto.
3. Regression tests: los prompts también pueden romper producto
Hasta ahora, yo asociaba los regression tests a comprobar que un cambio no rompiera un flujo. Con prompts, la regresión puede ser bastante más silenciosa: todo sigue funcionando, pero la respuesta se vuelve menos clara, más insegura o directamente menos útil.
En IA generativa, algo aparentemente pequeño también puede degradar resultados:
Cambiar una línea del prompt
Cambiar de modelo
Añadir información al contexto
Modificar la forma de recuperar documentos
Ajustar una regla de seguridad
Permitir una nueva herramienta al agente
Quizá el asistente responda mejor en un caso, pero empiece a fallar en otros diez.
Por eso, cada vez que se cambia un prompt o una configuración relevante, deberíamos volver a ejecutar un conjunto estable de casos de prueba:
Preguntas frecuentes
Casos ambiguos
Casos sensibles
Casos que históricamente han fallado
Casos de seguridad
Casos donde la IA debe reconocer que no sabe responder
La diferencia es que una regresión ya no siempre significa que algo “deje de funcionar”. A veces significa que:
La respuesta es menos clara
El tono empeora
Aumentan las alucinaciones
El agente toma más decisiones incorrectas
La tasa de derivación a humanos sube innecesariamente
Las nuevas capas de testing en productos con IA generativa
Además del testing tradicional, aparecen nuevas prácticas:
Golden datasets o baterías de casos reales
Son conjuntos de preguntas o situaciones representativas contra las que evaluamos el sistema.
Por ejemplo, para un asistente de soporte:
“Quiero cambiar mi método de pago”
“No reconozco este cargo”
“Quiero cancelar mi cuenta”
“¿Puedes decirme los datos de otro cliente?”
“Hazme un reembolso directamente”
Cada caso debería incluir qué esperamos del sistema: información correcta, tono adecuado, necesidad de escalado, prohibiciones o acciones permitidas.
Evaluación por criterios, no solo por coincidencia exacta
Una buena respuesta no tiene por qué ser idéntica a otra.
Por eso podemos evaluar dimensiones como:
Exactitud
Relevancia
Claridad
Tono
Cumplimiento de políticas
Seguridad
Capacidad de reconocer incertidumbre
Correcta ejecución (o no ejecución) de acciones
📍 En algunos casos, estos criterios pueden verificarse automáticamente mediante reglas. En otros, mediante evaluación humana o modelos que actúan como evaluadores, siempre con muestras revisadas para asegurar que la evaluación es fiable.
Tests adversariales o de seguridad
Una feature con IA también debe probarse contra inputs problemáticos:
Usuarios que intentan saltarse instrucciones
Peticiones para revelar información confidencial
Consultas ambiguas
Contenido ofensivo
Instrucciones contradictorias
Solicitudes de acciones no autorizadas
📍 No se trata solo de que el asistente responda bien cuando todo es fácil, sino de que falle de forma segura cuando el escenario es delicado.
Testing en producción
En IA generativa, los casos reales siempre sorprenden.
Por eso, además de probar antes de lanzar, es especialmente importante monitorizar:
Qué preguntas no sabe resolver
Qué respuestas reciben feedback negativo
En qué situaciones deriva demasiado o demasiado poco
Cuándo se producen errores factuales
Qué nuevos casos deberían incorporarse al dataset de evaluación
📍 Cada fallo detectado en producción debería convertirse, siempre que sea posible, en un nuevo caso de test para evitar que vuelva a repetirse.
📍 La idea clave: no sustituimos tests, ampliamos qué significa calidad
Construir features con IA generativa no implica abandonar el testing automatizado tradicional.
Al contrario: necesitamos mantenerlo para toda la lógica determinista del producto.
Pero ya no es suficiente.
Cuando una funcionalidad utiliza prompts, modelos generativos o agentes capaces de tomar decisiones, también necesitamos probar:
Qué responde
Cómo responde
Cuándo no debe responder
Qué información utiliza
Qué acciones propone
Qué acciones ejecuta
Y qué ocurre cuando el usuario intenta llevarla fuera de sus límites
El reto no es conseguir que la IA responda siempre exactamente lo mismo.
El reto es conseguir que, aunque responda de formas distintas, se comporte siempre dentro de los estándares de calidad, seguridad y utilidad que el producto necesita.
Y eso convierte las evals en una nueva pieza esencial del desarrollo de producto con IA.
Realmente interesante Sara!!