Testing de aplicaciones con inteligencia artificial

Dos cosas distintas que se confunden

Antes de empezar hay que separar dos temas que comparten las mismas palabras y son opuestos:

Esta guía trata la segunda: tu producto tiene una funcionalidad con un modelo detrás —un asistente, un clasificador, un resumidor, una búsqueda semántica, un detector de fraude— y tenés que decir si funciona.

Curiosamente, el ISTQB también separa las dos: publicó una certificación de Certified Tester AI Testing, cuya versión vigente es la 2.0, para probar sistemas basados en IA, y otra distinta sobre testing con IA generativa. Que el organismo de certificación las trate como temas separados confirma que la distinción no es un detalle.

Qué cambia y qué no

Conviene empezar por lo que no cambia, que es más de lo que suele suponerse. Una aplicación con IA sigue siendo una aplicación: tiene interfaz, autenticación, base de datos, permisos, manejo de errores, rendimiento. Todo eso se prueba exactamente igual que siempre, con las técnicas que están en estrategias para escribir casos de prueba.

Lo que cambia se concentra en un punto y de ahí se deriva el resto: desaparece el resultado esperado único.

En un sistema tradicional, expect(total).toBe(1250) es una aserción perfectamente razonable. Frente a un modelo que redacta la respuesta a un reclamo, no existe el texto correcto: existen cientos de respuestas aceptables y cientos inaceptables. Comparar contra una cadena fija no falla porque el sistema esté mal, falla porque la pregunta estaba mal formulada.

El problema del oráculo

En testing se llama oráculo a la fuente que dice cuál es el resultado correcto. Es lo que hace posible una aserción: sin oráculo no hay contra qué comparar. En una aplicación con IA el oráculo exacto no existe, y la salida —que sí existe— es una decisión de diseño que tenés que tomar vos:

1. Escribí qué hace que una respuesta sea aceptableAntes de automatizar nada. Tres o cuatro condiciones concretas: qué información tiene que incluir, qué no debe afirmar, en qué formato, con qué largo, con qué tono. Esto es un criterio de aceptación, no una respuesta modelo.
2. Separá lo verificable de lo subjetivo«Incluye el número de pedido» se comprueba con una expresión regular. «Suena empático» no. Cuanto más de tu criterio puedas empujar hacia el primer grupo, más barata y más estable va a ser tu evaluación.
3. Elegí cómo puntuar cada condiciónCon una de las cuatro formas de la sección siguiente.
4. Definí el umbral del conjuntoQué proporción de casos tiene que cumplir para considerar que el sistema está bien. Ese umbral es una decisión de producto, no técnica.

Las cuatro formas de evaluar

La documentación de Anthropic sobre evaluaciones empíricas ordena los métodos de puntuación, y el orden importa: van de más objetivo y barato a más flexible y costoso. Conviene bajar por la lista y quedarse en el primero que sirva.

1. Coincidencia exacta

Cuando la respuesta correcta es una de pocas opciones definidas. Es el caso de la clasificación —¿este mensaje es una queja, una consulta o una baja?—, la extracción de datos —¿cuál es el número de factura?— y el enrutamiento. Acá el testing es casi tradicional: hay etiqueta correcta, se compara y se cuenta.

Es el método más subestimado. Muchas funcionalidades que parecen requerir evaluación sofisticada son, en el fondo, una clasificación disfrazada, y conviene mirar si se puede reformular así antes de complicar.

2. Comprobación de propiedades

No comparás la salida con nada: comprobás que cumpla reglas verificables. Es el método que más rinde en aplicaciones generativas y el más ignorado:

// No: "la respuesta tiene que ser exactamente este texto"
// Sí: "la respuesta tiene que cumplir estas propiedades"

expect(() => JSON.parse(salida)).not.toThrow();          // formato válido
expect(salida.split(' ').length).toBeLessThan(120);           // largo acotado
expect(salida).toContain(pedido.numero);                     // dato obligatorio
expect(salida).not.toMatch(REGEX_DOCUMENTO);                // sin datos personales
expect(citasFueraDe(salida, material)).toHaveLength(0);      // no inventa fuentes

Estas aserciones son estables frente al no determinismo: no les importa cómo esté redactada la respuesta, solo si respeta las reglas. Y detectan los fallos que más duelen —formato roto, dato faltante, fuga de información, cita inventada— sin necesidad de ningún juicio.

3. Similitud con una referencia

Comparás contra una respuesta de referencia, pero no palabra por palabra: con una medida de parecido semántico o de solapamiento. Sirve especialmente para probar consistencia: que dos formas de preguntar lo mismo produzcan respuestas equivalentes, incluso con errores de tipeo o preguntas mal redactadas.

Su límite es conocido: puede castigar una respuesta correcta expresada de otro modo. Conviene usarla como señal de tendencia, no como criterio de aprobación por caso.

4. Evaluación por modelo o por personas

Para lo que no se puede reducir a una regla: tono, empatía, utilidad, si la respuesta usó bien el contexto que se le dio. Se puede usar otro modelo como evaluador, con una escala definida, o revisión humana.

Es el método más flexible y el más caro, y trae dos costos que hay que nombrar: consume presupuesto y aporta su propio sesgo, porque un modelo evaluando texto tiene preferencias propias. La práctica sensata es usarlo para una muestra, no para todo el conjunto, y calibrarlo comparando su juicio con el de personas en unos cuantos casos.

Cómo se arma un conjunto de evaluación

Un conjunto de evaluación —lo que en la práctica se llama eval— es un grupo de casos de prueba con su forma de puntuar. Es el equivalente de la suite de regresión, y la documentación de Anthropic da tres principios de diseño que vale seguir al pie de la letra:

• Que sea específico de la tarea. «Diseñá evaluaciones que reflejen la distribución real de tu tarea. Y no te olvides de los casos límite.» Un conjunto de preguntas genéricas no dice nada sobre tu producto.
• Automatizá cuando se pueda. Estructurar las preguntas para permitir puntuación automática: opción múltiple, coincidencia de cadenas, puntuación por código o por modelo.
• Priorizá el volumen sobre la calidad individual. Textualmente: «más preguntas con puntuación automática de señal algo más baja es mejor que menos preguntas con evaluaciones humanas de alta calidad hechas a mano».

El tercero es el más contraintuitivo y el más importante. La razón es estadística: con diez casos, un caso que cambia mueve el resultado diez puntos, y no podés distinguir una mejora real de una casualidad. Con cien casos podés. Y como el objetivo es detectar que algo empeoró, la sensibilidad del instrumento importa más que la perfección de cada medición.

Los casos límite que hay que incluir

Acá es donde un conjunto de evaluación se separa de una demostración. La documentación de Anthropic nombra explícitamente varios, y todos tienen su equivalente en tu producto:

El primero merece una nota, porque es el que más se omite y el que produce los peores incidentes: hay que probar explícitamente qué hace el sistema cuando no sabe. Un modelo que ante una pregunta sin respuesta en su material responde «no tengo esa información» es un sistema muy distinto de uno que completa con algo verosímil, y esa diferencia no aparece en ningún caso feliz.

Más allá de «responde bien»

El NIST enumera las características de una IA confiable, y esa lista funciona bien como recordatorio de las dimensiones que una prueba centrada solo en la corrección deja afuera: válida y fiable, segura, protegida y resiliente, responsable y transparente, explicable e interpretable, con privacidad reforzada, y justa con los sesgos dañinos gestionados. Traducidas a un plan de pruebas concreto:

Seguridad

La inyección de prompts encabeza el Top 10 de OWASP para aplicaciones con LLM en su edición de 2025. Se prueba en sus dos variantes: la directa, donde la entrada de quien usa el sistema busca alterar su comportamiento, y la indirecta, donde el contenido llega de una fuente externa —una página, un archivo, un correo— y es ese contenido el que lo altera. La segunda es la que más aparece en incidentes reales.

Otro riesgo de la lista que es puro trabajo de QA: el manejo inadecuado de la salida. Si tu sistema toma lo que devuelve el modelo y lo ejecuta, lo inserta en una consulta o lo renderiza sin validar, tenés un problema clásico de validación de entradas con un nombre nuevo. Todo esto se prueba sobre tus propios sistemas y con autorización; el marco completo está en fundamentos de hacking ético.

Privacidad

Dos preguntas concretas: qué datos entran al modelo, y si la respuesta puede contener datos que no correspondían. La segunda se prueba con casos diseñados a propósito: pedirle información de otra persona, de otro expediente, de otra cuenta.

Costo y latencia

En una aplicación con IA no son detalles de infraestructura: son requisitos, y se rompen en silencio. Un cambio de prompt que agrega contexto puede duplicar el costo por operación sin que ninguna aserción funcional falle. Conviene medir tokens por operación y tiempo de respuesta como parte de la evaluación, con sus propios umbrales. Para la parte de carga y concurrencia, pruebas de rendimiento con k6 y Grafana.

Cómo se prueba el sesgo

Es la dimensión con la técnica más elegante y la que menos se aplica. La regla base: el sesgo no se ve en el promedio. Un sistema con excelente rendimiento general puede atender sistemáticamente peor a un grupo, y el número agregado lo esconde.

La técnica concreta es una aplicación de la prueba metamórfica: en lugar de conocer la respuesta correcta, verificás una relación que tiene que mantenerse. Construís casos equivalentes que difieren solo en el atributo que te preocupa y comprobás que el resultado no cambia cuando no debería:

// Mismo caso, cambiando solo el nombre. La decisión no debería moverse.
const variantes = nombres.map((nombre) => ({ ...casoBase, nombre }));
const decisiones = await Promise.all(variantes.map(evaluar));

// La relación que se verifica: todas iguales entre sí
expect(new Set(decisiones).size).toBe(1);

Lo valioso de este enfoque es que no necesita saber cuál es la respuesta correcta: solo que sea la misma. Sirve igual para probar otras invariantes: que reordenar dos ítems no cambie el total, que traducir la pregunta no cambie la clasificación, que agregar un espacio no altere el resultado.

Evaluaciones como suite de regresión

Un conjunto de evaluación cumple el papel de la suite de regresión, y conviene tratarlo con la misma disciplina: versionado, ejecutado automáticamente y con un resultado que alguien mira.

Cuándo se ejecuta —y esta lista es específica de la IA—:

• Cada vez que cambia el prompt. Incluida una modificación que parece cosmética: el sistema es sensible al texto exacto.
• Cada vez que cambia el modelo o su versión. Es el caso más importante y el más fácil de pasar por alto, porque el cambio puede venir del proveedor sin que vos toques nada.
• Cada vez que cambia el material que consulta. Si el sistema recupera documentos, cambiar el índice cambia las respuestas.
• Periódicamente, sin cambios propios. Para detectar deriva.

Convivir con el no determinismo

Dos aclaraciones que ahorran tiempo perdido.

Bajar la temperatura ayuda pero no resuelve. La temperatura controla el grado de aleatoriedad de la salida, así que ponerla baja la hace más previsible. Lo que no hace es volverla determinista de forma garantizada: quedan fuentes de variación que no controlás, como los cambios de versión del modelo y las diferencias de infraestructura. Construir aserciones exactas sobre texto generado apoyándose en la temperatura es armar una suite frágil.

La variación esperada no es inestabilidad. Y esta distinción es crítica para no confundir dos problemas distintos:

La segunda columna es un tema completo por sí mismo y está en cómo detectar y solucionar flaky tests. La primera se arregla acá, cambiando la aserción.

Errores frecuentes

• Comparar texto generado con una cadena fija. El error de base. Produce una suite que falla todo el tiempo sin que nada esté roto.
• Evaluar con diez casos. Demasiado pocos para distinguir una mejora de una casualidad.
• Armar la evaluación solo con casos felices. Los fallos caros aparecen en la entrada rara, no en la típica.
• No probar qué hace cuando no sabe. Es el comportamiento que más impacto tiene y el que menos se prueba.
• Mirar solo el promedio. Esconde exactamente el problema que más consecuencias trae.
• Cambiar los casos y el umbral juntos. Perdés la comparación con la línea base, que era todo el valor de la medición.
• Olvidar costo y latencia. Se degradan sin que ninguna aserción funcional se queje.
• Usar un modelo evaluador sin calibrarlo. Trae su propio sesgo, y sin comparar contra juicio humano en algunos casos no sabés en qué dirección.

Preguntas frecuentes

Fuentes

Documentación oficial, marcos de referencia y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

Aportes de la comunidad Underc0de

1. Underc0de, foro. Funcionalidades de IA aplicables al testing (2025), por nagitarami, sección QA y Testing, 25 de abril de 2025.
2. Underc0de, foro. Testim: automatización de pruebas con inteligencia artificial, por Auri_gg, 19 de febrero de 2025.
3. Underc0de, foro. Herramientas basadas en inteligencia artificial, sección QA y Testing, 26 de junio de 2024.

Documentación oficial y marcos

4. Anthropic. Create strong empirical evaluations. Los tres principios de diseño de evaluaciones, los métodos de puntuación y la lista de casos límite, citados textualmente.
5. OWASP. Top 10 for LLM Applications 2025. Inyección de prompts en el primer puesto y manejo inadecuado de la salida.
6. OWASP. LLM01:2025 Prompt Injection. Distinción entre inyección directa e indirecta.
7. NIST. AI Risks and Trustworthiness. Las siete características de una IA confiable, usadas como lista de dimensiones a cubrir.
8. ISTQB. Certified Tester AI Testing (CT-AI) versión 2.0. Certificación específica sobre pruebas de sistemas basados en IA.
9. Google. Machine Learning Glossary. Definiciones de temperatura y alucinación.